World Chain Specs

Abstract

World Chain today derives all of its security from Ethereum: the safe and finalized heads are derived from L1, and the unsafe head — the segment of the chain built by the sequencer but not yet posted to L1 — carries no economic security and is extendable by exactly one party. This WIP introduces a secondary consensus layer over the unsafe chain, composed of validators staking WLD in an L2 predeploy.

Validators perform two duties. First, a per-block committee of validators each contributes a subblock: a signed, bounded, ordered transaction list that the sequencer’s block builder MUST place at the start of the block, ahead of its own mempool-derived contents. Every subblock carries a mandatory WIP-1007 Flashblock Access List, so the builder verifies and stitches pre-executed subblocks in parallel and the subblock region is streamed as the first flashblock of the block, preserving the 200 ms flashblock cadence. Second, every active validator verifies each new unsafe block and signs a BLS attestation over it. When attestations representing ≥ 2/3 of active stake are aggregated, the block obtains an attestation certificate and becomes attested — a new head label between unsafe and safe. Reorging an attested block requires equivocation by ≥ 1/3 of stake, all of it attributable and slashable.

The sequencer remains the sole block producer and aggregator; L1 derivation is unchanged. The overlay adds accountable safety and multi-party inclusion to the unsafe chain without touching the OP Stack derivation pipeline, and it degrades gracefully: if every validator is offline, World Chain produces blocks exactly as it does today.

Motivation

Three gaps motivate this proposal:

1. No economic security on the unsafe head. Between block production and L1 finalization, the chain tip is backed only by the sequencer’s reputation. Flashblocks give users 200 ms pre-confirmations, but a pre-confirmation is a promise from a single operator. Applications settling real value against the unsafe head (payments, exchange deposits) have no slashable counterparty if that promise is broken. An attestation certificate converts “the sequencer said so” into “reorging this block costs at least 1/3 of total staked WLD.”

2. Single-party inclusion. Every transaction on World Chain today is included at the discretion of one sequencer. Priority Blockspace for Humans (PBH) shapes ordering within the block, but not who controls entry. Subblocks give a rotating committee of independent, staked proposers a protocol-guaranteed region at the front of every block. A user who believes they are being censored can submit to any committee member, and omission of a valid subblock is attributable, attestation-blocking, and eventually slashable.

3. WLD utility. World Chain has no native staking function for WLD. Validators stake WLD to earn subblock priority fees and attestation rewards, giving the asset a productive, protocol-native role and sharding a portion of block revenue across the validator set.

The design deliberately keeps the sequencer as a meta-aggregator: subblocks compose the start of the block, and the sequencer extends them with transactions from its own mempool. This preserves the existing builder pipeline, flashblock streaming, PBH semantics, and — critically — chain liveness that does not depend on validator liveness.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Terminology

• Validator — an entity that has staked WLD in the StakeManager predeploy and is in the active set. Runs a full World Chain node plus a validator sidecar. (Distinct from the transaction-validation component of the builder.)
• Subblock — a signed, ordered transaction list produced by a validator selected for block N’s subblock committee.
• Subblock committee — the SUBBLOCK_COMMITTEE_SIZE validators eligible to submit a subblock for a given block.
• Attestation — a validator’s BLS signature over an unsafe block it has verified.
• Attestation certificate — an aggregate of attestations representing ≥ QUORUM_NUMERATOR/QUORUM_DENOMINATOR of active stake for one block.
• Attested head — the highest block with a known certificate; exposed as the attested block tag, ordered unsafe ≥ attested ≥ safe ≥ finalized.

Parameters

Provisional values; final numbers to be fixed before Review status.

Validator registry: the StakeManager predeploy

A new predeploy (address TBD in the World Chain predeploy namespace) is the single on-chain root of trust for the overlay:

interface IStakeManager {
    function register(bytes calldata blsPubkey, bytes calldata p2pPubkey, bytes calldata possessionProof) external; // locks msg.value-equivalent WLD via permit/transferFrom
    function deposit(uint256 amount) external;
    function initiateExit() external;
    function withdraw() external;                       // after WITHDRAWAL_DELAY
    function submitCertificate(AttestationData calldata data, bytes calldata aggSig, bytes calldata participation) external;
    function slash(bytes calldata evidence) external;   // permissionless; whistleblower reward
    function activeSet(uint64 epoch) external view returns (ValidatorInfo[] memory);
}

• Registration requires MIN_STAKE WLD, a BLS12-381 public key with a proof of possession, and an ed25519 P2P key for the flashblocks network.
• The active set for epoch e is the top MAX_ACTIVE_VALIDATORS by stake, snapshotted at the last block of epoch e − 2 (one full epoch of activation delay). All duties and quorum weights for epoch e are computed against this snapshot, so every node derives an identical validator set from chain state alone.
• BLS aggregate verification in submitCertificate and slash uses the EIP-2537 precompiles.

Duty assignment

For block N in epoch e, the subblock committee is a deterministic, stake-weighted sample without replacement of SUBBLOCK_COMMITTEE_SIZE validators from the epoch-e active set, seeded by:

seed(N) = keccak256(epoch_seed(e) ‖ uint64(N))
epoch_seed(e) = keccak256(l1_origin_hash(first block of epoch e − 1))

The seed is fixed one epoch in advance and derived from an L1 block hash already embedded in the L2 chain, so assignment is computable by every node and not grindable by the sequencer. Attestation duty is not sampled: every active validator attests every block.

Subblocks

Structure

#![allow(unused)]
fn main() {
pub struct SubBlock {
    pub chain_id: u64,
    pub block_number: u64,
    /// Unsafe head the proposer built against. Advisory: the builder
    /// re-validates against the actual parent (see Inclusion semantics).
    pub parent_hash: B256,
    pub validator_index: u16,
    /// EIP-2718 transaction envelopes, in proposer order.
    pub transactions: Vec<Bytes>,
    /// WIP-1007 Flashblock Access List for `transactions` executed
    /// against `parent_hash` state, plus its keccak256 commitment.
    /// REQUIRED: a subblock without a verifiable access list is invalid
    /// (validity condition 5).
    pub access_list: FlashblockAccessList,
    pub access_list_hash: B256,
}

pub struct SignedSubBlock {
    pub message: SubBlock,
    /// BLS signature over keccak256(SUBBLOCK_DOMAIN ‖ ssz/rlp(message)).
    pub signature: BlsSignature,
}
}

Validity

A SignedSubBlock for block N is valid iff:

1. validator_index is in N’s subblock committee and the signature verifies against that validator’s registered BLS key;
2. sum(gas_limit of transactions) ≤ SUBBLOCK_GAS_QUOTA and encoded size ≤ MAX_SUBBLOCK_BYTES;
3. it was received before SUBBLOCK_DEADLINE;
4. no transaction is a deposit transaction, and no transaction claims PBH blockspace (subblock quota is carved out of the non-PBH region; PBH guarantees are unaffected);
5. parent_hash references block N − 1 or N − 2 of the chain being extended, the encoded access list is ≤ MAX_SUBBLOCK_FBAL_BYTES, and the access list re-derives under WIP-1007 verification: executing transactions against per-transaction pre-states materialized from the list MUST reproduce an access list hashing to access_list_hash, and the list’s claimed pre-states MUST match the state at parent_hash;
6. it is the only subblock signed by this validator for height N (two distinct signed subblocks for the same height are slashable equivocation).

Inclusion semantics

Proposers build their subblock for block N against the unsafe head during slot N − 1 and broadcast it on the P2P network (below). The builder:

1. Collects valid subblocks until SUBBLOCK_DEADLINE.
2. Orders subblocks by the committee’s sampling order for N (deterministic given the seed).
3. Executes the subblock region first, at the top of the block. Within a subblock, transactions execute in proposer order; a transaction that is invalid against its pre-state (bad nonce, insufficient balance for fees) is skipped, not reverted-and-included, and does not invalidate the rest of the subblock. This rule is deterministic given the parent state and the ordered subblock set, so attestors can re-derive the exact expected region.
4. Extends the block with PBH and mempool transactions exactly as today.

The mandatory access lists are what make step 3 parallel rather than sequential. On receipt of each subblock — before the deadline, off the block-building critical path — the builder MUST verify it under WIP-1007: materialize each transaction’s pre-state from the FBAL, execute all of the subblock’s transactions in parallel against isolated snapshots, and check that the re-derived access list hashes to access_list_hash (validity condition 5). A subblock that fails verification is invalid, MUST be excluded, and does not bind attestors. At sealing time the builder stitches the pre-verified regions: where a subblock’s FBAL pre-state claims match the actual parent state of block N and no earlier-ordered subblock wrote to overlapping state, the cached execution results and state diffs are applied directly with no re-execution; only transactions whose pre-state diverges (stale parent_hash, cross-subblock overlap) are re-executed sequentially under the skip rule of step 3. The executed subblock region is emitted as flashblock index 0 with its own composite FBAL, so downstream flashblock consumers are unaffected and the 200 ms streaming cadence is preserved.

The builder MUST include every valid subblock it received by the deadline. This obligation is enforced by the attestation layer, not by L1 derivation (see Attestation validity policy).

P2P: flblk protocol v3

Subblock and attestation gossip reuses the existing flashblocks P2P network. The flblk protocol version bumps to 3 with three new top-level messages:

These messages are validator-signed rather than wrapped in the builder Authorized envelope; peers verify them against the StakeManager active-set snapshot and penalize peers relaying messages with invalid signatures, non-committee proposers, or heights outside [unsafe_head − 4, unsafe_head + 2]. Fanout, send/receive sets, and rotation follow p2p v2 unchanged.

Attestations

Data structures

#![allow(unused)]
fn main() {
pub struct AttestationData {
    pub chain_id: u64,
    pub epoch: u64,
    pub block_number: u64,
    pub block_hash: B256,
}

pub struct SignedAttestation {
    pub data: AttestationData,
    pub validator_index: u16,
    /// BLS signature over keccak256(ATTESTATION_DOMAIN ‖ ssz/rlp(data)).
    pub signature: BlsSignature,
}

pub struct AttestationCertificate {
    pub data: AttestationData,
    pub aggregate_signature: BlsSignature,
    /// Bit i set ⇔ active validator i contributed.
    pub participation: BitVec,
}
}

Attestation validity policy

Upon importing unsafe block N (via flashblocks or op-node gossip), an active validator MUST sign and broadcast an attestation iff all hold:

1. The block is valid under World Chain execution rules (the validator’s node has executed it).
2. The block’s subblock region matches the deterministic expected region: every valid subblock the validator observed on the P2P network at least SUBBLOCK_OBSERVATION_MARGIN (provisionally 200 ms) before SUBBLOCK_DEADLINE is present, correctly ordered, and correctly executed.
3. The block descends from every block the validator has previously seen a certificate for, and the validator has not attested a conflicting block at height N.

Rule 2 is intentionally subjective at the margin (a validator cannot prove what the builder did or did not receive); its role is to make sustained censorship quorum-blocking and publicly attributable rather than to adjudicate single-block races. Rule 3, combined with the slashing conditions, is objective and provides accountable safety.

Certificates and the attested head

Any node MAY aggregate attestations; in practice the builder aggregates as attestations arrive. When aggregated weight reaches quorum, the certificate is gossiped (msg 0x07) and the block becomes attested.

The builder MUST embed the newest certificate it holds on-chain via a StakeManager.submitCertificate call (a builder-injected transaction, gas-subsidized in the same manner as PBH transactions) no later than CERT_INCLUSION_WINDOW blocks after the certified height. On-chain inclusion is what drives reward accounting and makes certificates available to future L1-side consumers; the gossiped certificate alone already moves the attested tag on replicas.

Nodes expose attested as an additional block tag in the RPC layer. safe and finalized retain their L1-derived semantics unchanged.

Chain-extension rule

The sequencer and builder MUST NOT extend a fork that excludes an attested block. Honest validators will not attest such a fork (rule 3), so it can never reach quorum without ≥ 1/3 of stake double-signing — which is slashable. The batcher SHOULD prefer submitting attested blocks to L1; if quorum has been unattainable for more than BATCHER_ATTESTATION_TIMEOUT (provisionally 2 minutes), it MUST fall back to submitting unsafe blocks as today, emitting degraded-mode telemetry. Chain liveness never depends on validator liveness.

Slashing

StakeManager.slash(evidence) is permissionless. Evidence is verified on-chain against the epoch snapshot; a valid submission burns SLASH_FRACTION (provisionally 100% for equivocation offenses) of the offender’s stake, pays WHISTLEBLOWER_FRACTION (provisionally 5%) to the submitter, and ejects the offender.

The sequencer/builder is additionally bonded (amount TBD) via the same contract. Builder equivocation — two Authorized flashblock payloads with the same payload_id/index and different content, or sealing a block that abandons a certified ancestor — is attributable via the existing flashblocks dual-signature scheme and slashes the builder bond (S4). Header-chain verification for S2/S4 uses on-chain ancestry within the last 8192 block hashes; deeper evidence falls back to a governance-adjudicated path until a fault-proof-style verifier is specified.

Rewards

• Subblock proposers earn the priority fees of their included subblock transactions, minus a pro-rata share of the region’s L1 DA cost. The builder computes per-proposer totals during block construction and credits them in the submitCertificate call; attestors re-derive the amounts during block verification, so incorrect crediting is attestation-blocking (rule 2 extends to the settlement calldata).
• Attestors accrue a per-epoch WLD reward proportional to their certified participation (sum of participation bits landed within CERT_INCLUSION_WINDOW), paid from a governance-funded rewards budget held by StakeManager. No new WLD is issued by the protocol.
• There is no inclusion reward for the certificate transaction itself; embedding it is a builder obligation.

Rationale

Attestation overlay instead of full BFT leader rotation. Rotating block proposal among validators (CometBFT/HotStuff-style) would replace the sequencer, requiring deep changes to op-node, rollup-boost HA, and the derivation-adjacent operational stack, and would put validator liveness on the critical path of chain liveness. The overlay achieves the two properties users actually need on the unsafe head — accountable safety and multi-party inclusion — while keeping the sequencer as sole aggregator. Because there is exactly one proposer per height, no fork-choice or view-change machinery is needed; the protocol reduces to a single-shot finality gadget per block, and the classic BFT results still apply to its safety: conflicting certificates require ≥ 1/3 equivocating stake. Leader rotation remains a natural future extension once the validator set and slashing machinery are proven.

Subblocks à la Tempo. Tempo’s subblock architecture demonstrated that inclusion can be sharded across validators without sharding block production. It fits World Chain unusually well: the builder already assembles blocks from heterogeneous regions (PBH blockspace, mempool), already streams incremental payloads every 200 ms, and — via WIP-1007 — already has a format for shipping a region’s state transition as a verifiable bundle. A subblock is, mechanically, an externally-authored flashblock-0 fragment with an FBAL attached.

Enforcing inclusion via attestations instead of derivation validity. Making subblock omission a derivation-invalidity condition would fork the OP Stack derivation pipeline and make the canonical chain depend on P2P-observable facts, which is unsound. Attestation-gating gets the product property (sustained censorship becomes publicly attributable and blocks economic finality) without touching L1 validity rules.

Staking on L2 rather than L1. An L2 predeploy makes the active set, certificates, rewards, and slashing readable by the nodes that need them at zero latency, and WLD is natively liquid on World Chain. The cost is that slashing guarantees are themselves only as final as the L2 chain; WITHDRAWAL_DELAY is therefore anchored to L1 finality of the exit block, so stake cannot escape ahead of the evidence window.

BLS12-381 for both duties. Attestations require aggregation (128 signatures per 2 s block otherwise); EIP-2537 precompiles make on-chain verification affordable; using one key type for subblocks and attestations keeps the registry and possession-proof story simple.

Backwards Compatibility

• L1 derivation is unchanged. Blocks produced under this WIP are valid OP Stack blocks; a node ignoring the overlay follows the identical canonical chain. safe/finalized semantics are untouched.
• flblk bumps 2 → 3. v2 peers cannot parse the new message types and are incompatible, consistent with the v1 → v2 precedent.
• RPC adds the attested tag; existing tags are unchanged.
• PBH is unaffected: subblock quota is carved from non-PBH blockspace, and subblocks cannot claim PBH space.
• The StakeManager predeploy and certificate-settlement transaction require a hardfork activation.

Security Considerations

• Scope of the guarantee. Certificates protect against pre-L1 reorgs only. Once a block is derived from finalized L1 data, Ethereum’s guarantees dominate. The overlay’s accountable safety also assumes ≥ 2/3 of stake is honest and independent; stake concentration (few entities controlling quorum) reproduces single-operator trust with extra steps. MAX_ACTIVE_VALIDATORS, delegation policy, and stake caps are the levers; concentration metrics must be public.
• Subjectivity of inclusion enforcement. Rule 2 of the attestation policy depends on what each validator observed. A builder can plausibly deny receipt of any single subblock, and a malicious validator can broadcast a subblock late and cry censorship. The margin parameter, per-validator omission telemetry, and quorum (no single validator’s view decides) bound both attacks; the design goal is detecting and pricing sustained censorship, not adjudicating individual races. This subjectivity is why omission is quorum-blocking but not directly slashable.
• Liveness attacks on the overlay. ≥ 1/3 of stake refusing to attest halts certificates, not the chain (batcher falls back after BATCHER_ATTESTATION_TIMEOUT). The cost of this attack is forgone rewards; if attested becomes load-bearing for major applications, withholding-based griefing pricing (inactivity leaks) should be revisited.
• DA and resource griefing via subblocks. Subblock transactions consume L1 DA paid by the protocol’s fee flow. MAX_SUBBLOCK_BYTES, SUBBLOCK_GAS_QUOTA, and the skip-invalid rule bound the damage of junk subblocks; a proposer who persistently fills subblocks with skipped or zero-fee transactions earns nothing and is visible in telemetry. Per-proposer DA-cost deduction (Rewards) makes spam self-defeating economically. A well-formed subblock with a bogus access list costs the builder one bounded, parallel verification pass off the critical path before exclusion; MAX_SUBBLOCK_FBAL_BYTES and per-subblock gas quotas cap that work, and repeated verification failures are attributable to the signing proposer.
• Equivocation windows. Between a block reaching quorum and its certificate propagating, a validator could attest a competing block without yet “knowing” of the certificate. S1 (same-height equivocation) is unconditional and covers this window; S2 covers post-certificate forks. Validators MUST persist their signing history across restarts (slashing-protection database, as in Ethereum consensus clients).
• Key management. BLS possession proofs prevent rogue-key aggregation attacks. Validator keys are hot by necessity; the registry SHOULD support a separate cold withdrawal address so key compromise caps losses at slashing, not theft of stake.
• Builder bond and HA. In HA sequencer setups, failover between builders is already coordinated via StartPublish/StopPublish; S4 evidence must distinguish malicious equivocation from a benign failover race. The dual-signature Authorized envelope scopes accountability to the authorized builder for a given payload_id, which is the correct boundary, but the exact S4 predicate under failover needs adversarial review before it arms.

Open Questions

1. Final economic parameters: MIN_STAKE, reward budget sizing, slash fractions, and whether delegation is in scope for v1.
2. The exact settlement mechanism for routing subblock priority fees out of the sequencer fee vault, and its interaction with existing fee-vault withdrawal flows.
3. Whether attested should eventually gate flashblock-level pre-confirmations (validators attesting flashblocks, not just sealed blocks) — the natural next step for 200 ms economic finality.
4. S2/S4 evidence verification beyond the 8192-block ancestry window: governance adjudication vs. a fault-proof-style on-chain verifier.
5. Committee sizing: whether SUBBLOCK_COMMITTEE_SIZE should scale with the active set, and whether committee membership should be private until the slot (to resist targeted DoS on proposers).

Security Considerations Status

Needs adversarial review before leaving Draft, in particular the S4 failover predicate and the inclusion-enforcement subjectivity bounds.