Glossary

Volition

A volition is a hybrid rollup architecture where users choose between on-chain or off-chain data availability on a per-transaction basis.

Key Takeaways

  • A volition lets users choose between rollup mode (on-chain data availability) and validium mode (off-chain data availability) on a per-transaction basis, combining the security of rollups with the cost savings of validiums.
  • On-chain data availability can account for up to 95% of a Layer 2 transaction's cost: volitions let users opt out of that expense when full Ethereum-grade security is not required.
  • StarkNet and zkSync are the leading implementations: StarkNet uses two separate storage commitment trees (L1 and L2), while zkSync's ZK Stack supports configuring chains as rollup, validium, or volition.

What Is a Volition?

A volition is a hybrid data availability architecture for Layer 2 scaling solutions. It gives users and developers the ability to choose, on a per-transaction basis, whether transaction data is posted on-chain (rollup mode) or stored off-chain (validium mode). This flexibility means a single network can serve both high-security and low-cost use cases without forcing every user into the same tradeoff.

The term was introduced by StarkWare to describe a system that sits between a pure ZK-rollup and a pure validium. In a ZK-rollup, all transaction data is posted to Ethereum, guaranteeing that anyone can reconstruct the state and withdraw funds trustlessly. In a validium, data is kept off-chain with a Data Availability Committee (DAC), reducing costs dramatically but introducing a trust assumption. A volition combines both modes in one system, letting each transaction pick the appropriate point on the security-cost spectrum.

How It Works

A volition maintains two parallel data availability paths within a single Layer 2 network. Both paths share the same execution environment, sequencer, and validity proof system. The only difference is where the underlying state data lives.

Rollup Mode (On-Chain DA)

When a user selects rollup mode, the transaction's state changes are posted to Ethereum as calldata or blob data. This provides the strongest security guarantee: anyone can reconstruct the full state from Ethereum alone, and users can always force withdrawals through the L1 contract even if the sequencer goes offline.

  • Full Ethereum security inherited for state reconstruction
  • Trustless forced exits through L1 smart contracts
  • Higher cost due to Ethereum gas fees for data posting

Validium Mode (Off-Chain DA)

When a user selects validium mode, the transaction's state changes are stored off-chain, typically with a Data Availability Committee (DAC). Only a commitment (a hash of the state) is posted to Ethereum. The validity proof still verifies correct execution, but reconstructing the state requires cooperation from the DAC.

  • Significantly lower cost: no Ethereum gas paid for data storage
  • Privacy benefits: transaction data is not publicly visible on-chain
  • Trust assumption: users must trust the DAC to remain available and honest

Dual Commitment Trees

In StarkNet's implementation, the volition architecture uses two distinct storage commitment trees: one for L1 data availability mode and one for L2 data availability mode. Both trees are included in the state root verified by the validity proof on Ethereum.

// Conceptual volition state structure
VolitionState {
  L1_DA_Tree: MerklePatriciaTree   // Data posted to Ethereum
  L2_DA_Tree: MerklePatriciaTree   // Data stored off-chain (DAC)

  // Both trees are committed in the validity proof
  state_root = hash(L1_DA_Tree.root, L2_DA_Tree.root)
}

// Per-transaction DA choice
Transaction {
  da_mode: "L1" | "L2"   // User selects per transaction
  // ... other transaction fields
}

The L1 DA tree's data is posted to Ethereum with every batch. The L2 DA tree's data is communicated only within the L2 network, and just the root commitment is sent to L1 as part of the validity proof. This means both modes benefit from the same zero-knowledge proof guaranteeing correct execution, but they differ in data recoverability.

Implementations

StarkNet

StarkWare pioneered the volition concept and deployed it first in StarkEx (version 4.5). In StarkEx, each account can be designated as either an Off-Chain Data (OFFD) or On-Chain Data (OND) account. StarkNet extends this to smart contracts, where developers can choose the data availability mode at the individual storage variable level within a contract.

StarkNet's volition is part of its broader roadmap to reduce transaction costs. Since on-chain data availability alone can account for up to 95% of the average transaction cost on a ZK-rollup, offering an off-chain alternative creates dramatic savings for applications that can tolerate the DAC trust assumption.

zkSync (ZK Stack)

zkSync's ZK Stack framework allows chains to configure their data availability as rollup, validium, or volition. In volition mode, the chain supports both DA modes simultaneously, letting users and applications choose per transaction. This is particularly relevant for zkSync's Hyperchain architecture, where different chains in the ecosystem can adopt different DA configurations based on their use case.

Cost Comparison

The cost difference between rollup mode and validium mode within a volition is substantial. On-chain data posting is the dominant cost in ZK-rollup transactions, so bypassing it in validium mode can reduce fees by an order of magnitude or more.

FactorRollup Mode (On-Chain DA)Validium Mode (Off-Chain DA)
Data locationEthereum (calldata or blobs)Off-chain (DAC)
Transaction costHigher (L1 gas for data)Lower (no L1 data cost)
Security modelEthereum-equivalentDAC trust assumption
Forced exitTrustless via L1 dataRequires DAC cooperation
Data privacyPublic on EthereumPrivate (DAC only)
State reconstructionAnyone can reconstructDAC must provide data

The introduction of EIP-4844 blob transactions has reduced rollup-mode costs on Ethereum, but validium mode still offers significant savings for high-throughput applications. For more on how blob fees affect Layer 2 economics, see the research on EIP-4844 blob fee markets.

Use Cases

The per-transaction flexibility of a volition makes it well suited for applications where different operations have different security requirements.

High-Frequency Trading

A trading firm could move funds to validium-mode accounts at the start of a trading day for inexpensive, frequent trades, then transfer balances back to rollup-mode accounts at the end of the day for maximum security during overnight holding. This pattern minimizes costs during active trading while preserving full Ethereum security for asset custody.

Gaming and Social Applications

In-game asset transfers and social interactions generate high volumes of low-value transactions. These can run in validium mode for minimal cost. When a player wants to withdraw valuable items or sell assets, those critical transactions use rollup mode for trustless settlement guarantees.

Enterprise and Compliance

Regulated entities may prefer validium mode for certain transactions where data privacy is important: off-chain DA keeps transaction details visible only to the DAC rather than publishing them on Ethereum. When regulatory audits or settlements require verifiable on-chain records, those transactions use rollup mode.

DeFi Protocols

DeFi protocols can use rollup mode for high-value operations like large swaps, liquidations, or governance votes where trustless data availability is critical. Routine operations like small trades, fee claims, or position updates can use validium mode to reduce user costs.

Risks and Considerations

DAC Trust Assumptions

Validium-mode transactions within a volition depend on the Data Availability Committee remaining honest and available. If the DAC withholds data, users in validium mode cannot independently reconstruct the state needed to prove asset ownership and force withdrawals on L1. The security of validium-mode funds is only as strong as the DAC itself.

State Fragmentation

Maintaining two parallel commitment trees adds complexity to the protocol. Assets in the L1 DA tree and L2 DA tree may not be directly fungible without explicit transfer operations between modes. This fragmentation can complicate smart contract design and user experience if not handled carefully at the application layer.

Composability Challenges

Cross-mode interactions introduce complexity. A DeFi contract in rollup mode that needs to read state from a validium-mode contract faces data availability mismatches. The validity proof guarantees correct execution in both modes, but application-level composability may require careful architecture to handle transactions spanning both DA modes.

User Complexity

Asking users to choose a data availability mode per transaction introduces decision complexity. Most users are not equipped to evaluate the security-cost tradeoff for each transaction. Successful volition implementations need smart defaults: wallet interfaces or applications that automatically select the appropriate mode based on transaction value, type, or user preference, rather than surfacing raw DA choices.

Volitions in the Broader Scaling Landscape

Volitions represent one point on the data availability spectrum for Layer 2 networks. Pure ZK-rollups sit at the highest-security end, posting all data on-chain. Pure validiums sit at the lowest-cost end, keeping all data off-chain. Volitions occupy the middle, offering both options simultaneously.

Other approaches to flexible data availability include data availability sampling (used by Ethereum's danksharding roadmap) and external DA layers like Celestia or EigenDA. These solutions address the same fundamental tension between cost and security but at different layers of the stack. For a deeper comparison of scaling approaches, see the research on rollup vs. state channel scaling tradeoffs and Ethereum L2 rollup fee dynamics.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.