Zircuit
  • Introduction
  • Frequently Asked Questions (FAQ)
  • Tokenomics
    • Zircuit Token (ZRC)
    • Bridging ZRC to Zircuit
  • Build on Zircuit
    • Quick Start
    • Deploy on Zircuit
    • Zircuit LST/LRT Liquidity Hub
  • Architecture and Concepts
    • Architecture
      • Modular Prover Design
      • Template Proofs
      • Versions and Updates
    • Concepts
    • Sequencer Level Security (SLS)
    • Gas Pricing and Transaction Fees
    • Transaction Statuses
    • Supported Transaction Types
  • Research
    • Research
    • Publications and Grants
    • Talks and Panels
  • Dev Tools
    • Block Explorer
    • RPC Endpoints
    • Bridge
    • Verifying Contracts
    • ERC20 Tokens with Zircuit Canonical Bridge
    • Development Frameworks
    • CREATE2 Deployments
    • Oracles
    • Indexing and Subgraph
    • Relayers
    • Unsupported Opcodes
    • Precompiles
    • L1 Data Fee Calculation
  • Smart Contracts
    • L1 Contracts
    • L2 Contracts
    • Contract Addresses
    • Bridged Token Addresses
  • Security
    • Security
    • Privileged Roles
    • Bug Bounty
    • Audit Reports
  • Garfield Testnet
    • Garfield Testnet Quick Start
    • Garfield Testnet Bridging Prerequisites
      • Adding the Sepolia Network To Metamask
      • Adding The Zircuit Garfield Testnet Network To Metamask
      • Connecting Metamask To Zircuit’s Bridge
    • Deploy on the Zircuit Garfield Testnet
    • RPC Endpoints
    • Block Explorer
    • Verifying Contracts
    • Bridge
    • Faucet
    • Differences & Limitations
    • Contract Addresses
  • Testnet Legacy
    • Legacy Testnet Quick Start
    • Legacy Testnet Bridging Prerequisites
      • Adding The Sepolia Network To Metamask
      • Adding The Zircuit Legacy Testnet Network To Metamask
      • Connecting Metamask To Zircuit’s Bridge
    • Deploy on the Legacy Zircuit Testnet
    • RPC Endpoints
    • Block Explorer
    • Verifying Contracts
    • Bridge
    • Faucet
    • Contract Addresses
  • Bridging Step-by-Step
    • Prequisites
      • Adding The Zircuit Network To Metamask
    • Bridging From Sepolia To Zircuit
    • Bridging From Zircuit To Sepolia
    • Completing Withdrawals From Zircuit
    • Bridging ERC20 Tokens Manually
    • Binance Web3 Wallet Task Tutorial
      • Binance Web3 Wallet Tutorial: Bridging back to Ethereum
    • Exploring Bridging Behaviors with EIP-7702
Powered by GitBook
On this page
  • GasPriceOracle
  • L1Block
  • L2CrossDomainMessenger
  • L2ERC721Bridge
  • L2StandardBridge
  • L2toL1MessagePasser
  1. Smart Contracts

L2 Contracts

The following are brief descriptions of the L2 contracts and some of their notable features.

GasPriceOracle

This contract offers an API for querying how large the L1 portion of the transaction fee will be, providing transparency and predictability in fee computation.

Functions

getL1Fee(bytes memory _data): Computes the L1 portion of the fee for a given RLP-encoded transaction.

gasPrice(): Retrieves the current L2 gas price (base fee).

baseFee(): Retrieves the current L2 base fee.

overhead(): Retrieves the current fee overhead from the L1Block contract.

scalar(): Retrieves the current fee scalar from the L1Block contract.

l1BaseFee(): Retrieves the latest known L1 base fee from the L1Block contract.

decimals(): Retrieves the number of decimals used in the scalar.

getL1GasUsed(bytes memory _data): Computes the amount of L1 gas used for a given transaction, considering the overhead and padding.

L1Block

The L1Blockcontract allows users on L2 to access information about the latest L1 block.

L2CrossDomainMessenger

The L2CrossDomainMessenger contract is instrumental in facilitating communication between L1 and L2, allowing for messages to be sent from L2 to L1 and ensuring the validity and safety of these messages. It abstracts lower-level details, providing a more user-friendly interface for developers working with cross-domain communication.

L2ERC721Bridge

Overall, the L2ERC721Bridge contract plays a crucial role in the cross-layer functionality of ERC721 tokens, allowing them to be transferred between L1 and L2 while maintaining the integrity and ownership of the tokens.

The contract acts as a minter for new tokens on L2 when it detects deposits into the L1 ERC721 bridge.

It also acts as a burner for tokens being withdrawn from L2 to L1.

It ensures seamless cross-layer functionality for ERC721 tokens, enabling them to be transferred between Ethereum and Zircuit without losing ownership or metadata.

Events

Emits ERC721BridgeFinalized when a deposit is finalized on L2.

Emits ERC721BridgeInitiated when a withdrawal is initiated from L2.

L2StandardBridge

This contract manages asset transfers between L2 and L1. For L2-native ERC20 tokens, withdrawals escrow them in this contract, while L1-native ERC20s are burnt on L2. Deposits from L1 to L2 are finalized by minting or releasing assets on L2.

Functions:

withdraw & withdrawTo: Initiate L2 to L1 withdrawals. The contract discerns between ETH and ERC20 withdrawals.

Limitations: The contract may not support all ERC20 types, especially those with transfer fees, rebasing, or blocklists.

L2toL1MessagePasser

This contract serves as the storage and management system for these L2-to-L1 messages, ensuring they are uniquely identified and can be processed on L1.

Events:

MessagePassed: Triggered when a withdrawal is initiated. Provides details about the message, including the sender, target, value, and the unique withdrawal hash.

WithdrawerBalanceBurnt: Triggered when the balance of the contract is burned.

Functions

receive function that allows users to send ETH directly to it, which in turn initiates a withdrawal.

initiateWithdrawal: This is the primary function that users or other contracts will call to send a message from L2 to L1. It constructs a withdrawal message based on parameters like target address on L1, gas limit, data, and the value (ETH amount). The function then computes the hash of this message and stores it in the sentMessages mapping to ensure the same message isn't sent twice. An event MessagePassed is then emitted with details of the message.

messageNonce: Returns the next nonce for a message to be sent. The nonce also embeds the message version in its upper two bytes. This approach ensures that different message structures can be distinguished and handled accordingly in the future.

PreviousL1 ContractsNextContract Addresses

Last updated 11 months ago