LibraryConsensus2019Design paperCorpus record
Elrond: A Highly Scalable Public Blockchain via Adaptive State Sharding
MultiversX. The Elrond team.
The 2019 Elrond paper on adaptive state sharding: shards that hold state, a metachain that notarises results, and a secure proof-of-stake selection of validators. The network later rebranded as MultiversX. The paper remains the design document.
Elrond, later MultiversX, proposes adaptive state sharding: accounts, transactions and validators are all split, and the split changes size as the network grows.
The five-minute read
Three things can be sharded
You can split the validator set, the transaction flow, or the state. The paper argues for doing all three, so a shard holds only its accounts and only its validators execute them.
Adaptive means the shard count is not a constant
If more validators join, the protocol is supposed to create more shards rather than make each shard more crowded. That is the scaling sentence.
A metablock stitches shards
Shard blocks are notarised into a metachain block. Cross-shard calls become receipts that the metachain tracks. The metachain is the single place an observer can see that the shards agreed.
Secure proof of stake selects validators
A randomness source and stake together pick who serves in a shard for a round. The paper's security claim is that an attacker cannot gather themselves into one shard.
The virtual machine is part of the bet
A WASM-based VM is specified so contracts are not tied to one language family. Sharding still requires that a call's destination shard is knowable.
One action, walked through
- Stake-weighted randomness assigns a validator to a shard for the round.
- A user sends a transaction to the shard that holds the sender's account.
- The shard's consensus group produces a block and a proof that the group signed it.
- The metachain includes a notarisation of that shard block. A cross-shard call waits for this notarisation before the destination executes it.
- If the validator set grows past a threshold, a later round reconfigures the number of shards and reshuffles assignments.
The argument, unpacked
State sharding is the hard one
Splitting validators is a committee problem. Splitting state means most nodes cannot answer a question about most accounts. Light clients, wallets and indexers all depend on the metachain being a sufficient directory. If it is not, the chain has sharded itself into silence.
Adaptive cuts both ways
More shards when more validators arrive is how throughput is supposed to track participation. It is also a reconfiguration event, which is when state has to move. The paper is only as strong as its reshuffle. A network that never actually changes shard count has not tested the adjective in the title.
Notarisation is not execution
A metablock that commits a shard header does not re-execute the shard's transactions. Safety across shards rests on the signature threshold inside the shard plus the metachain's availability. Say which of those you are trusting.
What has to be true
- Random assignment is unbiasable and frequent enough that a captured shard cannot sit forever.
- The metachain has higher assurance than any single shard, because every cross-shard receipt depends on it.
- Contracts expose enough routing information to pick a destination shard without executing the call first.
- Resharding moves state correctly. A misplaced account is a loss, not a delay.
What happened after the paper
The project renamed itself MultiversX and continued from this design into a live network with its own VM and tooling. Economics, the exact consensus variant, and shard counts are subsequent parameters. The 2019 paper is the adaptive state-sharding argument, not a current network dashboard.
What to check before you use the idea
- How many shards are live, and has that number ever changed by the adaptive rule?
- What does a wallet trust when it wants an account that is not in its own shard?
- How many validators must collude to forge one shard's notarisation?
- Where does a cross-shard call sit between the source block and the destination execution?
Terms
- State sharding
- Giving each shard only a slice of accounts, so validators do not hold the full ledger.
- Metachain
- The coordinating chain that notarises shard blocks and tracks cross-shard receipts.
- Adaptive sharding
- Changing how many shards exist as participation changes, rather than fixing the number in a genesis file.
- Notarisation
- A signed commitment that a shard block happened, recorded where other shards can see it.
The problem the paper names
Transaction sharding without state sharding pushes the bottleneck into whoever still holds the full state. The paper's claim is that state, transactions and network can be sharded together, with a metachain that certifies shard results.
What the design proposes
- A metachain records shard headers and cross-shard outcomes.
- Validator selection uses stake plus a random sample, with reshuffling.
- Adaptive means the number of shards is not a constant carved into the genesis story.
How the mechanism is specified
- A cross-shard transfer is a protocol dance between source shard, metachain and destination shard. It is not one atomic call.
- The security argument depends on the cost of entering a shard and on the randomness.
- The rebrand did not rewrite the 2019 text. Current client behaviour has to be read from current docs.
What this page does not treat as proven
- The paper is not a performance certificate for the live network.
- Metachain liveness is a single place the design can still stall, even if shards are many.
- We do not describe token terms or later product modules.
Why a venture studio still reads it
State sharding is the version of 'scale' that actually changes what a node stores. If a pitch shards execution but every node keeps every account, it has not adopted this paper's problem statement.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.