The founding whitepaper proposed combining adaptive state sharding with Secure Proof of Stake. Instead of requiring every validator to execute and store the same complete workload, the network would divide work among shards and coordinate their outputs. The ambition was a public blockchain whose capacity could expand without continually raising the hardware burden on every participant. A whitepaper states a design and its assumptions. It does not establish that every advertised throughput figure has been achieved under ordinary production conditions.

The 2020 economics paper linked that architecture to eGold, the asset now written EGLD. It described staking, delegation, payments and contract fees as parts of a proposed public utility. Developer fee participation was intended to give application creators an economic reason to build on the network. This founding argument combined engineering with a distribution thesis: useful applications would attract users, and users would create demand for network resources.

The later community debates matter because they test that economic connection rather than simply ask whether the chain can process transactions.

At xDay in November 2022, Elrond became MultiversX. Beniamin Mincu's transformation statement connected the new name to a broader vision spanning financial applications, virtual worlds and other emerging technologies. Product names changed as well: Maiar Wallet became xPortal and Maiar DEX became xExchange. Those changes are part of the project's cultural history, but the network's continuity should remain visible. An old Elrond transaction or discussion is not automatically evidence about a different chain simply because the branding is unfamiliar.

EGLD remains the native asset used for network fees, staking and governance. MEX and its locked forms belong to xExchange's application economics, a distinction that becomes especially important when older discussions use Elrond, Maiar, eGold and MEX together. The official EGLD page describes the network asset's role, while Lucian Todea's xExchange announcement explains a separate redesign of exchange incentives. A wallet application, an exchange token and the base network can influence one another without giving their holders identical rights or risks.

MultiversX's sharding documentation separates network, transaction and state sharding. A validator works with its assigned portion of the system, while periodic redistribution changes shard membership to make persistent collusion harder. Moving every node at once would introduce synchronization delays, so the design redistributes a controlled portion. That tradeoff is part of the mechanism, not a footnote. A sharded network must balance the benefit of parallel work against the cost of moving state, coordinating participants and protecting each individual shard.

The transaction documentation explains cross-shard transfers as a sequence: work in the sender's shard, metachain notarization, then processing in the receiver's shard. Miniblocks group transactions by their shard relationship. For applications, that means the progress of a remote operation must be tracked across stages. A quick confirmation in one place does not by itself prove every downstream action has completed.

The older page's timing examples belong to its six-second configuration; the underlying distinction between local execution and cross-shard coordination remains useful after faster rounds.

The post-Andromeda consensus description moves from a small per-round subset to the full execution-shard validator group participating in each round. Aggregated signatures form an Equivalent Consensus Proof, and the old extra confirmation-block step is removed. This explains why the upgrade affected finality as well as raw throughput. Its safety argument still depends on the assumed bound on faulty participants and on correct implementation. Describing a proof as deterministic should not be turned into a claim that software bugs, operator failures or stolen signing keys have become impossible.

Supernova then addressed another constraint: execution and consensus had been tightly coupled. The January 8, 2026 design article proposes ordering and finalizing work without waiting for every execution step in the earlier arrangement. Its challenge is preserving deterministic results while allowing the pipeline to progress. This is a more specific idea than saying the chain became faster. It changes how work is staged, while users and integrators still need to distinguish transaction ordering, executed state and completion of a cross-shard application flow.

The published Supernova calendar scheduled mainnet activation for September 10, 2026 after testnet and devnet stages. At review time, that page still showed pending labels and an August update date. A countdown page is therefore insufficient evidence of either completion or delay. The versioned mainnet configuration supplies the concrete activation round, 32,157,661. Those records preserve the intended rollout, while a current network response is needed to establish that production has moved beyond the configured boundary.

On September 30, the public mainnet gateway reported a 600-millisecond round duration, three execution shards and the v2.1.7.0 software tag. Its status response was beyond the configured activation round. Together these observations support the faster production configuration despite older documentation still describing Supernova as pre-mainnet. They do not independently verify every advertised latency percentile or application benchmark. The September 29 release is a dated software artifact; the live gateway observation is a separate, time-specific check of network state.

The ESDT standard puts token operations into the protocol rather than requiring every issuer to recreate basic token accounting in a contract. Its documentation covers fungible and nonfungible forms and the properties attached to them. This can simplify integration, but a native token format does not establish an issuer's honesty or an asset's backing. A reader should identify the token and its permitted controls, then evaluate the application or issuer separately. The convenience of protocol handling is an engineering property, not an endorsement of every asset using it.

Relayed transactions let another account pay a user's transaction fee. The current developer guide distinguishes versions and explains the added relayer fields and signatures in version three. This can remove the need for a first-time user to acquire EGLD before a sponsored action, while still leaving a fee payer somewhere in the flow. Sponsorship also requires compatible wallets and services. An application can present a smooth experience without eliminating the network's resource cost or the need to understand what the user is authorizing.

Guardians add a co-signature requirement to a guarded account. The owner first sets a guardian and then activates protection after the documented waiting period. Normal protected transactions need both signatures, which can help when an owner key leaks. The guide also allows delayed guardian replacement without the old guardian's approval, addressing the danger of permanent lockout. That recovery path is part of the security model. A guardian is therefore more than a marketing label for safety, and its replacement process deserves as much attention as its everyday signing screen.

The same guide discusses human co-signers, automated services and wallet integration. These choices affect availability and the experience of approving legitimate transactions. A person who only sees an extra confirmation prompt may not know which service supplies the second signature or what happens if that service becomes unreachable. The useful question is whether the arrangement reduces the user's actual threat exposure while preserving a workable recovery path. No account-level guard establishes that a contract the user deliberately authorizes is economically sound.

Beniamin Mincu's June 11, 2022 incident report traces the attack to a newly deployed virtual-machine function involving execution in the original caller's context. The report describes manipulated wrapped EGLD accounting, exchange activity, emergency fixes and recovery work. It also records using foundation reserves as part of restoring the relationship between wrapped balances and backing. This was more specific than an ordinary trader losing money on the exchange.

The technical boundary between execution context and asset accounting failed in a way that affected the wider application economy.

The report says Maiar Exchange resumed normal operation on June 8 after verification and rebalancing. Its evidence includes transaction links, making the recovery claim more inspectable than a general reassurance. Nevertheless, the report is the project's own account and its conclusion should be read with that provenance. Recovery demonstrates coordinated intervention; it does not erase the original failure or establish that all later upgrades are safe. For future incidents, the relevant questions remain the affected code, privilege path, accounting gap and verifiable restoration transactions.

In August 2020, Mincu presented eGold through scarcity, broad distribution and easy consumer access. His argument went further than technical utility, suggesting adoption would be reflected directly in the asset's price. That is an identifiable founder thesis, not a reliable pricing rule. A new user can transact very little, fees can be low and markets can change independently of application use. Preserving the original pitch helps explain why later holders treated changes to supply policy as a change to the bargain they believed they had accepted.

The versioned September 2026 economics configuration contains a tail-inflation section enabled at epoch 1951, including a positive minimum rate. It also retains a developer reward percentage of 0.3. These concrete settings are stronger evidence than treating the entire proposed economic framework as one already-deployed package. In particular, continuing issuance and a proposed higher builder fee share are different changes.

The older capped-supply narrative cannot be presented as an eternal rule, while the proposed ninety-percent builder allocation should not replace the thirty-percent setting found in this release.

The economic framework posted by robert in October 2025 proposed new emissions, incentives and strategic capital formation tied to growth objectives. It linked these mechanisms to liquidity, applications and revenue, while describing controls around separate investment decisions. The document is valuable as a statement of intended policy and its rationale. A target in that document is not an achieved business result, and approval of a framework does not establish that every partner agreement, fund allocation or follow-on software change has happened.

MultiversX's governance guide describes public debate on Agora followed by an on-chain proposal tied to a commit or specification reference. Voting power derives from staked or delegated EGLD, with quorum and acceptance conditions. That gives holders a formal participation mechanism, but influence follows stake rather than one account per person. The visible forum discussion has a different role: it records arguments, objections and explanations before a vote.

Both are necessary for understanding a decision, and a high approval percentage alone does not reproduce the reasoning or turnout behind it.

Forum participant metothex proposed measuring sustainability through fees burned relative to tokens issued and wanted explicit accountability when targets were missed. The post offered alternative parameters rather than simply rejecting growth spending. Its numerical examples are the participant's proposal, not observed network performance. The deeper disagreement concerned what would count as success: a programme could attract activity while still issuing more tokens than its use removed. That is a question about the cost of adoption, which transaction counts alone cannot settle.

Participant jordan argued that paying builders, validators and users risked making subsidies the main reason to participate. The suggested alternative emphasized sales, business development and marketing around useful applications. In a separate response, gdad objected to complicating staking through a growth dividend. These are distinct concerns: one questions durable demand, the other the burden placed on ordinary participants. They document dissent within the discussion without establishing that either view represented most holders or that the proposed incentives were doomed to fail.

The March 2026 Battle of Nodes announcement invited validators, bug hunters and guild teams to compete while testing Supernova. Such events give the community an active ritual beyond watching price: operators stress infrastructure, builders demonstrate applications and participants compare results. A competition can generate useful engineering evidence, but incentivized test traffic should remain identified as test traffic. Its volume does not establish ordinary user retention or the economic value of production transactions.

The event belongs in both the technical history and the account of how participation is organized.

The April 2026 Agent Architecture article argued that faster deterministic settlement would make MultiversX suitable for autonomous applications. It also explicitly described mainnet activation as pending further gates at that time. This provides a dated official vision, connecting the project to another application frontier after its earlier consumer-wallet and metaverse campaigns. The defensible way to evaluate that vision is through working applications, sustained usage and their actual settlement requirements.

A new narrative or a performance improvement alone cannot establish that developers will choose the network.