Immunefi Audit Competitions
Base

75113 sc medium zk challenge proofs use 10 block intermediate roots while aggregateverifier verifies 30 block segments preventing zk correction of invalid proposals

Submitted on Apr 27th 2026 at 09:59:55 UTC by @Brainiac5 for Audit Comp | Base Azul

Description

Brief

The Sepolia Azul AggregateVerifier is deployed with a 30-block intermediate proof interval, but the ZK prover service still hardcodes a 10-block intermediate root interval. The challenger correctly reads 30 from the on-chain game implementation and asks the ZK service to prove a 30-block segment, but the ZK service produces a proof journal containing roots at 10, 20, and 30 blocks. AggregateVerifier.challenge() verifies a journal containing only the single 30-block root. The two journals are different, so a valid ZK proof generated by the official ZK path cannot pass challenge()/nullify() for the configured Sepolia multiproof game type.

Vulnerability Details

Sepolia Azul is configured with:

BLOCK_INTERVAL=600
INTERMEDIATE_BLOCK_INTERVAL=30
GAME_TYPE=621

This means one proposal contains 20 intermediate roots, one per 30 L2 blocks.

The challenger does read the on-chain interval and requests a ZK proof for exactly that segment:

ProveBlockRequest {
    start_block_number,
    number_of_blocks_to_prove: candidate.intermediate_block_interval,
    ...
}

For Sepolia type 621, candidate.intermediate_block_interval is 30.

The problem is that ProveBlockRequest has no field for the intermediate-root interval. It only carries start block, number of blocks, sequence window, proof type, session id, prover address, and L1 head. The ZK service then hardcodes:

pub const DEFAULT_INTERMEDIATE_ROOT_INTERVAL: u64 = 10;

and writes that hardcoded value into the SP1 witness:

let stdin = self.host.witness_generator().get_sp1_stdin(
    witness,
    base_proof_succinct_client_utils::client::DEFAULT_INTERMEDIATE_ROOT_INTERVAL,
)?;

The range executor records an intermediate output root every interval blocks:

if blocks_processed.is_multiple_of(interval) {
    intermediate_roots.push(output_root);
}

So for a 30-block challenge segment, the ZK proof journal contains three intermediate roots:

root_10 || root_20 || root_30

The aggregation program commits those roots into the public values:

let intermediate_roots: Bytes = agg_inputs
    .boot_infos
    .iter()
    .flat_map(|boot_info| boot_info.intermediateRoots.iter().copied())
    .collect::<Vec<u8>>()
    .into();

But AggregateVerifier.challenge() verifies only one root for the same 30-block segment:

_verifyProof(
    proofBytes[1:],
    proofType,
    msg.sender,
    l1Head().raw(),
    startingRoot,
    startingL2SequenceNumber,
    intermediateRootToProve,
    endingL2SequenceNumber,
    abi.encodePacked(intermediateRootToProve)
);

The ZK verifier receives the hash of:

prover || l1Head || startingRoot || startBlock || root_30 || endBlock || root_30 || configHash || rangeVKey

while the official ZK service proves:

prover || l1Head || startingRoot || startBlock || root_30 || endBlock || root_10 || root_20 || root_30 || configHash || rangeVKey

These cannot both be true for the same proof.

Impact Details

This breaks the permissionless ZK dispute path for the configured Sepolia Azul multiproof game type.

Concrete impact chain:

  • A TEE-backed proposal is created for game type 621.
  • A challenger detects that an intermediate output root is wrong.
  • The challenger reads the game implementation interval as 30 and requests a ZK proof for that 30-block segment.
  • The ZK service hardcodes a 10-block intermediate-root interval and produces public values containing three roots.
  • AggregateVerifier.challenge() reconstructs a public-input hash with only one root.
  • The verifier rejects the proof because the public inputs do not match.
  • The invalid proposal cannot be corrected through the advertised permissionless ZK challenge path before finalization.
  • After the slow finalization delay, the unchallenged game resolves DEFENDER_WINS and becomes claim-valid in AnchorStateRegistry.

This is different from a trusted-admin or intentional TEE-only-window argument. The bug is a concrete cross-repo mismatch after the contract is configured for a 30-block multiproof interval, while the ZK proof path is still fixed to 10. The available guardian/TEE paths may reduce severity, but they do not make the permissionless ZK challenge mechanism function.

References

  • Immunefi Base Azul scope: https://immunefi.com/audit-competition/audit-comp-base-azul/scope/
  • Blockchain/DLT target: https://github.com/base/base/tree/v0.8.0-rc.24
  • Smart Contract target: https://github.com/base/contracts/tree/v8.1.0/src/multiproof
  • Sepolia Azul task config sets INTERMEDIATE_BLOCK_INTERVAL=30: contract-deployments/sepolia/2026-04-20-activate-multiproof/.env:14-15
  • Challenger requests candidate.intermediate_block_interval blocks, but does not include the intermediate-root interval in the request: base/crates/proof/challenge/src/driver.rs:624-632
  • ProveBlockRequest has no intermediate_root_interval field: base/crates/proof/zk/client/proto/zk_prover.proto:17-33
  • ZK client hardcodes DEFAULT_INTERMEDIATE_ROOT_INTERVAL = 10: base/crates/proof/succinct/utils/client/src/client.rs:18-19
  • ZK service passes the hardcoded default interval into witness generation: base/crates/proof/zk/service/src/backends/op_succinct/provider.rs:100-103
  • Range executor records intermediate roots every configured interval: base/crates/proof/succinct/utils/client/src/client.rs:188-192
  • Aggregation program commits all intermediate roots into public values: base/crates/proof/succinct/programs/aggregation/src/main.rs:80-111
  • AggregateVerifier.challenge() hashes only abi.encodePacked(intermediateRootToProve) for one 30-block segment: contracts/src/multiproof/AggregateVerifier.sol:511-521
  • _verifyZkProof() builds the verifier journal from those exact intermediateRoots: contracts/src/multiproof/AggregateVerifier.sol:917-932
  • The on-chain segment length is derived from INTERMEDIATE_BLOCK_INTERVAL: contracts/src/multiproof/AggregateVerifier.sol:1018-1024
  • Runnable PoC: contracts/test/multiproof/AuditZkIntervalMismatch.t.sol

Suggested Fix

  • Add an intermediate_root_interval field to ProveBlockRequest.
  • Have the challenger pass candidate.intermediate_block_interval to the ZK service.
  • Remove the hardcoded DEFAULT_INTERMEDIATE_ROOT_INTERVAL from the service path for on-chain dispute proofs.
  • Add an assertion that the public input intermediateRoots.length matches what the target AggregateVerifier will hash for challenge()/nullify().
  • Add an integration test using the Sepolia task values: BLOCK_INTERVAL=600, INTERMEDIATE_BLOCK_INTERVAL=30.

Confidence

Confirmed locally with a runnable Foundry POC. The POC proves the public-input mismatch, proves that the official-style ZK challenge is rejected for the deployed 30-block interval, and proves that the unchallenged game can then resolve DEFENDER_WINS and become claim-valid in AnchorStateRegistry.

Proof of Concept

PoC file:

contracts/test/multiproof/AuditZkIntervalMismatch.t.sol

Run:

cd base-azul/contracts
forge test --match-path test/multiproof/AuditZkIntervalMismatch.t.sol -vvv

Observed result:

Ran 2 tests for test/multiproof/AuditZkIntervalMismatch.t.sol:AuditZkIntervalMismatchTest
[PASS] testOneRootJournalWouldChallengeSuccessfully() (gas: 680062)
[PASS] testZkServiceTenBlockJournalCannotChallengeThirtyBlockOnchainSegmentAndGameFinalizes() (gas: 677556)
Suite result: ok. 2 passed; 0 failed; 0 skipped

The test creates a Sepolia-like AggregateVerifier with:

BLOCK_INTERVAL=600
INTERMEDIATE_BLOCK_INTERVAL=30

It then computes both journals:

  • ZK service journal: root_10 || root_20 || root_30
  • On-chain challenge() journal: root_30

The mock verifier accepts only the ZK service journal. challenge() reverts with InvalidProof, then the game is able to pass the slow finalization delay, resolve DEFENDER_WINS, and become claim-valid in AnchorStateRegistry. A second positive-control test switches the mock verifier to accept the one-root on-chain journal and shows that the same challenge call succeeds. This isolates the issue to the public-input encoding mismatch, not to proof bytes, caller permissions, or the game setup.

PoC Code

// SPDX-License-Identifier: MIT
pragma solidity 0.8.15;

import { IAnchorStateRegistry } from "interfaces/dispute/IAnchorStateRegistry.sol";
import { IDelayedWETH } from "interfaces/dispute/IDelayedWETH.sol";
import { IDisputeGame } from "interfaces/dispute/IDisputeGame.sol";
import { Claim, GameStatus, Proposal } from "src/dispute/lib/Types.sol";
import { AggregateVerifier } from "src/multiproof/AggregateVerifier.sol";
import { Verifier } from "src/multiproof/Verifier.sol";
import { BaseTest } from "./BaseTest.t.sol";

contract JournalCheckingVerifier is Verifier {
    bytes32 public expectedJournal;

    constructor(IAnchorStateRegistry anchorStateRegistry) Verifier(anchorStateRegistry) { }

    function setExpectedJournal(bytes32 journal) external {
        expectedJournal = journal;
    }

    function verify(bytes calldata, bytes32, bytes32 journal) external view override notNullified returns (bool) {
        return journal == expectedJournal;
    }
}

contract AuditZkIntervalMismatchTest is BaseTest {
    uint256 internal constant SEPOLIA_BLOCK_INTERVAL = 600;
    uint256 internal constant SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL = 30;
    uint256 internal constant ZK_SERVICE_DEFAULT_INTERMEDIATE_ROOT_INTERVAL = 10;

    JournalCheckingVerifier internal strictZkVerifier;

    function setUp() public override {
        super.setUp();

        strictZkVerifier = new JournalCheckingVerifier(IAnchorStateRegistry(address(anchorStateRegistry)));

        AggregateVerifier sepoliaLikeImpl = new AggregateVerifier(
            AGGREGATE_VERIFIER_GAME_TYPE,
            IAnchorStateRegistry(address(anchorStateRegistry)),
            IDelayedWETH(payable(address(delayedWETH))),
            teeVerifier,
            strictZkVerifier,
            TEE_IMAGE_HASH,
            AggregateVerifier.ZkHashes(ZK_RANGE_HASH, ZK_AGGREGATE_HASH),
            CONFIG_HASH,
            L2_CHAIN_ID,
            SEPOLIA_BLOCK_INTERVAL,
            SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL,
            1
        );

        factory.setImplementation(AGGREGATE_VERIFIER_GAME_TYPE, IDisputeGame(address(sepoliaLikeImpl)));
    }

    function testZkServiceTenBlockJournalCannotChallengeThirtyBlockOnchainSegmentAndGameFinalizes() public {
        bytes32 correctRoot10 = keccak256("correct-root-10");
        bytes32 correctRoot20 = keccak256("correct-root-20");
        bytes32 correctRoot30 = keccak256("correct-root-30");
        bytes32 wrongRoot30 = keccak256("wrong-root-30");

        bytes32[] memory proposedRoots = new bytes32[](SEPOLIA_BLOCK_INTERVAL / SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL);
        proposedRoots[0] = wrongRoot30;
        for (uint256 i = 1; i < proposedRoots.length; i++) {
            proposedRoots[i] = keccak256(abi.encode("proposed-root", i));
        }

        Claim rootClaim = Claim.wrap(proposedRoots[proposedRoots.length - 1]);
        AggregateVerifier game = _createSepoliaLikeGame(rootClaim, proposedRoots);

        Proposal memory startingAnchor = anchorStateRegistry.getStartingAnchorRoot();
        bytes32 zkServiceJournal = _journal(
            ZK_PROVER,
            game.l1Head().raw(),
            startingAnchor.root.raw(),
            uint64(startingAnchor.l2SequenceNumber),
            correctRoot30,
            uint64(startingAnchor.l2SequenceNumber + SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL),
            abi.encodePacked(correctRoot10, correctRoot20, correctRoot30),
            ZK_RANGE_HASH
        );

        bytes32 onchainChallengeJournal = _journal(
            ZK_PROVER,
            game.l1Head().raw(),
            startingAnchor.root.raw(),
            uint64(startingAnchor.l2SequenceNumber),
            correctRoot30,
            uint64(startingAnchor.l2SequenceNumber + SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL),
            abi.encodePacked(correctRoot30),
            ZK_RANGE_HASH
        );

        assertTrue(zkServiceJournal != onchainChallengeJournal);
        assertEq(SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL / ZK_SERVICE_DEFAULT_INTERMEDIATE_ROOT_INTERVAL, 3);

        strictZkVerifier.setExpectedJournal(zkServiceJournal);

        bytes memory zkProof = abi.encodePacked(uint8(AggregateVerifier.ProofType.ZK), bytes("zk-proof"));
        vm.prank(ZK_PROVER);
        vm.expectRevert(AggregateVerifier.InvalidProof.selector);
        game.challenge(zkProof, 0, correctRoot30);

        vm.warp(block.timestamp + game.SLOW_FINALIZATION_DELAY() + 1);
        game.resolve();

        assertEq(uint8(game.status()), uint8(GameStatus.DEFENDER_WINS));
        vm.warp(block.timestamp + 1);
        assertTrue(anchorStateRegistry.isGameClaimValid(IDisputeGame(address(game))));
    }

    function testOneRootJournalWouldChallengeSuccessfully() public {
        bytes32 correctRoot30 = keccak256("correct-root-30");
        bytes32 wrongRoot30 = keccak256("wrong-root-30");

        bytes32[] memory proposedRoots = new bytes32[](SEPOLIA_BLOCK_INTERVAL / SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL);
        proposedRoots[0] = wrongRoot30;
        for (uint256 i = 1; i < proposedRoots.length; i++) {
            proposedRoots[i] = keccak256(abi.encode("proposed-root", i));
        }

        Claim rootClaim = Claim.wrap(proposedRoots[proposedRoots.length - 1]);
        AggregateVerifier game = _createSepoliaLikeGame(rootClaim, proposedRoots);
        Proposal memory startingAnchor = anchorStateRegistry.getStartingAnchorRoot();

        bytes32 onchainChallengeJournal = _journal(
            ZK_PROVER,
            game.l1Head().raw(),
            startingAnchor.root.raw(),
            uint64(startingAnchor.l2SequenceNumber),
            correctRoot30,
            uint64(startingAnchor.l2SequenceNumber + SEPOLIA_INTERMEDIATE_BLOCK_INTERVAL),
            abi.encodePacked(correctRoot30),
            ZK_RANGE_HASH
        );

        strictZkVerifier.setExpectedJournal(onchainChallengeJournal);

        bytes memory zkProof = abi.encodePacked(uint8(AggregateVerifier.ProofType.ZK), bytes("zk-proof"));
        vm.prank(ZK_PROVER);
        game.challenge(zkProof, 0, correctRoot30);
        assertEq(game.counteredByIntermediateRootIndexPlusOne(), 1);
    }

    function _createSepoliaLikeGame(
        Claim rootClaim,
        bytes32[] memory intermediateRoots
    )
        internal
        returns (AggregateVerifier game)
    {
        bytes memory roots;
        for (uint256 i = 0; i < intermediateRoots.length; i++) {
            roots = abi.encodePacked(roots, intermediateRoots[i]);
        }

        bytes memory extraData =
            abi.encodePacked(uint256(SEPOLIA_BLOCK_INTERVAL), address(anchorStateRegistry), roots);
        bytes memory proof = _generateProof("tee-proof", AggregateVerifier.ProofType.TEE);

        vm.deal(TEE_PROVER, INIT_BOND);
        vm.prank(TEE_PROVER);
        game = AggregateVerifier(
            address(
                factory.createWithInitData{ value: INIT_BOND }(
                    AGGREGATE_VERIFIER_GAME_TYPE, rootClaim, extraData, proof
                )
            )
        );
    }

    function _journal(
        address proposer,
        bytes32 l1OriginHash,
        bytes32 startingRoot,
        uint64 startingL2SequenceNumber,
        bytes32 endingRoot,
        uint64 endingL2SequenceNumber,
        bytes memory intermediateRoots,
        bytes32 imageHash
    )
        internal
        view
        returns (bytes32)
    {
        return keccak256(
            abi.encodePacked(
                proposer,
                l1OriginHash,
                startingRoot,
                startingL2SequenceNumber,
                endingRoot,
                endingL2SequenceNumber,
                intermediateRoots,
                CONFIG_HASH,
                imageHash
            )
        );
    }
}

Expected vs Actual

Expected:

The ZK challenger should generate public inputs using the same intermediate-root interval that AggregateVerifier uses for the relevant game type. For Sepolia type 621, a challenge for one 30-block segment should produce exactly the one root that AggregateVerifier.challenge() verifies, or the contract and ZK prover should both agree on a smaller sub-interval format.

Actual:

The challenger requests a 30-block proof, but the ZK service hardcodes a 10-block intermediate-root interval. The resulting ZK public values include three roots, while AggregateVerifier.challenge() hashes only one root. The proof cannot verify against the on-chain journal.

Why This Is In Scope

This is not a generic zk circuit issue, the mismatch is in Base’s in-scope proof/challenger integration:

  • The challenger reads the deployed game interval but does not pass it to the ZK service.
  • The ZK service API has no field for the interval.
  • The ZK witness path hardcodes 10.
  • The deployed Sepolia Azul contract uses 30.
  • The Solidity challenge path hashes a one-root 30-block journal.