World Chain Specs

Abstract

This WIP replaces PBH with a builder-enforced transaction subsidy system for World ID verified addresses.

The protocol fee market is effectively disabled: the in-protocol gas target and gas limit are set high enough that the protocol base fee never rises above the configured minimum base fee, and once the chain is running the minBaseFee-aware payload path that minimum base fee is set to 0. As a result, baseFeePerGas is always 0.

Fee pricing moves out of protocol. Builders maintain a virtual fee market with a virtualBaseFee, virtualMinBaseFee, virtualGasTarget, and virtualGasLimit. For ordinary transactions, the virtual base fee is enforced through maxPriorityFeePerGas, so the chain behaves like a simulated EIP-1559 market even though the protocol base fee is 0. For eligible World ID transactions, the builder may discount or fully waive that virtual fee floor and charge the waived amount against the account’s subsidy budget for the current WIP-1002 epoch.

Motivation

World Chain wants two properties at the same time:

• a real fee market for non-verified traffic
• fully subsidized transactions for verified humans up to a bounded limit

PBH solves priority and fairness, but it does not provide a unified fee model for free verified transactions and market-priced non-verified transactions. This WIP makes the subsidy model native to normal transaction inclusion. Verified transactions can be literally free up to a per-epoch wei limit, while the rest of the chain still sees a fee floor and blockspace competition.

Proposal

1. Protocol Fee Market

• The protocol gas target and protocol gas limit are set arbitrarily high, so the protocol base fee does not rise above the protocol minimum base fee.
• The chain must run the fork and client path that supports configurable minBaseFee in payload attributes and block extra data.
• Once that path is active, SystemConfig.setMinBaseFee(0) disables the protocol minimum base fee floor.
• After that, the protocol baseFeePerGas is always 0.
• This WIP does not introduce a new transaction type.

2. Virtual Fee Market

Builders maintain a virtual fee market with the following values:

• virtualBaseFee
• virtualMinBaseFee
• virtualGasTarget
• virtualGasLimit

These values are out of protocol. They control transaction admission and ordering in the World Chain client, but they do not affect block validity at the protocol level.

virtualGasLimit is the builder-local effective gas limit used for transaction selection and verified blockspace segmentation. virtualGasTarget is the target used by the virtual fee controller when deriving the next virtualBaseFee.

This WIP assumes the virtual fee parameters are made deterministic by a system contract, referred to here as VirtualFeeOracle.

• A builder-owned transaction at the end of block N writes the virtual fee parameters that apply to block N + 1.
• All builders validating or constructing block N + 1 use the parameters committed in block N.
• The virtual fee controller is intended to be EIP-1559-like, but the exact control law is out of scope for this WIP so long as the per-block values are deterministic.

3. Transaction Pricing

Because the protocol base fee is 0, the virtual base fee is represented through the priority fee.

For an ordinary non-subsidized transaction:

• maxPriorityFeePerGas must be at least virtualBaseFee
• any amount above virtualBaseFee is an optional tip

For a subsidy-eligible transaction, the required priority fee may be reduced by the account’s remaining subsidy.

4. Transaction Validation

The World Chain transaction validator is extended to enforce the virtual fee floor for in-scope transactions. WIP-1002 contains the specification for how to determine the subsidies available to an address.

• If a transaction is not subsidy-eligible, it is invalid unless it pays at least the virtual fee floor through maxPriorityFeePerGas.
• If a transaction is subsidy-eligible, the validator discounts the required priority fee using the charged account’s remaining subsidy.
• For admission, a conservative rule may use the transaction gas limit G and remaining subsidy S to derive: discountPerGas = min(virtualBaseFee, floor(S / G)) requiredPriorityFeePerGas = virtualBaseFee - discountPerGas
• This allows full subsidy when S >= G * virtualBaseFee and partial subsidy otherwise.
• Final settlement uses gasUsed, not gasLimit.
• PBH is removed by this WIP. Bundler transactions remain out of scope.

5. Subsidy Eligibility

A transaction is subsidy-eligible if either of the following is true:

• the sender is verified in the WIP-1002 defined contract for the current epoch
• the transaction is a valid WIP-1002 registration transaction that verifies a specific address for the current epoch or next epoch

For WIP-1002 registration transactions:

• the subsidy is attributed to the address being verified, not necessarily msg.sender
• the registration transaction counts toward that address’s subsidy budget for the current WIP-1002 epoch
• only canonical WIP-1002 registration calls are eligible

Exact WIP-1002 ABI and storage changes are out of scope here. A separate spec can define them in detail.

6. Subsidy Accounting

Each verified address has a subsidy budget denominated in wei for each WIP-1002 epoch.

• the subsidy budget uses the same epoch boundaries as the WIP-1002
• the full virtual base fee liability for an included transaction is gasUsed * virtualBaseFee
• the actual subsidy applied is min(remainingSubsidy, gasUsed * virtualBaseFee)
• the unsubsidized remainder is paid by the sender through priority fee
• any fee paid above the unsubsidized remainder is an optional tip and is not subsidized
• partial subsidy is allowed

7. Block Construction

The builder preferentially uses a fraction of each block, and optionally each flashblock, for verified transactions. This replaces PBH block segmentation.

• verified transactions get preferential access to the verified portion even if they have no subsidy remaining
• non-verified transactions may use the remainder of that portion near the end of block construction if verified demand does not fill it
• the rest of the block remains open to ordinary transactions
• transaction selection is bounded by virtualGasLimit, not the protocol gas limit

When constructing a block, the builder:

1. determines the charged account for each subsidy-eligible transaction
2. executes the transaction
3. computes virtualBaseFeeLiability = gasUsed * virtualBaseFee
4. computes actualSubsidy = min(remainingSubsidy, virtualBaseFeeLiability)
5. checks that the sender-paid priority fee covers virtualBaseFeeLiability - actualSubsidy
6. updates the charged account by actualSubsidy

Within the verified segment, transactions may still compete via optional tip.

8. Address-Book Updates

The WIP-1002 is extended to track subsidy usage per address per epoch.

At minimum it must support:

• checking whether an address is verified for the current epoch
• tracking total subsidized wei used by an address for a given epoch
• exposing enough state for builders to determine remaining subsidy

At the end of each block, the builder sends a builder-owned transaction that updates the WIP-1002 with the subsidy deltas for that block.

9. RPC Behavior

Current wallets typically estimate fees using some combination of:

• eth_estimateGas
• eth_maxPriorityFeePerGas
• eth_gasPrice
• eth_feeHistory
• the latest block’s baseFeePerGas

The World Chain client overrides fee suggestion RPC behavior so wallets quote the virtual fee market instead of the protocol base fee.

This includes:

• eth_maxPriorityFeePerGas
• eth_gasPrice
• eth_feeHistory, where needed for wallet compatibility

eth_estimateGas continues to estimate gas usage, not fees.

For ordinary transactions, overriding these fee RPCs is sufficient for compatibility with wallets that already rely on them.

Wallets that derive fees directly from the block header baseFeePerGas may underquote, because the protocol header value remains 0. Wallets integrating World Chain should therefore prefer the overridden fee RPCs rather than raw block-header base fee.

World Chain clients should also expose account-aware subsidy information. A client can read the WIP-1002 state for an account and return at least:

• whether the account is currently verified
• its remaining subsidy for the current epoch
• an account-specific suggested maxPriorityFeePerGas given an estimated gas limit

Subsidy-aware wallets may then send a lower priority fee, including 0, when the sender’s remaining subsidy covers the virtual base fee liability.

Rationale

The protocol base fee is pinned to 0 so verified transactions can be literally free. The fee market is moved into builder policy so World Chain can still price ordinary traffic while waiving fees for verified humans up to a bounded limit.

The virtual fee parameters are committed one block ahead so all builders can validate the same fee floor for the next block. Using the WIP-1002 epoch for subsidy accounting keeps verification state and subsidy state aligned.

Charging registration subsidies to the address being verified avoids tying subsidy attribution to the relayer or caller, which matches the intended beneficiary of the verification.

Backwards Compatibility

This WIP intentionally changes World Chain transaction admission, fee quoting, and block segmentation behavior.

• PBH is replaced by subsidy-aware verified blockspace
• the protocol block header still exposes baseFeePerGas = 0
• ordinary wallets interacting through standard fee RPCs continue to see a fee quote, but that quote is virtual rather than protocol-derived

Security Considerations

Because the fee market is out of protocol, all builders must derive the same virtual fee parameters for the same block. If they do not, transaction admission diverges. The fallback builder must therefore run the same World Chain client behavior.

Verified free transactions create a DoS surface unless both of the following are enforced:

• the preferential verified portion remains capped
• each verified address remains bounded by a per-epoch wei subsidy limit

Address-book registration transactions need careful attribution and selector filtering so callers cannot redirect subsidy eligibility to arbitrary calls. Only canonical registration calls that successfully verify an address should receive subsidy treatment.

The builder-owned end-of-block accounting transaction is trusted operational infrastructure. If it is omitted or delayed, subsidy accounting becomes stale.