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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 6
Code
Source, repository, and what is actually hosted
- MultiversX (formerly Elrond)https://multiversx.com/
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
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.
Claim 05 · Paper model
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.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 Three things can be sharded
Observation
What the study says
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.
Model
What has to hold
The metachain has higher assurance than any single shard, because every cross-shard receipt depends on it.
02 Adaptive means the shard count is not a constant
Observation
What the study says
If more validators join, the protocol is supposed to create more shards rather than make each shard more crowded. That is the scaling sentence.
Model
What has to hold
The metachain has higher assurance than any single shard, because every cross-shard receipt depends on it.
Falsifier
What would retire it
How many shards are live, and has that number ever changed by the adaptive rule?
03 A metablock stitches shards
Observation
What the study says
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.
Model
What has to hold
The metachain has higher assurance than any single shard, because every cross-shard receipt depends on it.
Falsifier
What would retire it
Where does a cross-shard call sit between the source block and the destination execution?
04 Secure proof of stake selects validators
Observation
What the study says
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.
Model
What has to hold
Random assignment is unbiasable and frequent enough that a captured shard cannot sit forever.
05 The virtual machine is part of the bet
Observation
What the study says
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.
Model
What has to hold
Contracts expose enough routing information to pick a destination shard without executing the call first.
Falsifier
What would retire it
Where does a cross-shard call sit between the source block and the destination execution?
03 Sequence
One action, as an operating tape
- 01Stake-weighted randomness assigns a validator to a shard for the round.
- 02A user sends a transaction to the shard that holds the sender's account.
- 03The shard's consensus group produces a block and a proof that the group signed it.
- 04The metachain includes a notarisation of that shard block. A cross-shard call waits for this notarisation before the destination executes it.
- 05If the validator set grows past a threshold, a later round reconfigures the number of shards and reshuffles assignments.
04 Load-bearing
The argument, and where a pitch drops it
State sharding is the hard one
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Metachain liveness is a single place the design can still stall, even if shards are many.
Adaptive cuts both ways
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The paper is not a performance certificate for the live network.
Notarisation is not execution
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Metachain liveness is a single place the design can still stall, even if shards are many.
05 Register
What has to be true
Cryptography · Not re-measured
Random assignment is unbiasable and frequent enough that a captured shard cannot sit forever.
Model · Not re-measured
The metachain has higher assurance than any single shard, because every cross-shard receipt depends on it.
Model · Not re-measured
Contracts expose enough routing information to pick a destination shard without executing the call first.
Network · Not re-measured
Resharding moves state correctly. A misplaced account is a loss, not a delay.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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 the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
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.