Context

Wormhole has deprecated and shut down their Standard Relaying service (the on-chain WormholeRelayer that automatically delivered VAAs to destination chains). Our current L1BitcoinDepositor contract on Arbitrum and Base relies on wormholeRelayer.sendVaasToEvm() to deliver tBTC to L2 after deposit finalization — this path no longer works.

The fix replaces the on-chain Wormhole Relayer dependency with our own off-chain tBTC cross-chain relayer, which already handles VAA delivery for SUI deposits. The new contract uses wormholeTokenBridge.transferTokensWithPayload() to lock tBTC and emit a TokensTransferredWithPayload event. Our relayer monitors this event, fetches the signed VAA from WormholeScan, and calls receiveTbtc() on the L2 WormholeGateway to complete delivery. The Wormhole Guardian network and Token Bridge remain fully operational — only the automatic delivery service was removed.

Summary

Upgrade the L1BitcoinDepositor proxy on both Arbitrum and Base from the current L1BitcoinDepositor implementation to L1BTCDepositorWormholeV2. The storage layout is identical (24 slots, no changes). The relayer has already been updated and deployed with the corresponding EVM manual VAA bridging pipeline.

Verified Implementations

Chain Contract Implementation Etherscan
Arbitrum L1BTCDepositorWormholeV2Arbitrum 0x82FDDF79765Ed75325bCBdf65F67dF0879AAbe8C Verified
Base L1BTCDepositorWormholeV2Base 0x32aAfccfb865060F7F9fB3766c50134F9228B67E Verified

Both compiled with Solidity 0.8.17, optimizer 1000 runs. The Arbitrum and Base implementations have different bytecodes because the Base proxy was originally deployed from a separate repo with a different C3 linearization order (the Initializable storage occupies slot 49 on Base instead of being packed into slot 0 on Arbitrum). Each implementation's storage layout matches its respective proxy exactly. The wormholeRelayer and l2FinalizeDepositGasLimit storage slots are preserved for layout compatibility but unused by the new implementation.

PR Reference

Governance


Step 1: Schedule (requires 6-of-9 multisig)

The Safe must submit two schedule transactions to the TimelockController. Both can be proposed in the same Safe transaction batch.

1a. Arbitrum — Schedule