fix(scripts): correct the Sepolia Mode chain Id, Celo Sepolia l1ChainId and the Celo processor ABI

[DavidMinarsch]

Three deployment-script defects. None affects a running contract; each would affect a fresh or repeated deployment.

Sepolia Mode target chain Id was Base's

globals_sepolia.json set modeL2TargetChainId to 84532 — Base Sepolia — the same value as baseL2TargetChainId. setDepositProcessorChainIds stores one processor per chain Id, so the second registration overwrote the first and Base claims would route through the Mode processor. Mode Sepolia is 919.

Celo Sepolia globals had no l1ChainId

The target deployment reads it and passed null for the fifth constructor argument, so it could not run; coercing to 0 fails too, because DefaultTargetDispenserL2 rejects a zero source chain. Added as "1", matching every sibling globals file and the value the deployed Mode Sepolia target carries.

deploy_10 attached the wrong ABI to the Celo processor

It used WormholeDepositProcessorL1 for a processor that is Optimism-style. Verified on-chain: the live Celo processor has no wormholeRelayer(), and its target exposes receiveMessage(bytes) rather than receiveWormholeMessages(...). deploy_05_celo_deposit_processor.sh already deploys OptimismDepositProcessorL1; only the registration step disagreed.

Documented rather than changed

deploy_10_set_deposit_processors.js cannot register the Mode processor, because Mode is deployed at step 11 — after it runs. deploy_10_set_deposit_processors.sh is the newer equivalent and registers all eight routes. Rather than reorder a numbered sequence, the JS now says so, and says what happens if used alone: an unregistered chain resolves to a zero processor and reverts the claim, taking the rest of a batch with it. The live Dispenser has all eight routes mapped, so nothing is affected today.

The Mode Sepolia token, which this PR does not fix

An earlier revision of this branch changed modeOLASAddress to the deployed target's olas(). That was wrong and is reverted — on Mode Sepolia that address is Aave Token, so the target is misconfigured and copying its value propagated the error.

Neither side of the route is right:

address	Mode Sepolia	Base Sepolia
0x01B8b6384298D4848E3BE63D4C9D17830EeE488A (modeOLASAddress, also baseOLASAddress)	no code	no code
0xcfD1D50ce23C46D3Cf6407487B2F8934e96DC8f9 (target's olas())	AAVE	—

The processor is told to bridge to an address with no code; the target settles against AAVE. There is no OLAS on Mode Sepolia to point either at, and the target's olas is immutable — so this needs an OLAS deployment and a target redeploy, not a globals edit.

Related, and not previously reported: baseOLASAddress is that same address and has no code on Base Sepolia either, so the Base Sepolia route may have the same problem. Not changed here.

[DavidMinarsch]

no - this is aave https://sepolia.explorer.mode.network/address/0xcfD1D50ce23C46D3Cf6407487B2F8934e96DC8f9

[DavidMinarsch]

You're right, and I've reverted it — thank you for catching it.

Confirmed on Mode Sepolia: 0xcfD1D50ce23C46D3Cf6407487B2F8934e96DC8f9 reads name() = "Aave Token", symbol() = "AAVE", 5,835 bytes of code. I took it from the deployed target's immutable olas() and treated "what is deployed" as "what is correct". The target is misconfigured, so copying its value into the L1 side propagated the error instead of fixing it.

Checking further, neither side of that route is right:

address	Mode Sepolia	Base Sepolia	Ethereum Sepolia
0x01B8b6384298D4848E3BE63D4C9D17830EeE488A (old modeOLASAddress, also baseOLASAddress)	no code	no code	—
0xcfD1D50ce23C46D3Cf6407487B2F8934e96DC8f9 (target's olas())	AAVE	—	—
0xeb2725bD76f6b1569Cf1484fCa0f2D55714A085d (L1 olasAddress)	—	—	ERC20TokenOwnerless, exists

So the processor was told to bridge to an address with no code, and the target settles against AAVE. There is no OLAS on Mode Sepolia to point either at, and the target's olas is immutable — the route cannot be made correct by editing globals. It needs an OLAS deployed on Mode Sepolia and the target redeployed against it.

I've left modeOLASAddress as it was and kept only the chain Id correction (84532 → 919), which is unambiguous.

One thing worth a separate look: baseOLASAddress is the same 0x01B8…488A and has no code on Base Sepolia either, so the Base Sepolia route may have the same problem. That was not in the original report and I have not changed it.