Key Smart Contracts

Introduction

The Multi-Ledger Rollup can receive deposits via smart contracts. The addresses of which are below:

The Multi-Ledger Rollup can also receive cross chain messages, which can be used for cross chain smart contract calls. The addresses of which are below:

How do deposits work?

The deposit process in the Multi-Ledger Rollup follows a secure cross-chain mechanism that enables users to transfer tokens from any connected L1 blockchain to the shared Multi-Ledger Rollup.

Here's more details on how the deposit process works:

Prerequisites for Deposits

Note: The following prerequisites are completed for each whitelisted token by Quant. This ensures that only authorized administrators can configure which chains and tokens are allowed to participate in the Multi-Ledger Rollup system.

To be able to deposit from a blockchain to the Rollup, the following whitelisting requirements must be met:

1. Rollup Whitelisted on Blockchain: The multi-ledger rollup must be whitelisted on the token whitelist contract located on each connected blockchain
2. Local Token Configuration: The token we want to deposit from a blockchain to the Rollup must be set as a local token on that blockchain's token whitelist contract
3. Rollup Token Whitelisted: The anchored token on the Rollup must be added as a whitelisted token on the Rollup's token whitelist contract

1. ERC20 Deposits

Important Note: If QNT is the ERC20 token being deposited, then the user will receive the native coin on the Rollup, not an ERC20 token. The native coin is required for transaction fees.

When a user wants to deposit tokens from a blockchain to the Multi-Ledger Rollup:

1. Token Approval: For ERC-20 tokens, the user must first approve the deposit contract to spend their tokens

2. Deposit Transaction: The user can call either of the following functions on the deposit contract:

   Option A: depositERC20() - Deposits to the sender's address on the Rollup:

   • _l1Token: Address of the blockchain token being deposited
   • _l2Token: Address of the anchored token on the Rollup
   • _amount: Amount of the token to deposit
   • _minGasLimit: Minimum gas limit for the deposit message on the Rollup
   • _extraData: Optional data to forward to the Rollup
   • _destinationChainId: Rollup chain Id

   Option B: depositERC20To() - Deposits to a specific address on the Rollup:

   • _l1Token: Address of the blockchain token being deposited
   • _l2Token: Address of the corresponding token on the Rollup
   • _to: Address of the recipient on the Rollup
   • _amount: Amount of the token to deposit
   • _minGasLimit: Minimum gas limit for the deposit message on the Rollup
   • _extraData: Optional data to forward to the Rollup
   • _destinationChainId: Rollup chain Id
   
   

2. Deposit Processing

The deposit contract on the original blockchain does the following:

1. Validates the deposit: Checks if the token is whitelisted and the user has sufficient balance
2. Locks the tokens: Transfers the tokens from user to the deposit contract
3. Creates cross-chain message: so that the token is transferred to the rollup

3. Rollup Processing

The Multi-Chain Rollup now processes the deposit:

1. Event Detection: The Rollup sequencer detects the TransactionDeposited event from the source blockchain
2. Transaction Creation: A deposit transaction is created on Rollup with the user's address and token amount
3. State Update: The Rollup updates its state to reflect the incoming deposit
4. Token Minting: The system creates a corresponding Rollup anchored token and sends it the the address requested by the user on the deposit step

How do withdrawals work?

Withdrawals in the Multi-Ledger Rollup follow a secure, fault-proof-based exit mechanism that allows users to move assets from the Rollup back to any connected L1 blockchain. Unlike deposits, withdrawals are asynchronous and require on-chain verification before funds can be released on L1.

This process ensures that Rollup state transitions are valid and challengeable before L1 assets are unlocked.

📘

Instant withdrawal route: The multi-ledger rollup also provides an instant withdrawal route. Further information on this will be released later.

---

Prerequisites for Withdrawals

Note: As with deposits, these prerequisites are configured and enforced by Quant to ensure that only authorized chains and tokens can participate in the Multi-Ledger Rollup.

Before a withdrawal can be finalized, the following conditions must be met:

1. Token Whitelisting The Rollup token must be whitelisted on the Rollup TokenWhitelist contract, and the corresponding L1 token must be authorized on the L1 side.

2. Valid Rollup State Commitment The Rollup block containing the withdrawal must be included in a "valid dispute game" whose output root is eventually finalized on L1.

3. Sufficient Balances and Approvals

   • The user must hold sufficient balance on the Rollup
   • ERC20 withdrawals require approval of the Rollup Standard Bridge

---

1. Initiating a Withdrawal on the Rollup

When a user wants to withdraw assets from the Rollup to L1:

1. (ERC20 only) Token Approval The user approves the Rollup Standard Bridge to transfer the specified token amount.

2. Withdrawal Transaction The user calls one of the following Rollup bridge functions:

   • withdraw() – withdraws to the sender’s address on L1
   • withdrawTo() – withdraws to a specific recipient on L1

   Parameters include:

   • Token address (or address(0) for native coin)
   • Withdrawal amount
   • Minimum gas limit for L1 execution
   • Source and destination chain IDs

3. State Recording The withdrawal is recorded in the Rollup’s L2ToL1MessagePasser contract and emits a MessagePassed event.

At this point, funds are burned or escrowed on the Rollup, but not yet released on L1.

---

2. Proving the Withdrawal on L1

After the withdrawal transaction is included in the Rollup:

1. Dispute Game Selection A dispute game is identified that covers a Rollup block at or after the withdrawal transaction.

2. Output Root Proof Construction The script derives:

   • Rollup state root
   • Message passer storage root
   • Block hash corresponding to the dispute game’s block

3. Merkle Proof Generation A Merkle proof is generated to show that the withdrawal exists in the Rollup state at the game’s block.

4. Proof Submission The user calls proveWithdrawalTransaction() on the Optimism Portal contract on L1, submitting:

   • The withdrawal parameters
   • The output root proof
   • The Merkle proof

Once proven, the withdrawal enters a proof maturity delay.

---

3. Dispute Resolution and Finalization

Before funds can be released on L1:

1. Dispute Game Resolution

   • The dispute game must resolve with DEFENDER_WINS
   • The game must then pass its finality delay

2. Proof Maturity Delay A mandatory waiting period ensures the proof cannot be front-run or invalidated.

3. Finalization After all delays have elapsed, the user calls:

   • finalizeWithdrawalTransaction()

At this point, the withdrawal is considered final.

---

4. L1 Settlement

After the withdrawal has been proven, all dispute games are finalized, and the proof maturity delay has elapsed, the withdrawal must be explicitly finalized on L1.

1. Finalize Transaction (L1) An L1 transaction is submitted calling finalizeWithdrawalTransaction() on the Optimism Portal contract. This is a standard L1 transaction, paid for with L1 gas, and can be submitted by any account (typically the withdrawing user).

2. Funds Release Upon successful execution of the finalization transaction:

   • ERC20 withdrawals transfer tokens to the recipient address on L1
   • Native coin withdrawals release ETH (or the native L1 asset) to the recipient

Until this L1 transaction is executed, the withdrawal remains authorized but not settled on L1.