C4 S-80 Multicall3 address as argument

[ScreamingHawk]

S-80 Multicall3 address mismatch on Sophon enables delegatecall hijack and complete wallet drain

https://code4rena.com/audits/2025-11-sequence-transaction-rails/submissions/S-80

Issue: Multicall3 is not available on all chains.

Analysis: As per the Multicall3 repo, Multicall3 can be deployed at 0xcA11bde05977b3631167028862bE2a173976CA11 via a presigned transaction. Most chains have this deployed already, however new chains may not have it available. The pre-deploy may not be able to be processed on some chains (due to gas prices / limits etc). Some chains use a different address for their canonical MultiCall3 implementation.

Fix: Adds Multicall3 as a parameter to support chains that do not have multicall3 deployed at the canonical address.

NOTE: I have also prepared 0xsequence/live-contracts#86 to deploy Multicall3 at the canonical address. Again, this pre-signed transaction may be blocked.

[ScreamingHawk]

Alternative suggestion: We are already tightly coupled to the Sequence V3 ecosystem. Why not leverage the Guest for multicall handling?

[Agusx1211]

Adding it to the constructor is cleaner, but it does not change much about how the contract works, since we are going to deploy this with a CREATE2 factory and it will be the same in all chains anyway.

I do agree that I am not sure why are we mix and matching stacks here, what is the logic behind not using the guest @shunkakinoki ? Using the Guest would make this a non-issue, a bit late to change it now

And about the issue:

Attacker deploys a malicious contract at 0xcA11… on Sophon.

How is the attacker supposed to do this? This is probably a (badly) AI generated vulnerability, if we are going to assume attackers can deploy any contract to any address then we have bigger problems than this

[shunkakinoki]

@Agusx1211 thank you for the above!

I do agree that I am not sure why are we mix and matching stacks here, what is the logic behind not using the guest @shunkakinoki ? Using the Guest would make this a non-issue, a bit late to change it now

This was kind of vibes things (sorry) but if I remember correctly there was something in the Guest module that prevented delegate calls here which the TrailsRouter is correct if I'm correct here but didn't want to affect downstream things so went with Multicall 😅
Sorry this was wrong.. yes we could definitely handle this as Guest going forward..

But.. definitely yes having as the same contracts w/ GuestModule would be nice

[ScreamingHawk]

There's a few changes we can make to the flow control if we want to leverage the seq wallets more. I suggest we pause going deep on those ideas for now.

Happy to drop this in favour of simply adding multicall3 deployment to our deployment scripts here: 0xsequence/live-contracts#86 See below

[ScreamingHawk]

Canonical Multicall3 deployment is blocked on a couple chains we support:

• Xai Sepolia
• Somnia testnet
• Somnia mainnet
• Maybe more mainnet ones I haven't checked them all

If we include this change we can use a different multicall3 address for these chains with known issues. Or we can use a consistent multicall address deployed via ERC-2470 instead of these presigned deployments that are prone to issues.

[Agusx1211]

I think we should re-deploy the multicall3 address using ERC-2470, that way we ensure we can deploy it everywhere that supports the main Sequence wallets

[ScreamingHawk]

Closing favour of #83