Skip to main content
This tutorial explains how to use Viem to process cross-domain transactions:
  • Deposited transactions: Also known as deposits, these are transactions initiated on L1 and executed on L2. They can be used to submit arbitrary L2 transactions from L1.
  • Withdrawals: These are cross-domain transactions initiated on L2 and finalized by a transaction executed on L1. They can be used to send arbitrary messages on L1 from L2 via the OptimismPortal.
Both deposit transactions and withdrawals can transfer ETH and data.

Supported networks

Viem supports any of the OP Stack networks. The OP Stack networks are included in Viem by default. If you want to use a network that isn’t included by default, you can add it to Viem’s chain configurations.

Dependencies

Create a demo project

You’re going to use Viem for this tutorial. Since Viem is a Node.js library, you’ll need to create a Node.js project to use it.
1

Make a project folder

2

Initialize the project

3

Install the Viem library

Want to create a new wallet for this tutorial? If you have cast installed you can run cast wallet new in your terminal to create a new wallet and get the private key.

Get ETH on Sepolia

This tutorial explains how to bridge ETH from Sepolia to OP Sepolia. You will need to get some ETH on Sepolia to follow along.
You can use this faucet to get ETH on Sepolia.

Add a private key to your environment

You need a private key in order to sign transactions. Set your private key as an environment variable with the export command. Make sure this private key corresponds to an address that has ETH on Sepolia.

Start the Node REPL

You’re going to use the Node REPL to interact with Viem. To start the Node REPL run the following command in your terminal:
This will bring up a Node REPL prompt that allows you to run JavaScript code.

Import dependencies

You need to import some dependencies into your Node REPL session.
1

Import Viem and other packages

2

Load private key and set account

3

Create L1 public client for reading from the Sepolia network

4

Create L1 wallet client for sending transactions on Sepolia

5

Create L2 public client for interacting with OP Sepolia

6

Create L2 wallet client on OP Sepolia

Get ETH on Sepolia

You’re going to need some ETH on L1 that you can bridge to L2. You can get some Sepolia ETH from this faucet.

Deposit ETH

Now that you have some ETH on L1, in addition to using the method described in Bridging ETH, you can also deposit ETH using the approach shown in the example below. If you are using a contract account, you should pay attention to Address Aliasing.
1

Check your wallet balance on L1

See how much ETH you have on L1 so you can confirm that the deposit worked later on.
We used formatEther method from viem to format the balance to ether.
2

Create the deposit transaction

Use buildDepositTransaction to build the deposit transaction parameters on L2.Be sure to understand the meanings of the optional parameters mint and value. You can also use someone else’s address as the to value if desired.
3

Send the deposit transaction

Send the deposit transaction on L1 and log the L1 transaction hash.
4

Wait for L1 transaction

Wait for the L1 transaction to be processed and log the receipt.
5

Extract the L2 transaction hash

Extracts the corresponding L2 transaction hash from the L1 receipt, and logs it. This hash represents the deposit transaction on L2.
6

Wait for the L2 transaction to be processed

Wait for the L2 transaction to be processed and confirmed and logs the L2 receipt to verify completion.

Withdraw ETH

You just bridged some ETH from L1 to L2. Nice! Now you’re going to repeat the process in reverse to bridge some ETH from L2 to L1. In addition to the method described in Bridging ETH, you can also withdraw ETH using the example approach shown below.
1

Create the withdrawal transaction

Uses buildInitiateWithdrawal to create the withdrawal parameters. Converts the withdrawal amount to wei and specifies the recipient on L1.
2

Executing the withdrawal

This sends the withdrawal transaction on L2, which initiates the withdrawal process on L2 and logs a transaction hash for tracking the withdrawal.
3

Confirming L2 transaction

Wait one hour (max) for the L2 Output containing the transaction to be proposed, and log the receipt, which contains important details like the block number etc.
4

Wait for withdrawal prove

Next, is to prove to the bridge on L1 that the withdrawal happened on L2. To achieve that, you first need to wait until the withdrawal is ready to prove.
Build parameters to prove the withdrawal on the L2.
5

Prove the withdrawal on the L1

Once the withdrawal is ready to be proven, you’ll send an L1 transaction to prove that the withdrawal happened on L2.
6

Wait for withdrawal finalization

Before a withdrawal transaction can be finalized, you will need to wait for the finalization period. This can only happen after the fault proof period has elapsed. On OP Mainnet, this takes 7 days.
We’re currently testing fault proofs on OP Sepolia, so withdrawal times reflect Mainnet times.
7

Finalize the withdrawal

8

Wait until the withdrawal is finalized

Recommend checking with getWithdrawalStatus before the waitToProve and waitToFinalize actions.

Submitting Arbitrary L2 Transactions from L1

EOAs can submit any transaction on L1 that needs to be executed on L2. This also makes it possible for users to interact with contracts on L2 even when the Sequencer is down. If the caller is a contract on L1, you need to pay attention to Address Aliasing. If you have just completed the Bridging ERC-20 tokens to OP Mainnet tutorial, you can try initiating an ERC-20 transfer transaction on L1 that will be executed on L2. encodeFunctionData and erc20Abi can be imported from Viem.

Use OptimismPortal to Send Arbitrary Messages on L1 from L2

The L2ToL1MessagePasser contract’s initiateWithdrawal function accepts a _target address and _data bytes. These are passed to a CALL opcode on L1 when finalizeWithdrawalTransaction is executed after the challenge period. This means that, by design, the OptimismPortal contract can be used to send arbitrary transactions on L1, with the OptimismPortal acting as the msg.sender.

Important Considerations

  • The purpose of this tutorial is to introduce deposited transactions and withdrawals. You should first consider whether the standard bridge and the messenger meet your use case requirements.
  • When working with deposited transactions, consider the implications of Address Aliasing.
  • When working with withdrawals, consider that OptimismPortal can send arbitrary messages on L1.
  • Challenge period: The 7-day withdrawal challenge period is crucial for security.
  • Gas costs: Withdrawals involve transactions on both L2 and L1, each incurring gas fees.
  • Private key handling: Use secure key management practices in real applications.
  • RPC endpoint security: Keep your API key (or any RPC endpoint) secure.