Volition

In blockchain architecture, a Volition is a system, pioneered by StarkWare on StarkEx, that gives users granular control over data availability (DA). For each transaction, a user can choose to post their data to the base layer (e.g., Ethereum mainnet) for maximum security or to a separate data availability committee (DAC) or validium layer for significantly lower costs. This choice directly trades off between security guarantees and transaction fees, creating a flexible, user-centric model for scaling.

The core mechanism involves two distinct data paths. When a user selects on-chain data availability, the transaction's critical state data is published as calldata on the Layer 1, ensuring it is permanently accessible and verifiable by anyone, matching the security of a zk-rollup. If the user opts for off-chain data availability, the data is held by a trusted committee or a decentralized network, and only a cryptographic proof (like a ZK-STARK or ZK-SNARK) is posted on-chain. This drastically reduces L1 gas costs but introduces a trust assumption regarding the committee's honesty and liveness.

This architecture is particularly impactful for applications with diverse security needs. For example, a high-value NFT trade or a large DeFi position settlement might justify the cost of on-chain DA, while low-value, high-frequency trades in a gaming application would benefit from the cost savings of off-chain DA. By not forcing a one-size-fits-all solution, Volition provides a pragmatic middle ground between pure rollups and pure validiums, enabling more efficient capital deployment across different use cases within the same ecosystem.

A Volition is a system architecture, pioneered by StarkWare, that provides users with granular control over data availability (DA). For each transaction, a user can select between two security models: on-chain data availability, where transaction data is published to a Layer 1 (e.g., Ethereum), ensuring maximum security and verifiability, or off-chain data availability, where only cryptographic proofs are posted on-chain, with data held by a separate committee or data availability committee (DAC). This choice directly impacts cost and security, creating a flexible trade-off for different application needs.

The core mechanism relies on validity proofs, such as STARKs or SNARKs. Regardless of the data location, a zero-knowledge proof is generated to attest to the correctness of a batch of transactions. This proof is always posted and verified on the Layer 1. The critical difference lies in what accompanies it. In on-chain mode, the full transaction data is published in calldata, allowing anyone to reconstruct the state. In off-chain mode, the data is made available through an external network, and the Layer 1 smart contract verifies a cryptographic commitment to that data, trusting the designated committee to provide it upon request for fraud challenges.

This architecture enables significant cost optimization. Posting data to a high-security Layer 1 like Ethereum is expensive. By allowing applications like high-frequency decentralized exchanges or social networks to opt for secure off-chain data for most transactions, gas fees are drastically reduced. Users performing high-value settlements, such as large NFT trades or institutional transfers, can still choose the maximum security of on-chain data for those specific actions, paying a higher fee for that guarantee. This per-transaction selectivity is a key differentiator from hybrid rollups with fixed DA policies.

From a security perspective, the on-chain DA path inherits the full security of the underlying L1. The off-chain path's security depends on the data availability committee model. A robust DAC with a sufficient number of honest, geographically distributed members and strong economic incentives or slashing conditions is crucial. The system is designed so that if the off-chain data becomes unavailable, the chain's progress halts—a property known as liveness failure—but the proven state remains secure and verifiable, preventing invalid state transitions.

In practice, a user's wallet or dApp interface presents the DA choice at the point of transaction signing, often framing it as a "security tier" or cost option. Developers can also set default policies for their applications. This model is foundational to appchains and sovereign rollups built with frameworks like StarkEx and Polygon Miden, providing a customizable data layer that balances the blockchain trilemma of scalability, security, and decentralization according to specific use-case requirements.

In blockchain, a volition is a hybrid data availability architecture that allows users to choose, on a per-transaction basis, whether their data is posted to a public blockchain (like Ethereum) or kept off-chain on a separate data availability layer (like a Validium). This concept was first formally proposed and coined by StarkWare in 2020 as a core feature of their Layer 2 scaling solution, StarkEx. The name was chosen to reflect the user's volition—their will or choice—in deciding the security and cost trade-off for each transaction, a fundamental shift from system-level decisions.

The etymology directly borrows from the Latin volitio, meaning 'will' or 'act of willing.' In the context of ZK-Rollups, this choice is critical: opting for on-chain data availability provides the full security guarantees of the underlying Layer 1, similar to a ZK-Rollup, while choosing off-chain data offers significantly lower fees but introduces different trust assumptions regarding data availability, akin to a Validium. StarkWare's implementation allows applications like dYdX and ImmutableX to offer this configurable security model to their users.

This architectural innovation addressed a key dilemma in scaling: the trade-off between cost and security. Before volitions, a rollup protocol had to commit to a single data availability model for all its transactions. The volition model modularizes this choice, pushing it to the end-user or application. It represents a move towards more granular and user-centric design in blockchain scalability, where the security level is a selectable parameter rather than a fixed property of the chain itself.