Summary: =nil; is best understood as a zk-sharded Ethereum L2 that tries to make cross-shard asynchronous execution a first-class protocol primitive rather than treating sharding as a hidden validator implementation detail or delegating cross-domain composition to bridges. Its reusable mechanism is a split between execution shards, a single consensus shard, local committee consensus plus global consensus, and a master proof path back to Ethereum. That makes =nil; a useful comparison class for modular rollups, appchains, and other parallel-execution designs where the real control surface is not just throughput but who decides shard placement, how cross-shard messages become mandatory, and how much composability survives once execution is partitioned.
What it does:
Partitions global state across execution shards that process messages for the accounts assigned to them
Uses a single consensus shard to coordinate execution shards, store recent shard-block hashes, and submit globally verified state changes to Ethereum
Treats cross-shard communication as protocol-native message passing instead of bridge-style application middleware
Exposes asynchronous contract-to-contract execution, including same-shard async calls, callback patterns, and request/response flows through Solidity helper libraries and precompiles
Lets participants request contract co-location on the same shard when they want tighter execution locality at the cost of concentrated shard load and potentially higher fees
Uses smart-contract-only accounts rather than the EOA-versus-contract split familiar from Ethereum
Key claims:
The official overview defines =nil; as an Ethereum L2 powered by zkSharding with three core qualities: horizontal scalability, modularity through Ethereum DA/consensus, and verifiable security via a single proof attesting to the correctness of all shards
The principles docs make the architecture legible as execution shards plus one consensus shard, with execution shards generating per-shard proofs and the main/consensus path aggregating them into a master proof sent to Ethereum
The architecture materials say execution shards run a local Sync-HotStuff-style security protocol while the consensus shard runs a HotStuff-2-style global protocol, which means the scaling story is not only more shards but also a layered consensus design with distinct local-versus-global coordination roles
The shard docs make cross-shard messaging a hard validity condition: if a shard sees an outgoing message targeting one of its accounts, blocks are invalid unless that necessary message is included
The async-execution docs show that =nil; is not merely sharding storage or batching transactions; it is trying to normalize async message-passing semantics at the smart-contract layer through asyncCall, awaitCall, and callback-oriented request flows
The docs also show a distinctive payment model where internal messages pay for their own top-level processing while external messages are paid by the receiving contract, which is a meaningful departure from the usual externally owned account gas-payment model
Because =nil; lets users request contract co-location and makes shards responsible for copying required messages, the analytical questions are where locality, congestion, and practical composability end up once shard assignment becomes a governance and application-design problem
Whitepaper: No single canonical =nil; whitepaper surfaced during this pass. The most useful primary-source packet is the official docs set plus the public GitHub organization and zkSharding research repository; see ../whitepapers/nil-primary-sources-2026-05-13.md.