World Chain
Summary
ExpandWorld Chain is an Optimism L2 blockchain node implementation built on the Reth execution client framework, extended with a "flashblocks" sub-block pre-commitment system and a Priority Block Handler (PBH) mechanism for Sybil-resistant priority transactions using World ID zero-knowledge proofs. The codebase spans approximately 15,000 lines of Rust across core infrastructure crates — `builder`, `payload`, `p2p`, `rpc`, and `cli` — alongside approximately 2,600 lines of Solidity smart contracts implementing PBH proof verification, ERC-4337 UserOperation aggregation, and an ETH-to-WLD buyback-and-burn fee management system. The Rust layer implements a `FlashblocksExecutionCoordinator` that processes incremental block payloads from a P2P network, a `FlashblocksPayloadBuilder` for local block construction with parallel transaction validation through layered temporal database views (`TemporalDb`, `BundleDb`, `BalBuilderDb`), and an RPC layer providing JSON-RPC endpoints with conditional transaction support and Engine API extensions for flashblocks fork-choice updates.
The codebase exhibits well-considered security controls at each architectural layer. The P2P protocol enforces ed25519 signature verification on all authorization messages, implements replay protection via timestamp comparison, applies per-peer rate limiting on control messages, and manages peer reputation with score-based rotation and banning. The smart contract layer employs UUPS-upgradeable proxies with `_disableInitializers()` to prevent implementation takeover, `ReentrancyGuardTransient` for gas-efficient reentrancy protection, `Ownable2StepUpgradeable` for safe ownership transfers, and transient-storage-based callback validation during aggregated UserOperation handling. The builder's post-execution verification pipeline independently validates block hash, state root, receipts root, and access list hash for every received flashblock, providing a cryptographic safety net against execution divergence. CLI argument parsing enforces mutual exclusivity between authorizer modes and requires explicit key provision through environment variables rather than command-line arguments.
The overall security posture of the World Chain codebase is strong, with no vulnerabilities identified across the entire audit scope. Two low-severity findings were identified: an incorrect fee calculation in the parallel flashblock validation path that could produce divergent state under specific execution conditions, and an unsafe ERC-20 `transfer` call in the `FeeEscrow` withdrawal path that will silently fail for non-standard tokens that do not return a boolean value. Both findings represent concrete correctness and integration risks rather than direct fund-theft vectors, though the latter could result in failed withdrawals against certain token implementations. The architecture's clean separation of concerns — with thin delegation in the RPC layer, narrow lock scopes and semaphore-bounded concurrency in the builder, and comprehensive re-org handling in the P2P event buffer — reflects mature infrastructure engineering practices appropriate for a production blockchain node.
Findings
2 issues identified
Incorrect Fee Calculation in Parallel Flashblock Validation Path
crates/builder/src/validator.rs
View Details
Description
The execute_transaction function in the parallel validation path calculates per-transaction fees as just effective_tip_per_gas(basefee) without multiplying by gas_used. Additionally, validate_flashblock_parallel does not add committed_state.fees to the total when constructing OpBuiltPayload. The sequential path correctly computes fees as gas_used * miner_fee and adds committed_state.fees.
Impact
OpBuiltPayload objects created via the parallel (BAL-enabled) validation path will report fees orders of magnitude lower than actual values. This incorrect fee metadata is broadcast to other components, stored in coordinator state, propagated to pending block RPC responses, and used as committed_state.fees for subsequent flashblocks. Consensus safety is not affected as block hash, state root, and receipts root are validated independently.
Recommendation
Multiply effective_tip_per_gas by gas_used in execute_transaction, and add committed_state.fees in validate_flashblock_parallel payload construction.
Fix
The first fix multiplies effective_tip_per_gas by gas_used to compute total transaction fees, matching the sequential path's calculation. The second fix adds committed_state.fees (accumulated fees from prior flashblocks) to the total, also matching the sequential path.
crates/builder/src/validator.rs
ERC20 withdraw uses unsafe `transfer` instead of `safeTransfer`
pkg/contracts/src/fees/FeeEscrow.sol:185
View Details
Description
The withdraw(address token, address to, uint256 amount) function calls IERC20(token).transfer(to, amount) directly instead of using SafeERC20.safeTransfer(). The contract imports SafeERC20 and declares using SafeERC20 for IERC20 at line 42, but this particular call does not use the safe wrapper. Tokens like USDT on mainnet do not return a bool from transfer(), causing the call to revert under Solidity >=0.8 due to ABI decoding failure.
Impact
The owner would be unable to withdraw any non-standard ERC20 tokens (e.g., USDT) that are accidentally sent to the contract. These tokens would be permanently locked.
Recommendation
Replace IERC20(token).transfer(to, amount) with IERC20(token).safeTransfer(to, amount) to use the SafeERC20 wrapper that is already imported and declared.
Fix
Conclusion
ExpandThe World Chain codebase demonstrates high code quality and security maturity across both its Rust node infrastructure and Solidity smart contracts. The Rust crates make disciplined use of the type system to enforce database layer composability, employ saturating arithmetic to prevent overflow in timing-sensitive code paths, and maintain narrow concurrency primitives that minimize lock contention. The Solidity contracts follow established security patterns including explicit 48-bit ceiling checks in the PBHExternalNullifier library, oracle freshness and positivity validation in FeeEscrow, and actual balance change verification rather than trusting callback return values. The extensive end-to-end and property-based test suites — covering flashblock validation, P2P authorization, transaction pool ordering, and multi-node topology scenarios — provide meaningful assurance beyond what static analysis alone can deliver.
The two low-severity findings, while not exploitable for direct fund theft or consensus manipulation, represent concrete operational and correctness risks that should be addressed before mainnet deployment. The fee calculation discrepancy in the parallel flashblock validation path (M-1) could cause the node to reject valid flashblocks or accept incorrectly computed ones under specific transaction ordering conditions — aligning the parallel path’s fee accumulation logic with the sequential reference implementation would eliminate this divergence. The use of the raw ERC-20 transfer call rather than OpenZeppelin’s safeTransfer wrapper in the FeeEscrow withdrawal function (M-2) means that tokens which do not return a boolean on transfer — a well-documented deviation from the ERC-20 standard present in widely deployed tokens such as USDT — will cause withdrawals to revert, potentially locking funds within the escrow contract.
The codebase is well-positioned for production deployment after the two identified findings are remediated. The flashblock validation pipeline should reconcile its parallel fee calculation logic against the canonical sequential path to ensure deterministic agreement, and the FeeEscrow contract should adopt safeTransfer from OpenZeppelin’s SafeERC20 library to handle non-compliant token implementations gracefully. Beyond these specific fixes, cross-crate trust boundaries warrant continued attention — particularly the flow of P2P-sourced pre-confirmed state into the builder’s execution pipeline, the pass-through of Authorization objects from the Engine API RPC through to the payload crate, and the builder’s trusted role in calling spendNullifierHashes after block production. With the recommended mitigations applied, the World Chain node and its associated smart contracts are suitable for mainnet operation.
On-Chain Verification
Compare these values with the on-chain attestation
Verify: download the markdown and compare the hash
sha256sum world-chain.md
Legal Disclaimer: This report covers the code submitted for analysis. It does not account for infrastructure, deployment configuration, third-party dependencies, or changes made after the audit date. Automated analysis may produce false positives or miss context-dependent vulnerabilities. audited.xyz provides this report “as is” without warranty of any kind.