[{"data":1,"prerenderedAt":1154},["ShallowReactive",2],{"blog-\u002Fblog\u002Fnews\u002Flustration-proposal":3,"blog-posts-\u002Fblog\u002Fnews\u002Flustration-proposal":831},{"id":4,"title":5,"body":6,"category":815,"date":816,"description":817,"extension":818,"image":819,"meta":820,"navigation":821,"path":822,"seo":823,"stem":824,"tags":825,"__hash__":830},"blog\u002Fblog\u002Fnews\u002Flustration-proposal.md","Lustration Proposal: Verifying Beam's Supply Integrity",{"type":7,"value":8,"toc":789},"minimark",[9,14,26,29,37,44,48,55,58,61,65,71,78,81,96,100,103,118,130,138,155,158,174,177,194,201,205,208,261,264,272,276,279,284,289,294,311,316,333,342,357,361,368,371,375,382,392,395,399,402,417,421,427,430,437,443,446,457,460,463,466,469,473,476,479,484,487,495,499,502,517,520,550,553,556,560,563,580,584,587,592,649,653,719,723,726,740,744,747,751,754,761,766,769,772,776,779,784],[10,11,13],"h2",{"id":12},"context","Context",[15,16,17,18,25],"p",{},"On June 13, 2026, a subtle vulnerability was discovered in Beam's Bulletproofs implementation. The issue was confirmed, patched in a private branch, and an emergency hard fork (HF6) was deployed at block 3928666. The full technical details of the vulnerability and the fix are described in the ",[19,20,24],"a",{"href":21,"rel":22},"https:\u002F\u002Fbeam.mw\u002Fblog\u002Fnews\u002Fhardfork-six",[23],"nofollow","Hard Fork 6 announcement",".",[15,27,28],{},"The vulnerability is now closed and cannot be exploited going forward. However, due to Beam's privacy-preserving design, we cannot simply inspect the blockchain to confirm whether the vulnerability was ever exploited before the fix. On transparent chains like Bitcoin or Ethereum, any unauthorized supply creation would be immediately visible. On a privacy chain, amounts are concealed, so past soundness problems cannot be retroactively verified by simply reading the ledger.",[15,30,31,32,36],{},"The Beam developers assess the probability of exploitation of the vulnerability as ",[33,34,35],"em",{},"low",", for the reasons outlined in the previous post. But \"low probability\" is not \"certainty\", and that is an inherent trade-off privacy coins live with.",[15,38,39,40,43],{},"A process called ",[33,41,42],{},"\"lustration\""," is a proposed mechanism to close that gap and increase certainty.",[10,45,47],{"id":46},"privacy-vs-verifiable-supply","Privacy vs Verifiable supply",[15,49,50,51,54],{},"The fundamental purpose of any blockchain is to prevent unauthorized supply creation (the double-spend problem). Without that guarantee, the entire system loses its meaning. On transparent chains, this guarantee is maintained continuously and publicly. On privacy chains, it is maintained ",[33,52,53],{},"cryptographically",". And cryptography can have flaws and bugs.",[15,56,57],{},"This is not a problem unique to Beam. Every privacy coin faces the same reality: if a soundness bug ever existed, there is no way to look back at the chain and confirm it wasn't exploited.",[15,59,60],{},"The lustration process is one way to provide that confirmation, at the cost of a one-time, limited reduction in privacy.",[10,62,64],{"id":63},"what-is-lustration","What is lustration?",[15,66,67,68,70],{},"The term ",[33,69,42],{}," refers to a purification rite, a ceremony to restore cleanliness or credibility after a period of defilement. In our context, it describes a one-time process through which legacy transaction outputs (\"TXOs\", which contain coin amounts) must pass to verify their legitimacy.",[15,72,73],{},[74,75],"img",{"alt":76,"src":77},"General definition of lustration","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Flustration-definition.png",[15,79,80],{},"This is not a new concept in the privacy coin space. ZCash has long employed a \"turnstile\" system that verifies amounts when coins enter or exit its shielded pools, and this mechanism is currently serving a similar purpose as ZCash users migrate from the bugged Orchard pool into the new Ironwood one. Other privacy coins also recently implemented comparable lustration processes following their own vulnerability discoveries.",[15,82,83,84,87,88,91,92,95],{},"Yet, Beam's approach would not be a continuous transparency feature, but a ",[33,85,86],{},"one-time gate"," at a fixed block height which would preserve holders anonymity, confidentiality of all future amounts, as well as Mimblewimble's ",[33,89,90],{},"cut-through"," and ",[33,93,94],{},"coinjoin"," features.",[10,97,99],{"id":98},"how-a-beam-transaction-works-today","How a Beam transaction works today",[15,101,102],{},"Before going further, let's start with a brief reminder of the internals of Beam transactions.",[15,104,105,106,109,110,113,114,117],{},"A Beam transaction consists of ",[33,107,108],{},"inputs"," (TXOs being spent), ",[33,111,112],{},"outputs"," (new TXOs being created), and ",[33,115,116],{},"kernels"," (the cryptographic signatures that validate the transactions).",[15,119,120,121,125,126,129],{},"In ",[122,123,124],"strong",{},"Mimblewimble transactions",", all input and output amounts are concealed, and zero-knowledge proofs guarantee that no coins are created during the transaction. All transactions within a block are ",[33,127,128],{},"coinjoined",", meaning inputs, outputs and kernels are not linked in any way (i.e. if there are multiple transactions in a block, we cannot know which inputs or outputs belong to each of them).",[15,131,132,136],{},[74,133],{"alt":134,"src":135},"Illustration of Beam's coinjoined confidential transactions","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Fmimblewimble-transactions.png",[33,137,134],{},[15,139,140,143,144,147,148,151,152,154],{},[122,141,142],{},"Lelantus transactions"," are similar to Mimblewimble transactions, except outputs are added to a ",[33,145,146],{},"shielded pool",". And when spent, transaction inputs from the pool are created using a ",[33,149,150],{},"one-out-of-many"," cryptographic scheme that hides which specific previous deposit is being spent. It's worth noting that these ",[33,153,150],{}," proofs were not affected by the vulnerability.",[15,156,157],{},"What is visible today in a block explorer:",[159,160,161,165,168,171],"ul",{},[162,163,164],"li",{},"The number of inputs, outputs, and kernels in each block.",[162,166,167],{},"The transaction fees.",[162,169,170],{},"The coinbase (mining reward), which are the only non-concealed amounts in the blockchain.",[162,172,173],{},"A range of 64 possible Confidential Asset ids for each TXO.",[15,175,176],{},"What is concealed:",[159,178,179,182,185,188,191],{},[162,180,181],{},"Individual amounts of all non-coinbase TXOs.",[162,183,184],{},"The specific Confidential Asset id of all TXOs.",[162,186,187],{},"Wallet addresses (neither sender nor receiver).",[162,189,190],{},"The linkage between specific inputs and outputs.",[162,192,193],{},"IP addresses and user identities.",[15,195,196,197,200],{},"The key cryptographic property of interest here is that every block contains zero-knowledge proofs that ",[122,198,199],{},"the sum of all inputs equals the sum of all outputs",", even though not a single individual amount is revealed. The lustration process is built over this property.",[10,202,204],{"id":203},"how-the-lustration-would-work","How the lustration would work",[15,206,207],{},"For the proposed lustration, a new hard fork would define a \"gate\" (or \"turnstile\") at a specific block height. From that height forward:",[159,209,210,220,229,236,247,254],{},[162,211,212,215,216,219],{},[122,213,214],{},"Old legacy UTXOs"," (created ",[33,217,218],{},"before"," the lustration hard fork) must disclose their amount and their specific asset id the first time they are spent.",[162,221,222,215,225,228],{},[122,223,224],{},"New UTXOs",[33,226,227],{},"after"," the lustration hard fork) remain fully confidential and never need any disclosure.",[162,230,231,232,235],{},"The disclosure is made by the wallet itself (since nowhere else are the amounts known) and it happens ",[122,233,234],{},"only once per UTXO",". After passing the lustration gate, the coins re-enter the concealed world and behave normally going forward.",[162,237,238,239,242,243,246],{},"The gate stays ",[122,240,241],{},"open forever",". An old UTXO sitting idle for years still has to pass through it whenever it is eventually spent. The only way to avoid lustration it to ",[33,244,245],{},"never"," move the coins again (basically making them dead).",[162,248,249,250,253],{},"Nodes track the ",[122,251,252],{},"cumulative disclosed total amount"," per asset type and compare it against the known emission schedule (both for Beam and for any Confidential Asset). If anything exceeds the expected maximum, an alert is triggered.",[162,255,256,257,260],{},"The process is ",[122,258,259],{},"mandatory at the consensus level",". Transactions trying to spend old UTXOs without disclosing their amounts are rejected by miners. It is not an optional feature.",[15,262,263],{},"In practice, the wallet would handle the disclosure automatically. For the average user, the process would be seamless: Sending coins to oneself once would be sufficient to pass all legacy UTXOs through the gate.",[15,265,266,270],{},[74,267],{"alt":268,"src":269},"Illustration of the lustration reveal of old legacy inputs","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Flustration-process.png",[33,271,268],{},[10,273,275],{"id":274},"what-is-exposed-and-what-is-not","What is exposed. And what is not.",[15,277,278],{},"This is an important section to understand, because this is where privacy concerns are concentrated.",[15,280,281],{},[122,282,283],{},"Exposed:",[159,285,286],{},[162,287,288],{},"The amount and the Confidential Asset id of each legacy input (pre-hard-fork), only at the moment it is spent. Nothing more.",[15,290,291],{},[122,292,293],{},"Not exposed:",[159,295,296,299,302,305,308],{},[162,297,298],{},"Wallet addresses.",[162,300,301],{},"IP addresses or user identities.",[162,303,304],{},"Amounts and Asset ids of newer inputs, created post-hard-fork.",[162,306,307],{},"Amounts and Asset ids of all outputs, and of anything forward.",[162,309,310],{},"The linkage between specific inputs and outputs (i.e. coinjoin is preserved).",[15,312,313],{},[122,314,315],{},"Cut-through:",[159,317,318,324,327,330],{},[162,319,320,321,323],{},"Mimblewimble's ",[33,322,90],{}," feature means that once a TXO is spent, it can normally be pruned from the blockchain (this is one of the reasons why the Beam blockchain is so lightweight).",[162,325,326],{},"However, the lustration process has a subtle implication here: When a legacy TXO is spent and its amount and asset type are revealed, this information must stay in the blockchain. It cannot be completely forgotten since new nodes joining the network after the lustration must have the means to verify it too.",[162,328,329],{},"Hence, when an old legacy TXO is spent, the blockchain will have to keep its commitment and the cryptographic \"revealing\" signature, so that the lustration can be independently verified by anyone, at any time.",[162,331,332],{},"This permanent footprint will have a small but real cost on the blockchain's lightweight property.",[15,334,335,339],{},[74,336],{"alt":337,"src":338},"Screenshot of current explorer block view","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Fscreenshot-explorer-before-lustration.jpeg",[33,340,341],{},"Screenshot of current explorer block view. All amounts and exact Asset ids are concealed.",[15,343,344,348,351,354],{},[74,345],{"alt":346,"src":347},"Mock-up of an explorer block view after lustration","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Fscreenshot-explorer-after-lustration.jpeg",[33,349,350],{},"Mock-up of an explorer block view after lustration (see the additional column in inputs).",[33,352,353],{},"Only old legacy inputs now show their amounts and exact Asset id.",[33,355,356],{},"Newer inputs, all outputs as well as everything else remain concealed.",[10,358,360],{"id":359},"why-a-one-time-disclosure-is-sufficient","Why a one-time disclosure is sufficient",[15,362,363,364,367],{},"Because every block holds a zero-knowledge proof that ",[122,365,366],{},"the sum of inputs equals the sum of outputs",", verifying once that the legacy inputs don't exceed the maximum supply guarantees the same for all downstream outputs.",[15,369,370],{},"After these legacy inputs have been accounted for, the chain can continue operating with full concealment, and the supply integrity guarantee simply propagates forward. That's why the lustration is said to be like a \"gate\" or a \"turnstile\".",[10,372,374],{"id":373},"minimizing-the-privacy-cost","Minimizing the privacy cost",[15,376,377,378,381],{},"The main privacy risk with the lustration process is the construction of a ",[33,379,380],{},"\"rich list\""," (something which is normally not possible in a privacy coin). Indeed, Beam currently has low chain usage, which means that most blocks contain only one or two transactions. Thus, a patient observer could infer that all the input amounts exposed in a block likely belong to one wallet only.",[15,383,384,385,388,389,391],{},"To mitigate this privacy risk, special ",[122,386,387],{},"UTXO management strategies"," (automatic and\u002For through a specific tool) could be proposed to be applied ",[33,390,218],{}," the lustration starts. With such strategies, large UTXOs could be splitted into smaller, standard (or randomized) amounts before the lustration height, so that they all appear similar. If the lustration is performed over several blocks, then no single disclosure would reveal total holdings.",[15,393,394],{},"An UTXO management tool could also allow selecting specific UTXOs for spending and consolidating, or even splitting, as needed. It would allow power users to better control how and when their coins pass the lustration gate.",[10,396,398],{"id":397},"collateral-privacy-advantages","Collateral privacy advantages",[15,400,401],{},"It is worth mentioning that despite exposing of certain amounts, two collateral privacy advantages would come with the lustration process:",[403,404,405,411],"ol",{},[162,406,407,410],{},[122,408,409],{},"Improved Confidential Asset id ranges",". All new UTXOs created after the lustration will use the new systematic CA id range definition that was developed some time ago but only released through hard fork 6. Instead of the old moving window of 64-id ranges, new UTXOs will carry either id:0 (Beam) or a range of 63 other possible ids. With this new scheme, it becomes impossible to know if a UTXO is either BEAM or a Confidential Asset. Over time, this creates a better-mixed anonymity set for confidential asset ids across the chain.",[162,412,413,416],{},[122,414,415],{},"Shielded pool enrichment",". If users send their coins to themselves through a Lelantus transaction during lustration, the anonymity set of the shielded pool will grow for all users going forward. The theoretical maximum for this anonymity set is 64k UTXOs, but even today the current pool is still far below that. A successful lustration campaign could increase the usage of the shielded pool, thus improving the anonymity set for everybody.",[10,418,420],{"id":419},"splitting-the-lelantus-shielded-pool","Splitting the Lelantus shielded pool",[15,422,423,424,426],{},"The current shielded pool contains pre-HF6 UTXOs, and they will remain there forever. When spending from the pool, the ",[33,425,150],{}," proof hides which specific shielded UTXO is being spent. So how does the lustration apply to the shielded pool?",[15,428,429],{},"The principle is the same as for regular Mimblewimble UTXOs: there is a clearly defined border between old coins and new ones, and every coin that crosses it must reveal its amount and asset type. No exceptions.",[15,431,432,433,436],{},"For the shielded pool, this means there will be a ",[33,434,435],{},"split"," between the old UTXOs and the new ones, with no mixing between them. When a shielded input is spent, the transaction indicates whether it is spending from the old side of the pool or from the new one. If it is from the old side, the amount and asset type are revealed, just like any legacy Mimblewimble UTXO. If it is from the new side of pool, then everything remains concealed as usual.",[15,438,439,440,442],{},"Technically, the shielded pool is a growing array, and its size is known at any point. When the lustration is activated, the current size of the pool becomes the separator between the old and the new sides of the pool. New UTXOs sent to the shielded pool after the lustration will go into the new side (above the separator), and when spent, they will only mix (via the ",[33,441,150],{}," proof) with other UTXOs from that same new side of the pool.",[15,444,445],{},"In effect, the old side of the pool is abandoned, and a new one is created with a fresh anonymity set that starts empty. This is similar to what ZCash does when users migrate from the old Orchard pool to the new Ironwood one.",[15,447,448,449,452,453,456],{},"If the lustration process happens mostly through Lelantus transactions, the new pool's anonymity set will start filling up right away, although not necessarily very quickly, because most users would send their coins to the shielded pool ",[33,450,451],{},"all at once",", thus creating ",[33,454,455],{},"only one"," new shielded UTXO per asset type and per wallet.",[15,458,459],{},"This also means that many of the initial shielded UTXOs of the new pool will have known amounts (since one shielded UTXO equals the sum of all its inputs, many of which would have been revealed).",[15,461,462],{},"Despite the two points above, performing lustration through Lelantus transactions is still significantly better than through regular Mimblewimble transactions, which expose the transaction graph and allow some chain analysis. Indeed, with the shielded pool, the transaction graph is broken: when coins from the new pool are spent, they cannot be linked to a specific shielded UTXO, nor to the original inputs whose amounts were exposed.",[15,464,465],{},"Moreover, the effect of both points above might be strongly reduced when specific UTXO management strategies are applied together with the lustration process (such as splitting holdings in multiple UTXOs of standard or random amounts, performing the lustration over several blocks, etc.).",[15,467,468],{},"In any case, over time, as users perform additional transactions through the shielded pool, the anonymity set will keep growing and the privacy of all its UTXOs will increase. The initial exposure is the price of a clean start, but it is a one-time cost only and it fades as the pool enriches.",[10,470,472],{"id":471},"smart-contracts-and-already-visible-amounts","Smart contracts and already-visible amounts",[15,474,475],{},"Funds currently locked in smart contracts (such as DEX liquidity pools, Nephrite troves, the BeamX DAO, and any other onchain contracts) are already publicly visible in the explorer. Indeed, all amounts in smart contracts are visible by design (what is hidden is the wallets they come from). Thus, these funds do not need lustration.",[15,477,478],{},"The total circulating supply is therefore:",[15,480,481],{},[33,482,483],{},"Circulating supply = Sum of disclosed legacy UTXO amounts + Sum of smart-contract-locked amounts",[15,485,486],{},"The lustration process only concerns the first part. The second part is already verifiable today.",[15,488,489,493],{},[74,490],{"alt":491,"src":492},"Example of the visible locked amounts within certain smart contracts","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Fsmart-contract-amounts.png",[33,494,491],{},[10,496,498],{"id":497},"what-if-the-lustration-reveals-the-vulnerability-was-exploited","What if the lustration reveals the vulnerability was exploited?",[15,500,501],{},"This is the question the community raised most often, and it deserves a direct answer.",[15,503,504,505,508,509,512,513,516],{},"Lustration can ",[122,506,507],{},"detect"," inflation, but it cannot ",[122,510,511],{},"ensure"," it didn't happen and it cannot ",[122,514,515],{},"mitigate"," it fairly if it did. If the disclosed total exceeds the expected emission, we know something happened, but we cannot distinguish legitimate coins from inflated ones. They are all valid UTXOs.",[15,518,519],{},"Some options in that scenario could be the following and would need community decision:",[159,521,522,528,534,544],{},[162,523,524,527],{},[122,525,526],{},"Make excess UTXOs unspendable."," This would cap the supply, but it could block legitimate coins. The last users to pass through the gate would be the ones penalized, regardless of whether their coins were honest.",[162,529,530,533],{},[122,531,532],{},"Accept the inflated amount into the official supply."," The network continues, holders' balances don't change, but the total supply becomes higher than initially intended.",[162,535,536,539,540,543],{},[122,537,538],{},"Rollback the chain."," This was already rejected as infeasible, because we cannot know ",[33,541,542],{},"when"," the vulnerability was exploited. Reverting a month or more of history on suspicion alone is not justifiable, and there is no clear point to roll back to.",[162,545,546,549],{},[122,547,548],{},"Fork and relaunch the chain",". A difficult decision which would require a lot of work, and could also lead to a full rebranding.",[15,551,552],{},"The realistic outcome (if exploitation indeed occurred), is that a careful attacker will only pass small amounts through the gate over time, aiming to stay under the threshold of coins presumed lost forever (from lost wallets, deceased holders, etc.) which will never move and pass the gate. In this scenario, the circulating supply will still end up capped below its original intended maximum. Some \"lost\" Beam would effectively have been replaced by some \"inflated\" Beam. But the actual balance of individual holders would not change, nor the total circulating supply.",[15,554,555],{},"Even with lustration, 100% certainty is impossible. Since lost wallets will never move and never disclose, some extra coins can technically trickle through the gate and take their place. Nonetheless, lustration would very significantly raise confidence regarding the supply integrity.",[10,557,559],{"id":558},"implementation-considerations","Implementation considerations",[15,561,562],{},"The following aspects can be considered:",[159,564,565,568,571,574,577],{},[162,566,567],{},"The lead developer of Beam already confirmed that the consensus-level changes to implement lustration are straightforward and can be implemented in a few days. They will require another network upgrade (hard-fork 7).",[162,569,570],{},"Some more work would be needed on the wallet side, and even more if some advanced UTXO management strategies are to be implemented.",[162,572,573],{},"The wallet would perform the disclosure automatically. No manual cryptographic work would be needed by the users. Just moving the coins (even simply sending to oneself) would be enough to pass the lustration.",[162,575,576],{},"Special UTXO management tooling could be released before the update, giving power users time to prepare if they need to fine tune how their coins will pass the lustration.",[162,578,579],{},"Block explorers would be updated to display disclosed amounts and running totals, so anyone can independently verify the cumulative disclosed supply.",[10,581,583],{"id":582},"summary-of-the-trade-off","Summary of the trade-off",[15,585,586],{},"The recent community discussions surfaced a range of positions, which can be broadly grouped into arguments in favor and arguments against implementing lustration. Both deserve to be stated in full, because the decision is not obvious, depends on individual perception and use cases, and reasonable people can reach very different conclusions.",[588,589,591],"h3",{"id":590},"arguments-in-favor","Arguments in favor",[159,593,594,600,606,619,625,631,637,643],{},[162,595,596,599],{},[122,597,598],{},"Supply verifiability is foundational",". The fundamental purpose of any blockchain, whether privacy-preserving or fully transparent, is to prevent unauthorized supply creation. Without a verifiable guarantee or a strong trust on the circulating supply, the whole system loses its meaning. Lustration provides a mechanism to verify the circulating supply in the case of a privacy chain.",[162,601,602,605],{},[122,603,604],{},"Increased trust and confidence",". Even if the probability of exploitation is assessed as low, lustration lowers the perceived likelihood much further. It helps users feel more secure about the total supply, and that psychological effect is not trivial because it influences adoption (and hence price, and security), for Beam and for the Confidential Assets (BeamX, Nephrite, etc.).",[162,607,608,611,612,615,616,618],{},[122,609,610],{},"The breach of privacy is acceptable and manageable",". The lustration process happens at the expense of a ",[33,613,614],{},"one-time only"," exposure of the circulating amounts. It only applies to transaction ",[33,617,108],{}," and it does not directly reveal anything else about wallets and their owners. The collateral privacy cost is mitigable through UTXO management and by using the Lelantus shielded pool. Any additional information that could be inferred from the exposed amounts will disappear over time, as coins circulate and more transactions happen.",[162,620,621,624],{},[122,622,623],{},"Early data and anomaly detection",". Some people estimate that 25-50% of coins are expected to pass through lustration in the first weeks, and that full lustration of all existing UTXOs will never happen. Nonetheless, this will still provide meaningful data to analyze about the supply integrity. For example, whether unusually large amounts appear, whether UTXOs with suspiciously close timestamps cluster together, etc. Such signals could be visible early if the inflation did happen and was massive.",[162,626,627,630],{},[122,628,629],{},"Special cases for Confidential Assets",". In the case of Beam coins, the impact of inflation is primarily on price. But for bridged assets (such as bETH or bWBTC), there are third-party coins locked in the Ethereum contract that could be stolen if the corresponding Confidential Asset supply was inflated beyond the locked collateral. Lustration provides an additional layer of assurance here.",[162,632,633,636],{},[122,634,635],{},"Lustration caps the future circulation of coins",". Even if the bug was exploited and inflated coins do exist, the lustration gate ensures they cannot circulate in large amounts without being detected. Small amounts might trickle through (passing lustration in place of the coins lost in dead wallets), but not excessive ones. The lustration gate stays open forever, so this guarantee is permanent.",[162,638,639,642],{},[122,640,641],{},"Precedent and optics",". ZCash's current handling of its own inflation bug, including its turnstile system, is perceived to be positive for trust, usage and price. Implementing lustration is already considered as the right way for privacy coins to handle inflation bugs transparently and responsibly. It signals that the project takes supply integrity seriously.",[162,644,645,648],{},[122,646,647],{},"Reveals actual liquid supply",". Lustration would give a clearer picture of how much Beam is actually in circulation versus lost or dormant, which is useful information for the market.",[588,650,652],{"id":651},"arguments-against","Arguments against",[159,654,655,669,675,681,687,693,707,713],{},[162,656,657,660,661,664,665,668],{},[122,658,659],{},"The privacy cost is real and applies to everyone",". Lustration requires a one-time breach of privacy and that breach applies to ",[33,662,663],{},"all users",", not just those who want and accept the verification. For a project whose reason for existing is privacy, this is a meaningful compromise. Certainty was never 100% to begin with (hidden bugs are always possible in ",[33,666,667],{},"any"," cryptographic system). Performing lustration demonstrates that privacy can be partially lifted, which might be seen as a breach of the project's basic commitments.",[162,670,671,674],{},[122,672,673],{},"Significant operational burden",". Lustration creates work for both project maintainers and power users. For users with simple holdings, the process will be straightforward. But for advanced and very active users maintaining multiple positions and dozens of segregated wallets with real operational security requirements, the process is non-trivial and potentially disruptive.",[162,676,677,680],{},[122,678,679],{},"No clear mitigation plan if exploitation is detected",". Lustration can detect inflation, but it cannot mitigate it fairly. If some disclosed totals indeed exceed their expected maximum, there is no clean response defined yet. An attacker who has already extracted value could push coins through the gate quickly, potentially displacing legitimate supply. Deciding to do lustration is not the same as deciding what to do if it detects a problem, and the community would face a difficult second decision in that scenario.",[162,682,683,686],{},[122,684,685],{},"Lustration does not prove the bug was not exploited",". It can only indicate whether the circulating supply exceeds the expected maximum. It does not verify the supply in an absolute sense, nor does it even prove the absence of surplus coins. Lost wallets will never move and never disclose, and a patient attacker can trickle small amounts through over time. Complete purity is not achieved: the name \"lustration\" is somewhat aspirational. At any given moment, we would only know that the circulating supply is sound... so far.",[162,688,689,692],{},[122,690,691],{},"Probabilistic linkability risk",". While wallet addresses are not exposed, the amounts are. If those amounts can be tied to KYC'd origins or identifying information through other means, probabilistic linking becomes possible. This is a concern for users whose operational security depends on not having their holdings visible, even in aggregate.",[162,694,695,698,699,702,703,706],{},[122,696,697],{},"Two kinds of trust, in tension",". There is ",[33,700,701],{},"user trust"," (confidence that the social contract has not changed, that operational security is not compromised, that the project behaves a certain way \"when things get thick\"), and there is ",[33,704,705],{},"investor trust"," (the desire for sound money and verifiable supply). These are not the same, and they can be at odds. A decision that strengthens investor trust may weaken user trust, and vice versa. Privacy projects aiming for the level of user trust that Monero enjoys would likely never adopt such a lustration process.",[162,708,709,712],{},[122,710,711],{},"The current economics do not change",". If the bug was exploited and inflated coins were already sold and distributed, those coins are already in the economy and the effect on price has already happened. Lustration does not reverse that. It provides peace of mind and a forward-looking cap, but it does not change the reality of the past supply distribution.",[162,714,715,718],{},[122,716,717],{},"Uncertainty about detection accuracy",". Even if the lustration total stays below the maximum, that does not necessarily mean no exploitation occurred. It could mean that apathetic users with large dormant holdings outweigh an attacker's lustrated coins, or that the attacker was very careful. The picture only becomes clear quickly if the inflation was massive.",[588,720,722],{"id":721},"important-clarifications","Important clarifications",[15,724,725],{},"Two particular points should be made explicit, as they affect how the above trade-off can be weighed:",[159,727,728,734],{},[162,729,730,733],{},[122,731,732],{},"Lustration does not imply censorship",". If the lustration process reveals that the vulnerability was exploited, that finding does not automatically trigger any specific response. What to do in that scenario would be a separate community discussion. It might involve accepting the inflated supply, forking the project, relaunching, or other options. Launching the lustration is not a decision about what happens to the project if it detects a problem. Those are two distinct decisions.",[162,735,736,739],{},[122,737,738],{},"The most probable outcome remains that no exploit is detected",". The developers assess the probability of exploitation as low, and the blockchain history has already been scanned for recognizable attack patterns with none found. If lustration proceeds and shows no excess, the community gains increased confidence in the supply integrity and the second decision (what to do if exploitation is detected) never needs to be made.",[588,741,743],{"id":742},"bottom-line","Bottom line",[15,745,746],{},"Both positions are legitimate. The decision depends on how each member of the community weighs supply certainty against absolute privacy, on their personal tolerance for residual uncertainty, and on whether they view Beam primarily as an investment (where verifiable supply matters most) or as a privacy tool (where operational privacy matters most). The vote should be made with these trade-offs fully in view.",[10,748,750],{"id":749},"community-discussion-and-next-steps","Community discussion and next steps",[15,752,753],{},"Several discussions already happened these last few days in the community chats about the lustration proposal. The general sentiment among those who expressed an opinion leaned toward implementing the lustration, but strong genuine reservations were also made, particularly around the \"rich list\" concern, the direct and indirect privacy cost, and the lack of a clean mitigation plan if exploitation is detected.",[15,755,756,757,760],{},"The next step which has been proposed is a formal ",[122,758,759],{},"BeamX DAO vote",". While this is a base-protocol issue rather than a DeFi governance matter, the BeamX DAO is the governance body available today (and the one which was recognized by the former Beam Foundation), and consulting the community before any such change is the right approach. The open questions (such as the one-click wallet solution or the UTXO management tooling) will need to be resolved as part of the implementation planning.",[15,762,763],{},[74,764],{"alt":759,"src":765},"\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002Fdao-vote.png",[15,767,768],{},"One ironic aspect worth noting: if the vulnerability was exploited to inflate the BeamX governance token itself, then an attacker could theoretically use those inflated tokens to influence the vote against the lustration! However, this would be difficult to hide because voting stakes are publicly visible, and locking BeamX for the vote makes holdings transparent. In a sense, the DAO vote itself acts as a specific lustration of the BeamX token alone.",[15,770,771],{},"Regardless, the vote will primarily be considered as a signaling mechanism: a way to formally confirm that the community broadly agrees with the direction. The effective adoption of the lustration would ultimately still depend on normal blockchain consensus, with miners and nodes accepting or rejecting the new hard fork through the network upgrade process.",[10,773,775],{"id":774},"conclusion","Conclusion",[15,777,778],{},"The hard fork 6 was a success, the vulnerability is now patched. The network is secure going forward. Privacy was fully preserved. The lustration process is now an optional additional step to try to verify the past. A one-time trade of partial privacy for increased certainty about the circulating supply. The subject raises many considerations and opinions about it can differ. Implementing it or not is not an easy decision to make.",[15,780,781],{},[122,782,783],{},"The choice belongs to the community.",[15,785,786],{},[33,787,788],{},"The author and the Beam developers would like to thank the community members who participated in the discussion chats for their thoughtful engagement with this difficult technical and ethical question.",{"title":790,"searchDepth":791,"depth":791,"links":792},"",2,[793,794,795,796,797,798,799,800,801,802,803,804,805,806,813,814],{"id":12,"depth":791,"text":13},{"id":46,"depth":791,"text":47},{"id":63,"depth":791,"text":64},{"id":98,"depth":791,"text":99},{"id":203,"depth":791,"text":204},{"id":274,"depth":791,"text":275},{"id":359,"depth":791,"text":360},{"id":373,"depth":791,"text":374},{"id":397,"depth":791,"text":398},{"id":419,"depth":791,"text":420},{"id":471,"depth":791,"text":472},{"id":497,"depth":791,"text":498},{"id":558,"depth":791,"text":559},{"id":582,"depth":791,"text":583,"children":807},[808,810,811,812],{"id":590,"depth":809,"text":591},3,{"id":651,"depth":809,"text":652},{"id":721,"depth":809,"text":722},{"id":742,"depth":809,"text":743},{"id":749,"depth":791,"text":750},{"id":774,"depth":791,"text":775},"news","2026-07-28","Following the emergency hard fork 6 and the correction of the vulnerability in the Bulletproofs implementation, this post details a 'lustration' process which is proposed as a one-time mechanism to verify Beam's circulating supply. The post is intentionally thorough, because the proposal involves a trade-off between privacy and supply certainty that every member of the community should understand when forming an opinion about it. This post aims at serving as a reference document for the upcoming BeamX DAO vote on whether to implement the lustration.","md","\u002Fimages\u002Fblog\u002Fnews\u002Flustration-proposal\u002F01.png",{},true,"\u002Fblog\u002Fnews\u002Flustration-proposal",{"title":5,"description":817},"blog\u002Fnews\u002Flustration-proposal",[826,827,828,829],"Beam core","Hard Fork","Lustration","Supply","tlxj2-5jsCBb7zj7DrUydR8R8vSeMzfJaIWdOIMIE4s",[832,1003,1061,1114],{"id":833,"title":834,"body":835,"category":815,"date":993,"description":994,"extension":818,"image":995,"meta":996,"navigation":821,"path":997,"seo":998,"stem":999,"tags":1000,"__hash__":1002},"blog\u002Fblog\u002Fnews\u002Fhardfork-six.md","Hard Fork Six",{"type":7,"value":836,"toc":986},[837,839,858,862,865,868,883,894,897,900,923,926,929,933,936,939,950,954,957,960,963,966,969,971,980,983],[10,838,13],{"id":12},[15,840,841,842,847,848,91,853,25],{},"On June 13, 2026, Beam developers were contacted with a report describing a possible vulnerability in Beam core code. After careful review and testing over the following days, the report was confirmed to identify a subtle but real vulnerability.\nOnce the issue was understood, the core code was corrected in a non-public branch. The main mining pools and exchanges were then contacted directly and asked to upgrade to the corrected version, eliminating any further risk of exploitation. The hard fork took place at block 3928666.\nThe latest corrected builds (wallets, nodes, etc.) can be downloaded from ",[19,843,846],{"href":844,"rel":845},"https:\u002F\u002Fbeam.mw\u002Fdownloads",[23],"beam.mw\u002Fdownloads"," or from ",[19,849,852],{"href":850,"rel":851},"https:\u002F\u002Fgithub.com\u002FBeamMW\u002Fbeam\u002Freleases",[23],"github.com\u002FBeamMW\u002Fbeam\u002Freleases",[19,854,857],{"href":855,"rel":856},"https:\u002F\u002Fgithub.com\u002FBeamMW\u002Fbeam-ui\u002Freleases",[23],"github.com\u002FBeamMW\u002Fbeam-ui\u002Freleases",[10,859,861],{"id":860},"technical-details","Technical details",[15,863,864],{},"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.",[15,866,867],{},"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.",[15,869,120,870,878,879,882],{},[19,871,874],{"href":872,"rel":873},"https:\u002F\u002Fgithub.com\u002FBeamMW\u002Fbeam\u002Fblob\u002Febc40098938197bea689b853a7f51fb507c843d5\u002Fcore\u002Fecc_bulletproof.cpp#L453",[23],[875,876,877],"code",{},"ecc_bulletproof.cpp#L453",", ",[875,880,881],{},"CycleStart()"," is where challenges are obtained.",[15,884,885,886,893],{},"And ",[19,887,890],{"href":888,"rel":889},"https:\u002F\u002Fgithub.com\u002FBeamMW\u002Fbeam\u002Fblob\u002Febc40098938197bea689b853a7f51fb507c843d5\u002Fcore\u002Fecc_bulletproof.cpp#L463",[23],[875,891,892],{},"ecc_bulletproof.cpp#L463"," is where the extracted LR are exposed.",[15,895,896],{},"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 because, in theory, it could be used to construct a TXO with a negative amount. If successfully exploited, such an output could be used to balance a transaction containing another TXO with a corresponding positive amount, creating a risk of unauthorized supply creation.",[15,898,899],{},"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:",[159,901,902,909,916],{},[162,903,904],{},[19,905,908],{"href":906,"rel":907},"https:\u002F\u002Fkudelskisecurity.com",[23],"Kudelski",[162,910,911],{},[19,912,915],{"href":913,"rel":914},"https:\u002F\u002Fleastauthority.com",[23],"Least Authority",[162,917,918],{},[19,919,922],{"href":920,"rel":921},"https:\u002F\u002Fpessimistic.io",[23],"SmartDec (now Pessimistic)",[15,924,925],{},"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.",[15,927,928],{},"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.",[10,930,932],{"id":931},"our-assessment","Our Assessment",[15,934,935],{},"The Beam developers consider that the probability of this vulnerability having been exploited is low.",[15,937,938],{},"Several aspects lead to this assessment:",[403,940,941,944,947],{},[162,942,943],{},"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.",[162,945,946],{},"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.",[162,948,949],{},"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.",[10,951,953],{"id":952},"the-next-steps","The next steps",[15,955,956],{},"As said above, Beam developers currently assess the likelihood of exploitation as low. However, due to Beam’s privacy-preserving design, additional verification is required to provide stronger assurance around supply integrity. This is why we are proposing a lustration process for community review.",[15,958,959],{},"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.",[15,961,962],{},"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.",[15,964,965],{},"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.",[15,967,968],{},"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).",[10,970,775],{"id":774},[15,972,973,974,979],{},"The Beam developers would like to thank ",[19,975,978],{"href":976,"rel":977},"https:\u002F\u002Fx.com\u002FMonclairTrades",[23],"MonclairTrades"," for the responsible disclosure of this vulnerability.",[15,981,982],{},"Most importantly, the vulnerability has now been patched, the network has upgraded, and the proposed next step is focused on giving the community an additional path to independently verify supply integrity.",[15,984,985],{},"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":790,"searchDepth":791,"depth":791,"links":987},[988,989,990,991,992],{"id":12,"depth":791,"text":13},{"id":860,"depth":791,"text":861},{"id":931,"depth":791,"text":932},{"id":952,"depth":791,"text":953},{"id":774,"depth":791,"text":775},"2026-07-01","Beam has completed a necessary security hard fork to address a subtle Bulletproofs rangeproof vulnerability discovered in the Beam core code. The issue was responsibly disclosed, reviewed by the developers, patched in a non-public branch, and resolved through a coordinated network upgrade. This post explains the technical background, our current risk assessment, and a proposed lustration process that would allow the community to verify supply integrity with a one-time, limited disclosure of legacy outputs.","\u002Fimages\u002Fblog\u002Fnews\u002Fhardfork-six\u002F01.png",{},"\u002Fblog\u002Fnews\u002Fhardfork-six",{"title":834,"description":994},"blog\u002Fnews\u002Fhardfork-six",[827,1001],"Emergency","jzDuxlNJO2uAGKrrV2hIaYJvWK3ll03i63kx9sDUT3U",{"id":1004,"title":1005,"body":1006,"category":1046,"date":1047,"description":1048,"extension":818,"image":1049,"meta":1050,"navigation":821,"path":1051,"seo":1052,"stem":1053,"tags":1054,"__hash__":1060},"blog\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-2.md","Beam Warp Development Update #2: Testing and Benchmarking",{"type":7,"value":1007,"toc":1044},[1008,1011,1017,1023,1026,1032,1035,1041],[15,1009,1010],{},"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.",[15,1012,1013],{},[74,1014],{"alt":1015,"src":1016},"Transaction duration over time","\u002Fimages\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-2\u002Ftx-duration-timeseries.png",[15,1018,1019],{},[74,1020],{"alt":1021,"src":1022},"Transaction duration histogram","\u002Fimages\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-2\u002Ftx-duration-histogram.png",[15,1024,1025],{},"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).",[15,1027,1028],{},[74,1029],{"alt":1030,"src":1031},"Perceived transaction times relative to block windows","\u002Fimages\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-2\u002Fperceived-tx-times.png",[15,1033,1034],{},"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.",[15,1036,1037],{},[74,1038],{"alt":1039,"src":1040},"Explorer view of the PBFT_DPOS contract state","\u002Fimages\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-2\u002Fexplorer-validators.png",[15,1042,1043],{},"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":790,"searchDepth":791,"depth":791,"links":1045},[],"updates","2026-04-08","Benchmarking the warp_dev3 devnet shows ~1.8s average transaction times, alongside dynamic tip trimming, multisig bridge ceremonies, and a fully operational dPoS contract.",null,{},"\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-2",{"title":1005,"description":1048},"blog\u002Fupdates\u002Fbeam-warp-dev-2",[1055,1056,1057,1058,1059],"Beam Warp","Sidechain","dPoS","Benchmarking","Development","ucpIdy9EwOt-M78bdDYugO731D_bC79g2fyoXVgP1_0",{"id":1062,"title":1063,"body":1064,"category":1046,"date":1106,"description":1107,"extension":818,"image":1049,"meta":1108,"navigation":821,"path":1109,"seo":1110,"stem":1111,"tags":1112,"__hash__":1113},"blog\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-1.md","Beam Warp Development Update #1: An innovative dPoS implementation",{"type":7,"value":1065,"toc":1104},[1066,1069,1072,1075,1078,1081,1084,1092,1095,1098,1101],[15,1067,1068],{},"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.",[15,1070,1071],{},"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.",[15,1073,1074],{},"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.",[15,1076,1077],{},"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.",[15,1079,1080],{},"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.",[15,1082,1083],{},"The bridge design ensures security without altering the mainchain. In the backend, the process looks like:",[403,1085,1086,1089],{},[162,1087,1088],{},"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!).",[162,1090,1091],{},"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).",[15,1093,1094],{},"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.",[15,1096,1097],{},"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!",[15,1099,1100],{},"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!",[15,1102,1103],{},"More news to come as tests and development move forward!",{"title":790,"searchDepth":791,"depth":791,"links":1105},[],"2026-02-12","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.",{},"\u002Fblog\u002Fupdates\u002Fbeam-warp-dev-1",{"title":1063,"description":1107},"blog\u002Fupdates\u002Fbeam-warp-dev-1",[1055,1056,1057,1059],"K7nuCA7Uce1wwhsTxe7PeMQCu80x_hN2Pj7U77vywMU",{"id":1115,"title":1116,"body":1117,"category":815,"date":1142,"description":1143,"extension":818,"image":1144,"meta":1145,"navigation":821,"path":1146,"seo":1147,"stem":1148,"tags":1149,"__hash__":1153},"blog\u002Fblog\u002Fnews\u002Fwelcome-to-beam-blog.md","Welcome to the Beam Blog!",{"type":7,"value":1118,"toc":1140},[1119,1122],[15,1120,1121],{},"This is the new Beam blog. Expect release notes, technical write-ups, and notes from the community — posted when there's something worth saying.",[15,1123,1124,1125,878,1130,1134,1135,25],{},"If you're new here, ",[19,1126,1129],{"href":1127,"rel":1128},"https:\u002F\u002Fbeam.mw\u002Fdownloads\u002F",[23],"download the wallet",[19,1131,1133],{"href":1132},"\u002Fdocs","read the docs",", or come say hi on ",[19,1136,1139],{"href":1137,"rel":1138},"https:\u002F\u002Ft.me\u002FBeamPrivacy",[23],"Telegram",{"title":790,"searchDepth":791,"depth":791,"links":1141},[],"2025-06-18","Discover the latest updates, news, and insights from the Beam ecosystem.","\u002Fsvg\u002Flogo.svg",{},"\u002Fblog\u002Fnews\u002Fwelcome-to-beam-blog",{"title":1116,"description":1143},"blog\u002Fnews\u002Fwelcome-to-beam-blog",[1150,1151,1152],"Announcement","Updates","Beam","zn2_RMZSxXcueZLIS0cf8MvGRfR4NraDivs-OnwNvL0",1785933212510]