[{"data":1,"prerenderedAt":217},["Reactive",2],{"blog-all-posts":3},[4,85,162],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"date":11,"category":6,"tags":12,"body":18,"_type":80,"_id":81,"_source":82,"_file":83,"_extension":84},"/blog/updates/beam-warp-dev-2","updates",false,"","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",[13,14,15,16,17],"Beam Warp","Sidechain","dPoS","Benchmarking","Development",{"type":19,"children":20,"toc":77},"root",[21,29,38,46,51,59,64,72],{"type":22,"tag":23,"props":24,"children":25},"element","p",{},[26],{"type":27,"value":28},"text","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":22,"tag":23,"props":30,"children":31},{},[32],{"type":22,"tag":33,"props":34,"children":37},"img",{"alt":35,"src":36},"Transaction duration over time","/images/blog/updates/beam-warp-dev-2/tx-duration-timeseries.png",[],{"type":22,"tag":23,"props":39,"children":40},{},[41],{"type":22,"tag":33,"props":42,"children":45},{"alt":43,"src":44},"Transaction duration histogram","/images/blog/updates/beam-warp-dev-2/tx-duration-histogram.png",[],{"type":22,"tag":23,"props":47,"children":48},{},[49],{"type":27,"value":50},"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":22,"tag":23,"props":52,"children":53},{},[54],{"type":22,"tag":33,"props":55,"children":58},{"alt":56,"src":57},"Perceived transaction times relative to block windows","/images/blog/updates/beam-warp-dev-2/perceived-tx-times.png",[],{"type":22,"tag":23,"props":60,"children":61},{},[62],{"type":27,"value":63},"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":22,"tag":23,"props":65,"children":66},{},[67],{"type":22,"tag":33,"props":68,"children":71},{"alt":69,"src":70},"Explorer view of the PBFT_DPOS contract state","/images/blog/updates/beam-warp-dev-2/explorer-validators.png",[],{"type":22,"tag":23,"props":73,"children":74},{},[75],{"type":27,"value":76},"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":8,"searchDepth":78,"depth":78,"links":79},2,[],"markdown","content:blog:updates:beam-warp-dev-2.md","content","blog/updates/beam-warp-dev-2.md","md",{"_path":86,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":87,"description":88,"date":89,"category":6,"tags":90,"body":91,"_type":80,"_id":160,"_source":82,"_file":161,"_extension":84},"/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",[13,14,15,17],{"type":19,"children":92,"toc":158},[93,98,103,108,113,118,123,138,143,148,153],{"type":22,"tag":23,"props":94,"children":95},{},[96],{"type":27,"value":97},"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":22,"tag":23,"props":99,"children":100},{},[101],{"type":27,"value":102},"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":22,"tag":23,"props":104,"children":105},{},[106],{"type":27,"value":107},"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":22,"tag":23,"props":109,"children":110},{},[111],{"type":27,"value":112},"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":22,"tag":23,"props":114,"children":115},{},[116],{"type":27,"value":117},"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":22,"tag":23,"props":119,"children":120},{},[121],{"type":27,"value":122},"The bridge design ensures security without altering the mainchain. In the backend, the process looks like:",{"type":22,"tag":124,"props":125,"children":126},"ol",{},[127,133],{"type":22,"tag":128,"props":129,"children":130},"li",{},[131],{"type":27,"value":132},"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":22,"tag":128,"props":134,"children":135},{},[136],{"type":27,"value":137},"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":22,"tag":23,"props":139,"children":140},{},[141],{"type":27,"value":142},"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":22,"tag":23,"props":144,"children":145},{},[146],{"type":27,"value":147},"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":22,"tag":23,"props":149,"children":150},{},[151],{"type":27,"value":152},"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":22,"tag":23,"props":154,"children":155},{},[156],{"type":27,"value":157},"More news to come as tests and development move forward!",{"title":8,"searchDepth":78,"depth":78,"links":159},[],"content:blog:updates:beam-warp-dev-1.md","blog/updates/beam-warp-dev-1.md",{"_path":163,"_dir":164,"_draft":7,"_partial":7,"_locale":8,"title":165,"description":166,"date":167,"category":164,"image":168,"tags":169,"body":173,"_type":80,"_id":215,"_source":82,"_file":216,"_extension":84},"/blog/news/welcome-to-beam-blog","news","Welcome to the Beam Blog!","Discover the latest updates, news, and insights from the Beam ecosystem.","2025-06-18","svg/logo.svg",[170,171,172],"Announcement","Updates","Beam",{"type":19,"children":174,"toc":213},[175,180],{"type":22,"tag":23,"props":176,"children":177},{},[178],{"type":27,"value":179},"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":22,"tag":23,"props":181,"children":182},{},[183,185,194,196,202,204,211],{"type":27,"value":184},"If you're new here, ",{"type":22,"tag":186,"props":187,"children":191},"a",{"href":188,"rel":189},"https://beam.mw/downloads/",[190],"nofollow",[192],{"type":27,"value":193},"download the wallet",{"type":27,"value":195},", ",{"type":22,"tag":186,"props":197,"children":199},{"href":198},"/docs",[200],{"type":27,"value":201},"read the docs",{"type":27,"value":203},", or come say hi on ",{"type":22,"tag":186,"props":205,"children":208},{"href":206,"rel":207},"https://t.me/BeamPrivacy",[190],[209],{"type":27,"value":210},"Telegram",{"type":27,"value":212},".",{"title":8,"searchDepth":78,"depth":78,"links":214},[],"content:blog:news:welcome-to-beam-blog.md","blog/news/welcome-to-beam-blog.md",1777633173599]