# Table of Contents
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Optimism Documentation](#optimism-documentation)
- [Page Not Found](#page-not-found)
- [Page Not Found](#page-not-found)
- [Page Not Found](#page-not-found)
- [Optimism Documentation](#optimism-documentation)
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/bridging/basics#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Bridging
Bridging basics
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Sending tokens](https://docs.optimism.io/app-developers/guides/bridging/basics#sending-tokens)
* [Sending data](https://docs.optimism.io/app-developers/guides/bridging/basics#sending-data)
* [Next steps](https://docs.optimism.io/app-developers/guides/bridging/basics#next-steps)
OP Mainnet is a “Layer 2” system and is fundamentally connected to Ethereum. However, OP Mainnet is also a distinct blockchain with its own blocks and transactions. App developers commonly need to move data and tokens between OP Mainnet and Ethereum. This process of moving data and tokens between the two networks is called “bridging”.
[](https://docs.optimism.io/app-developers/guides/bridging/basics#sending-tokens)
Sending tokens
----------------------------------------------------------------------------------------------------
One of the most common use cases for bridging is the need to send ETH or ERC-20 tokens between OP Mainnet and Ethereum. OP Mainnet has a system called the [Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge)
that makes it easy to move tokens in both directions. If you mostly need to bridge tokens, make sure to check out the [Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge)
guide.
[](https://docs.optimism.io/app-developers/guides/bridging/basics#sending-data)
Sending data
------------------------------------------------------------------------------------------------
Under the hood, the Standard Bridge is just an application that uses the OP Mainnet [message passing system to send arbitrary data between Ethereum and OP Mainnet](https://docs.optimism.io/app-developers/guides/bridging/messaging)
. Applications can use this system to have a contract on Ethereum interact with a contract on OP Mainnet, and vice versa. All of this is easily accessible with a simple, clean API.
[](https://docs.optimism.io/app-developers/guides/bridging/basics#next-steps)
Next steps
--------------------------------------------------------------------------------------------
Ready to start bridging? Check out these tutorials to get up to speed fast.
* [Learn how to bridge ERC-20 tokens with viem](https://docs.optimism.io/app-developers/tutorials/bridging/cross-dom-bridge-erc20)
* [Learn how to bridge ETH with viem](https://docs.optimism.io/app-developers/tutorials/bridging/cross-dom-bridge-eth)
* [Learn how to create a standard bridged token](https://docs.optimism.io/app-developers/tutorials/bridging/standard-bridge-standard-token)
* [Learn how to create a custom bridged token](https://docs.optimism.io/app-developers/tutorials/bridging/standard-bridge-custom-token)
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/bridging/basics.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/bridging/basics)
[Triggering OP Stack transactions from Ethereum](https://docs.optimism.io/app-developers/tutorials/transactions/send-tx-from-eth)
[Custom bridges](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/bridging/messaging#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Bridging
Sending data between L1 and L2
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Understanding contract calls](https://docs.optimism.io/app-developers/guides/bridging/messaging#understanding-contract-calls)
* [Basics of communication between layers](https://docs.optimism.io/app-developers/guides/bridging/messaging#basics-of-communication-between-layers)
* [Communication speed](https://docs.optimism.io/app-developers/guides/bridging/messaging#communication-speed)
* [For L1 to L2 transactions](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l1-to-l2-transactions)
* [For L2 to L1 transactions](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l2-to-l1-transactions)
* [Accessing msg.sender](https://docs.optimism.io/app-developers/guides/bridging/messaging#accessing-msg-sender)
* [Fees for sending data between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging#fees-for-sending-data-between-l1-and-l2)
* [For L1 to L2 transactions](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l1-to-l2-transactions-2)
* [For L2 to L1 transactions](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l2-to-l1-transactions-2)
* [Understanding the challenge period](https://docs.optimism.io/app-developers/guides/bridging/messaging#understanding-the-challenge-period)
Smart contracts on L1 (Ethereum) can interact with smart contracts on L2 (OP Mainnet) through a process called “bridging”. This page explains how bridging works, how to use it, and what to watch out for.
This is a high-level overview of the bridging process. For a step-by-step tutorial on how to send data between L1 and L2, check out the [Solidity tutorial](https://docs.optimism.io/app-developers/tutorials/bridging/cross-dom-solidity)
.
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#understanding-contract-calls)
Understanding contract calls
-----------------------------------------------------------------------------------------------------------------------------------
It can be easier to understand bridging if you first have a basic understanding of how contracts on EVM-based blockchains like OP Mainnet and Ethereum communicate within the _same_ network. The interface for sending messages _between_ Ethereum and OP Mainnet is designed to mimic the standard contract communication interface as much as possible. Here’s how a contract on Ethereum might trigger a function within another contract on Ethereum:
Report incorrect code
Copy
Ask AI
contract MyContract {
function doTheThing(address myContractAddress, uint256 myFunctionParam) public {
MyOtherContract(myContractAddress).doSomething(myFunctionParam);
}
}
Here, `MyContract.doTheThing` triggers a call to `MyOtherContract.doSomething`. Under the hood, Solidity is triggering the code for `MyOtherContract` by sending an [ABI encoded](https://docs.soliditylang.org/en/v0.8.23/abi-spec.html)
call for the `doSomething` function. A lot of this complexity is abstracted away to simplify the developer experience. Solidity also has manual encoding tools that allow us to demonstrate the same process in a more verbose way. Here’s how you might manually encode the same call:
Report incorrect code
Copy
Ask AI
contract MyContract {
function doTheThing(address myContractAddress, uint256 myFunctionParam) public {
myContractAddress.call(
abi.encodeCall(
MyOtherContract.doSomething,
(
myFunctionParam
)
)
);
}
}
Here you’re using the [low-level “call” function](https://docs.soliditylang.org/en/v0.8.23/units-and-global-variables.html#members-of-address-types)
and one of the [ABI encoding functions built into Solidity](https://docs.soliditylang.org/en/v0.8.23/units-and-global-variables.html#abi-encoding-and-decoding-functions)
. Although these two code snippets look a bit different, they’re doing the exact same thing. Because of limitations of Solidity, **the OP Stack’s bridging interface is designed to look like the second code snippet**.
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#basics-of-communication-between-layers)
Basics of communication between layers
-------------------------------------------------------------------------------------------------------------------------------------------------------
At a high level, the process for sending data between L1 and L2 is pretty similar to the process for sending data between two contracts on Ethereum (with a few caveats). Communication between L1 and L2 is made possible by a pair of special smart contracts called the “messenger” contracts. Each layer has its own messenger contract, which serves to abstract away some lower-level communication details, a lot like how HTTP libraries abstract away physical network connections. We won’t get into _too_ much detail about these contracts here. The most important thing that you need to know is that each messenger contract has a `sendMessage` function that allows you to send a message to a contract on the other layer.
Report incorrect code
Copy
Ask AI
function sendMessage(
address _target,
bytes memory _message,
uint32 _minGasLimit
) public;
The `sendMessage` function has three parameters:
1. The `address _target` of the contract to call on the other layer.
2. The `bytes memory _message` calldata to send to the contract on the other layer.
3. The `uint32 _minGasLimit` minimum gas limit that can be used when executing the message on the other layer.
This is basically equivalent to:
Report incorrect code
Copy
Ask AI
address(_target).call{gas: _minGasLimit}(_message);
Except, of course, that you’re calling a contract on a completely different network. This is glossing over a lot of the technical details that make this whole thing work under the hood, but this should be enough to get you started. Want to call a contract on OP Mainnet from a contract on Ethereum? It’s dead simple:
Report incorrect code
Copy
Ask AI
// Pretend this is on L2
contract MyOptimisticContract {
function doSomething(uint256 myFunctionParam) public {
// ... some sort of code goes here
}
}
// And pretend this is on L1
contract MyContract {
function doTheThing(address myOptimisticContractAddress, uint256 myFunctionParam) public {
messenger.sendMessage(
myOptimisticContractAddress,
abi.encodeCall(
MyOptimisticContract.doSomething,
(
myFunctionParam
)
),
1000000 // or use whatever gas limit you want
)
}
}
You can find the addresses of the `L1CrossDomainMessenger` and the `L2CrossDomainMessenger` contracts on OP Mainnet and OP Sepolia on the [Contract Addresses](https://docs.optimism.io/op-mainnet/network-information/op-addresses)
page.
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#communication-speed)
Communication speed
-----------------------------------------------------------------------------------------------------------------
Unlike calls between contracts on the same blockchain, calls between Ethereum and OP Mainnet are _not_ instantaneous. The speed of a cross-chain transaction depends on the direction in which the transaction is sent.
###
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l1-to-l2-transactions)
For L1 to L2 transactions
Transactions sent from L1 to L2 take **approximately 1-3 minutes** to get from Ethereum to OP Mainnet, or from Sepolia to OP Sepolia. This is because the Sequencer waits for a certain number of L1 blocks to be created before including L1 to L2 transactions to avoid potentially annoying [reorgs](https://www.alchemy.com/overviews/what-is-a-reorg)
.
###
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l2-to-l1-transactions)
For L2 to L1 transactions
Transactions sent from L2 to L1 take **approximately 7 days** to get from OP Mainnet to Ethereum, or from OP Sepolia to Sepolia. This is because the bridge contract on L1 must wait for the L2 state to be _proven_ to the L1 chain before it can relay the message. The process of sending transactions from L2 to L1 involves four distinct steps:
1. The L2 transaction that sends a message to L1 is sent to the Sequencer. This is just like any other L2 transaction and takes just a few seconds to be confirmed by the Sequencer.
2. The block containing the L2 transaction is proposed to the L1. This typically takes approximately 20 minutes.
3. A proof of the transaction is submitted to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol#L209)
contract on L1. This can be done any time after step 2 is complete.
4. The transaction is finalized on L1. This can _only_ be done after the [fault challenge period](https://docs.optimism.io/app-developers/guides/bridging/messaging#understanding-the-challenge-period)
has elapsed. This period is 7 days on Ethereum and a few seconds on Sepolia. This waiting period is a core part of the security model of the OP Stack and cannot be circumvented.
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#accessing-msg-sender)
Accessing `msg.sender`
---------------------------------------------------------------------------------------------------------------------
Contracts frequently make use of `msg.sender` to make decisions based on the calling address. For example, many contracts will use the [Ownable](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/access/Ownable.sol)
pattern to selectively restrict access to certain functions. Because messages are essentially shuttled between L1 and L2 by the messenger contracts, **the `msg.sender` you’ll see when receiving one of these messages will be the messenger contract** corresponding to the layer you’re on. In order to get around this, you can find a `xDomainMessageSender` function to each messenger:
Report incorrect code
Copy
Ask AI
function xDomainMessageSender() public returns (address);
If your contract has been called by one of the messenger contracts, you can use this function to see who’s _actually_ sending this message. Here’s how you might implement an `onlyOwner` modifier on L2:
Report incorrect code
Copy
Ask AI
modifier onlyOwner() {
require(
msg.sender == address(messenger)
&& messenger.xDomainMessageSender() == owner
);
_;
}
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#fees-for-sending-data-between-l1-and-l2)
Fees for sending data between L1 and L2
---------------------------------------------------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l1-to-l2-transactions-2)
For L1 to L2 transactions
The majority of the cost of an L1 to L2 transaction comes from the smart contract execution on L1. When sending an L1 to L2 transaction, you send to the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/L1CrossDomainMessenger.sol)
contract, which then sends a call to the [`OptimismPortal`](https://github.com/ethereum-optimism/optimism/blob/111f3f3a3a2881899662e53e0f1b2f845b188a38/packages/contracts-bedrock/src/L1/OptimismPortal.sol)
contract. This involves some execution on L1, which costs gas. The total cost is ultimately determined by gas prices on Ethereum when you’re sending the cross-chain transaction. L1 to L2 execution also triggers contract execution on L2. The `OptimismPortal` contract charges you for this L2 execution by burning a dynamic amount of L1 gas during your L1 to L2 transaction, depending on the gas limit you requested on L2. The amount of L1 gas charged increases when more people are sending L1 to L2 transactions (and decreases when fewer people are sending L1 to L2 transactions).
Since the gas amount charged is dynamic, the gas burn can change from block to block. You should always add a buffer of at least 20% to the gas limit for your L1 to L2 transaction to avoid running out of gas.
###
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#for-l2-to-l1-transactions-2)
For L2 to L1 transactions
Each message from L2 to L1 requires three transactions:
1. An L2 transaction that _initiates_ the transaction, which is priced the same as any other transaction made on OP Mainnet.
2. An L1 transaction that _proves_ the transaction. This transaction can only be submitted after the L2 block, including your L2 transaction, is proposed on L1. This transaction is expensive because it includes verifying a [Merkle trie](https://docs.optimism.io/connect/resources/glossary#merkle-patricia-trie)
inclusion proof on L1.
3. An L1 transaction that _finalizes_ the transaction. This transaction can only be submitted after the transaction challenge period (7 days on mainnet) has passed.
The total cost of an L2 to L1 transaction is therefore the combined cost of the L2 initialization transaction and the two L1 transactions. The L1 proof and finalization transactions are typically significantly more expensive than the L2 initialization transaction.
[](https://docs.optimism.io/app-developers/guides/bridging/messaging#understanding-the-challenge-period)
Understanding the challenge period
-----------------------------------------------------------------------------------------------------------------------------------------------
One of the most important things to understand about L1 ⇔ L2 interaction is that **mainnet messages sent from Layer 2 to Layer 1 cannot be relayed for at least 7 days**. This means that any messages you send from Layer 2 will only be received on Layer 1 after this one-week period has elapsed. We call this period of time the “challenge period” because it is the time during which a transaction can be challenged with a [fault proof](https://docs.optimism.io/op-stack/protocol/overview#fault-proofs)
. Optimistic Rollups are “optimistic” because they’re based around the idea of publishing the _result_ of a transaction to Ethereum without actually executing the transaction on Ethereum. In the “optimistic” case, this transaction result is correct and one can completely avoid the need to perform complicated (and expensive) logic on Ethereum. However, one still needs to find a way to prevent incorrect transaction results from being published in place of correct ones. Here’s where the “fault proof” comes into play. Whenever a transaction result is published, it’s considered “pending” for a period of time known as the challenge period. During this period of time, anyone may re-execute the transaction _on Ethereum_ in an attempt to demonstrate that the published result was incorrect. If someone can prove that a transaction result is faulty, then the result is scrubbed from existence and anyone can publish another result in its place (hopefully the correct one this time, financial punishments make faulty results _very_ costly for their publishers). Once the window for a given transaction result has fully passed without a challenge, the result can be considered fully valid (or else someone would’ve challenged it). Anyway, the point here is that **you don’t want to be making decisions about Layer 2 transaction results from inside a smart contract on Layer 1 until this challenge period has elapsed**. Otherwise you might be making decisions based on an invalid transaction result. As a result, L2 ⇒ L1 messages sent using the standard messenger contracts cannot be relayed until they’ve waited out the full challenge period.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/bridging/messaging.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/bridging/messaging)
[Custom bridges](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge)
[Using the Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Bridging
Custom bridges
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Guidelines](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#guidelines)
* [The Superchain Token List](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#the-superchain-token-list)
* [Next steps](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#next-steps)
Custom token bridges are any bridges other than the [Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge)
. You may find yourself in a position where you need to build a custom token bridge because the Standard Bridge doesn’t completely support your use case. This guide provides important information you should be aware of when building a custom bridge.
Custom bridges can bring a significant amount of complexity and risk to any project. Before you commit to a custom bridge, be sure that the [Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge)
definitely does not support your use case. [Building a custom bridged token](https://docs.optimism.io/app-developers/tutorials/bridging/standard-bridge-custom-token)
is often sufficient for projects that need more flexibility.
[](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#guidelines)
Guidelines
---------------------------------------------------------------------------------------------------
Custom bridges can use any design pattern you can think of. However, with increased complexity comes increased risk. Consider directly extending or modifying the [`StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/87dd5a4743380b717dac44a4e55c5e6e60e32684/packages/contracts-bedrock/src/universal/StandardBridge.sol)
contract before building your own bridge contracts from scratch. Doing so will provide you with an audited foundation upon which you can add extra logic. If you choose not to extend the `StandardBridge` contract, you may still want to follow the interface that the `StandardBridge` provides. Bridges that extend this interface will be compatible with the [Superchain Bridges UI](https://app.optimism.io/bridge?utm_source=op-docs&utm_medium=docs)
. You can read more about the design of the Standard Bridge in the guide on [Using the Standard Bridge](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge)
.
[](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#the-superchain-token-list)
The Superchain Token List
---------------------------------------------------------------------------------------------------------------------------------
The [Superchain Token List](https://docs.optimism.io/app-developers/reference/tokens/tokenlist)
exists to help users and developers find the right bridged representations of tokens native to another blockchain. Once you’ve built and tested your custom bridge, make sure to register any tokens meant to flow through this bridge by [making a pull request against the Superchain Token List repository](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list)
. You **must** deploy your bridge to OP Sepolia before it can be added to the Superchain Token List.
[](https://docs.optimism.io/app-developers/guides/bridging/custom-bridge#next-steps)
Next steps
---------------------------------------------------------------------------------------------------
You can explore several examples of custom bridges for OP Mainnet:
* [NFT Bridge](https://github.com/ethereum-optimism/optimism/blob/v1.1.4/packages/contracts-bedrock/src/L1/L1ERC721Bridge.sol)
* [L2 DAI Token Bridge](https://explorer.optimism.io/address/0x467194771dae2967aef3ecbedd3bf9a310c76c65#code)
and [deployed addresses](https://github.com/ethereum-optimism/ethereum-optimism.github.io/blob/master/data/DAI/data.json)
* [SNX Bridge](https://github.com/ethereum-optimism/ethereum-optimism.github.io/blob/master/data/SNX/data.json)
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/bridging/custom-bridge.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/bridging/custom-bridge)
[Bridging basics](https://docs.optimism.io/app-developers/guides/bridging/basics)
[Sending data between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/interoperability/estimate-costs#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/interoperability/estimate-costs.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/interoperability/estimate-costs)
[Message expiration](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration)
[Estimating transaction fees on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/estimates)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Interoperability
Message expiration
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Message expiration](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#message-expiration)
* [The expiry window](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#the-expiry-window)
* [Reemitting an expired message](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#reemitting-an-expired-message)
* [Next steps](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#next-steps)
[](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#message-expiration)
Message expiration
================================================================================================================================
[Messages](https://docs.optimism.io/app-developers/guides/interoperability/message-passing)
referenced between OP Stack chains have a limited validity period called the expiry window. Once this window elapses, the referenced message becomes invalid and can no longer be referenced. For messages using [`L2ToL2CrossDomainMessenger`](https://docs.optimism.io/app-developers/guides/interoperability/message-passing)
, if a message expires before being referenced, developers can reemit the message on the source chain. This triggers a fresh `SentMessage` event, enabling the message to be relayed.
[](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#the-expiry-window)
The expiry window
------------------------------------------------------------------------------------------------------------------------------
The expiry window is an offchain constant, defined by [OP-Supervisor](https://docs.optimism.io/chain-operators/reference/components/op-supervisor)
, that defines how long a cross-chain message or event emitted remains valid. For any chain in the [Superchain interop cluster](https://docs.optimism.io/interop/explainer#superchain-interop-cluster)
, messages must be referenced within 7 days (604,800 seconds) of the log being created. After this period, a message can no longer be referenced unless the event is remitted.
[](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#reemitting-an-expired-message)
Reemitting an expired message
------------------------------------------------------------------------------------------------------------------------------------------------------
The `resendMessage` function on the [`L2ToL2CrossDomainMessenger`](https://docs.optimism.io/app-developers/guides/interoperability/message-passing)
contract allows developers to reemit a message that was sent but not yet relayed. This emits a new `SentMessage` log with the same content as the original message, enabling offchain relayers to pick it up again. The process to reemit an expired message:
1. Call [`resendMessage`](https://github.com/ethereum-optimism/optimism/blob/a979a9444dbb482843f2a42f437ced54a8ac1053/packages/contracts-bedrock/interfaces/L2/IL2ToL2CrossDomainMessenger.sol#L110-L128)
on the origin chain to reemit the message event. The contract verifies the message hash was originally sent. The call requires [every parameter](https://github.com/ethereum-optimism/optimism/blob/a979a9444dbb482843f2a42f437ced54a8ac1053/packages/contracts-bedrock/interfaces/L2/IL2ToL2CrossDomainMessenger.sol#L110-L128)
to rebuild the original message.
2. [Relay the new message](https://docs.optimism.io/interop/message-passing#executing-message)
as normal.
Note: Re-emitting an already relayed message will have no effect on the destination chain since the re-emitted event won’t be logged by OP-Supervisor.
[](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration#next-steps)
Next steps
----------------------------------------------------------------------------------------------------------------
* [Build a revolutionary app](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
that uses multiple blockchains within the Superchain
* Learn how to [pass messages between blockchains](https://docs.optimism.io/app-developers/tutorials/interoperability/message-passing)
* Deploy a [SuperchainERC20](https://docs.optimism.io/app-developers/tutorials/tokens/deploy-superchain-erc20)
to the Superchain
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/interoperability/message-expiration.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/interoperability/message-expiration)
[Reading Logs with Superchain Interop](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs)
[Estimate costs](https://docs.optimism.io/app-developers/guides/interoperability/estimate-costs)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/transactions/statuses#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Transactions
Transaction statuses on OP Mainnet
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Pending](https://docs.optimism.io/app-developers/guides/transactions/statuses#pending)
* [Sequencer confirmed or unsafe](https://docs.optimism.io/app-developers/guides/transactions/statuses#sequencer-confirmed-or-unsafe)
* [Published to Ethereum or safe](https://docs.optimism.io/app-developers/guides/transactions/statuses#published-to-ethereum-or-safe)
* [Finalized](https://docs.optimism.io/app-developers/guides/transactions/statuses#finalized)
Transactions on OP Mainnet can have a number of different statuses depending on where a transaction is in the process of being included in the blockchain. Understanding these statuses can help you troubleshoot issues, build safer applications, and display more accurate information to your users.
[](https://docs.optimism.io/app-developers/guides/transactions/statuses#pending)
Pending
--------------------------------------------------------------------------------------------
**Instant after sending to the Sequencer** A transaction is considered “pending” when it has been sent to the Sequencer but has not yet been included in a block. This is the first status a transaction will have after being sent to the Sequencer. At this point the transaction is not part of the blockchain and there is no guarantee that the transaction will be included in the blockchain. The list of all pending transactions can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber)
with the parameter `pending` as the block number.
[](https://docs.optimism.io/app-developers/guides/transactions/statuses#sequencer-confirmed-or-unsafe)
Sequencer confirmed or unsafe
----------------------------------------------------------------------------------------------------------------------------------------
**Typically within 2-4 seconds** A transaction is considered “sequencer confirmed” or “unsafe” when it has been included in a block by the Sequencer but that block has **not** yet been published to Ethereum. Although the transaction is included in a block, it is still possible for the transaction to be excluded from the final blockchain if the Sequencer fails to publish the block to Ethereum within the [Sequencing Window](https://docs.optimism.io/connect/resources/glossary#sequencing-window)
(approximately 12 hours). Applications should make sure to consider this possibility when displaying information about transactions that are in this state. The latest “sequencer confirmed” block can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber)
with the parameter `safe` as the block number and comparing this to the result returned for the `latest` block. If the `safe` block is behind the `latest` block, then the earliest “sequencer confirmed” block is the `safe` block plus one.
[](https://docs.optimism.io/app-developers/guides/transactions/statuses#published-to-ethereum-or-safe)
Published to Ethereum or safe
----------------------------------------------------------------------------------------------------------------------------------------
**Typically within 5-10 minutes, up to 12 hours** A transaction is considered “safe” when it has been included in a block by the Sequencer and that block has been published to Ethereum but that block is not yet finalized. Once a block has been published to Ethereum there is a high likelihood that the block will be included in the final blockchain. However, it is still possible for the block to be excluded from the final blockchain if the Ethereum blockchain experiences a reorganization. The latest “safe” block can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber)
with the parameter `safe` as the block number. Transactions typically become “safe” within a few minutes of becoming “sequencer confirmed”.
[](https://docs.optimism.io/app-developers/guides/transactions/statuses#finalized)
Finalized
------------------------------------------------------------------------------------------------
**Typically within 15-20 minutes, up to 12 hours** A transaction is considered “finalized” when it has been included in a block by the Sequencer, that block has been published to Ethereum, and that block has been finalized. Once a block has been finalized it is guaranteed to be included in the OP Mainnet blockchain. Applications that require the highest level of certainty that a transaction will be included in the blockchain should wait until the transaction is “finalized” before considering the transaction to be successful. The latest “finalized” block can be retrieved by calling the standard JSON-RPC method [`eth_getBlockByNumber`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_getblockbynumber)
with the parameter `finalized` as the block number.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/transactions/statuses.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/transactions/statuses)
[Setting transaction gas parameters on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/parameters)
[Troubleshooting transactions](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/building-apps#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Guides
Building apps on the Superchain
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [OP Stack chains endpoint URLs](https://docs.optimism.io/app-developers/guides/building-apps#op-stack-chains-endpoint-urls)
* [Network choice](https://docs.optimism.io/app-developers/guides/building-apps#network-choice)
* [Interacting with contracts on OP Stack chains](https://docs.optimism.io/app-developers/guides/building-apps#interacting-with-contracts-on-op-stack-chains)
* [Development stacks](https://docs.optimism.io/app-developers/guides/building-apps#development-stacks)
* [Best practices](https://docs.optimism.io/app-developers/guides/building-apps#best-practices)
* [Use provided EVM](https://docs.optimism.io/app-developers/guides/building-apps#use-provided-evm)
* [Debug before deploying](https://docs.optimism.io/app-developers/guides/building-apps#debug-before-deploying)
* [Contract source verification](https://docs.optimism.io/app-developers/guides/building-apps#contract-source-verification)
This guide explains the basics of OP Stack development. OP Stack chains are [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306)
, meaning they run a slightly modified version of the same `geth` you run on mainnet. Therefore, the differences between OP Stack development and Ethereum development are minor. But a few differences [do exist](https://docs.optimism.io/op-stack/protocol/differences)
.
[](https://docs.optimism.io/app-developers/guides/building-apps#op-stack-chains-endpoint-urls)
OP Stack chains endpoint URLs
--------------------------------------------------------------------------------------------------------------------------------
To access any Ethereum type network you need an endpoint. [These providers](https://docs.optimism.io/app-developers/reference/rpc-providers)
support our networks.
###
[](https://docs.optimism.io/app-developers/guides/building-apps#network-choice)
Network choice
For development purposes we recommend you use either a local development network or [OP Sepolia](https://sepolia-optimism.etherscan.io/)
. That way you don’t need to spend real money. If you need ETH on OP Sepolia for testing purposes, [you can use this faucet](https://console.optimism.io/faucet?utm_source=op-docs&utm_medium=docs)
.
[](https://docs.optimism.io/app-developers/guides/building-apps#interacting-with-contracts-on-op-stack-chains)
Interacting with contracts on OP Stack chains
----------------------------------------------------------------------------------------------------------------------------------------------------------------
We have Hardhat’s Greeter contract on OP Sepolia at address [0x9d334aFBa83865E67a9219830ADA57aaA9406681](https://testnet-explorer.optimism.io/address/0x9d334aFBa83865E67a9219830ADA57aaA9406681#code)
. You can verify your development stack configuration by interacting with it.
[](https://docs.optimism.io/app-developers/guides/building-apps#development-stacks)
Development stacks
----------------------------------------------------------------------------------------------------------
As you can see in the different development stacks below, the way you deploy contracts and interact with them on OP Stack chains is almost identical to the way you do it with L1 Ethereum. The most visible difference is that you have to specify a different endpoint (of course). For more detail, see the guide on [Differences between Ethereum and OP Stack Chains](https://docs.optimism.io/op-stack/protocol/differences)
.
* [Foundry](https://getfoundry.sh/)
* [Hardhat](https://hardhat.org/)
* [Apeworx](https://www.apeworx.io/)
* [Brownie](https://eth-brownie.readthedocs.io/en/stable/install.html)
* [Remix](https://remix.ethereum.org/)
* [Waffle](https://getwaffle.io/)
[](https://docs.optimism.io/app-developers/guides/building-apps#best-practices)
Best practices
--------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/app-developers/guides/building-apps#use-provided-evm)
Use provided EVM
It is best to start development with the EVM provided by the development stack. Not only is it faster, but such EVMs often have extra features, such as the [ability to log messages from Solidity](https://hardhat.org/tutorial/debugging-with-hardhat-network.html)
or a [graphical user interface](https://trufflesuite.com/ganache/)
.
###
[](https://docs.optimism.io/app-developers/guides/building-apps#debug-before-deploying)
Debug before deploying
After you are done with that development, debug your decentralized application locally and then on a [Sepolia test network](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
. This lets you debug parts that are OP Stack chains specific such as calls to bridges to transfer ETH or tokens between layers. Only when you have a version that works well on a test network should you deploy to the production network, where every transaction has a cost.
###
[](https://docs.optimism.io/app-developers/guides/building-apps#contract-source-verification)
Contract source verification
You don’t have to upload your source code to [block explorers](https://docs.optimism.io/app-developers/tools/infrastructure/block-explorers)
, but it is a good idea. On the test network, it lets you issue queries and transactions from the explorer’s user interface. On the production network, it lets users know exactly what your contract does, which is conducive to trust. Just remember, if you use [the Etherscan API](https://explorer.optimism.io/apis?utm_source=op-docs&utm_medium=docs)
, you need one API key for OP Stack chains and a separate one for OP Sepolia.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/building-apps.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/building-apps)
[Integrating DeFi with Actions SDK](https://docs.optimism.io/app-developers/quickstarts/actions)
[Superchain Overview](https://docs.optimism.io/app-developers/guides/superchain)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Interoperability
Interop message passing overview
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Initiating message](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#initiating-message)
* [Executing message](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#executing-message)
* [Next steps](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#next-steps)
Superchain interop is in active development. Some features may be experimental.
This is an explanation of how interop works. You can find a step by step tutorial [here](https://docs.optimism.io/app-developers/tutorials/interoperability/message-passing)
.
The low-level [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol)
contract handles basic message execution. It verifies whether an initiating message exists but does not check the message’s destination, processing status, or other attributes. The [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol)
contract extends `CrossL2Inbox` by providing complete cross-domain messaging functionality. For high-level interoperability, both messages use the `L2ToL2CrossDomainMessenger` contract on their respective chains.
[](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#initiating-message)
Initiating message
-----------------------------------------------------------------------------------------------------------------------------
1. The application sends a transaction to a contract on the source chain.
2. The contract calls [`L2ToL2CrossDomainMessenger.SendMessage`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol#L125-L142)
. The call requires these parameters:
* `_destination`: The chain ID of the destination blockchain.
* `_target`: The address of the contract on that blockchain.
* `_message`: The actual message.
This message is provided to `_target` as calldata, which means it includes a function selector and the parameters for that function call.
3. `L2ToL2CrossDomainMessenger` on the source chain verifies the message is legitimate:
* The destination chain is one to which this chain can send messages.
* The destination chain is _not_ the source chain.
* The target is neither `CrossL2Inbox` nor `L2ToL2CrossDomainMessenger`.
4. `L2ToL2CrossDomainMessenger` emits a log entry. In addition to the parameters, the log entry also includes:
* `_nonce`: A [nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce)
value to ensure the message is only executed once.
* `_sender`: The contract that sent the cross domain message.
[](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#executing-message)
Executing message
---------------------------------------------------------------------------------------------------------------------------
1. Before the executing message is processed, the log event of the initiating message has to get to `op-supervisor` on the destination chain before the [expiry window](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration)
of 7 days.
2. The autorelayer, the application, or a contract calling on the application’s behalf calls [`L2ToL2CrossDomainMessenger.relayMessage`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol#L150-L203)
. This call includes the message that was sent (`_sentMessage`), as well as the [fields required to find that message (`_id`)](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/interfaces/L2/ICrossL2Inbox.sol#L4-L10)
.
3. The `L2ToL2CrossDomainMessenger` uses `CrossL2Inbox` to verify the message was sent from the source.
4. `L2ToL2CrossDomainMessenger` on the destination chain verifies the message is legitimate:
* `_destination`: Chain ID of the destination chain.
* `_nonce`: Nonce of the message sent
* `_sender`: Address that sent the message
* `_target`: Target contract or wallet address.
* `message`: Message payload to call target with.
5. If everything checks out, `L2ToL2CrossDomainMessenger` calls the destination contract with the calldata provided in the message.
[](https://docs.optimism.io/app-developers/guides/interoperability/message-passing#next-steps)
Next steps
-------------------------------------------------------------------------------------------------------------
* Build a [revolutionary app](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
that uses multiple blockchains within the Superchain
* Learn how to [pass messages between blockchains](https://docs.optimism.io/app-developers/tutorials/interoperability/message-passing)
.
* Deploy a [SuperchainERC20](https://docs.optimism.io/app-developers/tutorials/tokens/deploy-superchain-erc20)
to the Superchain.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/interoperability/message-passing.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/interoperability/message-passing)
[Build interoperable apps on Superchain devnet](https://docs.optimism.io/app-developers/guides/interoperability/get-started)
[Reading Logs with Superchain Interop](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Transactions
Troubleshooting transactions
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Transactions stuck in the transaction pool](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#transactions-stuck-in-the-transaction-pool)
* [Recommendation](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendation)
* [Recommendations for wallet developers](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendations-for-wallet-developers)
* [Recommendations for app developers](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendations-for-app-developers)
* [Recommendations for users](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendations-for-users)
* [Deposit transactions don’t have a chainId on L2](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#deposit-transactions-don%E2%80%99t-have-a-chainid-on-l2)
[](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#transactions-stuck-in-the-transaction-pool)
Transactions stuck in the transaction pool
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
OP Chain uses EIP-1559, but with different parameters than L1 Ethereum. As a result, while the base fee on L1 can grow by up to 12.5% in a twelve-second period (in the case of a single 30M gas block), the L2 base fee can grow by up to 77% (in the case of six 30M gas blocks). However, it still shrinks by only up to 12.5% in the same twelve-second period (if all the blocks are empty). If the maximum fee per gas specified by the transaction is less than the block base fee, it does not get included until the base fee drops to below the value in the transaction. When this happens, some users may see their transaction become stuck. No ETH is lost, but the transaction does not clear on its own. We have a workaround that users and wallet operators can implement immediately, and we expect a protocol-level fix to be live by the end of Q4.
###
[](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendation)
Recommendation
Set the maximum fee per gas for transactions to a relatively high value, such as 0.1 gwei. This will _not_ increase the transaction cost because the same base fee, determined by a formula, is charged to all the transactions in the block. To save on the cost of L2 gas you want to minimize the max priority fee. Also, if the [current base fee](https://optimistic.grafana.net/public-dashboards/c84a5a9924fe4e14b270a42a8651ceb8?orgId=1&refresh=5m)
is comparable to 0.1 gwei or higher, you might want to suggest to users a higher multiple of the base fee than you would on L1 Ethereum because it can grow faster in the time interval between transaction creation and transaction signing and submission.
####
[](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendations-for-wallet-developers)
Recommendations for wallet developers
Wallets are usually in charge of determining the default priority fee and max fee that a transaction would include, so the above recommendations can be applied directly.
####
[](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendations-for-app-developers)
Recommendations for app developers
As an app developer, you can usually override the default recommendation of the wallet (see, for example, [ethers](https://github.com/ethers-io/ethers.js/blob/v5.7/packages/contracts/lib/index.d.ts#L10-L11)
). As long as not all wallets are upgraded according to our recommendations, it makes sense for apps to get the current base fee and recommend a value based on that.
####
[](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#recommendations-for-users)
Recommendations for users
As a user, you are the final authority on transaction fields. Sometimes when submitting a transaction, the gas fee is set too low, and it gets stuck in the transaction pool (a.k.a. mempool). If you want to push that transaction through, [you can cancel it by submitting another transaction with the same nonce](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/)
. This method increases the fee and the sequencer will process it from the mempool quicker.
[](https://docs.optimism.io/app-developers/guides/transactions/troubleshooting#deposit-transactions-don%E2%80%99t-have-a-chainid-on-l2)
Deposit transactions don’t have a chainId on L2
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[Deposit transactions](https://specs.optimism.io/protocol/deposits.html?utm_source=op-docs&utm_medium=docs#the-deposited-transaction-type)
are transactions added to the L2 blockchain as part of the block derivation process. These transactions come from a dummy address and don’t have a signature. Because in Ethereum the chainID is encoded as part of the signature, this means there is no recoverable chainID for these transactions. This is not a problem because the only source of deposit transactions is the block derivation process. There shouldn’t be a need to recover the chainID.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/transactions/troubleshooting.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/transactions/troubleshooting)
[Transaction statuses on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/statuses)
[Testnet faucets](https://docs.optimism.io/app-developers/tools/faucets)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/transactions/parameters#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Transactions
Setting transaction gas parameters on OP Mainnet
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Selecting the base fee](https://docs.optimism.io/app-developers/guides/transactions/parameters#selecting-the-base-fee)
* [Selecting the priority fee](https://docs.optimism.io/app-developers/guides/transactions/parameters#selecting-the-priority-fee)
OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306)
which means that it is as compatible with Ethereum as possible, down to the client software used to run OP Mainnet nodes. Like Ethereum, OP Mainnet has an EIP-1559 style fee mechanism that dynamically adjusts a [base fee](https://ethereum.org/en/developers/docs/gas/#base-fee)
that acts as the minimum fee that a transaction must pay to be included in a block. OP Mainnet also allows transactions to pay a [priority fee](https://ethereum.org/en/developers/docs/gas/#priority-fee)
(also known as a tip) to incentivize the Sequencer to include transactions more quickly. Setting the base fee and the priority fee appropriately is important to ensure that your transactions are included in a timely manner. This guide will walk you through some best practices for determining the base fee and priority fee for your transactions.
[](https://docs.optimism.io/app-developers/guides/transactions/parameters#selecting-the-base-fee)
Selecting the base fee
----------------------------------------------------------------------------------------------------------------------------
The base fee is the minimum fee that a transaction must pay to be included in a block. Transactions that specify a maximum fee per gas that is less than the current base fee cannot be included in the blockchain. The simplest way to select a base fee is to look at the latest available OP Mainnet block. Each OP Mainnet block includes the current base fee and the amount of gas used within that block. You can use this information to predict a reasonable maximum fee for your transaction. Note that, like Ethereum, the base fee is not explicitly defined within a transaction. Instead, the maximum base fee is determined as the difference between the `maxFeePerGas` and the `maxPriorityFeePerGas` fields of any given transaction.
1
[](https://docs.optimism.io/app-developers/guides/transactions/parameters#)
Retrieve the latest block
Using the JSON-RPC API or your favorite Ethereum library, retrieve the latest block on OP Mainnet.
2
[](https://docs.optimism.io/app-developers/guides/transactions/parameters#)
Retrieve the base fee and gas used
From the block, retrieve the `baseFeePerGas` and `gasUsed` fields.
3
[](https://docs.optimism.io/app-developers/guides/transactions/parameters#)
Predict the next base fee
OP Mainnet adjusts the base fee based on the amount of gas used in the previous block. If the previous block used more than 5m gas (of the 30m gas limit), then the base fee will increase by up to 10%. If the previous block used less than 5m gas, then the base fee will decrease by up to 10%. Refer to the [OP Mainnet EIP-1559 Parameters](https://docs.optimism.io/op-stack/protocol/differences#eip-1559-parameters)
section for more details.
4
[](https://docs.optimism.io/app-developers/guides/transactions/parameters#)
Select a base fee per gas
Using the current base fee per gas and the amount of gas used in the previous block, you can predict the next base fee per gas. If you are highly sensitive to the base fee, you may want to select a base fee per gas that is either 10% higher or 10% lower than the previous base fee. However, you may run the risk that your transaction will not be included in a block quickly. If you are less sensitive to the base fee, you may wish to simply use a large multiple of the previous base fee (e.g. 2x).
[](https://docs.optimism.io/app-developers/guides/transactions/parameters#selecting-the-priority-fee)
Selecting the priority fee
------------------------------------------------------------------------------------------------------------------------------------
The priority fee is an optional tip that can be paid to the Sequencer to incentivize them to include your transaction more quickly. The priority fee is paid in addition to the base fee. The simplest way to select a priority fee is to use the [`eth_maxPriorityFeePerGas`](https://docs.alchemy.com/reference/eth-maxpriorityfeepergas)
JSON-RPC method to retrieve an estimate for an acceptable priority fee. Many Ethereum libraries will provide a function to call this JSON-RPC method. You can also use the [`eth_feeHistory`](https://docs.alchemy.com/reference/eth-feehistory)
JSON-RPC method to retrieve historical priority fee data. You can then use this data to predict a reasonable priority fee for your transaction. Alternatively, you can rely on Tenderly’s [`tenderly_gasPrice`](https://docs.tenderly.co/node/rpc-reference/optimism-mainnet/tenderly_gasPrice?mtm_campaign=ext-docs&mtm_kwd=optimism)
to get real-time gas predictions with 3 levels of likelihood for transaction inclusion.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/transactions/parameters.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/transactions/parameters)
[Flashblocks and Gas Usage on OP Stack](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage)
[Transaction statuses on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/statuses)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Transactions
Flashblocks and Gas Usage on OP Stack
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Background: Block Gas Limit vs. Transaction Gas Limit](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#background-block-gas-limit-vs-transaction-gas-limit)
* [What Are Flashblocks?](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#what-are-flashblocks)
* [Example](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#example)
* [Why a Transaction Can Get Stuck](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#why-a-transaction-can-get-stuck)
* [Real-World Example](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#real-world-example)
* [Client Behavior and Error Messages](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#client-behavior-and-error-messages)
* [Practical Guidance for Application Developers and End Users](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#practical-guidance-for-application-developers-and-end-users)
* [Leave Headroom for Large Transactions](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#leave-headroom-for-large-transactions)
* [Expect Variable Gas Availability During Congestion](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#expect-variable-gas-availability-during-congestion)
* [Transaction Resubmission](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#transaction-resubmission)
* [Key Takeaways](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#key-takeaways)
This document explains how **Flashblocks** affect block gas usage, transaction inclusion, large-transaction handling, and how to avoid unexpected transaction rejections. If you are unfamiliar with Flashblocks you can read more [here](https://docs.optimism.io/op-stack/features/flashblocks#flashblocks)
.
* * *
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#background-block-gas-limit-vs-transaction-gas-limit)
Background: Block Gas Limit vs. Transaction Gas Limit
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
On OP Mainnet, the **theoretical block gas limit** is currently **40M gas**. In a traditional EVM mental model, a single transaction can use up to the full block gas limit, as long as it does not exceed it. With **Flashblocks**, block construction is incremental and _effective transaction inclusion depends on the gas already consumed within the block_, not just the theoretical maximum.
* * *
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#what-are-flashblocks)
What Are Flashblocks?
----------------------------------------------------------------------------------------------------------------------------------------
Flashblocks are an incremental block-building mechanism used by the sequencer and block builder. Instead of constructing the full block at once, the block is built in **N flashblocks** (currently 8):
* Each flashblock increases the _cumulative gas budget_ available for inclusion
* Earlier flashblocks can only include smaller transactions
* Larger transactions can only be included later, _if enough gas remains_
###
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#example)
Example
Assume:
* Block gas limit **B = 40M**
* Number of flashblocks **N = 8**
Then the cumulative gas limit increases as follows:
| Flashblock | Max cumulative gas available |
| --- | --- |
| 1 | 5M |
| 2 | 10M |
| 3 | 15M |
| 4 | 20M |
| 5 | 25M |
| 6 | 30M |
| 7 | 35M |
| 8 | 40M |
A transaction with a **20M gas limit** can only be included starting from flashblock 4, _and only if prior flashblocks have not already consumed that gas_.
* * *
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#why-a-transaction-can-get-stuck)
Why a Transaction Can Get Stuck
-------------------------------------------------------------------------------------------------------------------------------------------------------------
A transaction may be submitted with a gas limit lower than the total block gas limit (e.g. **38M < 40M**) and still remain pending or, depending on the EL implementation, be rejected with the error: `exceeds block gas limit`. This happens because transaction acceptance and transaction inclusion are decided by different components. Genrally:
* Incoming transactions first enter the Execution Layer txpool.
* The EL checks whether `tx.gasLimit` exceeds the **full block gas limit**.
* If it does, it rejects with `exceeds block gas limit`.
* Otherwise, it keeps the transaction in the **pending/queued mempool** and **P2P-gossips** it eventually reaching **rbuilder**.
* **rbuilder** applies the incremental **remaining block gas** check to decide whether to include the tx in a flashblock or leave it pending.
###
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#real-world-example)
Real-World Example
* Block gas limit: **40M**
* Gas already used in earlier flashblocks: **13M**
* Remaining gas: **27M**
* Incoming transaction gas limit: **38M**
The **EL** checks if the transaction exceeds **40M**. Since **38M < 40M**, the transaction is accepted into the pending/queued mempool and gossiped to **rbuilder**. **rbuilder** applies the incremental remaining-gas constraint. With only **27M** gas remaining and the tx requiring **38M**, the transaction cannot be included yet and stays pending. **Result:** the transaction is not rejected, but remains pending in the mempool until there is enough remaining gas to include it in a flashblock.
* * *
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#client-behavior-and-error-messages)
Client Behavior and Error Messages
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
There are two distinct outcomes depending on the transaction size:
* **Rejected immediately (txpool admission failure):**
The EL (e.g. **op-geth**, **op-reth**) rejects transactions only when the transaction gas limit exceeds the **full block gas limit**:
* Condition: `tx.gasLimit > blockGasLimit`
* Error returned to the user: `exceeds block gas limit`
* **Accepted but pending inclusion:**
If the transaction gas limit is **within** the block gas limit, but still too large to fit into the **remaining block gas** at that point in rbuilder, it will not be included yet.
* The transaction remains in the **pending/queued mempool** or rbuilder, waiting for enough remaining gas to become available in a later flashblock.
* From the user’s perspective, the transaction may appear **pending** until it gets enough gas available for inclusion.
In practice, transactions are sent to Execution Layer RPC nodes (e.g. via proxyd), checked, and only if accepted into the EL txpool are eventually propagated to the sequencer/rbuilder for potential inclusion. Implementing mechanisms such as txpool rebroadcasting can mitigate this divergence automatically, so users do not notice retries. However, when an error is surfaced, it may originate from the ingress client’s gas checks.
* * *
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#practical-guidance-for-application-developers-and-end-users)
Practical Guidance for Application Developers and End Users
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#leave-headroom-for-large-transactions)
Leave Headroom for Large Transactions
If you submit large transactions, avoid targeting the full block gas limit. **Recommended approach:**
* Leave **20–30% headroom** relative to the block gas limit
* For a 40M block, aim for ≤ **28–32M gas**
Or:
* Proactively cap single-transaction gas usage to ~16.7M gas to align with the upcoming L2 Fusaka transaction limit
This increases the chance that the transaction fits within Execution Layer gas checks under partial block utilization. More generally, designing applications to avoid extremely large single transactions is good long-term practice since, with upcoming protocol changes (Fusaka on L2), transactions will be capped at 16.7M gas anyway.
* * *
###
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#expect-variable-gas-availability-during-congestion)
Expect Variable Gas Availability During Congestion
Under high demand:
* Early flashblocks are often full
* Remaining gas later in the block may be limited
* Very large transactions may be rejected or require retries
This is expected behavior with Flashblocks and not necessarily an issue with the transaction itself.
* * *
###
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#transaction-resubmission)
Transaction Resubmission
Because block state evolves quickly:
* Retrying submission in a later block may succeed
* Large transactions are more likely to be included when earlier flashblocks are less congested
* * *
[](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage#key-takeaways)
Key Takeaways
-------------------------------------------------------------------------------------------------------------------------
* Flashblocks build blocks incrementally, unlocking gas capacity over time rather than all at once
_(e.g. in a 40M gas block with 8 flashblocks, only 5M is available at the first flashblock, then 10M, and so on)_
* A transaction must be **within the full block gas limit** to be accepted into the EL txpool, but it must fit within the **remaining block gas** to be included by rbuilder in the next flashblock _(e.g. if 13M gas out of 40M has already been used, a 38M gas transaction can be accepted by EL but cannot be included until enough remaining gas is available once it reaches rbuilder)_
* As a result, large transactions may be **accepted but remain pending** even when their gas limit is below the nominal block limit
_(e.g. a 38M gas transaction can be accepted in a 40M gas block but delayed during periods of high activity)_
* Leaving meaningful headroom is the most reliable way to improve inclusion success for large transactions
_(e.g. targeting 28–32M gas instead of the full 40M or proactively implementing the Fusaka limit of 16.7M gas)_
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/transactions/flashblocks-and-gas-usage.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/transactions/flashblocks-and-gas-usage)
[Estimating transaction fees on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/estimates)
[Setting transaction gas parameters on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/parameters)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/transactions/estimates#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Transactions
Estimating transaction fees on OP Mainnet
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Execution gas fee](https://docs.optimism.io/app-developers/guides/transactions/estimates#execution-gas-fee)
* [L1 data fee](https://docs.optimism.io/app-developers/guides/transactions/estimates#l1-data-fee)
* [Tooling](https://docs.optimism.io/app-developers/guides/transactions/estimates#tooling)
* [Future proofing](https://docs.optimism.io/app-developers/guides/transactions/estimates#future-proofing)
Check out the guide on understanding [Transaction Fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees)
for an in-depth explanation of how OP Mainnet transaction fees work.
It’s important to properly estimate the cost of a transaction on OP Mainnet before submitting it to the network. Here you’ll learn how to estimate both of the components that make up the total cost of an OP Mainnet transaction, the [execution gas fee](https://docs.optimism.io/op-stack/transactions/fees#execution-gas-fee)
and the [L1 data fee](https://docs.optimism.io/op-stack/transactions/fees#l1-data-fee)
. Make sure to read the guide on [Transaction Fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees)
for a detailed look at how these fees work under the hood.
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#execution-gas-fee)
Execution gas fee
-----------------------------------------------------------------------------------------------------------------
Estimating the execution gas fee on OP Mainnet is just like estimating the execution gas fee on Ethereum. Steps are provided here for reference and convenience, but you can use the same tooling that you’d use to estimate the execution gas fee for a transaction on Ethereum.
A transaction’s execution gas fee is exactly the same fee that you would pay for the same transaction on Ethereum. This fee is equal to the amount of gas used by the transaction multiplied by the gas price attached to the transaction. Refer to the guide on [Transaction Fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees#execution-gas-fee)
for more information about the execution gas fee. When estimating the execution gas fee for a transaction, you’ll need to know the gas limit and the [max fee per gas](https://ethereum.org/en/developers/docs/gas/#maxfee)
for the transaction. Your transaction fee will then be the product of these two values. Refer to the guide on [Setting Transaction Gas Parameters on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/parameters)
to learn how to select an appropriate gas limit and max fee per gas for your transaction.
1
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#)
Estimate the gas limit
Using the same tooling that you’d use to estimate the gas limit for a transaction on Ethereum, estimate the gas limit for your transaction on OP Mainnet. OP Mainnet is designed to be [EVM equivalent](https://web.archive.org/web/20231127160757/https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306)
so transactions will use the same amount of gas on OP Mainnet as they would on Ethereum. This means you can feed your transaction to the [`eth_estimateGas`](https://ethereum.org/en/developers/docs/apis/json-rpc/#eth_estimategas)
JSON-RPC method just like you would on Ethereum. Alternatively, use Tenderly’s [`tenderly_estimateGas`](https://docs.tenderly.co/node/rpc-reference/optimism-mainnet/tenderly_estimateGas)
for 100% accurate gas estimations.
2
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#)
Estimate the max fee per gas
Like Ethereum, OP Mainnet uses an `EIP-1559` style fee market to determine the current base fee per gas. You can then additionally specify a priority fee (also known as a tip) to incentivize the Sequencer to include your transaction more quickly. Make sure to check out the guide on [Setting Transaction Gas Parameters on OP Mainnet](https://docs.optimism.io/app-developers/guides/transactions/parameters)
to learn more about how to select an appropriate max fee per gas for your transaction.
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#l1-data-fee)
L1 data fee
-----------------------------------------------------------------------------------------------------
The Viem library provides a convenient method for estimating the L1 data fee for a transaction. Check out the tutorial on [Estimating Transaction Costs on OP Mainnet](https://docs.optimism.io/app-developers/tutorials/transactions/sdk-estimate-costs)
to learn how to use the Viem library to estimate the L1 data fee for your transaction. Keep reading if you’d like to learn how to estimate the L1 data fee without the Viem library.
The L1 data fee is a fee paid to the Sequencer for the cost of publishing your transaction to Ethereum. This fee is paid in ETH and is calculated based on the size of your transaction in bytes and the current gas price on Ethereum. Refer to the guide on [Transaction Fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees#l1-data-fee)
for more information about the L1 data fee. Unlike the execution gas fee, the L1 data fee is an **intrinsic** fee for every transaction. This fee is automatically charged based on the size of your transaction and the current Ethereum gas price. You currently cannot specify a custom L1 data fee for your transaction.
The L1 data fee is paid based on the current Ethereum gas price as tracked within the [`GasPriceOracle`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol)
smart contract. This gas price is updated automatically by the OP Mainnet protocol. Your transaction will be charged the Ethereum gas price seen by the protocol at the time that your transaction is included in an OP Mainnet block. This means that the L1 data fee for your transaction may differ from your estimated L1 data fee.
1
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#)
Serialize your transaction
The L1 data fee is calculated based on the size of your serialized transaction in bytes. Most Ethereum tooling will provide a method for serializing a transaction. For instance, Ethers.js provides the [`ethers.utils.serializeTransaction`](https://docs.ethers.org/v5/api/utils/transactions/#utils-serializeTransaction)
method.
2
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#)
Estimate the L1 data fee
Once you have serialized your transaction, you can estimate the L1 data fee by calling the [`getL1Fee`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol#L109-L124)
method on the [`GasPriceOracle`](https://github.com/ethereum-optimism/optimism/blob/233ede59d16cb01bdd8e7ff662a153a4c3178bdd/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol)
smart contract available on OP Mainnet and all OP Stack chains. This method takes the serialized transaction as input and returns the L1 data fee in wei using the formula described in the [Transaction Fees on OP Mainnet](https://docs.optimism.io/op-stack/transactions/fees#l1-data-fee)
guide.
Fee estimation is typically performed before the transaction is signed. As a result, the `getL1Fee` method assumes that your input is an **unsigned** Ethereum transaction.
###
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#tooling)
Tooling
Several tools are available to help you estimate the L1 Data Fee for your transaction. Selecting the right tool for your use case will depend on your specific needs.
* [Viem](https://viem.sh/op-stack#getting-started-with-op-stack)
provides first-class support for OP Stack chains, including OP Mainnet. You can use Viem to estimate gas costs and send cross-chain transactions (like transactions through the Standard Bridge system). It’s strongly recommended to use Viem if you are able to do so as it will provide the best native support at the moment.
###
[](https://docs.optimism.io/app-developers/guides/transactions/estimates#future-proofing)
Future proofing
The L1 Data Fee formula is subject to change in the future, especially as the data availability landscape evolves. As a result, it’s important to future-proof your transaction fee estimation code to ensure that it will continue to function properly as the L1 Data Fee formula changes.
* Use existing [tooling](https://docs.optimism.io/app-developers/guides/transactions/estimates#tooling)
to estimate the L1 Data Fee for your transaction if possible. This tooling will be updated to reflect any changes to the L1 Data Fee formula. This way you won’t need to modify your code to account for any changes to the formula.
* Use the `getL1Fee` method on the `GasPriceOracle` if you are unable to use existing tooling. The `getL1Fee` method will be updated to reflect any changes to the L1 Data Fee formula. It’s strongly recommended that you do **not** implement the L1 Data Fee formula yourself.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/transactions/estimates.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/transactions/estimates)
[Estimate costs](https://docs.optimism.io/app-developers/guides/interoperability/estimate-costs)
[Flashblocks and Gas Usage on OP Stack](https://docs.optimism.io/app-developers/guides/transactions/flashblocks-and-gas-usage)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Bridging
Using the Standard Bridge
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Design](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#design)
* [Architecture](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#architecture)
* [Bridged tokens](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridged-tokens)
* [Bridging native tokens](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridging-native-tokens)
* [Bridging non-native tokens](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridging-non-native-tokens)
* [Bridging ETH](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridging-eth)
* [Tutorials](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#tutorials)
* [Superchain Token List](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#superchain-token-list)
* [Searching the Token List](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#searching-the-token-list)
The Standard Bridge is a basic token bridging system available on OP Mainnet and all other standard OP Stack chains. The Standard Bridge allows you to easily move ETH and most ERC-20 tokens between Ethereum and OP Mainnet. Transfers from Ethereum to OP Mainnet via the Standard Bridge are usually completed within 1-3 minutes. Transfers from OP Mainnet to Ethereum are completed in 7 days as a result of the [withdrawal challenge period](https://docs.optimism.io/app-developers/guides/bridging/messaging#understanding-the-challenge-period)
. The Standard Bridge is fully permissionless and supports standard ERC-20 tokens. Other bridging systems also exist that provide different features and security properties. You may wish to explore some of these options to find the bridge that works best for you and your application.
The Standard Bridge **does not** support [**fee on transfer tokens**](https://github.com/d-xo/weird-erc20#fee-on-transfer)
or [**rebasing tokens**](https://github.com/d-xo/weird-erc20#balance-modifications-outside-of-transfers-rebasingairdrops)
because these types of tokens may cause bridge accounting errors.
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#design)
Design
---------------------------------------------------------------------------------------------
The Standard Bridge allows users to convert tokens that are native to one chain (like Ethereum) into a representation of those tokens on the other chain (like OP Mainnet). Users can then convert these bridged representations back into their original native tokens at any time. This bridging mechanism functions identically in both directions — tokens native to OP Mainnet can be bridged to Ethereum, just like tokens native to Ethereum can be bridged to OP Mainnet. Here you’ll get to understand how the Standard Bridge works when moving tokens from Ethereum to OP Mainnet. Since the bridging mechanism is mirrored on both sides, this will also explain how the bridge works in the opposite direction.
###
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#architecture)
Architecture
The Standard Bridge is composed of two contracts, the [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L1/L1StandardBridge.sol)
(on `Ethereum`) and the [`L2StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/65ec61dde94ffa93342728d324fecf474d228e1f/packages/contracts-bedrock/contracts/L2/L2StandardBridge.sol)
(on `OP Mainnet`). These two contracts interact with one another via the `CrossDomainMessenger` system for sending messages between Ethereum and OP Mainnet. You can read more about the `CrossDomainMessenger` in the guide on [Sending Data Between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging)
.
###
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridged-tokens)
Bridged tokens
The Standard Bridge utilizes bridged representations of tokens that are native to another blockchain. Before a token native to one chain can be bridged to the other chain, a bridged representation of that token must be created on the receiving side. A bridged representation of a token is an ERC-20 token that implements the [`IOptimismMintableERC20`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/IOptimismMintableERC20.sol#L6-L18)
interface. This interface includes a few functions that the `StandardBridge` contracts use to manage the bridging process. All bridged versions of tokens **must** implement this interface to be used with the `StandardBridge`. Native tokens do not need to implement this interface. A native token may have more than one bridged representation at the same time. Users must always specify which bridged token they wish to use when using the bridge. Different bridged representations of the same native token are considered entirely independent tokens.
###
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridging-native-tokens)
Bridging native tokens
The Standard Bridge uses a “lock-and-mint” mechanism to convert native tokens into their bridged representations. This means that **native tokens are locked** into the Standard Bridge on one side, after which **bridged tokens are minted** on the other side. The process for bridging a native token involves a few steps.
1
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
User gives the Standard Bridge an allowance
The Standard Bridge must be able to pull tokens from the user to lock them into the bridge contract. To do this, the user must first give the bridge an [allowance](https://eips.ethereum.org/EIPS/eip-20#approve)
to transfer the number of tokens that the user wishes to convert into a bridged representation.
2
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
User calls the bridging function
After providing a sufficient allowance, the user calls the [`bridgeERC20To`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L193-L217)
function on the `StandardBridge` contract on the chain where the native token lives (e.g., the `L1StandardBridge` contract if the token is native to Ethereum).The user must provide the following parameters to this function call:
* `address _localToken`: Address of the native token on the sending side.
* `address _remoteToken`: Address of the bridged representation on the receiving side.
* `address _to`: Address of the recipient of these tokens, usually the sender’s address.
* `uint256 _amount`: Number of tokens to transfer.
* `uint32 _minGasLimit`: Gas to use to complete the transfer on the receiving side.
* `bytes calldata _extraData`: Optional identity extra data.
Users can also trigger the [`bridgeERC20`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L168-L191)
function instead of `bridgeERC20To` to avoid needing to specify the `address _to` parameter. Doing so will automatically set the `address _to` parameter to the `msg.sender`.**The `bridgeERC20` function can be potentially dangerous for users with [smart contract wallets](https://web.archive.org/web/20231012141406/https://blockworks.co/news/what-are-smart-contract-wallets)
as some smart contract wallets cannot be deployed at the same address on every blockchain.** To help users avoid potentially losing access to tokens by accident, the `bridgeERC20` function will always revert when triggered from a smart contract. Smart contract wallet users and other smart contracts should therefore use the `bridgeERC20To` function instead.
3
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The Standard Bridge locks the transferred tokens
When the user triggers the `bridgeERC20To` function while transferring a native token, the Standard Bridge will pull the `_amount` of `_localToken` tokens from the user’s address and lock them inside of the bridge contract. A record of all locked tokens is stored within a [`deposits` mapping](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L41-L42)
that keeps track of the total number of tokens deposited for a given `_localToken` and `_remoteToken` pair.Since a native token may have more than one bridged representation, the `deposits` token must keep track of the deposit pools for each `_localToken`/`_remoteToken` pair independently.To illustrate, suppose that two users deposit 100 units of the same native token, `Token A`, but wish to receive two different bridged tokens, `Token B` and `Token C`. Although the Standard Bridge would now have a total balance of 200 units of `Token A`, the mapping would show that the `Token A`/`Token B` pool and the `Token A`/`Token C` pool both have only 100 units.
4
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The Standard Bridge sends a minting message
After locking the native tokens, the Standard Bridge contract on the sending side will trigger a cross-chain message to the Standard Bridge contract on the receiving side via the [`CrossDomainMessenger`](https://docs.optimism.io/app-developers/guides/bridging/messaging)
system. This message tells the receiving side to **mint** tokens according to the parameters specified by the user. Specifically, this message is an encoded call to the [`finalizeBridgeERC20`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L250-L287)
function on the other Standard Bridge contract. At this point, execution ends on the sending side.
5
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The minting message is executed
Once the minting message is sent, it must be relayed to the receiving side. Message relaying is automatic when sending from Ethereum to OP Mainnet but requires additional user transactions when sending from OP Mainnet to Ethereum. Read more about the message relaying process in the guide to [Sending Data Between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging#communication-speed)
.When the message is relayed, the `finalizeBridgeERC20` function will be triggered on the receiving Standard Bridge contract. This function will receive the `_minGasLimit` gas defined by the user to execute to completion.
6
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The minting message is authenticated
Upon execution, `finalizeBridgeERC20` verifies a number of things about the incoming request:
* [The request must have originated from the Standard Bridge contract on the other blockchain](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L269)
.
* [The Standard Bridge must not be in an emergency paused state](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L271)
.
* [The bridged token must properly implement the `IOptimismMintableERC20` interface](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L272)
.
* [The bridged token must recognize the original native token as its `remoteToken()`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L273-L276)
.
7
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The bridged token is minted
If the minting message is fully verified, `finalizeBridgeERC20` will [mint tokens to the recipient](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L278)
equal to the number of tokens originally deposited on the other blockchain. For this to work properly, the bridged representation of the native token must correctly implement a `mint` function that allows the Standard Bridge to mint tokens arbitrarily. This is part of the [`IOptimismMintableERC20`](https://github.com/ethereum-optimism/optimism/blob/8ed8be8806208976e63421bd68779477d12295b5/packages/contracts-bedrock/src/universal/IOptimismMintableERC20.sol)
interface.This completes the process of bridging native tokens. This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions.
###
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridging-non-native-tokens)
Bridging non-native tokens
The Standard Bridge uses a “burn-and-unlock” mechanism to convert bridged representations of tokens back into their native tokens. This means that **bridged tokens are burned** on the Standard Bridge on one side, after which **native tokens are unlocked** on the other side. The process for bridging a non-native, bridged representation of a token involves a few steps.
1
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
User calls the bridging function
Unlike when bridging native tokens, users do not need to provide an approval to trigger a transfer of a bridged token because the Standard Bridge should already have the ability to `burn` these tokens. Here, the user calls the [`bridgeERC20To`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L193-L217)
function on the `StandardBridge` contract on the chain where the bridged token lives (e.g., the `L2StandardBridge` contract if the token is bridged to OP Mainnet).The user must provide the following parameters to this function call:
* `address _localToken`: Address of the bridged token on the sending side.
* `address _remoteToken`: Address of the native token on the receiving side.
* `address _to`: Address of the recipient of these tokens, usually the sender’s address.
* `uint256 _amount`: Number of tokens to transfer.
* `uint32 _minGasLimit`: Gas to use to complete the transfer on the receiving side.
* `bytes calldata _extraData`: Optional identity extra data.
2
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The Standard Bridge burns the transferred tokens
When the user triggers the `bridgeERC20To` function while transferring a bridge token, [the Standard Bridge will burn the corresponding `_amount` of tokens from the sender’s address](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L345)
.
3
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The Standard Bridge sends an unlock message
After burning the bridged tokens, the Standard Bridge contract on the sending side will trigger a cross-chain message to the Standard Bridge contract on the receiving side via the [`CrossDomainMessenger`](https://docs.optimism.io/app-developers/guides/bridging/messaging)
system. This message tells the receiving side to **unlock** tokens according to the parameters specified by the user. Specifically, this message is an encoded call to the [`finalizeBridgeERC20`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L250-L287)
function on the other Standard Bridge contract. At this point, execution ends on the sending side.
4
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The unlock message is executed
Once the unlock message is sent, it must be relayed to the receiving side. Message relaying is automatic when sending from Ethereum to OP Mainnet but requires additional user transactions when sending from OP Mainnet to Ethereum. Read more about the message relaying process in the guide to [Sending Data Between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging#communication-speed)
.When the message is relayed, the `finalizeBridgeERC20` function will be triggered on the receiving Standard Bridge contract. This function will receive the `_minGasLimit` gas defined by the user to execute to completion.
5
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The unlock message is authenticated
Upon execution, `finalizeBridgeERC20` verifies a number of things about the incoming request:
* [The request must have originated from the Standard Bridge contract on the other blockchain](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L269)
.
* [The Standard Bridge must not be in an emergency paused state](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L271)
.
6
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
The native token is unlocked
If the unlock message is fully verified, `finalizeBridgeERC20` will [unlock and transfer tokens to the recipient](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L280-L281)
equal to the number of tokens originally burned on the other blockchain.This completes the process of bridging native tokens. This process is identical in both the Ethereum to OP Mainnet and OP Mainnet to Ethereum directions.
###
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#bridging-eth)
Bridging ETH
The Standard Bridge contracts can also be used to bridge ETH from Ethereum to OP Mainnet and vice versa. The ETH bridging process is generally less complex than the ERC-20 bridging process. Users simply need to trigger and send ETH to the [`bridgeETH`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L143-L150)
or [`bridgeETHTo`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L152-L166)
functions on either blockchain.
Users can also deposit ETH from Ethereum to OP Mainnet by sending a basic ETH transfer from an EOA to the `L1StandardBridgeProxy`. This works because the `L1StandardBridgeProxy` contains a [`receive`](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L119-L121)
function. You can find the mainnet and testnet addresses on the [Contract Addresses](https://docs.optimism.io/op-mainnet/network-information/op-addresses)
page.
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#tutorials)
Tutorials
---------------------------------------------------------------------------------------------------
* [Learn how to bridge ERC-20 tokens with viem](https://docs.optimism.io/app-developers/tutorials/bridging/cross-dom-bridge-erc20)
* [Learn how to bridge ETH with viem](https://docs.optimism.io/app-developers/tutorials/bridging/cross-dom-bridge-eth)
* [Learn how to create a standard bridged token](https://docs.optimism.io/app-developers/tutorials/bridging/standard-bridge-standard-token)
* [Learn how to create a custom bridged token](https://docs.optimism.io/app-developers/tutorials/bridging/standard-bridge-custom-token)
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#superchain-token-list)
Superchain Token List
---------------------------------------------------------------------------------------------------------------------------
The [Superchain Token List](https://docs.optimism.io/app-developers/reference/tokens/tokenlist)
exists to help users discover the right bridged token addresses for any given native token. Consider checking this list to make sure that you’re not using the wrong bridged representation of a token when bridging a native token. Developers who are creating their own bridged tokens should consider [adding their token](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list)
to the Superchain Token List. Tokens on the Superchain Token List will automatically appear on certain tools like the [Superchain Bridges UI](https://app.optimism.io/bridge?utm_source=op-docs&utm_medium=docs)
.
###
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#searching-the-token-list)
Searching the Token List
You should strongly consider using the Superchain Token List to verify that you’re using the correct bridged representation of a token when bridging a native token. Doing so can help you avoid accidentally bridging to the wrong token and locking up your native token permanently. You can easily find the bridged representation of a token for OP Mainnet on the [Bridged Token Addresses](https://docs.optimism.io/superchain/tokenlist#op-mainnet)
page. If you want to find the bridged representation of a token for another chain, use the following steps.
1
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
Find the token you want to bridge
The Superchain Token List is organized by the token’s address and native blockchain. [Search the token list](https://github.com/ethereum-optimism/ethereum-optimism.github.io/blob/master/optimism.tokenlist.json)
for the token you want to bridge to confirm that it’s included in the list. Make sure that the chain ID in the entry matches the chain ID of the blockchain you’re bridging from. Retrieve the token’s name and symbol from the list.
2
[](https://docs.optimism.io/app-developers/guides/bridging/standard-bridge#)
Find the bridged representation of the token
Once you’ve found the token you want to bridge, look for the token’s name and symbol in the list. Find the entry that matches the name and symbol of the token you want to bridge and where the chain ID matches the chain ID of the blockchain you’re bridging to. The address of this entry is the address of the bridged representation of the token you want to bridge.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/bridging/standard-bridge.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/bridging/standard-bridge)
[Sending data between L1 and L2](https://docs.optimism.io/app-developers/guides/bridging/messaging)
[Build interoperable apps on Superchain devnet](https://docs.optimism.io/app-developers/guides/interoperability/get-started)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Actions SDK
Integrating wallets
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Which wallets are right for my use case?](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#which-wallets-are-right-for-my-use-case)
* [Embedded Wallet Providers](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#embedded-wallet-providers)
* [Gas Sponsorship](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#gas-sponsorship)
* [Connect your wallet to Actions](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#connect-your-wallet-to-actions)
* [Smart wallets & signers](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#smart-wallets-%26-signers)
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#which-wallets-are-right-for-my-use-case)
Which wallets are right for my use case?
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
In order to let your users access DeFi, they will need an EVM\-compatible wallet. There are plenty of considerations when selecting a wallet schema that works for you:
* Who will maintain custody of funds?
* What permissions must exist for my use case?
* Where in my stack should transaction signatures originate?
* How can my users on and off ramp funds?
Actions SDK supports popular [embedded wallet providers](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#embedded-wallet-providers)
to address all of these questions while remaining flexible to your use case.
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#embedded-wallet-providers)
Embedded Wallet Providers
-----------------------------------------------------------------------------------------------------------------------------------------
Embedded wallet providers give your users the ability to sign onchain transactions through your app’s existing email authentication and authorization flows. Actions works with:
[\
\
Privy\
-----](https://www.privy.io/)
[\
\
Turnkey\
-------](https://www.turnkey.com/)
[\
\
Dynamic\
-------](https://www.dynamic.xyz/)
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#gas-sponsorship)
Gas Sponsorship
---------------------------------------------------------------------------------------------------------------------
Signing and sending onchain transactions requires gas, or fee payment, which adds [additional overhead](https://docs.optimism.io/app-developers/guides/transactions/estimates)
for you and friction for users. Actions supports gas sponsorship via a combination of smart contract wallets and [paymasters](https://eips.ethereum.org/EIPS/eip-7677)
. First, configure a paymaster in the chain config by specifying a bundler url. Now, any transactions submitted via an actions SmartWallet on that chain will automatically use your paymaster, therefore eliminating the need for the wallet to pay gas.
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#connect-your-wallet-to-actions)
Connect your wallet to Actions
---------------------------------------------------------------------------------------------------------------------------------------------------
Regardless of where and how transactions are signed, Actions has you covered.
1
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#)
Choose a wallet provider
Follow embedded wallet provider documentation and installation steps. Actions works with Typescript clients, both frontend React and backend Node.
2
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#)
Import Actions SDK
Import [Actions SDK](https://actions.money/)
alongside your chosen wallet provider SDK.
3
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#)
Create and fetch embedded user wallets
Follow embedded wallet provider documentation for wallet creation and access.
4
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#)
Pass the wallet to Actions
Call `actions.wallet.toActionsWallet(...)`, and [pass in](https://docs.optimism.io/app-developers/quickstarts/actions#choose-a-wallet-provider)
the provider wallet.
5
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#)
Take Action
The returned [Wallet](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#wallet-instance)
is now capable of calling Actions [functions](https://docs.optimism.io/app-developers/quickstarts/actions#take-action)
like Lend, Borrow, Swap and Pay!
[](https://docs.optimism.io/app-developers/reference/actions/integrating-wallets#smart-wallets-&-signers)
Smart wallets & signers
-------------------------------------------------------------------------------------------------------------------------------------
In addition to using embedded provider wallets directly, Actions [supports the creation](https://docs.optimism.io/app-developers/quickstarts/actions#choose-a-wallet-provider)
of custom smart contract wallets. This additional wallet type is separate from, but still controlled by the owner of the embedded wallet. If you [configure it](https://docs.optimism.io/app-developers/guides/configuring-actions)
, Actions will deploy a [EIP-4337](https://eips.ethereum.org/EIPS/eip-4337)
compliant [Coinbase Smart Wallets](https://github.com/coinbase/smart-wallet)
on the chains you’ve chosen to support. Once created, an embedded wallet can be added as a signer on the smart wallet, capable of signing transactions on behalf of the Smart Wallet. See [Wallet Documentation](https://docs.optimism.io/app-developers/reference/actions/wallet-definitions)
for additional details.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/reference/actions/integrating-wallets.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/reference/actions/integrating-wallets)
[Superchain RPC directory](https://docs.optimism.io/app-developers/reference/rpc-providers)
[Wallet Documentation](https://docs.optimism.io/app-developers/reference/actions/wallet-definitions)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Interoperability
Reading Logs with Superchain Interop
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Overview](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#overview)
* [Why use CrossL2Inbox?](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#why-use-crossl2inbox)
* [How it works](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#how-it-works)
* [Architecture](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#architecture)
* [Key components](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#key-components)
* [Example: cross-chain attestation verification](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#example-cross-chain-attestation-verification)
* [Source chain: creating an attestation](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#source-chain-creating-an-attestation)
* [Destination chain: verifying the attestation](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#destination-chain-verifying-the-attestation)
* [Overview of the process](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#overview-of-the-process)
* [Important considerations](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#important-considerations)
* [Handling validation failures](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#handling-validation-failures)
* [Comparison with L2ToL2CrossDomainMessenger](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#comparison-with-l2tol2crossdomainmessenger)
* [End-to-End flow comparison](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#end-to-end-flow-comparison)
* [L2ToL2CrossDomainMessenger (Push Model):](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#l2tol2crossdomainmessenger-push-model-)
* [CrossL2Inbox (Pull Model):](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#crossl2inbox-pull-model-)
* [Next steps](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#next-steps)
Superchain interop is in active development. Some features may be experimental.
Superchain interop enables developers to leverage current and historical logs from other blockchains within the [Superchain interop cluster](https://docs.optimism.io/interop/explainer#superchain-interop-cluster)
directly on their local chain. This allows smart contracts to consume local and cross-chain logs with low latency in a trust-minimized way.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#overview)
Overview
------------------------------------------------------------------------------------------------------
Instead of relying solely on [`L2ToL2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/L2ToL2CrossDomainMessenger.sol)
, developers can use [`CrossL2Inbox#validateMessage`](https://github.com/ethereum-optimism/optimism/blob/af091753917c1d7101314cbfe8ac5cbc2efe0e5e/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L49)
and treat `CrossL2Inbox` as an oracle for logs that occurred on different chains or even their local chain. This enables developers to:
* Build cross-chain applications that react to events happening across the Superchain.
* Create novel applications that leverage data from multiple chains.
When reading logs, you must reference logs created within the [expiry window of 7 days](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration)
.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#why-use-crossl2inbox)
Why use `CrossL2Inbox`?
---------------------------------------------------------------------------------------------------------------------------------
* **Reference existing logs**: Allows contracts to verify and use logs that were already emitted, without requiring those logs to have been sent as cross-chain messages.
* **Trust-minimized security**: Leverages the existing Superchain security model with no additional trust assumptions.
* **Flexibility**: Can be used to validate events from another chain or even the local chain.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#how-it-works)
How it works
--------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#architecture)
Architecture
The process works through the [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/af091753917c1d7101314cbfe8ac5cbc2efe0e5e/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L33)
contract, which serves as an oracle for logs from other chains in the Superchain:
1. A smart contract on `Chain A` emits a log (event)
2. Your contract on `Chain B` calls `CrossL2Inbox#validateMessage` with the log’s identifier
3. The `CrossL2Inbox` contract verifies the log’s authenticity
4. Your contract can then use the validated log data
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#key-components)
Key components
* **Identifier**: A struct containing information about the log, including `chainId`, `origin` (contract address), and other log metadata
* **[validateMessage](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L79)
**: Function that verifies a log’s authenticity before allowing its use
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#example-cross-chain-attestation-verification)
Example: cross-chain attestation verification
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Let’s walk through a conceptual example of verifying an Ethereum Attestation Service (EAS) attestation across chains. EAS is a \[predeploy\](/> app-developers/reference/contracts/interop/predeploy) in the OP Stack for making attestations on or off-chain about anything.
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#source-chain-creating-an-attestation)
Source chain: creating an attestation
On the source chain (e.g., OP Mainnet), a user creates an attestation using EAS:
1. The user initiates a request for an attestation through an application.
2. The application calls the `createAttestation()` function on the EAS (Ethereum Attestation Service) contract on the source chain.
3. The EAS contract processes the attestation request and emits an `AttestationCreated` event.
4. The event is recorded in the chain’s log, containing all necessary attestation data.
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#destination-chain-verifying-the-attestation)
Destination chain: verifying the attestation
On the destination chain (e.g., Unichain), a DeFi application wants to verify this attestation:
1. The user requests access to a DeFi application on the destination chain, referencing an attestation created on the source chain.
2. The DeFi application calls a verification function on an attestation verifier contract, passing the attestation’s identifier and event data.
3. The attestation verifier calls `validateMessage()` on the `CrossL2Inbox` contract, passing the attestation identifier and a hash of the event data.
4. The [`CrossL2Inbox`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol)
contract interacts with the [`OP-Supervisor`](https://docs.optimism.io/chain-operators/reference/components/op-supervisor)
service to check if the specified log exists on the source chain.
5. The `OP-Supervisor` confirms the validity of the log to the `CrossL2Inbox` contract.
6. The `CrossL2Inbox` returns the validation result to the attestation verifier.
7. The attestation verifier returns the verification status to the DeFi application.
8. If validation is successful, the DeFi application grants the user access based on the verified attestation.
The primary benefit of this approach is that it allows your contract to verify attestations that already exist on another chain without requiring those attestations to have been explicitly sent as cross-chain messages.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#overview-of-the-process)
Overview of the process
------------------------------------------------------------------------------------------------------------------------------------
To implement cross-chain log reading:
1. First, identify which log from another chain you want to consume in your application.
2. Create an Identifier struct that contains all necessary information about the log, including the chain ID and the contract address that emitted the log.
3. Call the `validateMessage()` function on the `CrossL2Inbox` contract, passing the identifier and a hash of the log data.
4. After validation, process the log data according to your application’s requirements.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#important-considerations)
Important considerations
--------------------------------------------------------------------------------------------------------------------------------------
* This feature works between chains within the [Superchain interop cluster](https://docs.optimism.io/interop/explainer#superchain-interop-cluster)
.
* The same functionality can be used on a single chain (for example, to maintain a consistent architecture).
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#handling-validation-failures)
Handling validation failures
* The `validateMessage` call will revert the entire transaction if validation fails.
* Consider implementing a try-catch pattern in your application’s frontend to handle these failures.
* Design your contract to allow for retry mechanisms where appropriate.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#comparison-with-l2tol2crossdomainmessenger)
Comparison with `L2ToL2CrossDomainMessenger`
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Feature | L2ToL2CrossDomainMessenger | CrossL2Inbox#validateMessage |
| --- | --- | --- |
| Purpose | Send messages between chains | Verify logs from other chains or local chain |
| Initiation | Source explicitly sends message to destination | Destination queries for existing logs from source |
| Use Case | Transfer tokens, trigger actions | Verify attestations, reference events |
| Flow | Push model | Pull model |
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#end-to-end-flow-comparison)
End-to-End flow comparison
------------------------------------------------------------------------------------------------------------------------------------------
This diagram compares the two approaches for cross-chain communication:
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#l2tol2crossdomainmessenger-push-model-)
L2ToL2CrossDomainMessenger (Push Model):
1. A source contract calls `sendMessage()` on the `L2ToL2CrossDomainMessenger`.
2. The messenger emits an event to the event log.
3. An autorelayer detects the event and relays it to the destination chain.
4. The destination `L2ToL2CrossDomainMessenger` receives the relayed message.
5. The destination messenger executes the message on the target contract.
###
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#crossl2inbox-pull-model-)
CrossL2Inbox (Pull Model):
1. A source contract emits an event to the event log.
2. The `OP-Supervisor` service monitors events across chains.
3. A destination contract calls `validateMessage()` on the `CrossL2Inbox`.
4. The `CrossL2Inbox` verifies the log’s existence by communicating with the `OP-Supervisor`.
5. The destination contract receives verification and proceeds with its logic.
[](https://docs.optimism.io/app-developers/guides/interoperability/reading-logs#next-steps)
Next steps
----------------------------------------------------------------------------------------------------------
* [Build a revolutionary app](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
that uses multiple blockchains within the Superchain
* Learn how to [pass messages between blockchains](https://docs.optimism.io/app-developers/tutorials/interoperability/message-passing)
* Deploy a [SuperchainERC20](https://docs.optimism.io/app-developers/tutorials/tokens/deploy-superchain-erc20)
to the Superchain
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/interoperability/reading-logs.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/interoperability/reading-logs)
[Interop message passing overview](https://docs.optimism.io/app-developers/guides/interoperability/message-passing)
[Message expiration](https://docs.optimism.io/app-developers/guides/interoperability/message-expiration)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/quickstarts/starter-kit#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Quickstarts
Deploying a SuperchainERC20 (Starter Kit)
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [How it works](https://docs.optimism.io/app-developers/quickstarts/starter-kit#how-it-works)
* [Setup](https://docs.optimism.io/app-developers/quickstarts/starter-kit#setup)
* [Deploy SuperchainERC20s](https://docs.optimism.io/app-developers/quickstarts/starter-kit#deploy-superchainerc20s)
* [\[deploy-config\]](https://docs.optimism.io/app-developers/quickstarts/starter-kit#deploy-config)
* [\[token\]](https://docs.optimism.io/app-developers/quickstarts/starter-kit#token)
* [Best practices for deploying SuperchainERC20](https://docs.optimism.io/app-developers/quickstarts/starter-kit#best-practices-for-deploying-superchainerc20)
* [Use Create2 to deploy SuperchainERC20](https://docs.optimism.io/app-developers/quickstarts/starter-kit#use-create2-to-deploy-superchainerc20)
* [Set safe crosschainMint and crosschainBurn permissions](https://docs.optimism.io/app-developers/quickstarts/starter-kit#set-safe-crosschainmint-and-crosschainburn-permissions)
* [Next Steps](https://docs.optimism.io/app-developers/quickstarts/starter-kit#next-steps)
The SuperchainERC20 standard is ready for production use with active Mainnet deployments. Please note that the OP Stack interoperability upgrade, required for crosschain messaging, is currently still in active development.
The [SuperchainERC20 Starter Kit](https://github.com/ethereum-optimism/superchainerc20-starter)
is a development toolkit designed to simplify the creation, deployment, and testing of SuperchainERC20 tokens. It leverages cross-chain interoperability for the deployment of ERC20 tokens that can be used across different blockchains in the Superchain ecosystem.
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#how-it-works)
How it works
-------------------------------------------------------------------------------------------------
Here’s a breakdown of what’s under the hood:
* **Cross-Chain Interoperability**: SuperchainERC20 tokens can move across multiple chains. This is possible by using the [IERC-7802](https://eips.ethereum.org/EIPS/eip-7802)
interface, which lets tokens be minted on one chain and burned on another to maintain a consistent supply.
* **Superchain Network**: The Superchain is a network of connected blockchains, allowing smooth data and asset flow. By using Optimism’s scaling solutions, the Superchain reduces gas fees and speeds up transactions.
* **Deployment**: The kit helps deploy SuperchainERC20 tokens on Ethereum-compatible chains, including setting up contracts, minting, burning, and cross-chain communication.
* **Testing**: Test scripts simulate real token transfers across chains to ensure everything works properly before going live.
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#setup)
Setup
-----------------------------------------------------------------------------------
1
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Install foundry
`supersim` requires `anvil` to be installed.Follow the [Foundry toolchain](https://book.getfoundry.sh/getting-started/installation)
guide for detailed instructions.
2
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Clone the repo
Next, you need to clone and navigate to the repo:
Report incorrect code
Copy
Ask AI
git clone https://github.com/ethereum-optimism/superchainerc20-starter.git
cd superchainerc20-starter
3
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Install dependencies
Install project dependencies using `pnpm`:
Report incorrect code
Copy
Ask AI
pnpm i
4
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Initialize .env files
Report incorrect code
Copy
Ask AI
pnpm init:env
5
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Start the development environment
This command will:
* Start the `supersim` local development environment
* Deploy the smart contracts to the test networks
* Launch the example frontend application
Report incorrect code
Copy
Ask AI
pnpm dev
Show child attributes
title=“Sanity check”Browse to [the console](http://localhost:5173/)
, mint some tokens and transfer them.
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#deploy-superchainerc20s)
Deploy SuperchainERC20s
-----------------------------------------------------------------------------------------------------------------------
1
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Configure RPC urls
This repository includes a script to automatically fetch the public RPC URLs for each chain listed in the [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/chainList.json)
and add them to the `[rpc_endpoints]` configuration section of `foundry.toml`.The script ensures that only new RPC URLs are appended, preserving any URLs already present in `foundry.toml`. To execute this script, run:
Report incorrect code
Copy
Ask AI
pnpm contracts:update:rpcs
2
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Modify deploy config parameters
The deployment configuration for token deployments is managed through the `deploy-config.toml` file. Below is a detailed breakdown of each configuration section:
####
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#deploy-config)
`[deploy-config]`
This section defines parameters for deploying token contracts.
| Parameter | Description | Example |
| --- | --- | --- |
| `salt` | A unique identifier used for deploying token contracts via \[`Create2`\]. This value along with the contract bytecode ensures that contract deployments are deterministic. | `salt = "ethers phoenix"` |
| `chains` | Lists the chains where the token will be deployed. Each chain must correspond to an entry in the `[rpc_endpoints]` section of `foundry.toml`. | `chains = ["op_chain_a","op_chain_b"]` |
####
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#token)
`[token]`
Deployment configuration for the token that will be deployed.
| Parameter | Description | Example |
| --- | --- | --- |
| `owner_address` | The address designated as the owner of the token. The `L2NativeSuperchainERC20.sol` contract included in this repo extends the [`Ownable`](https://github.com/Vectorized/solady/blob/c3b2ffb4a3334ea519555c5ea11fb0e666f8c2bc/src/auth/Ownable.sol)
contract. | `owner_address = "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"` |
| `name` | The token’s name. | `name = "TestSuperchainERC20"` |
| `symbol` | The token’s symbol. | `symbol = "TSU"` |
| `decimals` | The number of decimal places the token supports. | `decimals = 18` |
3
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#)
Deploy a token
* Before proceeding, ensure that your `deploy-config.toml` file is fully configured (see the [Modify Deploy Config Parameters](https://docs.optimism.io/app-developers/quickstarts/starter-kit#modify-deploy-config-parameters)
section setup details).
* Also, confirm that the `[rpc_endpoints]` section in `foundry.toml` is properly set up by following the instructions in [Configure RPC urls](https://docs.optimism.io/app-developers/quickstarts/starter-kit#configure-rpc-urls)
.
Deployments are executed through the `SuperchainERC20Deployer.s.sol` script. This script deploys tokens across each specified chain in the deployment configuration using `Create2`, ensuring deterministic contract addresses for each deployment. The script targets the `L2NativeSuperchainERC20.sol` contract by default. If you need to modify the token being deployed, either update this file directly or point the script to a custom token contract of your choice.
* To execute a token deployment run:
Report incorrect code
Copy
Ask AI
pnpm contracts:deploy:token
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#best-practices-for-deploying-superchainerc20)
Best practices for deploying SuperchainERC20
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#use-create2-to-deploy-superchainerc20)
Use `Create2` to deploy SuperchainERC20
`Create2` ensures that the address is deterministically determined by the bytecode of the contract and the provided salt. This is crucial because in order for cross-chain transfers of `SuperchainERC20`s to work with interop, the tokens must be deployed at the same address across all chains.
###
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#set-safe-crosschainmint-and-crosschainburn-permissions)
Set safe `crosschainMint` and `crosschainBurn` permissions
For best security practices `SuperchainERC20Bridge` should be the only contract with permission to call `crosschainMint` and `crosschainBurn`. These permissions are set up by default when using the `SuperchainERC20` contract.
[](https://docs.optimism.io/app-developers/quickstarts/starter-kit#next-steps)
Next Steps
---------------------------------------------------------------------------------------------
* Test your token deployment on multiple chains using [Supersim](https://docs.optimism.io/app-developers/tools/development/supersim)
and run simple [end-to-end integration tests](https://github.com/ethereum-optimism/superchainerc20-starter/blob/main/README.md#-e2e-tests)
.
* For specific use cases, check out our guides for [bridging a SuperchainERC20 token to another chain](https://github.com/ethereum-optimism/superchainerc20-starter/blob/main/README.md#-example-how-to-bridge-a-superchainerc20-token-to-another-chain)
or [modifying an existing ERC20 contract to be interoperable](https://github.com/ethereum-optimism/superchainerc20-starter/blob/main/README.md#updating-an-erc20-contract-to-be-interoperable)
.
* Questions about Interop? Check out our collection of \[interop guides\](/> op-stack/interop/explainer) or check out this [Superchain interop design video walk-thru](https://www.youtube.com/watch?v=FKc5RgjtGes)
.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/quickstarts/starter-kit.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/quickstarts/starter-kit)
[Integrating DeFi with Actions SDK](https://docs.optimism.io/app-developers/quickstarts/actions)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/testing-apps#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Guides
Testing apps for the Superchain
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Unit tests and single layer integration tests](https://docs.optimism.io/app-developers/guides/testing-apps#unit-tests-and-single-layer-integration-tests)
* [Multilayer integration tests](https://docs.optimism.io/app-developers/guides/testing-apps#multilayer-integration-tests)
* [Testing and Staging with Tenderly](https://docs.optimism.io/app-developers/guides/testing-apps#testing-and-staging-with-tenderly)
* [Integration with other products](https://docs.optimism.io/app-developers/guides/testing-apps#integration-with-other-products)
For the most part, running applications on OP Stack chains is identical to running them on Ethereum, so the testing is identical too. In this guide, you learn the best practices for OP Stack testing where there are differences.
[](https://docs.optimism.io/app-developers/guides/testing-apps#unit-tests-and-single-layer-integration-tests)
Unit tests and single layer integration tests
---------------------------------------------------------------------------------------------------------------------------------------------------------------
The vast majority of tests do not involve any OP Stack-specific features. In those cases, while you _could_ test everything on an OP Stack chain or a test network, that would normally be inefficient. Most Ethereum development stacks include features that make testing easier, which normal Ethereum clients, such as geth (and our modified version, `op-geth`) don’t support. Therefore, it is a good idea to run the majority of tests, which do not rely on OP Stack-specific features, in the development stack. It is a lot faster. It is a best practice to design and run thorough tests across an OP test network, either in your [local multichain development environment](https://docs.optimism.io/app-developers/tools/development/supersim)
, our [devnets](https://docs.optimism.io/op-stack/introduction/op-stack)
, or on [the test network](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op#op-sepolia)
, depending on your use case. Alternatively, with [Tenderly Virtual TestNets](https://docs.tenderly.co/virtual-testnets?mtm_campaign=ext-docs&mtm_kwd=optimism)
you can run tests with complete integration with existing protocols, access to unlimited faucets, continuous state sync, and access to development tools such as Debugger and Simulator UI. Running proper testing is key to identifying fringe cases where the equivalence between OP Stack chains and Ethereum breaks down (or where Ethereum mainnet itself and the development stack may be non-equivalent in a production environment).
[](https://docs.optimism.io/app-developers/guides/testing-apps#multilayer-integration-tests)
Multilayer integration tests
-----------------------------------------------------------------------------------------------------------------------------
Some apps need OP Stack-specific features that aren’t available as part of the development stack. For example, if your decentralized application relies on [inter-domain communication](https://docs.optimism.io/app-developers/guides/bridging/messaging)
, the effort of developing a stub to let you debug it in a development stack is probably greater than the hassle of having the automated test go to [a local multichain development environment](https://docs.optimism.io/app-developers/tools/development/supersim)
each time.
[](https://docs.optimism.io/app-developers/guides/testing-apps#testing-and-staging-with-tenderly)
Testing and Staging with Tenderly
---------------------------------------------------------------------------------------------------------------------------------------
Tenderly [Virtual TestNets](https://docs.tenderly.co/virtual-testnets?mtm_campaign=ext-docs&mtm_kwd=optimism)
provide a powerful environment for testing OP Stack applications with mainnet-like conditions. They offer several advantages for testing OP Stack applications:
* **Mainnet State Replication**: Virtual TestNets can sync with the latest OP Stack mainnet state, allowing you to test against real network conditions and interact with up-to-date protocols without spending real assets.
* **Unlimited Faucet**: Access [unlimited test tokens](https://docs.tenderly.co/virtual-testnets/unlimited-faucet?mtm_campaign=ext-docs&mtm_kwd=optimism)
for both native currency and ERC-20 tokens, enabling comprehensive testing of complex DeFi interactions.
* **Collaborative Testing**: Your entire team can access the same testing environment, making it easier to debug issues and validate fixes.
* **CI/CD Integration**: Incorporate automated testing in your deployment pipeline using [Virtual TestNets’ API](https://docs.tenderly.co/reference/api#/operations/createAlert?mtm_campaign=ext-docs&mtm_kwd=optimism)
and [GitHub Actions integration](https://docs.tenderly.co/virtual-testnets/ci-cd/github-actions-foundry?mtm_campaign=ext-docs&mtm_kwd=optimism)
.
* **Development tools**: Rely on the built-in [developer explorer](https://docs.tenderly.co/developer-explorer?mtm_campaign=ext-docs&mtm_kwd=optimism)
and debugging tools to analyze test transactions and contract interactions.
[](https://docs.optimism.io/app-developers/guides/testing-apps#integration-with-other-products)
Integration with other products
-----------------------------------------------------------------------------------------------------------------------------------
In many cases a decentralized application requires the services of other contracts. For example, [Perpetual v. 2](https://docs.perp.com/docs/guides/integration-guide)
cannot function without [Uniswap v. 3](https://uniswap.org/blog/uniswap-v3)
.
* If that is the case, you can use [mainnet forking](https://docs.optimism.io/app-developers/reference/tools/supersim/fork)
. It works with OP Stack chains.
* Create a Virtual TestNet to get access to third party contracts (e.g. Uniswap) and it’s latest or historical state.
* Alternatively, you can connect to our [test network](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op#op-sepolia)
if those contracts are also deployed there (in many cases they are).
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/testing-apps.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/testing-apps)
[Superchain Overview](https://docs.optimism.io/app-developers/guides/superchain)
[Configuring Actions SDK](https://docs.optimism.io/app-developers/guides/configuring-actions)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/reference/networks#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Reference
Networks
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/reference/networks.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/reference/networks)
[Account abstraction](https://docs.optimism.io/app-developers/tools/account-abstraction)
[Superchain RPC directory](https://docs.optimism.io/app-developers/reference/rpc-providers)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/app-developers/guides/configuring-actions#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Guides
Configuring Actions SDK
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Next Steps](https://docs.optimism.io/app-developers/guides/configuring-actions#next-steps)
Actions SDK lets you choose which assets, markets, chains, protocols, and providers you want to support in your application via configuration file.
1
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Install Actions SDK
Follow the [quickstart](https://docs.optimism.io/app-developers/quickstarts/actions)
guide to add Actions SDK as a dependency in your app.
2
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Integrate an embedded wallet
Follow the [integrating wallets](https://docs.optimism.io/app-developers/quickstarts/actions#choose-a-wallet-provider)
guide, choose and install a Wallet Provider.
3
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Create a config file
`actions.ts` - An accessible file that holds all of your configuration preference.
4
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Configure a Wallet Provider
Let Actions SDK know which Wallet Provider you’ve chosen:
* Frontend
* Backend
Select a wallet provider:
* Privy
* Turnkey
* Dynamic
actions.ts
Report incorrect code
Copy
Ask AI
const walletConfig = {
hostedWalletConfig: {
provider: {
type: "privy" as const,
},
},
smartWalletConfig: {
provider: {
type: "default" as const,
attributionSuffix: "actions",
},
},
};
actions.ts
Report incorrect code
Copy
Ask AI
const walletConfig = {
hostedWalletConfig: {
provider: {
type: "turnkey" as const,
},
},
smartWalletConfig: {
provider: {
type: "default" as const,
attributionSuffix: "actions",
},
},
};
actions.ts
Report incorrect code
Copy
Ask AI
const walletConfig = {
hostedWalletConfig: {
provider: {
type: "dynamic" as const,
},
},
smartWalletConfig: {
provider: {
type: "default" as const,
attributionSuffix: "actions",
},
},
};
Select a wallet provider:
* Privy
* Turnkey
actions.ts
Report incorrect code
Copy
Ask AI
import { PrivyClient } from '@privy-io/node'
const privyClient = new PrivyClient(
process.env.PRIVY_APP_ID,
process.env.PRIVY_APP_SECRET,
)
const walletConfig = {
hostedWalletConfig: {
provider: {
type: "privy" as const,
config: {
privyClient,
},
},
},
smartWalletConfig: {
provider: {
type: "default" as const,
attributionSuffix: "actions",
},
},
};
actions.ts
Report incorrect code
Copy
Ask AI
import { Turnkey } from '@turnkey/sdk-server'
const turnkeyClient = new Turnkey({
apiBaseUrl: 'https://api.turnkey.com',
apiPublicKey: process.env.TURNKEY_API_KEY,
apiPrivateKey: process.env.TURNKEY_API_SECRET,
defaultOrganizationId: process.env.TURNKEY_ORGANIZATION_ID,
})
const walletConfig = {
hostedWalletConfig: {
provider: {
type: "turnkey" as const,
config: {
client: turnkeyClient.apiClient(),
},
},
},
smartWalletConfig: {
provider: {
type: "default" as const,
attributionSuffix: "actions",
},
},
};
5
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Configure supported assets
Configure which assets you want to support across all lend providers:
actions.ts
Report incorrect code
Copy
Ask AI
// Additional config from previous steps...
// Import popular assets
import { USDC } from '@eth-optimism/actions-sdk/assets'
import type { Asset, AssetsConfig } from "@eth-optimism/actions-sdk";
// Or define custom assets
export const CustomToken: Asset = {
address: {
[mainnet.id]: '0x123...',
[unichain.id]: '0x456...',
[baseSepolia.id]: '0x789...',
},
metadata: {
decimals: 6,
name: 'Custom Token',
symbol: 'CUSTOM',
},
type: 'erc20',
}
// Configure allowed/blocked assets
const assetsConfig: AssetsConfig = {
allow: [USDC, CustomToken],
block: [], // Optional
}
6
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Configure Markets
Define which markets you want to support or block within your app:
actions.ts
Report incorrect code
Copy
Ask AI
// Additional config from previous steps...
export const GauntletUSDC: LendMarketConfig = {
address: '0xabc...',
chainId: unichain.id,
name: 'Gauntlet USDC',
asset: USDC,
lendProvider: 'morpho',
}
7
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Configure Lend Providers
Configure which lend protocols you want to support. You can enable one or multiple providers:
actions.ts
Report incorrect code
Copy
Ask AI
// Additional config from previous steps...
import type { LendConfig } from "@eth-optimism/actions-sdk";
const lendConfig: LendConfig = {
morpho: {
marketAllowlist: [GauntletUSDC],
marketBlocklist: [], // Optional
},
aave: {
marketAllowlist: [AaveWETH],
marketBlocklist: [], // Optional
},
};
8
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Configure supported chains
Configure supported chains:
actions.ts
Report incorrect code
Copy
Ask AI
// Additional config from previous steps...
import { optimism, base } from "viem/chains";
// Define any EVM chain
const OPTIMISM = {
chainId: optimism.id,
rpcUrls: env.OPTIMISM_RPC_URL,
bundler: {
// Bundle and sponsor txs with a gas paymaster
type: "simple" as const,
url: env.OPTIMISM_BUNDLER_URL,
},
};
const BASE = {
chainId: base.id,
rpcUrls: env.BASE_RPC_URL,
bundler: {
// Bundle and sponsor txs with a gas paymaster
type: "simple" as const,
url: env.BASE_BUNDLER_URL,
},
};
const chains = [OPTIMISM, BASE];
9
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Initialize Actions
Finally bring it all together and initialize Actions:
actions.ts
Report incorrect code
Copy
Ask AI
// Additional config from previous steps...
export const actions = createActions({
wallet: walletConfig,
assets: assetsConfig,
lend: lendConfig,
chains,
});
10
[](https://docs.optimism.io/app-developers/guides/configuring-actions#)
Take Action
Once you’ve initialized your actions instance, import it anywhere you need to take action:
Report incorrect code
Copy
Ask AI
import { actions } from './actions';
// Use actions anywhere in your app
const market = await actions.lend.getMarket({ ... });
const wallet = await actions.wallet.createSmartWallet({ ... });
const receipt = await wallet.lend.openPosition({ ... });
[](https://docs.optimism.io/app-developers/guides/configuring-actions#next-steps)
Next Steps
------------------------------------------------------------------------------------------------
For detailed API documentation and type definitions, see the [Actions SDK Reference](https://docs.optimism.io/app-developers/reference/actions)
.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/app-developers/guides/configuring-actions.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/app-developers/guides/configuring-actions)
[Testing apps for the Superchain](https://docs.optimism.io/app-developers/guides/testing-apps)
[Transferring ETH](https://docs.optimism.io/app-developers/tutorials/bridging/bridge-crosschain-eth)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/governance/evolution-and-experimentation#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
How Optimism Evolves
Evolution & Experimentation
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Evolution](https://docs.optimism.io/governance/evolution-and-experimentation#evolution)
* [Key Stakeholders](https://docs.optimism.io/governance/evolution-and-experimentation#key-stakeholders)
* [High Impact Inputs](https://docs.optimism.io/governance/evolution-and-experimentation#high-impact-inputs)
* [The Core Set of Decisions](https://docs.optimism.io/governance/evolution-and-experimentation#the-core-set-of-decisions)
* [Experimentation](https://docs.optimism.io/governance/evolution-and-experimentation#experimentation)
[](https://docs.optimism.io/governance/evolution-and-experimentation#evolution)
Evolution
---------------------------------------------------------------------------------------------
In our pursuit to design a new type of organization, Optimism’s public decision making process has undergone significant evolution since its inception, reflecting Optimism’s commitment to iterative improvement and experimentation. Below is a summary of some of the key things we learned along the way.
###
[](https://docs.optimism.io/governance/evolution-and-experimentation#key-stakeholders)
Key Stakeholders
* We’ve run multiple experiments to understand who our most engaged stakeholders are and how they participate in our public decision making process.
* **Tokenholders:** Anyone who holds OP can vote
* We’ve also run multiple delegation experiments aimed at getting if specific types of tokenholders (protocols, chains, and individual community members) more involved. Our main learning has been that tokenholders need strong incentive alignment to invest time in decision making processes and they want to be involved in low effort, high impact ways.
* While our system allows for delegation - whereby tokenholders can assign their votes to someone else to cast on their behalf - over time we’ve come to believe that delegation disrupts the incentives of token-weighted voting and that voting directly should be heavily encouraged.
* Tokenholders are asked to make decisions that would benefit from investor protections
* **Users, Apps, and Chains:** You must qualify to be a Citizen
* Citizenship started with a small initial group and expanded via a Web of Trust model. This model suffered from in-group dynamics (which were replicated here), resulting in many Citizens that were impacted by the decisions being made.
* We later ran targeted experiments to evaluate how community members, chains, and past grant recipients voted, ultimately resulting in our key stakeholder model. Our stakeholder models ensures chains, apps, and end-users are able to influence the decisions that impact them.
* Citizens are asked to make decisions that would benefit from consumer protections
* We’ve realized that input from different stakeholders is needed depending on the type of decision being made:
* **Preferences**: There is no absolute “right” answer and all stakeholders should have a say
* **Prediction**: There is a correct answer, which is only revealed in the future. Experts are best suited to make these decisions.
* When “experts” are needed, these decisions are made by Councils and Boards - such as the Developer Advisory Board and Security Council. These Councils and Boards are still ultimately accountable to key stakeholders.
* **Measurement**: This is best done objectively, by a computer, when possible, or by experts.
###
[](https://docs.optimism.io/governance/evolution-and-experimentation#high-impact-inputs)
High Impact Inputs
* Different decisions impact each stakeholder group in unique ways. Our approach has evolved from “everyone decides everything” to one that only asks stakeholders to make decisions that directly impact them.
* In many cases, a stakeholder doesn’t need to make a decision directly, but should still have the ability to veto - or reject - a decision that disadvantages their stakeholder group.
* Stakeholders will also be able to express preferences and influence strategy via non-voting processes.
* We’ve outlined the different decisions here: Figma
###
[](https://docs.optimism.io/governance/evolution-and-experimentation#the-core-set-of-decisions)
The Core Set of Decisions
* Governance minimization is a foundational principle of Optimism’s collective decision making process. Our evolution has been one of continuously simplifying process, reducing structure, and further refining scope.
* We’ve learned over time that several decisions that used to be made publicly, actually benefit from more centralized decision making (CoCC, CFC, BB.)
* We believe the set of decisions that should be made collectively are those that:
* Reduce platform risk for customers and users of the protocol
* Prevent short-term profit seeking at the long-term expense of the platform
* Optimism has always been committed to supporting public goods, but the way we support public goods has evolved greatly over time. We started with a fully public grant making process, which gradually evolved to be more metrics-driven and programmatic approach, requiring less human input. We expect this to be a continued area of evolution and innovation.
* Our Decentralization Milestones outlines the remaining steps we hope to take to refine and further decentralize our public decision making process.
[](https://docs.optimism.io/governance/evolution-and-experimentation#experimentation)
Experimentation
---------------------------------------------------------------------------------------------------------
Underpinning the learnings outlined above is a culture of experimentation. In our early days, our [iterative approach](https://gov.optimism.io/t/the-path-to-open-metagovernance/7728)
sometimes involved a less-scientific, trial-and-error approach. Over time, we’ve realized a more rigorous, data-driven approach - leveraging controlled trials where possible - allows us to truly understand what works and what doesn’t. A sample of our Research & Experiments findings are summarized in the table below. We often collaborate with academics, industry experts, and independent researchers.
| **Topic** | **Research question** | **Methods** | **Key Takeaways** | **Write-up** |
| --- | --- | --- | --- | --- |
| **Airdrops** | Do airdrops drive prosocial behaviors like delegation? Do they increase retention among new users? | Regression discontinuity design (RDD) | Increased delegation esp among small wallets; Baseline reward increases retention but high activity bonuses decrease retention | \- [Did OP Airdrop 2 Increase Governance Engagement?](https://gov.optimism.io/t/did-op-airdrop-2-increase-governance-engagement/7270)
\- [Did OP Airdrop 5 Increase User Retention Rates? A Regression Discontinuity Analysis](https://gov.optimism.io/t/did-op-airdrop-5-increase-user-retention-rates-a-regression-discontinuity-analysis/9610) |
| **Citizenship** | How do we identify key stakeholders (eg, end users, app devs, or partner chains) and give them decision-making rights? | Voting data analysis, surveys, qualitative interviews | Experts no “better” at values questions but better at assessing impact; Guest voters don’t vote differently to existing set; 3 clear personas | \- [Citizenship Learnings 2024](https://gov.optimism.io/t/citizenship-learnings-2024/9563) |
| **Deliberation** | How does participating in a deliberative process with direct policy implications change individual attitudes and behaviors? | Randomized experiment, instrumental variable regression | Deliberation increases knowledge and trust; No reduction in polarization when outcome is binding | \- [When Is Deliberation Useful for Optimism Governance?](https://gov.optimism.io/t/when-is-deliberation-useful-for-optimism-governance/9142) |
| **Futarchy** | Do projects selected via Futarchy see greater increase in TVL than projects selected by existing Grants Council? | Time-series analysis, RDD, analysis of telegram, survey, and trading data | Futarchy grants produced more Superchain TVL after 3 months than Grants Council picks; Predictions notably overpriced; 400+ forecasters participated | \- [Futarchy v1 Preliminary Findings](https://gov.optimism.io/t/futarchy-v1-preliminary-findings/10062) |
| **Public Goods Funding** | What voting designs lead to impactful grant allocation decisions? Does algorithmic/ metrics-based voting improve outcomes? | Voting data analysis, synthetic control method, surveys, qualitative feedback | Humans are bad at quantification and bias toward even distributions rather than reflecting value; Experts with context make better decisions for OSS; Individual bias about impact vs need is inevitable | \- [Retro Funding 4: Learnings and Reflections](https://gov.optimism.io/t/retro-funding-4-learnings-and-reflections/9271)
\- [Season 7 Retro Funding - Early Evidence on Developer Tooling Impact](https://gov.optimism.io/t/season-7-retro-funding-early-evidence-on-developer-tooling-impact/10162) |
| **Voter mobilization** | Do appeals to civic duty, economic self-interest, collective security, or decision authority increase tokenholder turnout? | Randomized multi-wave experiment | Economic and security (tangible stakes) were most effective in driving turnout; Repeated reminders are necessary to sustain increase in participation; catchy visuals and follow-ups important | \- “What Drives Turnout in Digital Governance? Evidence from a Multi-stage Voter Mobilization Experiment among 34,328 Tokenholders” (Draft available upon request: [\[email protected\]](https://docs.optimism.io/cdn-cgi/l/email-protection#60050c091a01200f1014090d09130d4e090f)
) |
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/governance/evolution-and-experimentation.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/governance/evolution-and-experimentation)
[Capital Allocation](https://docs.optimism.io/governance/capital-allocation)
[FAQs](https://docs.optimism.io/governance/gov-faq)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/governance/capital-allocation#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
How Optimism Evolves
Capital Allocation
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [How does Optimism ensure long-term success?](https://docs.optimism.io/governance/capital-allocation#how-does-optimism-ensure-long-term-success)
* [How does Optimism generate revenue?](https://docs.optimism.io/governance/capital-allocation#how-does-optimism-generate-revenue)
* [How is the treasury managed?](https://docs.optimism.io/governance/capital-allocation#how-is-the-treasury-managed)
* [What is Optimism’s commitment to Open Source Software?](https://docs.optimism.io/governance/capital-allocation#what-is-optimism%E2%80%99s-commitment-to-open-source-software)
* [What can I do with the OP Token?](https://docs.optimism.io/governance/capital-allocation#what-can-i-do-with-the-op-token)
[](https://docs.optimism.io/governance/capital-allocation#how-does-optimism-ensure-long-term-success)
How does Optimism ensure long-term success?
-----------------------------------------------------------------------------------------------------------------------------------------------------
Optimism strives to create a sustainable ecosystem flywheel. In this flywheel, revenue contributed by OP Chains to the Optimism Collective funds open-source development and drives ecosystem growth, which strengthens the OP Stack and attracts more end-users, apps, integration partners, and chains. In implementing this flywheel, Optimism uses a public decision making process designed to prevent short-term profit seeking at the expense of the platform, while ensuring organizations contributing the OP Stack remain accountable to tokenholders and customers. This process includes a capital allocation model, designed to avoid many of the common failure modes of corporate governance, aiming to ensure the product always remains at the cutting edge. For more details, please see the [Operating Manual.](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)
[](https://docs.optimism.io/governance/capital-allocation#how-does-optimism-generate-revenue)
How does Optimism generate revenue?
-------------------------------------------------------------------------------------------------------------------------------------
OP Chains in the Superchain earn transaction fees whenever users send transactions onchain, including for payments, trading, identity, and other applications. Each chain also pays costs to publish its activity to Ethereum for security. OP Chains contribute a portion of their revenue to Optimism. This treasury is used to drive growth, provide shared infrastructure, and fund open source contributions that benefit the Superchain. Superchain member chains contribute the greater of:
* 15% of net transaction fee profit (transaction fees earned on L2 - costs paid to Ethereum L1), or
* 2.5% of gross transaction fees
OP Mainnet contributes 100% of its revenue to this shared treasury. You can find more information about revenue in the [Superchain Revenue Explainer documentation](https://docs.optimism.io/superchain/superchain-information/superchain-revenue-explainer)
. You can also find the list of wallets across L1 and OP Mainnet where the Optimism Collective Revenue earned sits [here](https://docs.google.com/spreadsheets/d/1f-uIW_PzlGQ_XFAmsf9FYiUf0N9l_nePwDVrw0D5MXY/edit?gid=155717474#gid=155717474)
, on the right-hand side of the Collective Contribution page.
* OP Treasury Address for Foundation Allocated Budget: `0x2A82Ae142b2e62Cb7D10b55E323ACB1Cab663a26`
* This address hold the remaining OP tokens allocated to the Foundation, which the Foundation requires governance approval to access (via annual FND budget proposals).
* OP Treasury Address for Foundation Approved Budget: `0x2501c477D0A35545a387Aa4A3EEe4292A9a8B3F0`
* This is the Foundation’s OP Treasury which is available for the Foundation to utilize as the Foundation’s budget granted through the initial token allocation. Transactions from this wallet are typically internal operational movements per the Foundation’s needs.
* Additional token may be moved from `0x2…a26` to `0x2…3F0` based on governance approval of budgets.
* OP Foundation Grants Wallet: `0x19793c7824Be70ec58BB673CA42D2779d12581BE`
* This Foundation wallet is used to make private OP grants. This is topped up from the OP Treasury Foundation Approved Budget wallet `0x2…B3F0` as needed.
* OP Foundation Locked Grants Wallet: `0xE4553b743E74dA3424Ac51f8C1E586fd43aE226F`
* This Foundation wallet is used to hold OP for one year lockups. This is topped up from the OP Foundation Grants Wallet `0x1...81BE` as needed.
[](https://docs.optimism.io/governance/capital-allocation#how-is-the-treasury-managed)
How is the treasury managed?
-----------------------------------------------------------------------------------------------------------------------
The treasury is currently stewarded by the Foundation, but is subject to oversight by key stakeholder groups, via Optimism’s public decision making process. Specifically, tokenholders, chains, apps, and users are asked to oversee annual budgets, which enable the Foundation to deploy the treasury into initiatives aimed at generated the sustainable flywheel described above. Foundation Budget Reports can be found [here](https://gov.optimism.io/c/updates-and-announcements/foundation-budgets/)
on the governance forum. The OP Token Unlock (Estimated) sheet can be found [here](https://docs.google.com/spreadsheets/d/1qVMhLmmch3s6XSbiBe8hgD4ntMkPIOhc1WrhsYsQc7M/edit?usp=sharing)
. You can find more information via the Operating Manual [here](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)
.
[](https://docs.optimism.io/governance/capital-allocation#what-is-optimism%E2%80%99s-commitment-to-open-source-software)
What is Optimism’s commitment to Open Source Software?
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Optimism has always been committed to funding open-source software. OP Labs, a core contributor to the OP Stack, is registered as a public benefit corporation with a mission to enhance and enshrine access to public goods. The OP Stack is MIT licensed and Optimism dedicates a significant portion of its treasury to funding public goods and open-source software. Optimism operates various grant programs to incentivize and reward open-source contributions. Grant programs can be found via [atlas.optimism.io](http://atlas.optimism.io/)
.
[](https://docs.optimism.io/governance/capital-allocation#what-can-i-do-with-the-op-token)
What can I do with the OP Token?
-------------------------------------------------------------------------------------------------------------------------------
The OP token was created in May of 2022, with an initial supply of 4,294,967,296 OP tokens. The token was launched as a governance token to enable tokenholders to weigh in on technical and economic decisions that impact Optimism, such as protocol upgrades and capital allocation. The Optimism Foundation estimates the total supply of circulating OP tokens to increase as detailed in [this sheet](https://docs.google.com/spreadsheets/d/1qVMhLmmch3s6XSbiBe8hgD4ntMkPIOhc1WrhsYsQc7M/)
. Tokenholders can use OP to vote on:
* Protocol Upgrades
* Token Allocations
* Adjusting Inflation
* Removing the Director of the Optimism Foundation
* Dissolutions
* Elections (and representative removal)
* Protecting the rights of tokenholders by consenting to any changes to the founding documents of the Optimism Foundation, if those changes would materially reduce their rights.
* Ratification of Governing Documents
You can find full details of what Tokenholders can vote with the Operating Manual [here](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)
. You can sign up to vote with your tokens [here](https://vote.optimism.io/delegates)
.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/governance/capital-allocation.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/governance/capital-allocation)
[Protocol Upgrades](https://docs.optimism.io/governance/protocol-upgrades)
[Evolution & Experimentation](https://docs.optimism.io/governance/evolution-and-experimentation)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/governance/protocol-upgrades#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
How Optimism Evolves
Protocol Upgrades
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [How does the OP Stack stay up to date with the latest innovation?](https://docs.optimism.io/governance/protocol-upgrades#how-does-the-op-stack-stay-up-to-date-with-the-latest-innovation)
* [How are new features added to the OP Stack?](https://docs.optimism.io/governance/protocol-upgrades#how-are-new-features-added-to-the-op-stack)
* [What is the protocol upgrade process?](https://docs.optimism.io/governance/protocol-upgrades#what-is-the-protocol-upgrade-process)
* [How can my chain specifically influence the feature roadmap?](https://docs.optimism.io/governance/protocol-upgrades#how-can-my-chain-specifically-influence-the-feature-roadmap)
* [How does Optimism help my chain achieve decentralization?](https://docs.optimism.io/governance/protocol-upgrades#how-does-optimism-help-my-chain-achieve-decentralization)
[](https://docs.optimism.io/governance/protocol-upgrades#how-does-the-op-stack-stay-up-to-date-with-the-latest-innovation)
How does the OP Stack stay up to date with the latest innovation?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The OP Stack is Optimism’s open-source software for deploying next-generation onchain products. The software is licensed under the MIT license, meaning it can be freely used and forked by all parties. The OP Stack has a vibrant core developer community who contribute to the stack, ensuring it reflects the features and values protocol users care about. The Superchain is an ecosystem of chains running on Optimism’s OP Stack, featuring some of the world’s largest enterprises. Superchain networks benefit from shared security, upgrades and services provided by Optimism. Each chain maintains peak performance with access to innovative new features developed anywhere on the stack, continually strengthening the entire Superchain ecosystem. Chains may also configure components of the OP Stack to fit their regulatory and business needs while still benefiting from shared infrastructure and innovation. Learn more about the best way to build on the OP Stack for your business [here](https://www.optimism.io/compare)
.
[](https://docs.optimism.io/governance/protocol-upgrades#how-are-new-features-added-to-the-op-stack)
How are new features added to the OP Stack?
----------------------------------------------------------------------------------------------------------------------------------------------------
OP Labs and external contributors determine the feature roadmap. Based on discussions, protocol upgrades are drafted, which go through the protocol upgrade process.
[](https://docs.optimism.io/governance/protocol-upgrades#what-is-the-protocol-upgrade-process)
What is the protocol upgrade process?
----------------------------------------------------------------------------------------------------------------------------------------
The protocol upgrade process is designed to make sure the OP Stack does not change against the interests of the businesses building on the platform. This is a key benefit of crypto systems compared to their centralized alternatives. Platform risk is a common risk of [Web 2 platforms](https://a16zcrypto.com/posts/article/when-is-decentralizing-on-a-blockchain-valuable/)
and is a key consideration for the largest partners building on the OP Stack.  Protocol upgrades are drafted by OP Labs or other core contributors to the OP Stack. Before they are implemented, they are reviewed by an independent group of developers (the Developer Advisory Board) to ensure the upgrade is well justified. After a proposal has been reviewed by the Developer Advisory Board, it enters a 7 day veto period. This allows all impacted stakeholders, namely tokenholders, chains, apps, and end-users to override the DAB’s decision if they believe an upgrade disadvantages their interests. This is how platform risk is reduced for key stakeholders of the OP Stack. If a proposal is veto’d, it enters an appeals and discussion phase and can be resubmitted. For full details about the protocol upgrade process, please see the [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md)
. Overall - contributors, tokenholders, chains, apps, and end-users all have a voice. Checks and balances exist so that no single entity (including OP Labs or the Foundation) can unilaterally dictate the future of the OP Stack. Platform risk is reduced by distributing veto power across stakeholder groups while maintaining an efficient core developer process. This ensures upgrades happen quickly but can be vetoed if they harm key stakeholders.
[](https://docs.optimism.io/governance/protocol-upgrades#how-can-my-chain-specifically-influence-the-feature-roadmap)
How can my chain specifically influence the feature roadmap?
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Superchain members who contribute revenue back to the Collective are consulted by OP Labs and core developers about the feature roadmap to ensure their voices are heard. All development happens in the open and chains are encouraged to participate and share their perspectives within various research and development repositories.
[](https://docs.optimism.io/governance/protocol-upgrades#how-does-optimism-help-my-chain-achieve-decentralization)
How does Optimism help my chain achieve decentralization?
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Permissionless Fault Proof OP Chains that have their upgrade keys managed by the Optimism Security Council are classified as Stage 1 in [L2Beat’s framework](https://l2beat.com/stages)
. This distributed group delivers the benefit of security scrutinized upgrades that are managed by Optimism.
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/governance/protocol-upgrades.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/governance/protocol-upgrades)
[Capital Allocation](https://docs.optimism.io/governance/capital-allocation)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/op-mainnet/network-information/op-addresses#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Network Information
OP Mainnet Contract Addresses
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [L2 Contract Addresses](https://docs.optimism.io/op-mainnet/network-information/op-addresses#l2-contract-addresses)
* [OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/op-addresses#op-mainnet)
* [OP Sepolia](https://docs.optimism.io/op-mainnet/network-information/op-addresses#op-sepolia)
* [L1 Contract Addresses](https://docs.optimism.io/op-mainnet/network-information/op-addresses#l1-contract-addresses)
* [Ethereum Mainnet](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-mainnet)
* [Ethereum Testnet (Sepolia)](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-testnet-sepolia)
* [Superchain Contracts](https://docs.optimism.io/op-mainnet/network-information/op-addresses#superchain-contracts)
* [Ethereum Mainnet](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-mainnet-2)
* [Ethereum Testnet (Sepolia)](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-testnet-sepolia-2)
* [Legacy Contracts](https://docs.optimism.io/op-mainnet/network-information/op-addresses#legacy-contracts)
* [OP Mainnet Legacy (L2)](https://docs.optimism.io/op-mainnet/network-information/op-addresses#op-mainnet-legacy-l2)
* [Ethereum Mainnet Legacy (L1)](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-mainnet-legacy-l1)
This page lists all contract addresses for OP Mainnet and OP Sepolia. For high-level details and source code, see the [Smart Contracts Overview](https://docs.optimism.io/op-stack/protocol/smart-contracts)
.
Contract addresses are automatically synced from the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry/tree/main)
.
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#l2-contract-addresses)
L2 Contract Addresses
------------------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#op-mainnet)
OP Mainnet
| Contract Name | Contract Address |
| --- | --- |
| `L2ToL1MessagePasser` | [`0x4200000000000000000000000000000000000016`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000016) |
| `L2CrossDomainMessenger` | [`0x4200000000000000000000000000000000000007`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000007) |
| `L2StandardBridge` | [`0x4200000000000000000000000000000000000010`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000010) |
| `L2ERC721Bridge` | [`0x4200000000000000000000000000000000000014`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000014) |
| `SequencerFeeVault` | [`0x4200000000000000000000000000000000000011`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000011) |
| `OptimismMintableERC20Factory` | [`0x4200000000000000000000000000000000000012`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000012) |
| `OptimismMintableERC721Factory` | [`0x4200000000000000000000000000000000000017`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000017) |
| `L1Block` | [`0x4200000000000000000000000000000000000015`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000015) |
| `GasPriceOracle` | [`0x420000000000000000000000000000000000000F`](https://explorer.optimism.io/address/0x420000000000000000000000000000000000000F) |
| `ProxyAdmin` | [`0x4200000000000000000000000000000000000018`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000018) |
| `BaseFeeVault` | [`0x4200000000000000000000000000000000000019`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000019) |
| `L1FeeVault` | [`0x420000000000000000000000000000000000001A`](https://explorer.optimism.io/address/0x420000000000000000000000000000000000001A) |
| `GovernanceToken` | [`0x4200000000000000000000000000000000000042`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000042) |
| `SchemaRegistry` | [`0x4200000000000000000000000000000000000020`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000020) |
| `EAS` | [`0x4200000000000000000000000000000000000021`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000021) |
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#op-sepolia)
OP Sepolia
| Contract Name | Contract Address |
| --- | --- |
| `L2ToL1MessagePasser` | [`0x4200000000000000000000000000000000000016`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000016) |
| `L2CrossDomainMessenger` | [`0x4200000000000000000000000000000000000007`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000007) |
| `L2StandardBridge` | [`0x4200000000000000000000000000000000000010`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000010) |
| `L2ERC721Bridge` | [`0x4200000000000000000000000000000000000014`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000014) |
| `SequencerFeeVault` | [`0x4200000000000000000000000000000000000011`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000011) |
| `OptimismMintableERC20Factory` | [`0x4200000000000000000000000000000000000012`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000012) |
| `OptimismMintableERC721Factory` | [`0x4200000000000000000000000000000000000017`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000017) |
| `L1Block` | [`0x4200000000000000000000000000000000000015`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000015) |
| `GasPriceOracle` | [`0x420000000000000000000000000000000000000F`](https://sepolia-optimism.etherscan.io/address/0x420000000000000000000000000000000000000F) |
| `ProxyAdmin` | [`0x4200000000000000000000000000000000000018`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000018) |
| `BaseFeeVault` | [`0x4200000000000000000000000000000000000019`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000019) |
| `L1FeeVault` | [`0x420000000000000000000000000000000000001A`](https://sepolia-optimism.etherscan.io/address/0x420000000000000000000000000000000000001A) |
| `GovernanceToken` | [`0x4200000000000000000000000000000000000042`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000042) |
| `SchemaRegistry` | [`0x4200000000000000000000000000000000000020`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000020) |
| `EAS` | [`0x4200000000000000000000000000000000000021`](https://sepolia-optimism.etherscan.io/address/0x4200000000000000000000000000000000000021) |
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#l1-contract-addresses)
L1 Contract Addresses
------------------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-mainnet)
Ethereum Mainnet
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-testnet-sepolia)
Ethereum Testnet (Sepolia)
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#superchain-contracts)
Superchain Contracts
----------------------------------------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-mainnet-2)
Ethereum Mainnet
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-testnet-sepolia-2)
Ethereum Testnet (Sepolia)
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#legacy-contracts)
Legacy Contracts
--------------------------------------------------------------------------------------------------------------
Legacy contracts are from previous versions of the OP Stack and are maintained for backwards compatibility.
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#op-mainnet-legacy-l2)
OP Mainnet Legacy (L2)
| Contract Name | Contract Address |
| --- | --- |
| `L1MessageSender` | [`0x4200000000000000000000000000000000000001`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000001) |
| `DeployerWhitelist` | [`0x4200000000000000000000000000000000000002`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000002) |
| `LegacyERC20ETH` | [`0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000`](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000) |
| `L1BlockNumber` | [`0x4200000000000000000000000000000000000013`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000013) |
| `LegacyMessagePasser` | [`0x4200000000000000000000000000000000000000`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000000) |
###
[](https://docs.optimism.io/op-mainnet/network-information/op-addresses#ethereum-mainnet-legacy-l1)
Ethereum Mainnet Legacy (L1)
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/op-mainnet/network-information/op-addresses.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/op-mainnet/network-information/op-addresses)
[Connecting to OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
⌘I
---
# Page Not Found
[Skip to main content](https://docs.optimism.io/superchain/superchain-information/superchain-registry.mdx#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Page Not Found
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
404
Page Not Found
==============
We couldn't find the page. Maybe you were looking for one of these pages below?
[The Superchain Registry](https://docs.optimism.io/superchain/superchain-information/superchain-registry#the-superchain-registry)
[Superchain Overview](https://docs.optimism.io/app-developers/guides/superchain#superchain-overview)
[What makes a chain standard?](https://docs.optimism.io/chain-operators/reference/standard-configuration#superchain-registry)
⌘I
---
# Page Not Found
[Skip to main content](https://docs.optimism.io/chain-operators/tools/op-deployer/overview.mdx#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Page Not Found
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
404
Page Not Found
==============
We couldn't find the page. Maybe you were looking for one of these pages below?
[OP Deployer](https://docs.optimism.io/chain-operators/tools/op-deployer/overview#op-deployer)
[What makes a chain standard?](https://docs.optimism.io/chain-operators/reference/standard-configuration#role-of-op-deployer-in-standardization)
[Deploy a Custom Gas Token chain](https://docs.optimism.io/chain-operators/guides/features/custom-gas-token-guide#deploy-a-custom-gas-token-chain)
⌘I
---
# Page Not Found
[Skip to main content](https://docs.optimism.io/op-stack/security/governance/evolution-and-experimentation#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Page Not Found
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
404
Page Not Found
==============
We couldn't find the page. Maybe you were looking for one of these pages below?
[OP Stack security model](https://docs.optimism.io/op-stack/security/faq-sec-model#op-stack-security-model)
[The OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack#the-op-stack)
[OP Stack components](https://docs.optimism.io/op-stack/protocol/components#op-stack-components)
⌘I
---
# Optimism Documentation
[Skip to main content](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#content-area)
[Optimism Documentation home page](https://docs.optimism.io/)
Search...
⌘KAsk AI
Search...
Navigation
Alt-DA Mode Explainer
[Chain Operators](https://docs.optimism.io/)
[Node Operators](https://docs.optimism.io/node-operators/overview)
[App Developers](https://docs.optimism.io/app-developers/quickstarts/starter-kit)
[OP Stack](https://docs.optimism.io/op-stack/introduction/op-stack)
[OP Mainnet](https://docs.optimism.io/op-mainnet/network-information/connecting-to-op)
[Superchain](https://docs.optimism.io/superchain/introduction/superchain-explainer)
[How Optimism Evolves](https://docs.optimism.io/governance/protocol-upgrades)
[Notices](https://docs.optimism.io/notices/upgrade-18)
On this page
* [Sustainably low costs](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#sustainably-low-costs)
* [How it works](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#how-it-works)
* [Future improvements](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#future-improvements)
* [Tradeoffs of Alt-DA Mode](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#tradeoffs-of-alt-da-mode)
* [Next steps](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#next-steps)
* [FAQs](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#faqs)
* [Can I deploy a chain using Ethereum L1 DA and later switch to Alt-DA?](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#can-i-deploy-a-chain-using-ethereum-l1-da-and-later-switch-to-alt-da)
* [Can I deploy a chain using Alt-DA and then later switch to Ethereum L1 DA?](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#can-i-deploy-a-chain-using-alt-da-and-then-later-switch-to-ethereum-l1-da)
* [Can I switch between Alt-DA layers when using Alt-DA Mode?](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#can-i-switch-between-alt-da-layers-when-using-alt-da-mode)
This is an experimental feature. Use with caution.
Alt-DA Mode enables seamless integration of various Data Availability (DA) Layers, regardless of their commitment type, into the OP Stack. This allows any chain operator to launch an OP Stack chain using their favorite DA Layer for sustainably low costs.
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#sustainably-low-costs)
Sustainably low costs
-----------------------------------------------------------------------------------------------------------------------
In order to function securely, OP Stack chains need to ensure that L2 transaction data is available to all node operators. EIP-4844 has massively reduced Ethereum L1 data costs for OP Stack rollups, but blobspace is on the path to congestion, which will lead to higher blob fees and increased chain operator costs. Over the past few years, alternative DA Layers have been built as an alternative place for L2s to post L2 data that is cheap, with more throughput, but remains stable and minimizes security and decentralization tradeoffs.
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#how-it-works)
How it works
-----------------------------------------------------------------------------------------------------
Alt-DA Mode introduces a standard interface for reading and writing data to Alt-DA Layers and allows any DA Layer team to build and maintain their own [DA Server](https://specs.optimism.io/experimental/alt-da.html?utm_source=op-docs&utm_medium=docs#da-server)
to enable the OP Stack to communicate with their DA Layer. The DA Server handles any of the custom DA Layer logic, such as key management, interfacing with a DA Layer node, etc. This abstraction ensures that new features and improvements to Alt-DA Mode will come to all chains using Alt-DA Mode, regardless of the DA Layer they choose to use. Although the Data Availability Challenge (DA Challenge) will be disabled at launch, this integration provides a solution compatible with upcoming OP Stack features.
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#future-improvements)
Future improvements
-------------------------------------------------------------------------------------------------------------------
Just like with the Rollup configuration of the OP Stack, core contributors are continuously improving the decentralization, security, and cost-effectiveness of Alt-DA Mode. Some of the future features that core contributors are looking to build are:
* Integration with Fault Proofs
* Alt-DA Challenges support for more DA Layers (currently only supports DA Layers with a `keccak256` commitment type)
* DA Bridge integrations (like Celestia Blobstream and Eigen DA Cert Verification)
* Increasing the amount of data that can be committed to in a single commitment (potentially with merklization)
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#tradeoffs-of-alt-da-mode)
Tradeoffs of Alt-DA Mode
-----------------------------------------------------------------------------------------------------------------------------
Alt-DA Mode will always have more trust assumptions than simply posting data to L1 Ethereum. In its current initial iteration, Alt-DA Mode with generic commitments fully trusts the chain operator to make data available by both posting all data to the DA Layer and posting corresponding commitments to L1 Ethereum. If a chain operator posts incorrect commitments or does not post data to the DA Layer, it will not be accessible by node operators. The future improvements mentioned above are intended to address this trust assumption. After DA Bridges are integrated, then as long as the DA Layer and its DA Bridge are decentralized and functioning as intended, then once data is posted to the DA Layer, the L1 commitments would be bridged without relying on a single trusted party. It is important to remember that, even after integrating the DA Bridges and Fault Proofs, there will still be an added trust assumption that the DA Layer and DA Bridge are secure and functioning as intended.
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#next-steps)
Next steps
-------------------------------------------------------------------------------------------------
* Ready to get started? Read our guide on how to [deploy your Alt-DA Mode chain](https://docs.optimism.io/chain-operators/guides/features/alt-da-mode-guide)
.
* For more info about how Alt-DA Mode works under the hood, [check out the specs](https://specs.optimism.io/experimental/alt-da.html?utm_source=op-docs&utm_medium=docs)
.
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#faqs)
FAQs
-------------------------------------------------------------------------------------
###
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#can-i-deploy-a-chain-using-ethereum-l1-da-and-later-switch-to-alt-da)
Can I deploy a chain using Ethereum L1 DA and later switch to Alt-DA?
While it is a future goal to spec out a migration path from Ethereum L1 DA to Alt-DA Mode, the migration path has not been scoped out yet.
###
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#can-i-deploy-a-chain-using-alt-da-and-then-later-switch-to-ethereum-l1-da)
Can I deploy a chain using Alt-DA and then later switch to Ethereum L1 DA?
Same as above, it is a future goal to spec out this migration path, but the migration path has not been scoped out yet.
###
[](https://docs.optimism.io/op-stack/features/experimental/alt-da-mode#can-i-switch-between-alt-da-layers-when-using-alt-da-mode)
Can I switch between Alt-DA layers when using Alt-DA Mode?
This is technically possible today. A chain operator can start posting data to two DA Layers simultaneously during a transition period and coordinates their node operators to switch the DA Server they operate during that time. If assistance is needed here, please reach out [via Github](https://github.com/ethereum-optimism/developers/discussions)
Was this page helpful?
YesNo
[Suggest edits](https://github.com/ethereum-optimism/docs/edit/mintlify/op-stack/features/experimental/alt-da-mode.mdx)
[Raise issue](https://github.com/ethereum-optimism/docs/issues/new?title=Issue%20on%20docs&body=Path:%20/op-stack/features/experimental/alt-da-mode)
⌘I
---