feat(protocol): raise the inbox basefee sharing percentage to 100% (Proposal0026) - #22127

Stacked on #22155, which renumbers the existing bridge / ERC20 vault proposal from Proposal0023 to Proposal0024.

What

Proposal0026 raises the mainnet Shasta inbox's basefeeSharingPctg from 75 to 100, so the whole L2 basefee of every block in a proposal made after execution goes to that block's coinbase and nothing is retained by the L2 fee treasury, the Anchor contract 0x1670000000000000000000000000000000010001. The percentage is a constructor immutable of the inbox implementation, so the proposal is one upgradeTo on the inbox proxy 0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f, executed by the DAO controller that owns it. 1 L1 action, no L2 leg, no initializer, immutables only.

The implementation is deployed and verified, and Proposal0026.action.md carries the executable calldata. Deployed on 2026-09-12 in L1 block 25,961,745 by DeployInboxUpgradeL1 (deployer 0x56706f118e42ae069f20c5636141b844d1324ae1, sources at 9deb5b590b4bf303ff161f0b8b14a49ab518a312); the address was checked on-chain before being written in.

	Address
MainnetInbox impl	0xA18431d42C8dF9778905fBEa912aCF1881b49D2e	codediff
LibInboxSetup (linked)	0x526957d1a25E9D3F5ab5a4926d07eEE5d612ED42	CREATE2 by the same run
LibForcedInclusion (linked)	0x511e1E5D9b9E23958076ccF1dD0033237a8cE4f8	CREATE2 by the same run

The Rationale section of Proposal0026.md is now written: it is what TAIKO holders read during the veto window, so it states where the non-coinbase share actually goes (an un-swept ETH balance in the Anchor, withdrawable by the DAO through the L2 delegate controller), the asymmetry the change trades on, the two limits of the refund, and a trade-offs section covering the forgone revenue and the fact that a proposer's own L2 gas round-trips fully at 100.

Under contracts/ three things move:

• MainnetInbox.sol: basefeeSharingPctg: 75 → 100. This is the change the proposal ships.
• DevnetInbox.sol: the same flip, so local and devnet deployments match mainnet. See below.
• LibL1Addrs.ZK_REQUIRED_VERIFIER: the live proof verifier 0x7284aaC0… (Proposal0019's ZkRequiredVerifier), which was only a Proposal0019 constant until now, so the deploy script reproduces all five live immutables from the address library.

The rest is the deploy script, the proposal, the action file, the runbook and tests. BuildProposal.sol is untouched.

Why this PR touches DevnetInbox and syncer_test.go

DevnetInbox.sol moves to basefeeSharingPctg: 100 as well, so local and devnet deployments behave like mainnet after execution. It is not in MainnetInbox's dependency tree and no deployed contract reads it; its only consumer is DeployProtocolOnL1.

That is what pulls packages/taiko-client/driver/chain_syncer/event/syncer_test.go in. The taiko-client integration tests deploy the protocol through DeployProtocolOnL1, and two of them — TestTreasuryIncome and TestTreasuryIncomeAllAnchors — asserted the treasury balance strictly grows. That only holds below 100: at 100 the coinbase takes the whole basefee and the treasury receives nothing. Both now derive the expectation from the inbox's own basefeeSharingPctg, so they are correct at any setting, and the per-transaction reconciliation in TestTreasuryIncome still pins the split exactly.

Kept here rather than split out, because it is load-bearing for the devnet flip in this PR: without it, merging this breaks main. Splitting them would only create a merge-order dependency — the test change would have to land first or main goes red — for no benefit, since the change is a no-op at 75.

Note that this PR's own integration lanes do not currently exercise the flip. taiko-client--test.yml checks the protocol out from main rather than from the PR, so they deploy DevnetInbox at 75 and only ever take the < 100 branch of the new assertions. #22142 fixes that; once it lands, merging main in here makes these lanes deploy this PR's contracts at 100.

The new implementation is the live one with one field changed

DeployInboxUpgradeL1 read the live proxy's getConfig() before broadcasting and would have aborted unless its five addresses were the LibL1Addrs constants it compiles in and its percentage still exactly 75 (OLD_BASEFEE_SHARING_PCTG); after deploying it compared the new implementation's getConfig() with the live one and would have aborted unless the percentage was the only difference. Read back on-chain at block 25,961,770: the new implementation's getConfig() equals the live proxy's in every field but basefeeSharingPctg (100 vs 75), it has 23,058 bytes of code, and proxiableUUID() returns the EIP-1967 implementation slot, which is what upgradeTo checks. test_mainnetInbox_MatchesTheLiveConfigExceptForBasefeeSharing pins every field of the live configuration as a literal against a MainnetInbox built from this tree.

Diffing the implementation's dependency tree (MainnetInbox.sol and its 23 imports under contracts/) from the commit the live implementation was built from (9078278909a43a83fc5bb2664f30b81eb5c967f6, Proposal0019) to main changes two files: MainnetInbox.sol (the literal, and the LibFasterReentryLock overrides that #22058 moved into the base contract) and EssentialContract.sol (#22058: the reentry lock in transient storage at the byte-identical _REENTRY_SLOT 0xa5054f72…; __reentry becomes private and keeps its slot). Nothing under contracts/layer1/core/ changed. MainnetInbox_Layout.sol is identical at both commits, _initialized is 3 and Inbox has no init4, the ABI and the Proposed event are unchanged, and LibInboxSetup.validateConfig allows <= 100, so 100 is the maximum rather than an edge case; both execution clients compute fee × pctg / 100, so the treasury remainder is exactly 0.

Evidence

• The code is authenticated, not just its getters. Etherscan holds the verified source (MainnetInbox, solc 0.8.30, osaka, optimizer 200 runs). Independently, the creation code is reproduced byte for byte from this branch: forge build, patch the two link references with the deployed library addresses, append the constructor arguments, and the result equals the deployment transaction's input (24,947 bytes). forge verify-bytecode cannot do this for a library-linked contract ("Unlinked bytecode is not supported"), and compiling with --libraries changes the metadata hash, so the runbook documents the manual comparison instead.
• Fork rehearsal against live mainnet state (Proposal0026Fork.t.sol, gated on L1_FORK_URL, passing on 2026-09-12 through a public RPC after the deployment): asserts the proxy still runs the Unzen implementation 0x5253D4C9…, executes the committed calldata from the DAO controller against the deployed implementation, and asserts the proxy answers 100 with every other configuration field, the core state, the last and last-finalized proposal hashes, the forced-inclusion queue and fee, the owner, the activation timestamp and the initializer version unchanged. Nothing is deployed by the test. A second test runs Controller.dryrun on the fork and expects DryrunSucceeded().
• P=0026 pnpm proposal:dryrun:l1 simulated against the deployment RPC reverts with DryrunSucceeded(), the success signal.
• Unit tests pin the encoding of the single upgradeTo, the revert on a missing implementation, the absence of an L2 leg, that the no-argument builder forwards the deployed address (a DEPLOYED_INBOX_IMPL literal, so a library edit cannot be mirrored silently), the full live configuration as literals, and that Proposal0026.action.md matches what the code builds.

Client rollout (runbook, Client rollout)

The drivers derive the byte from the Proposed event and provers take it from the event they verify, so neither needs a change. The whitelisted preconfer (Catalyst) caches getConfig().basefeeSharingPctg at startup, so it must be restarted right after execution: until then every block it preconfirms is re-derived with 100 once proposed (same transactions, different extraData and state root), i.e. one preconfirmation reorg per block. Blocks preconfirmed under 75 but carried by the first post-execution proposal are re-derived the same way, once; executing right after a proposal lands bounds that to a few blocks.

Review notes

• Error declarations sit at the top of the script and proposal files, matching Proposal0024.s.sol and DeployERC20VaultUpgradeL1.s.sol.
• MainnetInbox links two libraries (LibForcedInclusion and LibInboxSetup both have public functions), so the deployment was three creates, all in one block with status 1; the receipts were checked rather than forge's summary line.
• Contract logs are not touched here. They follow the docs(protocol): update mainnet contract logs for Proposal0023 #22120 pattern: a separate PR with the post-execution entries pre-written as TBD, filled after execution.
• DeployInboxUpgradeL1 must not be re-run; it also refuses to run once the live proxy answers 100.

Next steps

1. Create the DAO proposal from Proposal0026.action.md (target: DAO controller, execute(bytes)).
2. After execution: restart the whitelisted preconfer nodes, and record the upgrade in the contract logs.

🤖 Generated with Claude Code