[{"data":1,"prerenderedAt":499},["Reactive",2],{"blog-/blog/news/hardfork-six":3,"blog-posts-/blog/news/hardfork-six":302},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":8,"description":9,"date":10,"category":5,"tags":11,"body":14,"_type":297,"_id":298,"_source":299,"_file":300,"_extension":301},"/blog/news/hardfork-six","news",false,"","Hard Fork Six","Beam completed an emergency hard fork to patch a subtle Bulletproofs rangeproof vulnerability that eluded multiple professional audits and AI reviews. Read the technical breakdown, our risk assessment, and the proposed lustration process for verifying supply integrity.","2026-07-01",[12,13],"Hard Fork","Emergency",{"type":15,"children":16,"toc":289},"root",[17,26,32,37,71,77,82,87,114,132,137,142,177,182,187,193,198,203,233,239,244,249,254,259,264,270,284],{"type":18,"tag":19,"props":20,"children":22},"element","h2",{"id":21},"context",[23],{"type":24,"value":25},"text","Context",{"type":18,"tag":27,"props":28,"children":29},"p",{},[30],{"type":24,"value":31},"The Beam developers were contacted on June 13th 2026 with a report about a possible vulnerability in Beam core code. As the former Beam team still proposes bounties for serious vulnerabilities, many such reports have been received lately, most of them being AI slop without any real interest. However, after careful examination and testing during the next few days, that one report proved to indeed identify a well hidden, but real and important vulnerability.",{"type":18,"tag":27,"props":33,"children":34},{},[35],{"type":24,"value":36},"With the deep analysis done and the problem well identified, the core code was corrected in a non-public branch, and direct contact was made with the main mining pools and exchanges to ask them to upgrade to the new version, so that any further risk of exploitation of this vulnerability would be eliminated. The hard fork took place at block 3928666.",{"type":18,"tag":27,"props":38,"children":39},{},[40,42,51,53,60,62,69],{"type":24,"value":41},"The latest corrected builds (wallets, nodes, etc.) can be downloaded from ",{"type":18,"tag":43,"props":44,"children":48},"a",{"href":45,"rel":46},"https://beam.mw/downloads",[47],"nofollow",[49],{"type":24,"value":50},"beam.mw/downloads",{"type":24,"value":52}," or from ",{"type":18,"tag":43,"props":54,"children":57},{"href":55,"rel":56},"https://github.com/BeamMW/beam/releases",[47],[58],{"type":24,"value":59},"github.com/BeamMW/beam/releases",{"type":24,"value":61}," and ",{"type":18,"tag":43,"props":63,"children":66},{"href":64,"rel":65},"https://github.com/BeamMW/beam-ui/releases",[47],[67],{"type":24,"value":68},"github.com/BeamMW/beam-ui/releases",{"type":24,"value":70},".",{"type":18,"tag":19,"props":72,"children":74},{"id":73},"technical-details",[75],{"type":24,"value":76},"Technical details",{"type":18,"tag":27,"props":78,"children":79},{},[80],{"type":24,"value":81},"The discovered vulnerability was in Beam’s implementation of Bulletproofs, a popular variant of rangeproofs with exponential compression (excellent for scalability). A rangeproof is the zero-knowledge cryptographic scheme which proves that the transaction output (TXO) is a well-formed Pedersen commitment, and holds a non-negative amount.",{"type":18,"tag":27,"props":83,"children":84},{},[85],{"type":24,"value":86},"While the algebra behind Beam’s implementation was correct, there was an error in the transcript, i.e. in the order of challenge-response sequence for the challenges derived via the Fiat-Shamir heuristic. Specifically, the error was in the IPA (inner-product argument) part where the order of challenge-response was inverted: the sequence where the prover gets the challenge and then emits the LR pair should happen the other way around.",{"type":18,"tag":27,"props":88,"children":89},{},[90,92,104,106,112],{"type":24,"value":91},"In ",{"type":18,"tag":43,"props":93,"children":96},{"href":94,"rel":95},"https://github.com/BeamMW/beam/blob/ebc40098938197bea689b853a7f51fb507c843d5/core/ecc_bulletproof.cpp#L453",[47],[97],{"type":18,"tag":98,"props":99,"children":101},"code",{"className":100},[],[102],{"type":24,"value":103},"ecc_bulletproof.cpp#L453",{"type":24,"value":105},", ",{"type":18,"tag":98,"props":107,"children":109},{"className":108},[],[110],{"type":24,"value":111},"CycleStart()",{"type":24,"value":113}," is where challenges are obtained.",{"type":18,"tag":27,"props":115,"children":116},{},[117,119,130],{"type":24,"value":118},"And ",{"type":18,"tag":43,"props":120,"children":123},{"href":121,"rel":122},"https://github.com/BeamMW/beam/blob/ebc40098938197bea689b853a7f51fb507c843d5/core/ecc_bulletproof.cpp#L463",[47],[124],{"type":18,"tag":98,"props":125,"children":127},{"className":126},[],[128],{"type":24,"value":129},"ecc_bulletproof.cpp#L463",{"type":24,"value":131}," is where the extracted LR are exposed.",{"type":18,"tag":27,"props":133,"children":134},{},[135],{"type":24,"value":136},"As a result, after the very last challenge, the prover emits the last LR pair, plus the two \"folded\" scalars. Meaning that the LR, the EC points (group elements), are not pinned by the challenge, and could thus be modified a-posteriori to satisfy the equation. This is a serious vulnerability, as it could -in theory- be used to forge a TXO that holds a negative amount. This in turn allows to create a balanced transaction where another TXO is minted from thin air with the appropriate positive amount.",{"type":18,"tag":27,"props":138,"children":139},{},[140],{"type":24,"value":141},"This was a very difficult vulnerability to discover, and it is worth noting that before the release of its mainnet in 2019, Beam code underwent security audits by several companies, which did not identify it:",{"type":18,"tag":143,"props":144,"children":145},"ul",{},[146,157,167],{"type":18,"tag":147,"props":148,"children":149},"li",{},[150],{"type":18,"tag":43,"props":151,"children":154},{"href":152,"rel":153},"https://kudelskisecurity.com",[47],[155],{"type":24,"value":156},"Kudelski",{"type":18,"tag":147,"props":158,"children":159},{},[160],{"type":18,"tag":43,"props":161,"children":164},{"href":162,"rel":163},"https://leastauthority.com",[47],[165],{"type":24,"value":166},"Least Authority",{"type":18,"tag":147,"props":168,"children":169},{},[170],{"type":18,"tag":43,"props":171,"children":174},{"href":172,"rel":173},"https://pessimistic.io",[47],[175],{"type":24,"value":176},"SmartDec (now Pessimistic)",{"type":18,"tag":27,"props":178,"children":179},{},[180],{"type":24,"value":181},"More recently, with the rise of AI, several AI agents were used to scan the Beam codebase for security vulnerabilities. Both Claude Opus 4.8 and ChatGPT Codex were used, and neither found anything serious over multiple runs.",{"type":18,"tag":27,"props":183,"children":184},{},[185],{"type":24,"value":186},"Moreover, after the above vulnerability was discovered, these AI agents were asked to revisit and review the bulletproof implementation specifically. And, again, they didn't find any problem with it.",{"type":18,"tag":19,"props":188,"children":190},{"id":189},"our-assessment-at-the-moment",[191],{"type":24,"value":192},"Our assessment at the moment",{"type":18,"tag":27,"props":194,"children":195},{},[196],{"type":24,"value":197},"The Beam developers consider that the probability of this vulnerability having been exploited is low.",{"type":18,"tag":27,"props":199,"children":200},{},[201],{"type":24,"value":202},"Several aspects lead to this assessment:",{"type":18,"tag":204,"props":205,"children":206},"ol",{},[207,212,217,222],{"type":18,"tag":147,"props":208,"children":209},{},[210],{"type":24,"value":211},"The vulnerability is not obvious at all. Neither for the Beam developers, nor for the security audit companies. Modern AI agents also fail to discover it, even when asked specifically to review the Bulletproofs code. This was definitely not a \"low-hanging fruit\" discoverable by anyone with access to an AI agent. The person who found it made the discovery by manually analyzing the code, and specifically by checking the transcript.",{"type":18,"tag":147,"props":213,"children":214},{},[215],{"type":24,"value":216},"The current low market cap of Beam makes exploiting it not justified economically. Receiving a bounty for the vulnerability disclosure makes far more sense than taking the risk of exploiting the Beam blockchain.",{"type":18,"tag":147,"props":218,"children":219},{},[220],{"type":24,"value":221},"If done naively (for instance by asking an AI to create a working proof of concept, and then try using it) such an attack could leave a pattern that can be recognized. After the vulnerability was reported, the entire blockchain history was scanned, and no such pattern was identified.",{"type":18,"tag":147,"props":223,"children":224},{},[225,227,231],{"type":24,"value":226},"We are aware that there was a harsh Beam coin price decline recently. We analyzed the public trading data: trading volumes, possible price discrepancies between exchanges, unusual activities, etc. We believe there is no evidence that suggests a hidden inflation exploitation.\nPrior to the price drop, the first anomaly we see is the sudden trade volume drop on MEXC (used to be the biggest exchange for Beam) on June 12th 2026. We don’t know the exact reason for this, probably a Market Maker was deactivated. Immediately after this, the Beam price started declining. Then, during the following days, there was a surge in the Beam trade volume on the NonKYC exchange. But this surge (1) albeit high for this exchange, still was much lower than normal daily volume on MEXC before the drop, (2) lasted for some period, then stopped on June 29th 2026.",{"type":18,"tag":228,"props":229,"children":230},"br",{},[],{"type":24,"value":232},"If the Beam price decline would’ve been due to hidden inflation, we’d expect to see an overall increase in market volume, not decline. The spike in trading volume on NonKYC probably indicates big holders (whales) anonymously cashing-out.",{"type":18,"tag":19,"props":234,"children":236},{"id":235},"the-next-steps",[237],{"type":24,"value":238},"The next steps",{"type":18,"tag":27,"props":240,"children":241},{},[242],{"type":24,"value":243},"As said above, Beam developers consider at the moment that the probability of this vulnerability having been exploited is low. However, we cannot be 100% sure. There is objectively no guaranteed way -today- to ensure the exploit did not take place.",{"type":18,"tag":27,"props":245,"children":246},{},[247],{"type":24,"value":248},"One considered option to confirm it didn’t, is the implementation of a \"lustration\" process, which would allow verifying the supply integrity at a given moment. Within this process, every unspent output of a past transaction (both Mimblewimble and Lelantus) would have to be disclosed upon its first use. Its amount and its asset type will be disclosed, but its owner would remain concealed. This disclosure would happen only once, and further transactions would then go back to the normal privacy of the Mimblewimble and Lelantus protocols.",{"type":18,"tag":27,"props":250,"children":251},{},[252],{"type":24,"value":253},"Each node would keep track of the total disclosed amount for each asset type. And since the total supply of any asset type is not secret and can be calculated, this lustration process would allow demonstrating that the overall circulating amount doesn't exceed the expected maximum. Attempts to violate this would be prevented and flagged.",{"type":18,"tag":27,"props":255,"children":256},{},[257],{"type":24,"value":258},"Such a process would provide a cryptographic guarantee of supply integrity, at the cost of a one-time, limited disclosure of legacy outputs. It is a trade-off between absolute assurance and the strongest possible privacy guarantees.",{"type":18,"tag":27,"props":260,"children":261},{},[262],{"type":24,"value":263},"If and when the community chooses to do this, an additional network upgrade will be needed. Technically, such a lustration process will be seamless to the users, as the wallet would automatically attach the corresponding cryptographic proof for each legacy output being spent (which could be done by simply sending the assets to oneself).",{"type":18,"tag":19,"props":265,"children":267},{"id":266},"conclusion",[268],{"type":24,"value":269},"Conclusion",{"type":18,"tag":27,"props":271,"children":272},{},[273,275,282],{"type":24,"value":274},"The Beam developers would like to thank ",{"type":18,"tag":43,"props":276,"children":279},{"href":277,"rel":278},"https://x.com/MonclairTrades",[47],[280],{"type":24,"value":281},"MonclairTrades",{"type":24,"value":283}," for the responsible disclosure of this vulnerability.",{"type":18,"tag":27,"props":285,"children":286},{},[287],{"type":24,"value":288},"This discovery underscores the enduring value of careful cryptographic review, which allowed identifying such a subtle flaw that eluded multiple professional audits as well as state-of-the-art AI agents. The strength of Beam’s privacy guarantees depends on the robustness of its underlying cryptography, and that robustness is, in the end, upheld by the vigilance of the people who read and challenge the code.",{"title":7,"searchDepth":290,"depth":290,"links":291},2,[292,293,294,295,296],{"id":21,"depth":290,"text":25},{"id":73,"depth":290,"text":76},{"id":189,"depth":290,"text":192},{"id":235,"depth":290,"text":238},{"id":266,"depth":290,"text":269},"markdown","content:blog:news:hardfork-six.md","content","blog/news/hardfork-six.md","md",[303,374,449],{"_path":304,"_dir":305,"_draft":6,"_partial":6,"_locale":7,"title":306,"description":307,"date":308,"category":305,"tags":309,"body":315,"_type":297,"_id":372,"_source":299,"_file":373,"_extension":301},"/blog/updates/beam-warp-dev-2","updates","Beam Warp Development Update #2: Testing and Benchmarking","Benchmarking the warp_dev3 devnet shows ~1.8s average transaction times, alongside dynamic tip trimming, multisig bridge ceremonies, and a fully operational dPoS contract.","2026-04-08",[310,311,312,313,314],"Beam Warp","Sidechain","dPoS","Benchmarking","Development",{"type":15,"children":316,"toc":370},[317,322,331,339,344,352,357,365],{"type":18,"tag":27,"props":318,"children":319},{},[320],{"type":24,"value":321},"We are thrilled to share the latest progress on Beam Warp, the super-fast sidechain designed for sub-second transactions, over 1000 TPS, and instant finality. Following the innovative dPoS (delegated Proof of Stake) integration, the developers have been testing and refining the sidechain architecture.\nPerformance Benchmarking\nTesting on the warp_dev3 network has yielded impressive results. With a constant 3-second block time, the average transaction time (as experienced by the user) is approximately 1.8 seconds, with values varying from 400 ms up to 3600 ms.",{"type":18,"tag":27,"props":323,"children":324},{},[325],{"type":18,"tag":326,"props":327,"children":330},"img",{"alt":328,"src":329},"Transaction duration over time","/images/blog/updates/beam-warp-dev-2/tx-duration-timeseries.png",[],{"type":18,"tag":27,"props":332,"children":333},{},[334],{"type":18,"tag":326,"props":335,"children":338},{"alt":336,"src":337},"Transaction duration histogram","/images/blog/updates/beam-warp-dev-2/tx-duration-histogram.png",[],{"type":18,"tag":27,"props":340,"children":341},{},[342],{"type":24,"value":343},"In fact, the perceived duration mostly depends on when the transaction is submitted within the block's time window. If it’s early, it will have to wait until the end of the 3-second window. If it’s late, it will appear as completed much faster. And if it’s too late, it might have to be left for the following block (then leading to a perceived duration longer than 3 seconds).",{"type":18,"tag":27,"props":345,"children":346},{},[347],{"type":18,"tag":326,"props":348,"children":351},{"alt":349,"src":350},"Perceived transaction times relative to block windows","/images/blog/updates/beam-warp-dev-2/perceived-tx-times.png",[],{"type":18,"tag":27,"props":353,"children":354},{},[355],{"type":24,"value":356},"Nonetheless, submitting transactions at random moments shows that around 5% of them complete in under 550ms (with the fastest recorded at just 180ms!). This confirms that the underlying network logic is incredibly efficient and it validates that the target of 1-second block times is technically achievable.\nBeam Warp’s Dandelion protocol was also optimized for speed. The wait time used in Beam’s mainchain to allow potential coin joins during the \"stem\" phase was removed, allowing decoy outputs to be added immediately without delaying consensus.\nBlockchain Size Optimization\nThe devnet also verified blockchain storage efficiency, even though a new block is created every few seconds. This is achieved through an innovative feature called \"dynamic tip trimming\" which automatically prunes away empty blocks. Consequently, the ledger's footprint remains lightweight, as in Beam mainchain.\nFurthermore, the lead dev also optimized the fee distribution process. Previously, every non-empty block required an AddReward call to the dPoS smart contract. This has been removed, the node now directly updating the contract state to distribute fees. This reduces redundant processing and cleans up blockchain data without sacrificing transparency, as reward distribution remains visible in the explorer.\nBridging and Security\nTesting of the two-way bridge between the devnet mainchain (dappnet2) and sidechain (warp_dev3) continues to be successful. A sophisticated development to secure this bridge now involves \"multisig ceremonies\". After block finalization, validators merge their signatures into one single constant-sized signature, accompanied by a bitmask. This not only significantly reduces block header bloat (one single signature instead of dozens) but also allows the mainchain side of the bridge smart contract to efficiently track changes in the sidechain validator set.\nAnother key security decision was made regarding non-validator nodes. To keep the network efficient and lightweight, only validators are now required to monitor the mainchain for bridge validity. Non-validator nodes skip this verification during transaction propagation, relying instead on the validators' signed blocks. This prevents a single misconfigured node from stalling the network.\nAdditionally, validators can configure a bridge_height_delay parameter to protect against potential mainchain reorgs.\nDelegated Proof of Stake Parameters\nThe core economic engine of Beam’s sidechains is fully operational. The PBFT_DPOS smart contract manages the lifecycle of validators and delegators:\nDynamic Validator Sets: The network currently supports up to 96 active validators (this number could be increased at a modest cost). New validators can register by staking a minimum amount of coins (to be defined), while existing validators can be jailed or slashed for misbehavior.\nStake Delegation: Users can delegate their stake to validators via the same smart contract and earn a share of transaction fees, calculated proportionally to their stake minus the validator's commission.\nCommissions: Validators can set a commission fee on delegator rewards (e.g. 5%). And users can be protected by configuring the contract so that commission can only be reduced, not increased.\nReward Distribution: For each block, fees are distributed among non-jailed validators. However, the process is optimized to compute effective rewards only when a validator or delegator state changes, rather than for each and every block.\nLastly, the explorer has been updated to visualize this data, displaying each validator's status, voting power (stake), commission, and accumulated rewards.",{"type":18,"tag":27,"props":358,"children":359},{},[360],{"type":18,"tag":326,"props":361,"children":364},{"alt":362,"src":363},"Explorer view of the PBFT_DPOS contract state","/images/blog/updates/beam-warp-dev-2/explorer-validators.png",[],{"type":18,"tag":27,"props":366,"children":367},{},[368],{"type":24,"value":369},"Looking Ahead\nThe devs are discussing the optimal parameters for the next devnet, specifically the minimum stake, and the target number of validators to balance decentralization with speed. Preliminary analysis suggests a minimum stake of ~150,000 BEAMX could support up to 100 validators while maintaining performance.\nWith the Beam Warp implementation feature-complete and already showing exceptional speed, further testing and optimization now continue in areas like SBBS communications and wallet data management.\nMore news to come as we approach the next milestone!",{"title":7,"searchDepth":290,"depth":290,"links":371},[],"content:blog:updates:beam-warp-dev-2.md","blog/updates/beam-warp-dev-2.md",{"_path":375,"_dir":305,"_draft":6,"_partial":6,"_locale":7,"title":376,"description":377,"date":378,"category":305,"tags":379,"body":380,"_type":297,"_id":447,"_source":299,"_file":448,"_extension":301},"/blog/updates/beam-warp-dev-1","Beam Warp Development Update #1: An innovative dPoS implementation","Beam Warp integrates full dPoS logic with staking, bonding, and rewards handled in a smart contract, anchored to the Beam mainchain via a secure two-way bridge.","2026-02-12",[310,311,312,314],{"type":15,"children":381,"toc":445},[382,387,392,397,402,407,412,425,430,435,440],{"type":18,"tag":27,"props":383,"children":384},{},[385],{"type":24,"value":386},"We are excited to announce a major milestone for Beam Warp, our super-fast PoS sidechain designed for sub-second transactions (>1000 transactions-per-second) and instant finality.",{"type":18,"tag":27,"props":388,"children":389},{},[390],{"type":24,"value":391},"Following the initial pBFT (practical Byzantine Fault Tolerance) devnet, the lead dev has completed a significant refactor, successfully integrating the full dPoS (delegated Proof of Stake) logic.",{"type":18,"tag":27,"props":393,"children":394},{},[395],{"type":24,"value":396},"A key architectural decision moved the dPoS management logic (staking, bonding, rewards, commissions) into a smart contract rather than the native node code. This streamlines the node for optimal performance (handling only consensus communication natively), while allowing delegators to manage stakes directly via a standard dApp. The system remains transparent (staking weights are visible in explorers) while preserving users’ privacy.",{"type":18,"tag":27,"props":398,"children":399},{},[400],{"type":24,"value":401},"Beam Warp will use BEAM for transaction fees and BEAMX for staking. Users stake $BEAMX through validators to earn a share of the sidechain $BEAM fees. Users may also register and become a validator themselves by locking a minimum $BEAMX amount (TBD). Both $BEAM and $BEAMX are bridged from the mainchain, creating a robust link between both chains. The bridge is managed by smart contracts and secured by the sidechain validators, who monitor and sign transactions on both chains.",{"type":18,"tag":27,"props":403,"children":404},{},[405],{"type":24,"value":406},"This ensures the sidechain is anchored by the mainchain’s Proof-of-Work (PoW) security. Conversely, using $BEAM and $BEAMX on the sidechain brings value back to the mainchain rather than competing with it.",{"type":18,"tag":27,"props":408,"children":409},{},[410],{"type":24,"value":411},"The bridge design ensures security without altering the mainchain. In the backend, the process looks like:",{"type":18,"tag":204,"props":413,"children":414},{},[415,420],{"type":18,"tag":147,"props":416,"children":417},{},[418],{"type":24,"value":419},"From mainchain to sidechain: Funds are locked on the mainchain, then mirrored assets are minted on the siedchain upon validator approval (and the bridged assets conveniently keep the same token id!).",{"type":18,"tag":147,"props":421,"children":422},{},[423],{"type":24,"value":424},"From sidechain back to mainchain: Assets are burned on the sidechain, then unlocked on the mainchain via a transaction signed by a quorum of sidechain validators (multisig via SBBS).",{"type":18,"tag":27,"props":426,"children":427},{},[428],{"type":24,"value":429},"In super simple words, Think of the two blockchains (Beam and Beam Warp), as two seamlessly connected ledgers. When a token amount moves from one ledger (Beam) to the other ledger (Beam Warp), the token amount is frozen on the main ledger and minted on the second ledger. Then when it is time for the token amount to move back to the first ledger, it is burned on the second ledger (Beam Warp) and unfrozen on the first ledger (Beam).\nThis automatic mechanism ensures there is no double-spend and all tokens are accounted for. The true beauty of the untamperable blockchain technology. All of this happens in the backend. In the mainend, users can enjoy significantly faster transaction speeds and developers may build new dApps with cutting-edge tx speed in a private-by-default environment.",{"type":18,"tag":27,"props":431,"children":432},{},[433],{"type":24,"value":434},"The smart contract architecture of Beam Warp will also allow anyone to fork the code to permisionlessly launch their own custom private sidechain on Beam!",{"type":18,"tag":27,"props":436,"children":437},{},[438],{"type":24,"value":439},"With the dPoS implementation now feature-complete (including dynamic validator sets, slashing, and jailing) the dappnet2 and test2 devnet have been redeployed. The team is currently testing speed and throughput, bringing the vision of a scalable, private, and ultra-fast sidechain closer to reality!",{"type":18,"tag":27,"props":441,"children":442},{},[443],{"type":24,"value":444},"More news to come as tests and development move forward!",{"title":7,"searchDepth":290,"depth":290,"links":446},[],"content:blog:updates:beam-warp-dev-1.md","blog/updates/beam-warp-dev-1.md",{"_path":450,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"title":451,"description":452,"date":453,"category":5,"image":454,"tags":455,"body":459,"_type":297,"_id":497,"_source":299,"_file":498,"_extension":301},"/blog/news/welcome-to-beam-blog","Welcome to the Beam Blog!","Discover the latest updates, news, and insights from the Beam ecosystem.","2025-06-18","svg/logo.svg",[456,457,458],"Announcement","Updates","Beam",{"type":15,"children":460,"toc":495},[461,466],{"type":18,"tag":27,"props":462,"children":463},{},[464],{"type":24,"value":465},"This is the new Beam blog. Expect release notes, technical write-ups, and notes from the community — posted when there's something worth saying.",{"type":18,"tag":27,"props":467,"children":468},{},[469,471,478,479,485,487,494],{"type":24,"value":470},"If you're new here, ",{"type":18,"tag":43,"props":472,"children":475},{"href":473,"rel":474},"https://beam.mw/downloads/",[47],[476],{"type":24,"value":477},"download the wallet",{"type":24,"value":105},{"type":18,"tag":43,"props":480,"children":482},{"href":481},"/docs",[483],{"type":24,"value":484},"read the docs",{"type":24,"value":486},", or come say hi on ",{"type":18,"tag":43,"props":488,"children":491},{"href":489,"rel":490},"https://t.me/BeamPrivacy",[47],[492],{"type":24,"value":493},"Telegram",{"type":24,"value":70},{"title":7,"searchDepth":290,"depth":290,"links":496},[],"content:blog:news:welcome-to-beam-blog.md","blog/news/welcome-to-beam-blog.md",1782918205224]