Skip to content

Conversation

@leopoldjoy
Copy link
Contributor

This PR adds MultisigScriptDeposit, an extension of MultisigScript that simplifies L1→L2 deposit transactions.

More specifically:

  • Task writers define L2 calls via _buildL2Calls() instead of manually wrapping in depositTransaction
  • Automatically wraps L2 calls in OptimismPortal.depositTransaction targeting CBMulticall on L2
  • Supports ETH bridging (sums values from L2 calls)

@cb-heimdall
Copy link
Collaborator

cb-heimdall commented Jan 5, 2026

🟡 Heimdall Review Status

Requirement Status More Info
Reviews 🟡 0/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
2 if repo is sensitive 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 0
Sum 1

@leopoldjoy
Copy link
Contributor Author

Since PR #170 makes some changes to the MultisigScript, we should hold off on merging this PR until that one is complete. I will make any necessary modifications to this one.


/// @notice Returns the OptimismPortal address on L1
/// @dev This is the portal contract that will be called to initiate the L2 deposit
function _optimismPortal() internal view virtual returns (address);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can provide a virtual function implementation for this below that returns the associated address based on the chain ID. This only exists on Sepolia and Mainnet and to my knowledge the addresses have never changed. Would be nice to not require every task to override this

///
/// Future enhancement: This could be expanded to calculate gas automatically
/// from per-call gas estimates provided in an extended Call3Value struct.
function _l2GasLimit() internal view virtual returns (uint64);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would also be ideal to not have to supply a hardcoded value for this. Is there a way we can simulate the call on a fork below within _buildCalls so we can estimate the value during script execution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants