What is Volition?

Introduction

Volition is a rollup-family design that lets a transaction choose where its data will be available. That sounds like a small implementation detail, but it changes the core tradeoff in blockchain scaling: how much you pay, what you can recover from the base chain alone, and who you must trust if something goes wrong. In many systems, execution correctness and data availability are discussed together, yet they are not the same thing. Volition matters because it exposes that separation directly.

The puzzle is this: if a validity proof already shows that state transitions are correct, why should anyone care where the transaction data lives? The answer is that a proof can tell you the new state root is valid, but it cannot by itself give every user the underlying data needed to reconstruct balances, generate withdrawal proofs, or recover independently from operator failure. The hard part is not only proving that the update was correct. The hard part is making sure the data needed to use that correctness remains available.

That is the design space in which Volition sits. A conventional validity rollup puts data on-chain, so anyone can recover state from the base layer alone. A validium keeps most data off-chain, which is much cheaper and can hide account details from public chain observers, but it introduces an extra availability assumption. Volition combines these two modes and lets the choice be made at a finer granularity; often per transaction, and in some designs per application or storage region. The result is not “best of both worlds” in any absolute sense. It is a system that makes the tradeoff explicit and selectable.

How do validity proofs differ from data availability?

The easiest way to understand Volition is to separate two jobs that are often mentally bundled together.

The first job is validity: are the transactions and state transitions correct according to the protocol rules? In validity-rollup systems, this is handled by a proof system such as STARKs or SNARKs. If the proof verifies, the chain accepts that the new state commitment follows from the old one and the submitted transactions.

The second job is data availability: do users and verifiers have access to the transaction data or state diffs needed to reconstruct the state and act on it later? This is not solved merely by checking a validity proof. A proof can certify that some transition is correct without revealing or preserving the underlying ledger data for everyone.

That distinction explains why three closely related architectures exist. In rollup mode, transaction data is posted on-chain with the proof, so the base layer itself preserves availability. In validium mode, the proof still guarantees correctness, but the ledger data is stored off-chain and only a cryptographic commitment, such as a hash or root, is posted on-chain. Volition is the hybrid: some transactions use rollup-style on-chain availability, while others use validium-style off-chain availability.

This is the compression point that makes Volition click: Volition does not change whether the state transition is proven correct; it changes who is responsible for keeping the underlying data available. Once that is clear, the rest of the design follows naturally.

Why use Volition instead of a pure rollup or a pure validium?

The immediate reason is cost. Posting transaction data to a base layer like Ethereum is expensive, and for many rollup-style systems it can dominate transaction fees. StarkWare has described on-chain data availability as accounting for up to 95% of average transaction cost in some settings. If the expensive part of scaling is not the proof but the data publication, then moving some data off-chain can dramatically reduce fees.

But cost is only half the story. Off-chain data availability also changes what is publicly visible. In rollup mode, account balances or transaction details included in posted data are readable by anyone watching the chain. In validium-style systems, that data is held off-chain by a committee or some external data-availability layer, so public chain observers do not automatically see it. That can be useful for applications where confidentiality matters more than trust-minimized recoverability.

The difficulty is that these benefits are not free. If data is not on-chain, users cannot necessarily recover solely from the base layer. Their ability to exit, prove ownership, or reconstruct state may depend on some external service still providing the data. Volition was created because a single application often has transactions with very different priorities. A high-value asset transfer may justify the cost of on-chain data. A low-value in-game purchase or frequent exchange update may not.

So Volition is best seen as a response to heterogeneity. Not all transactions need the same availability guarantee, and forcing one setting on everything is often wasteful.

How does Volition mix on-chain and off-chain data availability?

At a high level, a Volition system keeps a common proving system and a common state machine, but splits the way state data is made available. In StarkWare’s description of Volition, this is expressed as having one ledger whose data is stored on-chain and another whose data is kept off-chain with a Data Availability Committee, or DAC. In Starknet’s planned design, the same idea appears as two distinct storage commitment trees: one for L1 data availability and one for L2 data availability.

The important invariant is that the proof still attests to a single coherent state transition across the system. What changes is where the data corresponding to different parts of that state is published. If a transaction touches the on-chain-availability part of the state, the relevant data is posted to the base layer. If it touches the off-chain-availability part, the transaction data is propagated and stored off-chain, while only a commitment to that data is anchored on-chain.

A commitment here is just a compact cryptographic summary (for example, a Merkle root or another state root) that binds the system to a particular dataset without putting the entire dataset on-chain. The base chain can verify that the operator is updating the committed state consistently with the proof. But if the raw data behind that commitment is unavailable, a user may be unable to reconstruct the relevant branch of the state tree or produce the witness needed for some recovery path.

This is why Volition is not merely a fee optimization toggle. It partitions the state into zones with different recovery assumptions.

A concrete example helps. Imagine a game running on a validity-based L2. A player buys a rare sword worth a large amount and also buys 200 cheap arrows. The game developer may decide that ownership of the rare sword should live in the rollup-style part of the state, meaning the purchase data is posted on Ethereum and can always be reconstructed from Ethereum alone. The arrows, being low-value and numerous, can live in the validium-style part of the state, where the data is stored off-chain and only a commitment reaches Ethereum. Both updates can still be included in the same proving system, and both can still be proven valid. But if the off-chain data provider disappears, the user’s recoverability is very different for the arrows than for the sword.

That difference is the mechanism, not an edge case.

What security guarantees change when a system uses Volition?

A common misunderstanding is to think that validium-mode transactions are somehow less correct than rollup-mode transactions. That is usually false in a validity-proof setting. The proof system still guarantees that the transition from old committed state to new committed state followed the protocol rules. StarkWare states this directly: regardless of which data-availability mode is used, transaction validity is guaranteed by STARK proofs.

What changes is not validity but availability and autonomous recovery.

In rollup mode, anyone who can read the base chain can reconstruct the relevant ledger data. That means users can typically recover the state or withdraw by interacting with the base chain alone, without depending on an operator, committee, or external DA network to hand them missing records. This is why rollups are often described as inheriting stronger base-layer security for data availability.

In validium mode, the base chain knows a commitment to the data, but not the data itself. So if the operator or committee withholds data, the system may remain provably correct in a narrow state-transition sense while becoming unusable for affected users. Ethereum.org’s validium explainer captures the core failure mode: if data availability managers withhold state data, users may be unable to compute the Merkle proofs needed to withdraw funds.

Volition therefore gives a menu of guarantees, not a single guarantee. Rollup-mode transactions inherit the stronger on-chain data-availability guarantee. Validium-mode transactions inherit the off-chain system’s trust and liveness assumptions.

That distinction is the heart of every serious Volition discussion. If a product markets Volition only as “cheaper rollups,” it is hiding the most important part.

What is a Data Availability Committee (DAC) and what risks does it introduce?

In many validium and Volition designs, off-chain data is held by a Data Availability Committee. The committee’s job is simple in concept and difficult in consequence: it stores the ledger data and attests that the data for a given batch is available.

In StarkEx-style validium systems, the committee stores off-chain ledger information, while the chain stores only a hash or other commitment. Committee members can sign batches to attest availability before state updates are accepted. This reduces the risk that the operator posts a valid state commitment while quietly withholding the underlying data.

Still, a DAC is an added trust assumption. You do not need to trust it to judge whether a proven state transition was mathematically valid. You do need to trust, or at least assume, that the committee will keep the data accessible when users need it. Research on DAC security makes the tradeoff explicit: off-chain committees avoid L1 data costs, but they also move the system away from the ideal where security depends solely on the base chain.

This is where wording matters. Saying “the system is secured by validity proofs” is true but incomplete. For a validium branch of a Volition system, correctness of state updates and availability of the state data come from different places.

Some systems try to strengthen this with economics rather than a small trusted committee. Research on cryptoeconomic DACs proposes staking and slashing to deter withholding. Other architectures replace committees with dedicated data-availability layers and bridges that attest to off-chain publication. The mechanism varies, but the underlying question does not: when data is not on the base layer, what credible process ensures users can get it later?

Can Volition be used across different chains and data-availability layers?

Volition is often introduced through StarkWare systems, but the underlying idea is broader than a single product. Any architecture that combines validity proofs with a selectable choice between on-chain and off-chain data availability is in the same conceptual family.

That is why the term appears outside StarkWare as well. Ethereum.org describes volitions as hybrids of ZK-rollups and validiums. Avail’s documentation describes Volition as letting users choose, per transaction, whether data is posted on-chain or kept off-chain with an external DA layer. Avail’s Data Attestation Bridge is explicitly positioned as an enabler for Validium and Volition modes across different rollup stacks.

The reason this generalizes is straightforward. A proving system tells you whether computation was done correctly. A data-availability layer tells you whether the underlying transaction data is retrievable. Those functions can be combined in different ways across ecosystems. You can anchor proofs on one chain, publish some data to that chain, and publish other data to a separate DA system or committee. If the user or application can choose between those modes for different transactions or state partitions, you have the essence of Volition.

What changes across ecosystems is not the concept but the trust surface. A DAC, an L2-operated DA network, and an external DA chain all have different failure modes and liveness assumptions. Volition does not remove those differences. It makes them selectable.

What implementation and recovery edge cases should developers watch for with Volition?

The appealing story is easy: expensive important transactions go on-chain, cheap less-important ones go off-chain. But once you think about state as a single evolving object, some harder questions appear.

If one part of the state has Ethereum-backed data availability and another depends on a DAC or L2 network, how exactly do they stay consistent under one proof? Starknet’s answer, at a high level, is dual commitment trees. That gives a clean structural separation: one commitment tracks the L1-DA state and another tracks the L2-DA state. The proof covers updates to both. This explains how the system can mix modes without losing integrity.

What the public explainers generally do not fully spell out is the complete operational story under stress: how cross-tree interactions are handled in detail, what the exact recovery procedures are during an L2 DA crisis, and how users experience these distinctions in wallets and applications. Those are not signs that the concept is unsound; they are reminders that the implementation burden is significant.

This is also why StarkWare has recommended that developers using weaker DA modes design contracts that can continue to function, even if assets tied to L2 data availability are lost or become inaccessible in a DA crisis. That guidance is revealing. It means Volition should not be understood as a local optimization inside an otherwise unchanged app. It can affect application-level failure handling and contract design.

Which real-world applications benefit most from Volition?

The natural use cases are the ones where value and frequency diverge.

Games are an obvious example. High-value items, rare collectibles, or assets intended for open secondary markets may justify on-chain data availability because ownership recovery matters a great deal. Low-value consumables, frequent inventory changes, or rapid gameplay events may benefit more from cheaper off-chain availability.

Exchanges and trading applications are another case. A trader may prefer low-cost, high-frequency updates for ordinary activity, while larger balances or more safety-sensitive positions may justify stronger availability guarantees. StarkWare has described this kind of split explicitly: low-fee trading activity on the cheaper side, with larger balances moved to the more secure side when needed.

NFT and consumer applications also fit the model because they often contain a mix of assets that are socially or economically very different. A single platform may host both premium items whose ownership should survive operator failure with minimal assumptions and ordinary items where users are comfortable accepting more platform trust in exchange for lower fees.

What all these examples share is a mismatch between a single global security setting and the actual value distribution of user actions. Volition exists to price that mismatch more efficiently.

What are the failure modes if off-chain data becomes unavailable?

The key failure mode is not invalid state transition. It is data unavailability.

Suppose the validium branch of a Volition system relies on a DAC. The operator produces a valid proof and the on-chain contract accepts the new commitment. Later, users need the underlying off-chain records to reconstruct balances or generate withdrawal data. If the committee withholds that data or becomes unavailable, the affected portion of the system may become practically unrecoverable for users, even though the accepted state root was valid at the time it was posted.

That is why people sometimes say validium can freeze funds. The phrase is slightly imprecise but directionally right: users may not be able to prove what they own or exit independently if the necessary data was never posted on-chain and later cannot be obtained.

StarkWare notes a partial mitigation in some StarkEx validium settings: a user seeking trustless withdrawal may require the digital signature of one DAC member to prove ownership. That is better than needing universal committee cooperation, but it is still not the same as recovery from chain data alone. It remains an extra assumption.

More broadly, if a Volition system uses an external DA layer rather than a committee, the guarantees follow that external layer’s model. An optimistic attestation bridge, for example, creates a different security envelope from direct on-chain publication. A dedicated DA chain with sampling-based guarantees creates yet another. The central lesson is stable across all of them: Volition inherits the availability model of whichever mode each transaction chooses.

How does Volition change wallet and application UX and what should developers show users?

A protocol designer may find this elegant. A user may find it confusing.

Per-transaction choice sounds empowering, but it also means the same wallet or application can contain assets with different recovery properties. Two balances shown side by side may look equally real in the interface while depending on very different assumptions underneath. If this is not communicated clearly, Volition can create hidden risk rather than transparent choice.

So the hardest part may not be proof engineering. It may be product design. Users need to know not only what they own but under what availability mode they own it. Developers need sensible defaults, warnings for high-value actions, and contract logic that behaves predictably if the weaker DA path fails.

This is where Volition differs from many lower-level scaling primitives. It is not just a backend optimization. It changes the semantics of user safety in a way the frontend must expose.

Volition vs. rollup vs. validium: how do they compare?

Volition is easiest to place between two cleaner extremes.

A pure rollup says: all relevant transaction data goes on-chain. You pay more for publication, but users can recover from the base layer alone. A pure validium says: the proof still guarantees correct execution, but data is kept off-chain. You pay less and may get more confidentiality, but availability now depends on an external provider, committee, or DA layer.

Volition says: neither extreme is always the right answer, so let the mode vary across the system.

That flexibility is its advantage and its burden. It is more economically expressive than a pure rollup and less trust-minimized than a pure rollup. It is safer than putting everything in validium mode, but more complex than doing so. In that sense, Volition is not a new security model so much as a policy layer over data availability.

Conclusion

Volition is a hybrid scaling design that lets transactions choose between rollup-style on-chain data availability and validium-style off-chain data availability. The crucial point is that the validity proof can stay the same while the availability guarantee changes. That is why Volition can lower costs or improve confidentiality for some activity without giving every transaction the same recovery properties.

The idea to remember is simple: Volition separates “was this state update correct?” from “who keeps the data available afterward?” and lets different transactions answer the second question differently. That flexibility is powerful, but it only helps if users and developers understand exactly what they are trading away when they choose the cheaper path.

How does this part of the crypto stack affect real-world usage?

Volition changes which layer or party must provide transaction data after a state update, so it directly affects how easily you can recover funds or prove ownership if something goes wrong. Before you fund or trade assets tied to an L2 that uses Volition, confirm each asset’s data-availability mode and use Cube Exchange to control exposure and execute trades once you understand the recovery model.

1. Check the project's DA mode in its docs or contract: look for terms like “Volition,” “validium,” “rollup,” “Data Availability Committee,” or dual commitment trees and note whether commitments or raw data are posted on-chain.
2. Verify the withdrawal/recovery path required: confirm whether withdrawals need only on-chain Merkle proofs or also require DAC signatures or off-chain archives; find explicit instructions or API endpoints that produce the proof material.
3. Do a small deposit-and-withdraw test: deposit a minimal amount, then withdraw and time the process; confirm the exact evidence the protocol or operator returns (Merkle branch, DAC signature, or external attestation).
4. Use Cube to manage exposure: fund your Cube account, limit large balances to assets whose projects post on-chain data availability, and use lower-risk position sizing for assets that rely on off-chain DA before trading or holding significant value.