This post introduces a proposed new EVM feature: Transient Block Storage - a block-scoped key-value store that:
- Persists across all transactions within a single block
- Is automatically cleared at the end of the block
- Enables native onchain coordination between multiple transactions
- Complements EIP-1153’s transient storage (which is tx-scoped)
We propose two new opcodes:
BSTORE(bytes32 key, bytes32 value)
- sets a value for the current blockBLOAD(bytes32 key) returns (bytes32)
- retrieves a value (returns 0 if unset)
Motivation
EIP-1153 introduced transient storage for ephemeral intra-transaction state. However, many advanced protocols require ephemeral state that spans multiple transactions in the same block, but is still cleared at block end. Transient Block Storage offers a native mechanism for:
- Aggregating multi-user intents across a block
- Executing batched or netted finalizations only once per block
- Coordinating protocols in a gas-efficient, onchain-native way
- Enabling Application-Specific Sequencing (ASS) to combat MEV
Today, these goals require costly or centralized workarounds:
- Persistent storage (gas-heavy, requires cleanup)
- Offchain mempools or relays (introduce trust and censorship risk)
- Rollup-native sequencers (fragmented and L2-specific)
Transient Block Storage fills this gap at the base layer.
Key Use Cases
MEV Resistance via Application-Specific Sequencing
Protocols can implement Application-Specific Sequencing using Transient Block Storage:
-
Users submit signed intents via public
registerIntent()
calls -
Intents are recorded in transient block storage
-
At the end of the block, the protocol deterministically processes the full set via
finalizeBlock()
:- Canonical order (FIFO, gas price, reputation, etc.)
- Netting, batching, matching
This eliminates frontrunning and sandwich attacks by deferring execution until after intent collection is complete - without any offchain infra or special builder privileges.
Multi-Asset Batching (Multiswap)
In Multiswap, a multi-asset AMM, users trade multiple tokens into and out of a shared pool. To minimize slippage and maximize capital efficiency:
- Users submit swap intents throughout the block
- The protocol aggregates all intents in transient block storage
- A finalizer calls
finalizeBlock()
at block end, solving a single master equation for all trades - The net trade is executed atomically across all assets
All users receive execution at the same fair prices, determined by the global value-preserving equation. There is no opportunity for frontrunning or preferential execution, since pricing is based on the aggregate net flow rather than transaction order.
Transient Block Storage enables this by holding intents onchain during the block without polluting persistent storage or incurring high gas costs.
Semantics
-
Key-value storage (
bytes32 => bytes32
) -
Shared across all contracts and transactions in the current block
-
Cleared at block end by client implementation
-
Not persisted to the state trie
-
Not eligible for gas refunds
-
Opcodes:
BSTORE(key, value)
BLOAD(key)
Design Considerations
- Cost: Read/write gas costs should be lower than
SSTORE
and similar toTSTORE
- Client requirements: Requires block-local memory structure, flushed at block finalization
- Abuse prevention: Recommend key hashing and namespaces to avoid cross-contract collisions
- Finalization: Execution of stored intents can be permissioned, decentralized, or randomized
Update Log
- 2025-05-22: Initial draft, [GitHub PR link TBD]
External Reviews
None as of 2025-05-22.
Outstanding Issues
None as of 2025-05-22.