title:How do I get project support (marketing / integrations / etc.)?
lang:en-US
---
Welcome! We're stoked that you're launching on Optimism.
If you have not filled out the [get started form](https://oplabs.typeform.com/get-in-touch?typeform-source=community.optimism.io) please do so prior to reading this.
We are excited for your deployment onto Optimism!
You will be welcomed by [the following metrics](https://dune.com/optimismfnd/Optimism) 📈📈 (up and to the right!), [a budding community](https://discord-gateway.optimism.io/) 🫂🫂, and some great exclusive [Telegram Channels](https://t.me/+Cb7q0a1YqItkZTRk) ⚙️⚙️ for builders.
The OPLabs team gets a flurry of inbound messages and calls every day and we reply to them as efficiently as possible, but we are only human!
Please be patient if you are in need of direct support.
We cannot always provide direct help, but we strive to help everyone succeed on Optimism through the various resources we provide to projects.
## Developer Support 🙋💻
Steps to take if you would like developer support immediately, ranked in order of response times.
1. See our [Developer Documentation](../developers/), [Tutorials](https://github.com/ethereum-optimism/optimism-tutorial), and [Help Center](https://help.optimism.io)
1. Head over to [**#dev-support**](https://discord.com/channels/667044843901681675/887914409207414785) on discord for the fastest help
1. Join [this TG group](https://t.me/+Cb7q0a1YqItkZTRk) and ask for help there
1. Last attempt: [Fill out this form](https://oplabs.typeform.com/get-in-touch?typeform-source=community.optimism.io)
## Marketing Requests 🦸🦸
When your project is deployed on Optimism, you can be added to [our ecosystem page](https://www.optimism.io/apps/all).
Simply [fill out this form](https://oplabs.typeform.com/op-marketing) to be included. Inclusion is at our discretion.
We add new projects live on the Optimism mainnet [here](https://www.optimism.io/apps/all) once a week.
### Promoting Values before anything else
We love to promote values-aligned projects as part of our broader content program.
### Tweeting
We do the occasional retweet but the bar for these is kept quite high in order to keep our Twitter feed as valuable/high signal as possible.
Other than RT's, we may like or reply to a tweet or include it in our weekly wrap up thread.
You're welcome to submit your tweet for amplification but please keep in mind if and how we interact with it is at our sole discretion.
### OPRadio
We also host a weekly Twitter Space in an interview/podcast format called OP Radio. You're welcome to express interest in being featured on OP Radio, but keep in mind that we maintain the final say on whether it makes sense or not.
## Governance Grants
Grants are mainly handled by [The Optimism Collective](https://app.optimism.io/announcement), our open governance system/digital society. If you are interested in applying, we first recommend the following:
- Check that your application falls within the possible Governance Grant categories in the [OPerating manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types).
- Deploy to Optimism (we are [EVM Equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), not just EVM compatible so it is very easy to deploy).
Check out our [getting started tutorial](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/getting-started) to see how to deploy. We also have [tons of more in-depth tutorials](https://github.com/ethereum-optimism/optimism-tutorial) for bridging and other L2 specific functionality.
- Try gaining organic traction:
- Traction can be gained through our community.
- Head over to [our discord](https://discord-gateway.optimism.io/) and check out [#showandtell](https://discord.com/channels/667044843901681675/819333988719263774) or [#demoday](https://discord.com/channels/667044843901681675/960493820674465883).
Demo Day is an AMA about your product to our community. Apply in Discord.
- Seek synergies – look at other teams already deployed on Optimism that could work with your product and reach out to them.
- Once you have done the above, check out our [governance grant process](https://gov.optimism.io/t/grant-proposal-template/3233).
- To get reviews in real time from governance delegates go to discord and post about your project in [#temp-check](https://discord.com/channels/667044843901681675/1011238484373159956).
## Other Helpful Links
Curious about our Optimistic Origins?
Listen to [this OPRadio Episode](https://twitter.com/optimismFND/status/1585015947626426368) with one of our founders, [@JingleJam](https://twitter.com/jinglejamOP).
What do the next 100 years have in store for crypto? [@Karl_dot_tech](https://twitter.com/karl_dot_tech) shares his vision in [this chat with Bankless](https://www.youtube.com/watch?v=60F2wtjZO5M).
Want to see what we are doing with Retroactive Public Goods? [See here](../governance/retropgf-2.md)
Changes to the protocol coming in the near term include multi-client architecture, and the world’s next generation fault proof.
Check out [Bedrock](https://dev.optimism.io/introducing-optimism-bedrock/) and [Cannon](https://medium.com/ethereum-optimism/cannon-cannon-cannon-introducing-cannon-4ce0d9245a03).
Want to see the first ever step forward into a modular rollup architecture? We are making it easy for anyone to deploy their own app-specific rollup via the [OP Stack](https://optimism.mirror.xyz/fLk5UGjZDiXFuvQh6R_HscMQuuY9ABYNF7PI76-qJYs).
**Fun fact:** A team has already launched [a Voxel Game on the OP Stack](https://dev.optimism.io/opcraft-autonomous-world/)!
Interested in exploring more?
[Fill out this form](https://docs.google.com/forms/d/e/1FAIpQLSciIONqVoMI6ivlrvp2EAdjrWqmZVGIpEaBbhaVZ17ZOf8DqQ/viewform?usp=sharing).
Although Optimism is an L2 (and therefore fundamentally connected to Ethereum), it's also a separate blockchain system.
App developers commonly need to move data and assets between Optimism and Ethereum.
We call the process of moving data and assets between the two networks "bridging".
## Sending tokens
For the most common usecase, moving tokens around, we've created the [Standard Token Bridge](./standard-bridge.md).
The Standard Token Bridge is a simple smart contract with all the functionality you need to move tokens between Optimism and Ethereum.
It also allows you to easily create L2 representations of existing tokens on Ethereum.
## Sending data
If the Standard Token Bridge doesn't fully cover your usecase, you can also [send arbitrary data between L1 and L2](./messaging.md).
You can use this functionality to have a contract on Ethereum trigger a contract function on Optimism and vice versa.
We've made this process as easy as possible by giving developers a simple API for triggering a cross-chain function call.
We even [use this API under the hood](https://github.com/ethereum-optimism/optimism/blob/a21cec6d3d00c9d7ed100c0257d4b966b034620f/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol#L202) inside the Standard Token Bridge.
Dapps' inter-layer communication strategies are based on trade-offs between several parameters:
- Speed
- Cost
- Trust assumptions
An issue related to both speed and decentralization is the L2 state.
This state is vulnerable to fault challenges until the fault challenge period (currently one week) passes.
If you want to do something that relies on the L2 state prior to that point, you should [run a replica](../build/run-a-node.md) yourself to make sure the state you use is correct.
## Fully centralized
If your dapp has a centralized always on server, the easiest solution is to just have two providers, one connected to Ethereum (L1) and the other to Optimism (L2).
| Parameter | Evaluation |
| - | - |
| Speed | Fastest
| Cost | Cheapest
| Trust assumption | Centralized
### Using the client (please don't)
The client (typically a browser with a wallet) can also connect to both Ethereum and Optimism, but it isn't a great mechanism for inter-layer communication.
You know what the code in the server is, because you wrote it.
You know what the code in the client is *supposed to be*, but it is possible for users to run a different client that pretends to be the legitimate one.
The only time that you can trust the client for inter-layer communication is when it is in the best interest of the user running the client not to lie.
And even then, you shouldn't because a hacker can cause a user to run malware.
## Fully decentralized
If you want to keep the same decentralization promises as Optimism and Ethereum, you can [rely on our messaging infrastructure](messaging.md).
You are already trusting Optimism to run the chain, and the messaging infrastructure goes through the same development process.
### Messages from L1 to L2
If you want L1 code to either tell L2 code to do something, or update L2 code with some information, you just need to [issue a single L1 transaction](messaging.md#for-ethereum-l1-to-optimism-l2-transactions).
| Parameter | Evaluation |
| - | - |
| Speed | ~15 minutes
| Cost | Cheapish (requires an L1 transaction)
| Trust assumption | Same as using Optimism
### Messages from L2 to L1
Sending messages from L2 to L1 is [a lot harder](messaging.md#for-optimism-l2-to-ethereum-l1-transactions).
It requires two transactions:
1. An initiating transaction on L2, which is pretty cheap.
1. Once the fault challenge period passes, a claiming transaction on L1, which includes [a merkle proof](https://medium.com/crypto-0-nite/merkle-proofs-explained-6dd429623dc5).
This transaction is expensive because merkle proof verification is expensive.
| Parameter | Evaluation |
| - | - |
| Speed | >7 days
| Cost | Expensive
| Trust Assumption | Almost as good as using Optimism, however someone needs to initiate the claim transaction on L1
## Incentivized communication
You can also use incentives, for example using a mechanism such as [UMA's](../../useful-tools/oracles/#universal-market-access-uma).
This is similar to the way optimistic rollups work - honest relays get paid, dishonest ones get slashed.
However, this mechanism is only truly decentralized if there are enough relayers to make sure there will always be an honest one.
Otherwise, it's similar to centralized communications, just with a few extra relayers that can take over.
To understand the process of creating bridges between contracts on Layer 1 and Layer 2, you should first have a basic understanding of the way contracts on *Ethereum* communicate with one another.
If you're a smart contract developer, you might be familiar with stuff like this:
```solidity
contract MyContract {
function doSomething(uint256 myFunctionParam) public {
// ... some sort of code goes here
}
}
contract MyOtherContract {
function doTheThing(address myContractAddress, uint256 myFunctionParam) public {
Here, `MyOtherContract.doTheThing` triggers a "call" to `MyContract.doSomething`.
A "call" is defined by a few key input parameters, mainly a `target address` and some `calldata`.
In this specific example, the `target address` is going to be the address of our instance of `MyContract`.
The `calldata`, on the other hand, depends on the function we're trying to call.
Solidity uses an encoding scheme called [Contract ABI](https://docs.soliditylang.org/en/v0.8.4/abi-spec.html) to both [select which function to call](https://docs.soliditylang.org/en/v0.8.4/abi-spec.html#function-selector) and to [encode function input arguments](https://docs.soliditylang.org/en/v0.8.4/abi-spec.html#argument-encoding).
Solidity gives us some useful tools to perform this same encoding manually.
For the sake of learning, let's take a look at how we can duplicate the same code with a manual encoding:
```solidity
contract MyContract {
function doSomething(uint256 myFunctionParam) public {
// ... some sort of code goes here
}
}
contract MyOtherContract {
function doTheThing(address myContractAddress, uint256 myFunctionParam) public {
myContractAddress.call(
abi.encodeWithSignature(
"doSomething(uint256)",
myFunctionParam
)
);
}
}
```
Here we're using the [low-level "call" function](https://docs.soliditylang.org/en/v0.8.4/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.4/units-and-global-variables.html#abi-encoding-and-decoding-functions).
Although these two code snippets look a bit different, they're actually functionally identical.
</details>
## Communication basics between layers
At a high level, this process is pretty similar to the same process for two contracts on Ethereum (with a few caveats).
**Communication between L1 and L2 is enabled by two special smart contracts called the "messengers"**.
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 only thing you really need to know about is the `sendMessage` function attached to each messenger:
```solidity
function sendMessage(
address _target,
bytes memory _message,
uint32 _gasLimit
) public;
```
It's the same as that `call` function used for contract messaging within L1 Ethereums.
We have an extra `_gasLimit` field here, but `call` has that too.
This is basically equivalent to:
```solidity
address(_target).call{gas: _gasLimit}(_message);
```
Except, of course, that we're calling a contract on a completely different network.
We're glossing over a lot of the technical details that make this whole thing work under the hood.
Point is, it works.
Want to call a contract on Optimism from a contract on Ethereum?
It's dead simple:
```solidity
// 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 MyOtherContract {
function doTheThing(address myOptimisticContractAddress, uint256 myFunctionParam) public {
ovmL1CrossDomainMessenger.sendMessage(
myOptimisticContractAddress,
abi.encodeWithSignature(
"doSomething(uint256)",
myFunctionParam
),
1000000 // use whatever gas limit you want
)
}
}
```
::: tip Using the messenger contracts
Our messenger contracts, the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol) and [`L2CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2CrossDomainMessenger.sol), always come pre-deployed to each of our networks.
You can find the exact addresses of these contracts on our various deployments [inside of the Optimism monorepo](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/deployments).
:::
## Communication speed
Unlike calls between contracts on the same blockchain, calls between Ethereum and Optimism are *not* instantaneous.
The exact speed of a cross-chain transaction depends on the direction in which the transaction is sent.
### For Ethereum (L1) to Optimism (L2) transactions
Transactions sent from L1 to L2 take up to approximately 15 minutes on mainnet and 5 minutes on the Optimism Goerli testnet to reach the target L2 contract.
This is because L2 nodes will wait for a certain number of block confirmations on Ethereum before executing an L1 to L2 transaction.
### For Optimism (L2) to Ethereum (L1) transactions
L2 to L1 transactions have to wait two periods:
1. The time until the state root is written to L1.
You can estimate this time by looking at how often transactions happen to the State Commitment Chain (on both [mainnet](https://etherscan.io/address/0xBe5dAb4A2e9cd0F27300dB4aB94BeE3A233AEB19) and [goerli](https://goerli.etherscan.io/address/0xE6Dfba0953616Bacab0c9A8ecb3a9BBa77FC15c0)).
As of the Bedrock update, it is necessary to provide a Merkle proof of the message on L1 after the state root is written.
The fault challenge period starts *after* that proof transaction becomes part of the L1 chain.
1. The [fault challenge period](#understanding-the-challenge-period), which is a few seconds on goerli and seven days on mainnet.
This waiting period is a core part of the security mechanism designed to keep funds on Optimism secure and cannot be circumvented.
After this waiting period, any user can "finalize" the transaction by triggering a second transaction on Ethereum that sends the message to the target L1 contract.
## Accessing `msg.sender`
Contracts frequently make use of `msg.sender` to make decisions based on the calling account.
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, we added a `xDomainMessageSender` function to each messenger:
```solidity
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:
The majority of the cost of an L1 to L2 transaction comes from sending a transaction on Ethereum.
You send a transaction to the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol)
contract, which then sends a call to the [`CanonicalTransactionChain`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/rollup/CanonicalTransactionChain.sol).
This cost is ultimately determined by gas prices on Ethereum when you're sending the cross-chain transaction.
An L1 to L2 message is expected to trigger contract execution on L2, and that contract execution costs gas.
The first 1.92 million gas on L2 is free.
The vast majority of L1 to L2 calls spend less than the 1.92 million, so nothing further is required.
If you think that your call might spend more than that on L2, you can specify a higher gas limit.
However, to prevent denial of service attacks, we have to impose a cost on gas limits higher than 1.92 million.
This cost is one unit of L1 gas for every 32 units of L2 gas requested beyond the free amount.
For example, if you specify a 2.0 million gas limit in the call to `L1CrossDomainMessenger`, it will be processed this way:
| Amount | Action |
| ------ | ------- |
| free gas: 1.92 million | Nothing, this gas is provided on L2 for free |
| excess gas required: 80,000 | 2,500 gas is spent on the L1 portion of the gas fee and in return 80,000 extra gas is provided to the L2 transaction. This is inline with the 1:32 ratio of gas. |
This gas burn happens on L1 when the L1 contract calls `L1CrossDomainMessenger`.
This is before the message has been sent to the L2, and as such there is no way to know how much L2 gas will actually be used.
Therefore, the amount burned is based *only* on the gas limit specified in the L1 call.
For example, if the call above with a gas limit of two million only takes ten thousand gas on L2, the 2,500 gas on L1 is still burned.
There is no refund.
The parameters in the explanation above were 1.92 million and 32 at the time of writing, but they may change in the future.
To see the present values, [go to Etherscan](https://etherscan.io/address/0x5E4e65926BA27467555EB562121fac00D24E9dD2#readContract) and expand `enqueueL2GasPrepaid` for the free L2 gas amount and `l2GasDiscountDivisor` for the exchange rate at which L1 gas is burned for additional L2 gas.
### Fees for L2 ⇒ 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 Optimism.
1. An L1 transaction that *proves* the transaction.
This transaction can only be submitted after the state root is submitted to L1.
This transaction is expensive because it includes verifying a [Merkle trie](https://eth.wiki/fundamentals/patricia-tree) inclusion proof.
1. 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.
## Understanding the challenge period
One of the most important things to understand about L1 ⇔ L2 interaction is that **messages sent from Layer 2 to Layer 1 cannot be relayed for at least one week**.
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](../../protocol/2-rollup-protocol.md#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 we can completely avoid the need to perform complicated (and expensive) logic on Ethereum.
Cheap transactions, yay!
However, we still need some 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 is able 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.
::: tip On the length of the challenge period
We've set the challenge period to be exactly seven days on the Optimism mainnet.
We believe this is a reasonable balance between security and usability, with an emphasis on increased security to start.
We're open to changing the length of the window as long as we feel this can be done without significantly reducing the security of the system.
If you're strongly opinionated about this, we recommend [opening an issue on GitHub](https://github.com/ethereum-optimism/optimism/issues) explaining your position.
Certain interactions, like transferring ETH and ERC20 tokens between the two networks, are common enough that we've built the "Standard Bridge" to make moving these assets between L1 and L2 as easy as possible.
The standard bridge functionality provides a method for an ERC20 token to be deposited and locked on L1 in exchange of the same amount of an equivalent token on L2. This process is known as "bridging a token", e.g. depositing 100 USDC on L1 in exchange for 100 USDC on L2 and also the reverse - withdrawing 100 USDC on L2 in exchange for the same amount on L1. In addition to bridging tokens the standard bridge is also used for ETH.
The Standard Bridge is composed of two main contracts the [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol)(for Layer 1) and the [`L2StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/master/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol)(for Layer 2).
Here we'll go over the basics of using this bridge to move ERC20 assets between Layer 1 and Layer 2.
::: tip
[See here for a step by step tutorial](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/cross-dom-bridge-erc20)
:::
## Deposits
::: warning NOTICE
We're working hard to get more smart contract wallet software deployed and tested on Optimism.
However, as a safety measure, **we currently block smart contract wallets from calling the `depositETH` and `depositERC20` functions**.
If you want to deposit using a smart contract wallet and you know what you're doing, you can use the `depositETHTo` and `depositERC20To` functions instead.
:::
### Depositing ERC20s
ERC20 deposits into L2 can be triggered via the `depositERC20` and `depositERC20To` functions on the [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol).
You **must** approve the Standard Token Bridge to use the amount of tokens that you want to deposit or the deposit will fail.
::: danger Use the standard bridge contract only with standard bridge tokens
The standard bridge can only be used with tokens that have a properly configured ERC-20 version on Optimism.
If you send any other type of token to the standard bridge directly (not using the user interface or the API), it gets stuck there and you lose that value.
Note that if you use the [Optimism bridge UI](https://app.optimism.io/bridge), or the [Optimism SDK](../../sdk/js-client.md) it automatically chooses the correct bridge contract, so this problem does not happen.
There are two ways to check if a token can use the standard bridge:
1. Look in [the token list](https://static.optimism.io/optimism.tokenlist.json).
If a token can use the standard bridge, then the `"chainId": 10` entry will have the standard L2 bridge address, `0x4200..0010`. For example, this entry shows that on the main Optimism network `0xBTC` can use the standard bridge.
In the token exists in the token list but does not use the standard bridge, the `extensions.optimismBridgeAddress` value is different. For example, this entry shows that on the main Optimism network `DAI` uses a different bridge:
1. You can "ask" the L2 token contract by calling it.
ERC-20 tokens that can use the standard bridge not only if they:
- Have an `l2Bridge` method
- That method returns `0x4200...0010`.
For example, [this link](https://explorer.optimism.io/address/0xe0bb0d3de8c10976511e5030ca403dbf4c25165b#readContract) can be used to see that `0xBTC` uses the standard bridge.
Note that you cannot query the L1 token contract the same way.
L2 contracts know the identity of their L1 counterpart, but L1 contracts only need to implement the standard ERC-20 methods.
:::
### Depositing ETH
ETH deposits into L2 can be triggered via the `depositETH` and `depositETHTo` functions on the [`L1StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1StandardBridge.sol).
ETH deposits can alternatively be triggered by sending ETH directly to the `L1StandardBridge`.
Once your deposit is detected and finalized on Optimism, your account will be funded with the corresponding amount of ETH on L2.
## Withdrawals
### Withdrawing ERC20s
ERC20 withdrawals can be triggered via the `withdraw` or `withdrawTo` functions on the [`L2StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol).
If you'd like to see this contracts in action, you should check out the [L1 ⇔ L2 deposit-and-withdraw example](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/cross-dom-bridge-erc20).
### Withdrawing ETH
Unlike on L1, we do not have a separate function on L2 for withdrawing ETH.
Instead, you can use the `withdraw` or `withdrawTo` functions on the [`L2StandardBridge`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/messaging/L2StandardBridge.sol) and use the address `0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000` as the L2 token address.
## Adding an ERC20 token to the Standard Bridge
::: tip
To add your token to the standard bridge, see the guide [Adding an ERC20 token to the Standard Bridge](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/standard-bridge-standard-token).
:::
## The Optimism token list
The Standard bridge allows a one-to-many mapping between L1 and L2 tokens, meaning that there can be many Optimism implementations of an L1 token.
However there is always a one-to-one mapping between L1 and L2 tokens in the [Optimism token list](https://github.com/ethereum-optimism/ethereum-optimism.github.io/blob/master/optimism.tokenlist.json).
The token list is used as the source of truth for the [Optimism Gateway](https://gateway.optimism.io) which is the main portal for moving assets between Layer 1 and Layer 2.
If you want to have your token added to the token list, you must make a pull request against the [Optimism token list repository](https://github.com/ethereum-optimism/ethereum-optimism.github.io#adding-a-token-to-the-list).
You'll need the addresses for both the L1 and L2 tokens, as well as a logo for the token.
If you're looking for an example to follow, take a look at [this simple pull request that adds a token to the token list](https://github.com/ethereum-optimism/ethereum-optimism.github.io/pull/43/files).
The cost of using a decentralized application in Optimism is much lower than the cost of the equivalent application on L1 Ethereum.
[See here](https://l2fees.info/) for the current values.
However, with proper optimization, we can make our decentralized applications even cheaper.
Here are some strategies.
## Background
This is a basic introduction into some of the concepts you need to understand to fully optimise your contracts in the Optimism L2 environment.
### What are the transaction fees?
The cost of an L2 transaction on Optimism is composed of two components:
- L2 execution fee, which is proportional to the gas actually used in processing the transaction.
Normally the cost of L2 gas is 0.001 gwei, but this may increase when the system is extremely congested.
Do not hardcode this value.
- L1 data fee, which is proportional to:
- The gas cost of writing the transaction's data to L1 (roughly equal to the transaction's length)
- The cost of gas on L1.
The cost of gas on L1 can be extremely volatile.
To view the current gas costs as a user, [see here](https://public-grafana.optimism.io/). To retrieve them programatically, [see here](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/sdk-estimate-gas).
For a more in depth look at how transaction fees are calculated see our [fee documentation](transaction-fees.md).
### Optimization tradeoffs
In almost all cases, the L1 data fee is the vast majority of the transaction's cost.
The L2 execution fee is, comparatively speaking, negligible.
This means that the optimization tradeoffs are very different in Optimism than they are in Ethereum.
Transaction call data is *expensive*.
The cost of writing a byte to L1 is approximately 16 gas.
At a cost of 45 gwei per L1 gas unit, writing one byte to L1 on Optimism costs 720 gwei, or 720,000 units of L2 gas (at the non-congested price of 0.001 gwei per L2 gas unit).
In comparison, on-chain processing and storage are cheap.
The worst case for writing to storage (previously uninitialized storage) is a cost of [22100 L2 gas per EVM word, which contains 32 bytes of data](https://www.evm.codes/#55), which averages out to less than 700 L2 gas / byte.
At a cost of 45 gwei per L1 gas unit, this means it is cheaper to write a whole kilobyte to storage, rather than add one byte to the transaction call data.
## Modify the [ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html)
[The standard ABI](https://docs.soliditylang.org/en/latest/abi-spec.html) was designed with L1 tradeoffs in mind.
It uses four byte function selectors and pads values to a 32 byte size.
Neither is optimal when using Optimism.
It is much more efficient to [create a shorter ABI with just the required bytes, and decode it onchain](https://ethereum.org/en/developers/tutorials/short-abi/).
All of your [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) and [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) functions can use the standard ABI at no cost.
## Use smaller values when possible
Your modified ABI is not going to pad values, so the less bytes you use the better.
For example, it is standard to use `uint256` for amounts.
This means that the highest number we can represent is 2<sup>256</sup>-1, or about 1.2*10<sup>77</sup>.
When storing ETH balances, for example, using `uint256` is overkill as there are only [120 million ETH](https://ycharts.com/indicators/ethereum_supply). Thus, we can safely store ETH balances in `uint88` which is just eleven bytes.
Go through your contracts and identify any values that will never reach 32 bytes and reduce them to logical sizes. You can do this same process for ints, bytes and [other Solidity data types](https://docs.soliditylang.org/en/develop/types.html#types).
A development environment is a local installation of the entire Optimism system.
Our default development environment includes both L1 and L2 development nodes.
Running the Optimism environment locally is a great way to test your code and see how your contracts will behave on Optimism before you graduate to a testnet deployment (and eventually a mainnet deployment).
Alternatively, you can get a hosted development node from [Alchemy](https://www.alchemy.com/optimism) or [any of these providers](../../useful-tools/providers.md).
## Do I need this?
We generally recommend using the local development environment if your application falls into one of the following categories:
1.**You're building contracts on both Optimism and Ethereum that need to interact with one another.** The local development environment is a great way to quickly test interactions between L1 and L2. The Optimism testnet and mainnet environments both have a communication delay between L1 and L2 that can make testing slow during the early stages of development.
2.**You're building an application that might be subject to one of the few [differences between Ethereum and Optimism](./differences.md).** Although Optimism is [EVM equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), it's not exactly the same as Ethereum. If you're building an application that might be subject to one of these differences, you should use the local development environment to double check that everything is running as expected. You might otherwise have unexpected issues when you move to testnet. We strongly recommend reviewing these differences carefully to see if you might fall into this category.
However, not everyone will need to use the local development environment.
Optimism is [EVM equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), which means that Optimism looks almost exactly like Ethereum under the hood.
If you don't fall into one of the above categories, you can probably get away with simply relying on existing testing tools like Truffle or Hardhat.
If you don't know whether or not you should be using the development environment, feel free to hop into the [Optimism discord](https://discord-gateway.optimism.io).
Someone nice will help you out!
## What does it include?
Everything you need to test your Optimistic application:
1. An L1 (Ethereum) node available at [http://localhost:9545](http://localhost:9545).
1. An L2 (Optimism) node available at [http://localhost:8545](http://localhost:8545).
1. All of the Optimism contracts and services that make L1 ⇔ L2 communication possible.
1. Accounts with lots of ETH on both L1 and L2.
## Prerequisites
You'll need to have the following installed:
1.[Docker](https://www.docker.com/). these directions were verified with version 20.10.17
To compile the software on your own you also need:
1.[Node.js](https://nodejs.org/en/), version 12 or later
Note that these permissions do not take effect until you log in again, so you need to open a new command line window.
```sh
sudo usermod -a-G docker `whoami`
```
::: tip There is no need to install docker-compose anymore
It is now available on Docker itself as `docker compose`
:::
## Getting the software
You can set up your development environment either by downloading the required software from [Docker Hub](https://hub.docker.com/u/ethereumoptimism) or by building the software from the [source code](https://github.com/ethereum-optimism/optimism).
Downloading images from Docker Hub is easier and more reliable and is the recommended solution.
### Downloading from Docker Hub
1. Clone and enter the [Optimism monorepo](https://github.com/ethereum-optimism/optimism):
You can then dump the logs for a given container as follows:
```sh
docker logs <container name>
```
For example, to see the logs produced by the L1 node:
```sh
docker logs ops_l1_chain_1
```
If you'd like to follow these logs as they're being generated, run:
```sh
docker logs --follow <name of container>
```
## Getting Optimism system contract addresses
If you want to [interact with Optimism system contracts](./system-contracts.md), you'll need to know the addresses of the contracts that are deployed on the network.
### Getting L2 contract addresses
L2 contracts are always deployed to the same addresses on every Optimism network.
You can simply look at [the L2 contract addresses for the mainnet Optimism network](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/deployments/mainnet#layer-2-contracts) and you'll have the addresses for your local environment.
### Getting L1 contract addresses
Optimism's L1 contracts are deployed to different addresses on different networks.
However, the addresses for your local environment will always be the same, even if you reset the environment.
You can get the addresses for your environment with the following command:
```sh
curl http://localhost:8080/addresses.json
```
You should get back a JSON object that contains a mapping of contract names to contract addresses.
These addresses should not change, even if you restart your environment.
It's important to note that there are various minor discrepancies between the behavior of Optimism and Ethereum.
You should be aware of these descrepancies when building apps on top of Optimism.
## Opcode Differences
### Modified Opcodes
| Opcode | Solidity equivalent | Behavior |
| - | - | - |
| `COINBASE` | `block.coinbase` | Value is set by the sequencer. Currently returns the `OVM_SequencerFeeVault` address (`0x420...011`). |
| `DIFFICULTY` | `block.difficulty` | Always returns zero. [You can use an oracle for randomness](../../useful-tools/oracles.md#verifiable-randomness-function-vrf). |
| `BASEFEE` | `block.basefee` | Currently unsupported. |
| `ORIGIN` | `tx.origin` | If the transaction is an L1 ⇒ L2 transaction, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally. |
### Added Opcodes
| Opcode | Behavior |
| - | - |
| `L1BLOCKNUMBER` | Returns the block number of the last L1 block known by the L2 system. Typically this block number will lag by up to 15 minutes behind the actual latest L1 block number. See section on [Block Numbers and Timestamps](#block-numbers-and-timestamps) for more information. |
## Block Numbers and Timestamps
### Block production is not constant
On Ethereum, the `NUMBER` opcode (`block.number` in Solidity) corresponds to the current Ethereum block number.
Similarly, in Optimism, `block.number` corresponds to the current L2 block number.
However, as of the OVM 2.0 release of Optimism (Nov. 2021), **each transaction on L2 is placed in a separate block and blocks are NOT produced at a constant rate.**
This is important because it means that `block.number` is currently NOT a reliable source of timing information.
If you want access to the current time, you should use `block.timestamp` (the `TIMESTAMP` opcode) instead.
### Timestamps
The `TIMESTAMP` opcode (`block.timestamp` in Solidity) uses the timestamp of the transaction itself. It gets updated every fifteen seconds.
### Accessing the latest L1 block number
::: warning NOTICE
The hex value that corresponds to the `L1BLOCKNUMBER` opcode (`0x4B`) may be changed in the future (pending further discussion).
**We strongly discourage direct use of this opcode within your contracts.**
Instead, if you want to access the latest L1 block number, please use the `OVM_L1BlockNumber` contract as described below.
:::
The block number of the latest L1 block seen by the L2 system can be accessed via the `L1BLOCKNUMBER` opcode.
Solidity doesn't make it easy to use non-standard opcodes, so we've created a simple contract located at [`0x4200000000000000000000000000000000000013`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000013) that will allow you to trigger this opcode.
You can use this contract as follows:
```solidity
import { iOVM_L1BlockNumber } from "@eth-optimism/contracts/L2/predeploys/iOVM_L1BlockNumber.sol";
import { Lib_PredeployAddresses } from "@eth-optimism/contracts/libraries/constants/Lib_PredeployAddresses.sol";
contract MyContract {
function myFunction() public {
// ... your code here ...
uint256 l1BlockNumber = iOVM_L1BlockNumber(
Lib_PredeployAddresses.L1_BLOCK_NUMBER // located at 0x4200000000000000000000000000000000000013
).getL1BlockNumber();
// ... your code here ...
}
}
```
## Using ETH in Contracts
As of the OVM 2.0 update (Nov. 2021), **the process of using ETH on L2 is identical to the process of using ETH in Ethereum.**
Please note that ETH was previously accessible as an ERC20 token, but this feature has been removed as part of OVM 2.0.
For tooling developers and infrastructure providers, please note that ETH is still represented internally as an ERC20 token at the address [`0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000`](https://explorer.optimism.io/address/0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000).
As a result, user balances will always be zero inside the state trie and the user's actual balance will be stored in the aforementioned token's storage.
**It is NOT possible to call this contract directly, it will throw an error.**
## Address Aliasing
Because of the behavior of the `CREATE` opcode, it is possible for a user to create a contract on L1 and on L2 that share the same address but have different bytecode.
This can break trust assumptions, because one contract may be trusted and another be untrusted (see below).
To prevent this problem the behavior of the `ORIGIN` and `CALLER` opcodes (`tx.origin` and `msg.sender`) differs slightly between L1 and L2.
The value of `tx.origin` is determined as follows:
The value of `msg.sender` at the top-level (the very first contract being called) is always equal to `tx.origin`.
Therefore, if the value of `tx.origin` is affected by the rules defined above, the top-level value of `msg.sender` will also be impacted.
Note that in general, [`tx.origin` should *not* be used for authorization](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin).
However, that is a separate issue from address aliasing because address aliasing also affects `msg.sender`.
### Why is address aliasing an issue?
The problem with two identical source addresses (the L1 contract and the L2 contract) is that we extend trust based on the address.
It is possible that we will want to trust one of the contracts, but not the other.
1. Helena Hacker forks [Uniswap](https://uniswap.org/) to create her own exchange (on L2), called Hackswap.
**Note:** There are actually multiple contracts in Uniswap, so this explanation is a bit simplified.
[See here if you want additional details](https://ethereum.org/en/developers/tutorials/uniswap-v2-annotated-code/).
1. Helena Hacker provides Hackswap with liquidity that appears to provide profitable arbitrage opportunities.
For example, she can make it so that you can spend 1 [DAI](https://www.coindesk.com/price/dai/)to buy 1.1 [USDT](https://www.coindesk.com/price/tether/).
Both of those coins are supposed to be worth exactly $1.
1. Nimrod Naive knows that if something looks too good to be true it probably is.
However, he checks the Hackswap contract's bytecode and verifies it is 100% identical to Uniswap.
He decides this means the contract can be trusted to behave exactly as Uniswap does.
1. Nimrod approves an allowance of 1000 DAI for the Hackswap contract.
Nimrod expects to call the swap function on Hackswap and receive back nearly 1100 USDT.
1. Before Nimrod's swap transaction is sent to the blockchain, Helena Hacker sends a transaction from an L1 contract with the same address as Hackswap.
This transaction transfers 1000 DAI from Nimrod's address to Helena Hacker's address.
If this transaction were to come from the same address as Hackswap on L2, it would be able to transfer the 1000 DAI because of the allowance Nimrod *had* to give Hackswap in the previous step to swap tokens.
Nimrod, despite his naivete, is protected because Optimism modified the transaction's `tx.origin` (which is also the initial `msg.sender`).
That transaction comes from a *different* address, one that does not have the allowance.
**Note:** It is simple to create two different contracts on the same address in different chains.
But it is nearly impossible to create two that are different by a specified amount, so Helena Hacker can't do that.
## Network specifications
### JSON-RPC differences
Optimism uses the same [JSON-RPC API](https://eth.wiki/json-rpc/API) as Ethereum.
Some additional Optimism specific methods have been introduced.
See the full list of [custom JSON-RPC methods](./json-rpc.md) for more information.
### Pre-EIP-155 support
[Pre-EIP-155](https://eips.ethereum.org/EIPS/eip-155) transactions do not have a chain ID, which means a transaction on one Ethereum blockchain can be replayed on others.
This is a security risk, because transactions that are legitimate on one chain could be a security risk on another.
For example, you might agree to send me 1 ETH on Goerli (chain ID 5) to help me test my contracts.
If you submit the transaction as a pre-EIP-155 transaction, then I can wait until your address's nonce on mainnet (chain ID 1) is the same as the one you had when you submitted the Goerli transaction and send the transaction to mainnet.
Mainnet would then interpret it as a legitimate transaction and transfer a *real* ETH from your account to mine (assuming your balance is high enough, of course)
Starting in November 2022, pre-EIP-155 transactions are no longer supported on Optimism using the public endpoint or through Alchemy.
::: warning Pre-EIP-155 transactions are dangerous
It is highly recommended not to use pre-eip-155 transaction.
But if you absolutely must use them, [Infura](../../useful-tools/providers.md#infura) and [QuickNode](../../useful-tools/providers.md#quicknode) still support them.
Just be careful.
:::
# Bedrock
In [the Bedrock version](../bedrock/how-is-bedrock-different.md) there are even less differences between Optimism and L1 Ethereum.
## Opcode Differences
| Opcode | Solidity equivalent | Behavior |
| - | - | - |
| `COINBASE` | `block.coinbase` | Undefined |
| `DIFFICULTY` | `block.difficulty` | Random value. As this value is set by the sequencer, it is not as reliably random as the L1 equivalent. [You can use an oracle for randomness](../../useful-tools/oracles.md#verifiable-randomness-function-vrf). |
| `NUMBER` | `block.number` | L2 block number
| `TIMESTAMP` | `block.timestamp` | Timestamp of the L2 block
| `ORIGIN` | `tx.origin` | If the transaction is an L1 ⇒ L2 transaction, then `tx.origin` is set to the [aliased address](#address-aliasing) of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally. |
| `CALLER` | `msg.sender` | If the transaction is an L1 ⇒ L2 transaction, and this is the initial call (rather than an internal transaction from one contract to another), the same [address aliasing](#address-aliasing) behavior applies.
::: tip `tx.origin == msg.sender`
On L1 Ethereum `tx.origin` is equal to `msg.sender` only when the smart contract was called directly from an externally owned account (EOA).
However, on Optimism `tx.origin` is the origin *on Optimism*.
It could be an EOA.
However, in the case of messages from L1, it is possible for a message from a smart contract on L1 to appear on L2 with `tx.origin == msg.origin`.
This is unlikely to make a significant difference, because an L1 smart contract cannot directly manipulate the L2 state.
However, there could be edge cases we did not think about where this matters.
:::
### Accessing L1 information
If you need the equivalent information from the latest L1 block, you can get it from [the `L1Block` contract](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/contracts/L2/L1Block.sol).
This contract is a predeploy at address [`0x4200000000000000000000000000000000000015`](https://goerli-optimism.etherscan.io/address/0x4200000000000000000000000000000000000015).
You can use [the getter functions](https://docs.soliditylang.org/en/v0.8.12/contracts.html#getter-functions) to get these parameters:
-`number`: The latest L1 block number known to L2
-`timestamp`: The timestamp of the latest L1 block
-`basefee`: The base fee of the latest L1 block
-`hash`: The hash of the latest L1 block
-`sequenceNumber`: The number of the L2 block within the epoch (the epoch changes when there is a new L1 block)
### Address Aliasing
<details>
Because of the behavior of the `CREATE` opcode, it is possible for a user to create a contract on L1 and on L2 that share the same address but have different bytecode.
This can break trust assumptions, because one contract may be trusted and another be untrusted (see below).
To prevent this problem the behavior of the `ORIGIN` and `CALLER` opcodes (`tx.origin` and `msg.sender`) differs slightly between L1 and L2.
The value of `tx.origin` is determined as follows:
The value of `msg.sender` at the top-level (the very first contract being called) is always equal to `tx.origin`.
Therefore, if the value of `tx.origin` is affected by the rules defined above, the top-level value of `msg.sender` will also be impacted.
Note that in general, [`tx.origin` should *not* be used for authorization](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin).
However, that is a separate issue from address aliasing because address aliasing also affects `msg.sender`.
#### Why is address aliasing an issue?
The problem with two identical source addresses (the L1 contract and the L2 contract) is that we extend trust based on the address.
It is possible that we will want to trust one of the contracts, but not the other.
1. Helena Hacker forks [Uniswap](https://uniswap.org/) to create her own exchange (on L2), called Hackswap.
**Note:** There are actually multiple contracts in Uniswap, so this explanation is a bit simplified.
[See here if you want additional details](https://ethereum.org/en/developers/tutorials/uniswap-v2-annotated-code/).
1. Helena Hacker provides Hackswap with liquidity that appears to allow for profitable arbitrage opportunities.
For example, she can make it so that you can spend 1 [DAI](https://www.coindesk.com/price/dai/)to buy 1.1 [USDT](https://www.coindesk.com/price/tether/).
Both of those coins are supposed to be worth exactly $1.
1. Nimrod Naive knows that if something looks too good to be true it probably is.
However, he checks the Hackswap contract's bytecode and verifies it is 100% identical to Uniswap.
He decides this means the contract can be trusted to behave exactly as Uniswap does.
1. Nimrod approves an allowance of 1000 DAI for the Hackswap contract.
Nimrod expects to call the swap function on Hackswap and receive back nearly 1100 USDT.
1. Before Nimrod's swap transaction is sent to the blockchain, Helena Hacker sends a transaction from an L1 contract with the same address as Hackswap.
This transaction transfers 1000 DAI from Nimrod's address to Helena Hacker's address.
If this transaction were to come from the same address as Hackswap on L2, it would be able to transfer the 1000 DAI because of the allowance Nimrod *had* to give Hackswap in the previous step to swap tokens.
Nimrod, despite his naivete, is protected because Optimism modified the transaction's `tx.origin` (which is also the initial `msg.sender`).
That transaction comes from a *different* address, one that does not have the allowance.
**Note:** It is simple to create two different contracts on the same address in different chains.
But it is nearly impossible to create two that are different by a specified amount, so Helena Hacker can't do that.
</details>
## Blocks
There are several differences in the way blocks are produced between L1 Ethereum and Optimism Bedrock.
| Parameter | L1 Ethereum | Optimism Bedrock |
| - | - | - |
| Time between blocks | 12 seconds(1) | 2 seconds |
| Block target size | 15,000,000 gas | to be determined |
| Block maximum size | 30,000,000 gas | to be determined |
(1) This is the ideal.
If any blocks are missed it could be an integer multiple such as 24 seconds, 36 seconds, etc.
**Note:** The L1 Ethereum parameter values are taken from [ethereum.org](https://ethereum.org/en/developers/docs/blocks/#block-time). The Optimism Bedrock values are taken from [the Optimism specs](https://github.com/ethereum-optimism/optimism/blob/develop/specs/guaranteed-gas-market.md#limiting-guaranteed-gas).
## Network specifications
### JSON-RPC differences
Optimism uses the same [JSON-RPC API](https://eth.wiki/json-rpc/API) as Ethereum.
Some additional Optimism specific methods have been introduced.
See the full list of [custom JSON-RPC methods](./json-rpc.md) for more information.
### Pre-EIP-155 support
[Pre-EIP-155](https://eips.ethereum.org/EIPS/eip-155) transactions do not have a chain ID, which means a transaction on one Ethereum blockchain can be replayed on others.
This is a security risk.
Starting in November 2022, pre-EIP-155 transactions are no longer supported on Optimism.
## Transaction costs
[Transaction costs on Optimism](./transaction-fees.md) include an [L2 execution fee](./transaction-fees.md#the-l2-execution-fee) and an [L1 data fee](./transaction-fees.md#the-l1-data-fee).
## Contract addresses
The addresses in which various infrastructure contracts are installed are different between L1 Ethereum and Optimism.
For example, [WETH9](https://github.com/gnosis/canonical-weth/blob/master/contracts/WETH9.sol) is installed on L1 Ethereum on [address `0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2`](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2).
On Optimism the same contract is installed on [address `0x4200000000000000000000000000000000000006`](https://explorer.optimism.io/address/0x4200000000000000000000000000000000000006).
Optimism shares the same [JSON-RPC API](https://eth.wiki/json-rpc/API) as Ethereum.
Some custom methods have been introduced to simplify certain Optimism specific interactions.
## Custom JSON-RPC Methods
### `eth_getBlockRange`
Like `eth_getBlockByNumber` but accepts a range of block numbers instead of just a single block.
**Parameters**
1.`QUANTITY|TAG` - integer of the starting block number for the range, or the string `"earliest"`, `"latest"` or `"pending"`, as in the [default block parameter](https://eth.wiki/json-rpc/API#the-default-block-parameter).
2.`QUANTITY|TAG` - integer of the ending block number for the range, or the string `"earliest"`, `"latest"` or `"pending"`, as in the [default block parameter](https://eth.wiki/json-rpc/API#the-default-block-parameter).
3.`BOOLEAN` - If `true` it returns the full transaction objects, if `false` only the hashes of the transactions.
**Returns**
An array of `block` objects.
See [`eth_getBlockByHash`](https://eth.wiki/json-rpc/API#eth_getblockbyhash) for the structure of a `block` object.
There are several bedrock components with an RPC API:
## Rollup node (op-node)
[*Rollup node*](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md) refers to the component in the protocol specifications.
The Optimism implementation is called *op-node*.
The `op-node` component implements several RPC methods:
### `optimism_outputAtBlock`
Get the output root at a specific block.
This method is documented in [the specifications](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md#output-method-api).
```sh
curl -X POST -H"Content-Type: application/json"--data\
Optionally, the rollup node can provide [peer to peer synchronization](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node-p2p.md) to provide pending L2 blocks to other rollup nodes.
## Execution engine (op-geth)
[*Execution engine*](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md) refers to the component in the protocol specifications.
The Optimism implementation is called *op-geth*.
The execution engine's RPC interface is identical to [the upstream Geth RPC interface](https://geth.ethereum.org/docs/rpc/server). This includes the ability to provide [snap sync](https://github.com/ethereum/devp2p/blob/master/caps/snap.md) functionality to other execution engines.
The responses are nearly identical too, except we also include the L1 gas usage and price information.
## Daisy chain
The daisy chain is a proxy that distributes requests either to the execution engine (if related to post-Bedrock blocks), or the legacy geth (if related to blocks prior to bedrock).
It accepts [the interface used by L1 execution engines](https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/openrpc.json&uiSchema%5BappBar%5D%5Bui:splitView%5D=false&uiSchema%5BappBar%5D%5Bui:input%5D=false&uiSchema%5BappBar%5D%5Bui:examplesDropdown%5D=false).
## Legacy geth
The legacy geth provides information about the blockchain prior to Bedrock.
It implements the read-only methods of [the interface used by L1 execution engines](https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/execution-apis/assembled-spec/openrpc.json&uiSchema%5BappBar%5D%5Bui:splitView%5D=false&uiSchema%5BappBar%5D%5Bui:input%5D=false&uiSchema%5BappBar%5D%5Bui:examplesDropdown%5D=false).
It does not implement `eth_sendTransaction` and `eth_sendRawTransaction`, because they don't make sense in a read-only copy.
If you're looking to build an app on Optimism you'll need access to an Optimism node. You have two options - use a hosted node from providers like Alchemy or run your own.
## Hosted node providers
You can get a free, hosted one from [any of these providers](../../useful-tools/providers.md) to get up and building quickly. Of them, [Alchemy](https://www.alchemy.com/optimism) is our preferred node provider, and is used to power our [public endpoint](../../useful-tools/networks.md).
However, you might be interested in running your very own Optimism node.
Here we'll go over the process of running a testnet or mainnet Optimism node for yourself.
## Upgrades
If you run a node you need to subscribe to [an update feed](../releases.md)(either[the mailing list](https://groups.google.com/a/optimism.io/g/optimism-announce) or [the RSS feed](https://changelog.optimism.io/feed.xml)) to know when to upgrade.
Otherwise, your node will eventually stop working.
## Configuration choices
### Hardware requirements
Replicas need to store the transaction history of Optimism and to run Geth.
They need to be relatively powerful machines (real or virtual).
We recommend at least 16 GB RAM, and an SSD drive with at least 100 GB free.
Prior to Bedrock you choose one of two configurations.
-**Replicas** replicate from L2 (Optimism).
Replicas gives you the most up to date information, at the cost of having to trust Optimism's updates.
-**Verifiers** replicate from L1 (Ethereum).
Verifiers read and execute transactions from the cannonical block chain.
As a result, the only way for them to have inaccurate information is an [Ethereum reorg](https://www.paradigm.xyz/2021/07/ethereum-reorgs-after-the-merge#post-merge-ethereum-with-proof-of-stake), an extremely rare event.
</details>
<details>
<summary><b>Bedrock (coming late 2022)</b></summary>
In Bedrock the [op-geth](https://community.optimism.io/docs/developers/bedrock-temp/infra/#bedrock-geth) typically synchronizes from other Optimism nodes (https://github.com/ethereum-optimism/optimism/blob/develop/specs/exec-engine.md#happy-path-sync), meaning L2, but it can [synchronize from L1](https://github.com/ethereum-optimism/optimism/blob/develop/specs/exec-engine.md#worst-case-sync) if necessary.
To synchronize only from L1, you edit the [op-node configuration](https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md) to set `OP_NODE_P2P_DISABLE` to `true`.
When you use RPC to get block information (https://github.com/ethereum-optimism/optimism/blob/develop/specs/rollup-node.md#l2-output-rpc-method), you can specify one of four options for `blockNumber`:
- an actual block number
-**pending**: Latest L2 block
-**latest**: Latest block written to L1
-**finalized**: Latest block fully finalized on L1 (a process that takes 12 minutes with Proof of Stake)
</details>
## Docker configuration
The recommended method to create a replica is to use [Docker](https://www.docker.com/) and the [Docker images we provide](https://hub.docker.com/u/ethereumoptimism).
They include all the configuration settings.
This is the recommended method because it is what we for our own systems.
As such, the docker images go through a lot more tests than any other configuration.
### Configuring and running the node
Follow [these instructions](https://github.com/smartcontracts/simple-optimism-node) to build and run the node.
## Non-docker configuration
Here are the instructions if you want to build you own replica without relying on our images.
These instructions were generated with a [GCP e2-standard-4](https://cloud.google.com/compute/docs/general-purpose-machines#e2-standard) virtual machine running [Debian 10](https://www.debian.org/News/2021/2021100902) with a 100 GB SSD drive.
They should work on different operating systems with minor changes, but there are no guarantees.
Note that these directions are for a replica of the main network.
You need to modify some of them if you want to create a replica of the test network.
**Note:** This is *not* the recommended configuration.
While we did QA on these instructions and they work, the QA that the docker images undergo is much more extensive.
### Install packages
1. These packages are all required either to compile the software or to run it.
We need `libusb-1.0` because geth requires it to check for hardware wallets.
This TypeScript program reads data from an Optimism endpoint and passes it over to the local instance of l2geth ([geth](https://geth.ethereum.org/) with minor changes for layer 2 support).
| DATA_TRANSPORT_LAYER__L1_RPC_ENDPOINT | Get an endpoint from [a service provider](https://ethereum.org/en/developers/docs/nodes-and-clients/nodes-as-a-service/) unless you run a node yourself |
**Note**: If synchronizing from L1, replace the last line with
```sh
export ROLLUP_BACKEND=l1
```
1. Run the new file.
This syntax (dot, space, and then the name of the script) runs the script in the context of the current shell, rather than in a new shell.
The reason for doing this is that we want to modify the current shell's environment variables, not start a new shell, set up the environment in it, and then exit.
```sh
. env.sh
```
1. Initialize l2geth with the genesis state.
This process takes about nine minutes on my system.
Optimism is composed, in part, of a series of smart contracts on both L1 (Ethereum) and L2 (Optimism).
You may want to interact with these contracts for any number of reasons, including:
- Sending messages between L1 and L2
- Sending tokens between L1 and L2
- Querying information about the current [L1 data fee](./transaction-fees.md#the-l1-data-fee)
- And lots more!
On this page we'll show you how to work with these contracts directly from other contracts and how to work with them from the client side.
## Finding contract addresses
You'll need to find the address of the particular contract that you want to interact with before you can actually interact with it.
Check out the [Networks and Connection Details page](../../useful-tools/networks.md) for links to the contract addresses for each network.
You can also find the addresses for all networks in the [deployments folder](https://github.com/ethereum-optimism/optimism/tree/master/packages/contracts/deployments) of the [`contracts` package](https://github.com/ethereum-optimism/optimism/tree/master/packages/contracts).
## Interacting from another contract
All you need to interact with the Optimism system contracts from another contract is an address and an interface.
You can follow [the instructions above](#finding-contract-addresses) to find the address of the contract you want to interact with.
Now you simply need to import the appropriate contracts.
### Installing via NPM or Yarn
We export a package [`@eth-optimism/contracts`](https://www.npmjs.com/package/@eth-optimism/contracts?activeTab=readme) that makes it easy to use the Optimism contracts within NPM or Yarn based projects.
Install the package as follows:
```
npm install @eth-optimism/contracts
```
### Importing contracts
Simply import the desired contract or interface from the `@eth-optimism/contracts` package:
```solidity
import { SomeOptimismContract } from "@eth-optimism/contracts/path/to/SomeOptimismContract.sol";
```
Please note that `path/to/SomeOptimismContract` is the path to the contract [within this folder](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts/contracts).
For example, if you wanted to import the [`L1CrossDomainMessenger`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L1/messaging/L1CrossDomainMessenger.sol) contract, you would use the following import:
```solidity
import { L1CrossDomainMessenger } from "@eth-optimism/contracts/L1/messaging/L1CrossDomainMessenger.sol";
```
### Getting L2 contract addresses
Addresses of system contracts on the L2 side of the network are the same on every network.
We provide these addresses as constants within the [`Lib_PredeployAddresses`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/libraries/constants/Lib_PredeployAddresses.sol) contract.
## Interacting from the client side
Just like when interacting from another contract, we've created a few packages that make it easy to interact with the Optimism system contracts from the client side.
### Installing via NPM or Yarn
You can use the [`@eth-optimism/contracts`](https://www.npmjs.com/package/@eth-optimism/contracts?activeTab=readme) package to interact with the Optimism system contracts from a JavaScript or TypeScript based project.
Install the package as follows:
```
npm install @eth-optimism/contracts
```
### Getting contract artifacts, interfaces, and ABIs
You can get the compiler artifact, bytecode, and ABI for any Optimism contract as follows:
title:Testing Decentralized Applications with Optimism
lang:en-US
---
For the most part running applications on Optimism is identical to running them on Ethereum, so the testing is identical too.
In this article you learn the best practices for Optimism testing where there are differences.
## Unit tests and single layer integration tests
The vast majority of tests do not involve any Optimism-specific features.
In those cases, while you *could* test everything on Optimism, 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, l2geth) don't support.
Therefore, it is a good idea to run the majority of tests, which do not rely on Optimism-specific features, in the development stack.
It is a lot faster.
Ideally you would want to be able to run some tests on Optimism (either a [local development environment](dev-node.md) or [the test network](../../useful-tools/networks.md#optimism-goerli).
This would be a much slower process, but it would let you identify cases where [the equivalence between Optimism and Ethereum breaks down](differences.md)(or the equivalence between Ethereum itself and the development stack, for that matter).
## Multilayer integration tests
Some dapps need Optimism-specific features that aren't available as part of the development stack.
For example, if your decentralized application relies on [inter-domain communication](../bridge/messaging.md), 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 development environment](dev-node.md) each time.
## Integration with other products
In many cases a decentralized application requires the services of other contracts.
For example, [Perpetual v. 2](https://v2docs.perp.fi/benefits-of-v2) cannot function without [Uniswap v. 3](https://uniswap.org/blog/uniswap-v3).
If that is the case you can use [mainnet forking](https://hardhat.org/hardhat-network/guides/mainnet-forking.html).
It works with Optimism with the exception of transactions that use the `L1BlockNumber` opcode directly.
Alternatively, you can connect to our [test network](../../useful-tools/networks.md#optimism-goerli) if those contracts are also deployed there (in many cases they are).
Transaction fees on Optimism work a lot like fees on Ethereum.
However, Layer 2 introduces some new paradigms that means it can never be exactly like Ethereum.
Luckily, Optimism's [EVM equivalence](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306) makes these differences easy to understand and even easier to handle within your app.
Let's take a look at the two sources of cost in a transaction on Optimism: the L2 execution fee and the L1 data/security fee.
### The L2 execution fee
Just like on Ethereum, transactions on Optimism have to pay **gas** for the amount of computation and storage that they use.
Every L2 transaction will pay some **execution fee**, equal to the amount of gas used by the transaction multiplied by the gas price attached to the transaction.
This is exactly how fees work on Ethereum with the added bonus that gas prices on Optimism are seriously low.
The amount of L2 gas used depends on the particular transaction that you're trying to send.
Thanks to [EVM equivalence](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306), transactions typically use approximately the same amount of gas on Optimism as they do on Ethereum.
Gas prices fluctuate with time and congestion, but you can always check the current estimated L2 gas price on the [public Optimism dashboard](https://public-grafana.optimism.io/d/9hkhMxn7z/public-dashboard?orgId=1&refresh=5m).
### The L1 data fee
Optimism differs from Ethereum because all transactions on Optimism are also published to Ethereum.
This step is crucial to the security properties of Optimism because it means that all of the data you need to sync an Optimism node is always publicly available on Ethereum.
It's what makes Optimism an L2.
Users on Optimism have to pay for the cost of submitting their transactions to Ethereum.
We call this the **L1 data fee**, and it's the primary discrepancy between Optimism (and other L2s) and Ethereum.
Because the cost of gas is so expensive on Ethereum, the L1 data fee typically dominates the total cost of a transaction on Optimism.
This fee is based on four factors:
1. The current gas price on Ethereum.
2. The gas cost to publish the transaction to Ethereum. This scales roughly with the size of the transaction (in bytes).
3. A fixed overhead cost denominated in gas. This is currently set to 2100.
4. A dynamic overhead cost which scales the L1 fee paid by a fixed number. This is currently set to 1.0.
You can read the parameter values from the [gas oracle contract](https://explorer.optimism.io/address/0x420000000000000000000000000000000000000F#readContract).
::: warning NOTE
Ethereum has limited support for adding custom transaction types.
As a result, unlike the L2 execution fee, **users are not able to set limits for the L1 data fee that they may be charged**.
The L1 gas price used to charge the data fee is automatically updated when new data is received from Ethereum.
**Spikes in Ethereum gas prices may result in users paying a higher or lower than estimated L1 data fee, by up to 25%.**
[See here for a detailed explanation why the difference is capped at 25%](https://help.optimism.io/hc/en-us/articles/4416677738907-What-happens-if-the-L1-gas-price-spikes-while-a-transaction-is-in-process).
:::
## Stuff to keep in mind
### Sending transactions
The process of sending a transaction on Optimism is identical to the process of sending a transaction on Ethereum.
When sending a transaction, you should provide a gas price greater than or equal to the current L2 gas price.
Like on Ethereum, you can query this gas price with the `eth_gasPrice` RPC method.
Similarly, you should set your transaction gas limit in the same way that you would set your transaction gas limit on Ethereum (e.g. via `eth_estimateGas`).
### Responding to gas price updates
Gas prices on L2 default to 0.001 Gwei but can increase dynamically if the network is congested.
When this happens, the lowest fee that the network will accept increases.
Unlike Ethereum, Optimism currently does not have a mempool to hold transactions with too low a fee.
Instead, Optimism nodes will reject the transaction with the message `Fee too low`.
You may need to handle this case explicitly and retry the transaction with a new gas price when this happens.
### Displaying fees to users
Many Ethereum applications display estimated fees to users by multiplying the gas price by the gas limit.
However, as discussed earlier, users on Optimism are charged both an L2 execution fee and an L1 data fee.
As a result, you should display the sum of both of these fees to give users the most accurate estimate of the total cost of a transaction.
[See here for a code sample using the JavaScript SDK](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/sdk-estimate-gas)
#### Estimating the L2 execution fee
You can estimate the L2 execution fee by multiplying the gas price by the gas limit, just like on Ethereum.
#### Estimating the L1 data fee
You can use the SDK [(see here)](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/sdk-estimate-gas).
Alternatively, you can estimate the L1 data fee using the `GasPriceOracle` predeployed smart contract located at [`0x420000000000000000000000000000000000000F`](https://explorer.optimism.io/address/0x420000000000000000000000000000000000000F).
[The `GasPriceOracle` contract](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/predeploys/OVM_GasPriceOracle.sol) is located at the same address on every Optimism network (mainnet and testnet).
To do so, call `GasPriceOracle.getL1Fee(<unsigned RLP encoded transaction>)`.
#### Estimating the total fee
You can estimate the total fee by combining your estimates for the L2 execution fee and L1 data fee.
### Sending max ETH
Sending the maximum amount of ETH that a user has in their wallet is a relatively common use case.
When doing this, you will need to subtract the estimated L2 execution fee and the estimated L1 data fee from the amount of ETH you want the user to send.
Use the logic described above for estimating the total fee.
You'll get this error when attempting to send a transaction and you don't have enough ETH to pay for the value of the transaction, the L2 execution fee, and the L1 data fee.
You might get this error when attempting to send max ETH if you aren't properly accounting for both the L2 execution fee and the L1 data fee.
### Gas price too low
- Error code: `-32000`
- Error message: `gas price too low: X wei, use at least tx.gasPrice = Y wei`
This is a custom RPC error that Optimism returns when a transaction is rejected because the gas price is too low.
See the section on [Responding to gas price updates](#responding-to-gas-price-updates) for more information.
### Gas price too high
- Error code: `-32000`
- Error message: `gas price too high: X wei, use at most tx.gasPrice = Y wei`
This is a custom RPC error that Optimism returns when a transaction is rejected because the gas price is too high.
We include this as a safety measure to prevent users from accidentally sending a transaction with an extremely high L2 gas price.
See the section on [Responding to gas price updates](#responding-to-gas-price-updates) for more information.
How do you use your favorite tools for building contracts when you're working with Optimism?
Just use them!
<!--
TODO: We need a page on EVM equivalence.
-->
Optimism isn't just EVM compatible, it's EVM *equivalent*.
All the Ethereum tooling you know and love should work on Optimism without lots of fiddling.
Hardhat? Brownie? Truffle?
Yep, yep, and yep.
If you find a tool that *doesn't* seem to work with Optimism out of the box, try [opening an issue over on GitHub](https://github.com/ethereum-optimism/optimism/issues).
Someone working on Optimism will probably help fix the issue pretty quickly.
## Hardhat
Configuring Hardhat to deploy your contracts to Optimism is a breeze.
Simply add the following to your Hardhat config file:
```js
module.exports={
networks:{
...
// for mainnet
'optimism':{
url:"https://mainnet.optimism.io",
accounts:[privateKey1,privateKey2,...]
},
// for testnet
'optimism-goerli':{
url:"https://goerli.optimism.io",
accounts:[privateKey1,privateKey2,...]
},
// for the local dev environment
'optimism-local':{
url:"http://localhost:8545",
accounts:[privateKey1,privateKey2,...]
},
},
...
}
```
## Foundry
[Foundry](https://www.paradigm.xyz/2021/12/introducing-the-foundry-ethereum-development-toolbox) is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.
returnnewHDWalletProvider('test test test test test test test test test test test junk','http://localhost:8545')
}
network_id:"420"
}
},
...
}
```
## Brownie
[Brownie](https://github.com/eth-brownie/brownie) is a Python-based development and testing framework for EVM smart contracts. Brownie supports Optimism out of the box!
## Waffle
Starting from [Waffle](https://github.com/TrueFiEng/Waffle) v4.x.x you can use Waffle chai matchers to test your smart contracts on Optimism. We recommend following [this guide](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/getting-started)(scroll down to `Waffle` section) to get to know [Waffle](https://github.com/TrueFiEng/Waffle).
If you want to add [Waffle](https://github.com/TrueFiEng/Waffle) to an already existing project, you can install it with (replace `npm install` with the package manager's you're using relevant command):
<iframesrc="https://www.youtube.com/embed/_Y6CwsYgqwI"title="Getting Started with Optimism"frameborder="0"allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"allowfullscreen></iframe>
## ETHOnline 2022 | Optimism Summit
September 22nd, 2022
### Modular OP Stack - Karl Floersch
This talk covers the OP Stack chain software, and how the Bedrock release will enable deployments of op-chains which serve new use cases, are future proof, and will all one day fit together to form the Superchain.
<iframesrc="https://www.youtube.com/embed/jlKPjiDu_KM?list=RDCMUCfF9ZO8Ug4xk_AJd4aeT5HA"title="Modular OP Stack - Karl Floersch"frameborder="0"allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"allowfullscreen></iframe>
### Introduction to Architecture - Joshua Gutow
This talks covers bedrock’s architecture. It explains how redesigning the rollup architecture in bedrock reduces fees & increases implementation simplicity. It also covers the various components of the system & how they interact.
In this talk protolambda explains how the next Optimism upgrade improves the rollup with modular design, and how this can be utilized to quickly adopt future scaling improvements like EIP-4844 (a.k.a. proto-danksharding).
OP Labs is contributing to L1 research and development to increase the data availability used for securing all L2s.
<iframesrc="https://www.youtube.com/embed/-xWpalvZeEU?list=PLXzKMXK2aHh4vbe7GLQfOnL-QJ1O5EqMv"title="Pluggable data availability - Protolambda"frameborder="0"allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"allowfullscreen></iframe>
### Panel: State of 4844
The end game for data availability on Ethereum - Full Sharding - and how EIP-4844 gets us closer to that goal. This video discusses:
- Where we are with the implementation of EIP-4844 and what else was needed to be done before CFI.
- How the community could help us ship EIP-4844.
- Data Availability and the concept of a Data Availability Layer; analogous to the CL and EL. This concept helps reason about how data, i.e. the blobs, fits in Ethereum.
<iframesrc="https://www.youtube.com/embed/uxYkGdCFsjI?list=PLXzKMXK2aHh4vbe7GLQfOnL-QJ1O5EqMv"title="Panel: State of 4844"frameborder="0"allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"allowfullscreen></iframe>
### Intro to Quix - Mark Dawson
The NFT ecosystem on Optimism is an exciting, growing space.
Mark Dawson is the co-founder of Quix, the largest NFT marketplace on Optimism.
He discusses early NFT communities on Optimism, the upcoming NFT bridge, composable NFTs, and how to get started in the OP NFT ecosystem.
<iframesrc="https://www.youtube.com/embed/Z8L8vNDgJjY?list=PLXzKMXK2aHh4vbe7GLQfOnL-QJ1O5EqMv"title="Intro to Quix - Mark Dawson"frameborder="0"allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"allowfullscreen></iframe>
The [Optimism Collective](https://app.optimism.io/announcement) is a band of companies, communities, and citizens working together to reward public goods and build a sustainable future for Ethereum.
Together we will dispel the myth that public goods cannot be profitable.
Public goods (including public goods for Optimism and Ethereum) often go underfunded when incentives aren't properly aligned, forcing many to make trade-offs between earning a profit and building for the common good.
The Optimism Collective is bound by a mutually beneficial pact, [a vision](https://www.optimism.io/vision) that can be summed up with the equation **Impact = Profit**.
### Impact = Profit
The Optimism Collective will deploy a new model for rewarding those who create or sustain public goods - [retroactive public goods funding](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), to support projects and communities building for the common good.
Retroactive public goods funding is advantageous because it is relatively easy to agree on what *is* useful, and see who built it.
It is a lot harder to identify in advance what *will be* useful, and which team will do the best job of building it.
The possibility of an eventual exit payment can also encourage investors to fund initial public good development efforts until the usefulness is obvious, in the same way that the possibility of an eventual IPO or buy out encourages investors to fund startups today.
### How is this going to be governed?
The Optimism Collective takes [an experimental and agile approach to governance](https://optimism.mirror.xyz/r888e4B5iiNQi-3_mO26ixgv-plQ099XWgqEOv9iWKA) relentlessly iterating towards a system which stands the test of time.
Initially, the Collective's model of digital democratic governance will consist of two houses: the *Token House* and the *Citizens' House*.
## Token House
Governance of the Optimism Collective began with the launch of the OP token and the [Token House](token-house.md).
OP was distributed to hundreds of thousands of addresses that engaged in positive-sum, community-oriented behavior with [Airdrop #1](airdrop-1.md).
You can read more about the [distribution criteria here](airdrop-1.md).
As Token House members, OP holders are responsible for submitting, deliberating, and voting on various types of governance proposals.
In carrying out these functions, OP holders may either [vote directly, or delegate their OP voting power to an eligible third party](delegate.md).
The Token House votes on these proposal types:
-[Governance fund](gov-fund.md) grants
- Protocol upgrades
- Inflation adjustment
- Director removal
- Treasury appropriations
- Rights protection
[Read here for more details](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types).
## Citizens' House
The Citizens' House is a large-scale experiment in [non-plutocratic governance](https://vitalik.ca/general/2021/08/16/voting3.html) and retroactive funding of public goods.
The Citizens' House is responsible for [retroactive public goods funding (RPGF)](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c).
For more information about the Citizens' House, read [the Overview](./citizens-house.md).
For details about RetroPGF 2, visit [the RetroPGF 2 program details](./retropgf-2.md).
For plans around identity and governance, see [the Citizenship page](./citizenship.md).
**What is described here is an initial experiment**.
The specifics of this system will evolve as the Collective grows.
The Optimism Foundation’s Airdrop #1 rewards those who have been instrumental as early adopters and active users of projects in the Optimism ecosystem.
To celebrate our Ethereum roots, The Optimism Foundation also wants to welcome active L1 participants who can help scale Ethereum’s innovations, culture, and values to Layer 2.
In total, **248,699** addresses are eligible to claim OP in this *initial* airdrop.
Our airdrop has six sets of criteria.
Two for Optimism users that target early adopters and active project users, and four for L1 Ethereum, which target active contribution, positive-sum behaviors, and active participation.
Each set is distinct, meaning that an address can be eligible for multiple and allocated a sum of tokens accordingly.
A snapshot of addresses was taken on 03-25-2022 0:00 UTC.
The allocations and criteria break down as follows:
## Airdrop #1 Allocations
| Name | # of Addresses Eligible | OP Allocated per Address |
| Overlap Bonuses | # of Addresses Eligible | OP Allocated per Address
| - | -: | -:
| 4 Categories & OP User | 2,707 | 4,180.54
| 5 Categories & OP User | 627 | 13,330.16
| 6 Categories & OP User | 45 | 27,534.98
The amount of OP tokens that an address receives is cumulative, meaning that the sum of OP tokens allocated for each matching criteria set is the amount that an address is eligible to claim (overlap bonuses are not cumulative).
### Optimism Early Adopters
The Foundation sought to identify Optimism users who had actively used applications on Optimism as a part of their crypto experience.
#### Optimism Users
This group selects for addresses that have used Optimism, including both early adopters and newer users, but narrows down to a group that has used Optimism multiple times.
*Criterion: Address bridged to Optimism from L1 during the early phases of mainnet (prior to Jun 23, 2021), or used Optimism for more than 1 day (at least 24 hours between their first and last transaction) and made a transaction using an app (after to Jun 23, 2021).*
-*These rules are only based on usage on Optimism. It does not matter which bridge, exchange, fiat on-ramp, etc you used in order to come to Optimism.*
#### Repeat Optimism Users
This tier selects for the most active Optimism users, who repeatedly come back to use applications in the Optimism ecosystem.
*Criterion: Address is an ‘Optimism User’ and made at least 1 transaction with an Optimism application across four or more distinct weeks. This selects for the top 20% of ‘Optimism Users’.*
-*"Distinct weeks" are counted based on the time of an addresses' first transaction (i.e. days 1 - 7 are considered Week 1, not the calendar week). This makes sure that there is no skew by which day of the week an address joined Optimism.*
### Active Ethereum Participants
These rules aim to target behaviors that match Ethereum and Optimism’s values of active contribution, positive-sum behavior, and scaling decentralized applications to the world.
#### DAO Voters
The Foundation believes that active and engaged governance is crucial to scaling decentralized systems.
Addresses who match this criterion have actively chosen to actively contribute by participating in governance.
*Criterion: Address has either voted on or authored at least one proposal on-chain, or at least two on Snapshot (off-chain).*
-*We filtered to “active DAOs” who have had at least 5 proposals with at least 5 votes.*
-*On-Chain governance contracts included: Governor Alpha and Bravo, Aave, Curve, Maker, Aragon, DAOHaus, DAOStack, and forks.*
-*Since Snapshot votes were off-chain, the Foundation recognized that these were more susceptible to spam/farming behavior, often driven by voters with nominal voting power.
To mitigate this, we filtered Snapshot votes to voters who made up the top 99.9% of total voting power in each DAO (i.e. >= 0.1% of voting power was made up by the sum of all smaller voters).*
#### Multi-Sig Signers
Multi-sig signers are entrusted with larger pools of capital or control over key protocol functions.
They are often the present (and future) DAO leaders and builders.
*Criterion: Address is a current signer on a Multi-Sig which has executed at least 10 transactions all-time (this cohort includes 95% of all multisig transactions).*
-*Multisig Wallets Include: Gnosis Safe v0.1.0-1.3.0, MultiSigWithDailyLimit, MultiSigWalletWithTimeLock, and addresses in Etherscan’s ‘Multisig’ label which had a function to get owner addresses.*
#### Gitcoin Donors (on L1)
Gitcoin donors have chosen to behave in positive-sum ways by funding public goods.
These addresses may also align with Optimism’s goal to build sustainable funding source for public goods through [retroactive funding (RetroPGF](https://medium.com/ethereum-optimism/retropgf-experiment-1-1-million-dollars-for-public-goods-f7e455cbdca)).
*Criterion: Address has made an on-chain donation through Gitcoin on L1. This includes any donation, regardless of if it was during a matching round.*
-*For the time period between rounds 1 - 5, we included addresses who interacted with Gitcoin contracts, sent legacy `ExecuteSubscription` calls, or appeared in [Gitcoin’s donor API](https://docs.gitcoin.co/mk_rest_api/).*
-*For the period between rounds 6 - 13 (present), we included donor addresses in the Gitcoin ‘BulkCheckout’ contract transaction logs.*
#### Users Priced Out of Ethereum
Active users of dapps on Ethereum are critical to ecosystem growth. Many of these addresses have started bridging to other chains due to high fees, and we want to help retain them in the Ethereum ecosystem while rewarding their curiosity and exploration. Optimism’s airdrop is also calibrated to reward loyalty to Ethereum, so users who have abandoned Ethereum entirely would not receive an airdrop.
*Criterion: Address bridged to another chain, but still made an app transaction on Ethereum in each month after they bridged, and transacted at an average rate of at least 2 per week since then (top 60% of matching addresses).*
-*Bridges included top L1s by TVL: Terra, BSC, Fantom, Avalanche, Solana, Polygon; and general-purpose L2s: Arbtirum, Optimism, Metis, Boba.*
-*To ensure that we gave a long enough period to sample activity, addresses had to have bridged away from Ethereum at least 90 days before the snapshot.*
### Overlap Bonus
Early Optimism users who also match multiple Ethereum criteria may be most likely to become important participants in the Optimism ecosystem, so these addresses were rewarded with an extra overlap bonus.
*Criterion: Address matches an ‘Optimism Early Adopter’ criterion, and matches at least 4 criteria sets in total (including Optimism criteria).*
-*The overlap bonus increases as more criteria are matched (i.e. the bonus for 5 criteria is greater than the bonus for 4 criteria)*
### Global Filtering Criteria
We believe that it’s best for the community for our airdrop list narrows as well as possible to real users and honest actors.
So we applied some basic filters to various criteria:
-**Address Activity:** Addresses needed to have used Ethereum for more than 1 day (24 hours between their first and last transaction) in order to qualify for ‘Active Ethereum Participants’ criteria.
This applied to all Ethereum criteria except for multisig signers, since it’s common for signers to have “signing-only” addresses.
-**Sybil Farmers:** We identified a few patterns of likely sybil attackers, who often created tens, hundreds, or more duplicate addresses.
We required stronger activity criteria for these addresses, which helped filter out these attackers, but also preserved many real users.
It’s impossible to catch everything, but removing as many sybillors as we can help get more OP in the hands of true positive-sum participants.
-**Snapshot Bots and Spam:** We used [ENS’ bot-catching proposal](https://snapshot.org/#/ens.eth/proposal/QmfLwPbo5UwnyvkXo7emsSMDMFCr8UtJ76n87v9Rf7gEuH) to filter out addresses that spam Snapshot votes. Snapshot spaces that appeared to be either compromised or falsified were also excluded.
-**Exchanges and On-Ramps:** We filtered our known centralized exchange and fiat on-ramp addresses.
-**Exploiters:** Known exploit addresses were filtered out.
-**Recency Filter:** Addresses needed to have made a transaction after Jan 1, 2019.
For multisig signers, only the multisig needed to have executed a transaction after Jan 1, 2019.
We chose this cutoff date to narrow in on active addresses, while also providing a window before [L1 gas prices](https://etherscan.io/chart/gasprice) consistently rose and potentially priced some users out of Ethereum.
### Additional Sybil Filtering
Optimism is for the people, not the sybils.
After the announcement of Airdrop #1, we received limited reports of sybil activity that was not excluded by our initial filtering.
We have since applied additional filtering to Airdrop #1 that excludes 17k addresses and recovers 14m OP.
Recovered OP will be redistributed proportionally to remaining addresses already included in Airdrop #1.
The [Airdrop #1 Allocations](#airdrop-1-allocations) table above has been updated accordingly to reflect this.
For a list of excluded sybil addresses, [see this spreadsheet](https://docs.google.com/spreadsheets/d/1kUAt-vrkID0yBkic72djWRxdliK8W_5rBGxq6-Iv3cg).
In the interest of maintaining the integrity of future OP Airdrops, we will not be publishing the additional filters used to remove these addresses.
If you have feedback about this additional sybil filtering process, please feel free to [fill out this feedback form](https://oplabs.typeform.com/sybil-feedback).
## What’s Next?
To check your eligibility for Airdrop #1 and claim your tokens visit [the airdrop app](https://app.optimism.io/airdrop/check).
We made our best effort to make Airdrop #1 as fair as possible.
However, there’s always a chance some great community members may have slipped through the cracks.
Don’t worry!
This is Airdrop #1, and 14% of the total initial token supply is reserved for future airdrops.
The best way to earn OP is to get involved in the Optimism Collective:
- If you want to build on Optimism, visit our [developer documentation](../developers/README.md) or jump in to [Discord](https://discord-gateway.optimism.io).
- If your talents are non-technical, jump in to [Discord](https://discord-gateway.optimism.io) to find other builders, apply to be a Support NERD, or just make some memes 🍉
-[Bridge your assets to Optimism here](https://app.optimism.io/bridge) and explore projects on OP
As always: stay safe and stay Optimistic.
## References
-**Application Transaction:** Any transaction, excluding token transfer and approval transactions.
-**Optimism on Twitter:**[https://twitter.com/optimismFND](https://twitter.com/optimismFND)
-**Join the Optimism Discord:**[https://discord-gateway.optimism.io/](https://discord-gateway.optimism.io/)
-**CSV with the list of airdropped addresses:**[publish_op_airdrop1.csv](https://drive.google.com/file/d/1VVcHGHNMLeyRQMHcfkzT4fVbU2xPeT1X/view?usp=sharing)
| Ecosystem Fund | 25% | The Ecosystem Fund is a proactive program meant to stimulate development in the Collective ecosystem by providing funding to projects and communities |
| Retroactive Public Goods Funding (RetroPGF) | 20% | RetroPGF is the Optimism Collective’s primary mechanism to adequately and reliably **reward** public goods for the impact they provide |
| User airdrops | 19% | A series of airdrops to reward users for specific helpful behaviors, beginning with Airdrop #1 |
| Core contributors | 19% | The people who’ve been working tirelessly to bring the Optimism Collective into existence |
| Sugar xaddies | 17% | Investors |
## User Airdrops
***Allocation: 19%***
The Optimism Foundation will distribute a portion of the OP allocation to members of the Optimism and Ethereum communities in multiple waves.
### Airdrop #1
The first user airdrop will distribute **5%** of the OP token supply.
This airdrop is targeted towards people who:
- Behave in positive-sum ways.
- Contribute actively to their communities.
- Have been priced out of Ethereum.
The addresses and amounts were chosen to reward Optimism users, as well as attract core Ethereum users to the OP family.
Airdrop #1 cast a wide net to distribute OP to more than 250k addresses. See the [Airdrop #1 documentation](airdrop-1.md) for a detailed breakdown of eligibility criteria.
### Future airdrops (#2, 3, …)
An allocation of **14%** of the OP token supply will be held in reserve for future user airdrops.
As a result of the game-able nature of airdrops, the Optimism Foundation will be responsible for determining airdrop metrics as fairly as possible.
The intent behind airdrops is to distribute them to addresses which positively impact the Optimism community.
The best way to improve your odds of receiving future airdrops is to get involved!
## Ecosystem Fund
***Allocation: 25%***
The Ecosystem Fund is an incentive program designed to stimulate development of the Collective ecosystem.
The Ecosystem Fund will be used to directly fund the communities and companies that drive the expansion of the Collective ecosystem (OPCOs).
The allocation dedicated to the Ecosystem Fund is to be further split into the following categories:
1. Governance Fund **(5.4%)**
2. Partner Fund **(5.4%)**
3. Seed Fund **(5.4%)**
4. Unallocated **(8.8%)**
The Ecosystem Fund is intended to be a kick-starting mechanism that will be phased out entirely once the OP in the fund has been depleted.
The Optimism Foundation expects the function served by the Ecosystem Fund (proactive funding) to eventually be replaced by private third-party investors who can expect to be paid out by the [Retroactive Public Goods Funding](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) mechanism.
The wide variety of funding mechanisms ensures that airdrops constantly flow to users who make valuable contributions to the ecosystem.
These contributions result in ecosystem growth, ecosystem growth results in demand for block space, demand for block space results in revenues, and these revenues are then productively re-deployed into the ecosystem as additional airdrops.
Each fund can be thought of as a parallel experiment in OP allocation, enabling rapid iteration and doubling down on what works to further grow the ecosystem.
### Governance Fund
An allocation of **5.4%** of the OP token supply will be dedicated to the first Governance Fund.
All projects demonstrating usage on Optimism can request tokens from this fund at [gov.optimism.io](https://gov.optimism.io/)
### Partner Fund
An allocation of **5.4%** of the OP token supply will be dedicated to the Partner Fund.
These funds will be distributed strategically by the Optimism Foundation to grow the Optimism ecosystem for the benefit of the entire Collective.
### Seed Fund
An allocation of **5.4%** of the OP token supply will be dedicated to the Seed Fund, a fund for early stage projects launching in and adjacent to the Optimism ecosystem.
### Unspent allocation for future growth programs
An allocation of **8.8%** of the OP token supply will be held in reserve for future community growth programs.
## Retroactive Public Goods Funding
***Allocation: 20%***
[Retroactive Public Goods Funding (RetroPGF)](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c) will initially be distributed by the [Citizens' House](citizens-house.md).
RetroPGF rounds are expected to occur on a quarterly basis with the objective of ensuring that all OPCOs are rewarded adequately, appropriately, and reliably based on their impact to the Collective—key to our [vision](https://optimism.io/vision).
RetroPGF will be funded by several revenue sources:
1. 20% of the initial OP token supply held as the “RetroPGF Reserve”.
1. Optimism network transaction fees and sequencer revenue.
The Optimism Foundation may choose to increase the total OP payout of any given period by tapping into the 20% RetroPGF Reserve.
## Core Contributors
***Allocation: 19%***
The Core Contributors allocation will be distributed to the people who helped bring Optimism and the Optimism Collective from concept to reality, and will continue to pay for development of the protocol.
All tokens distributed as part of the Core Contributors allocation will be subject to a lockup period.
## Sugar Xaddies
***Allocation: 17%***
Investors.
They funded us and our crazy vision for the future.
Couldn’t-a done it without ya.
All tokens distributed as part of the Sugar Xaddies allocation will be subject to a lockup period.
## Token Distribution Details
At genesis there will be an initial total supply of 4,294,967,296 OP tokens.
The total token supply will inflate at a rate of 2% per year.
64% of the initial token supply (i.e., the aggregate amount of OP **not** reserved for core contributors or sugar xaddies) will be distributed to the community as described above.
These distributions will be administered over time by the Optimism Foundation in its role as steward of the Optimism Collective.
In Year 1, 30% of the initial token supply will be made available to the Foundation for distribution.
After the first year, token holders will vote to determine the Foundation’s annual OP distribution budget.
The Foundation expects to seek the following annual allocations:
- Year 2: 15% of the initial token supply
- Year 3: 10% of the initial token supply
- Year 4: 4% of the initial token supply
If the Foundation’s authorized OP expenditures ever reaches below 10% of the initial token supply, it is expected to request an additional allocation.
Taken together, the Foundation expects the total supply of unlocked OP tokens to approximate the graph below.
Note this graph is for illustration only, and actual unlocked supply will depend on governance and the rate that OP is allocated across user airdrops, the Ecosystem Fund, and RetroPGF.
The AttestationStation is an **attestation smart contract** deployed on Optimism.
The goal of the AttestationStation is to provide a permissionless and accessible data source for builders creating reputation-based applications. By enabling anyone to make arbitrary attestations about other addresses, we can create a rich library of qualitative and quantitative data that can be used across the ecosystem.
<!-- TODO: Add source code link when we have an authoritative source -->
## General FAQ
#### What are attestations?
Attestations are statements by a creator (who attested this) about a subject (who is being attested about). Attestations could present any qualitative or quantitative statement. To paint a picture — actors might submit attestations that are contextual to their brand, ecosystem, and governance structure.
We imagine the first use case for attestations is to create sybil resistant identity that can power [non-plutocratic governance](https://vitalik.ca/general/2021/08/16/voting3.html).
Longer term, this open-source primitive can be used for a variety of sybil-resistant applications including on-chain credit scoring / under collateralized loans.
#### How can you go from attestations to sybil-resistant identity?
Attestations in the AttestationStation are on-chain and can be used by other smart contracts in a variety of applications. Instead of having a single entity owning user data and identity, the AttestationStation is a graph of peer-to-peer (p2p) attestations.
The first step to get from attestations to sybil-resistant identity is to grow the number of attestations in the AttestationStation. To do that, we are taking a two pronged approach by growing the number of:
***Trusted attestations**: These attestations are made by organizations like Gitcoin, DegenScore, Otterspace, etc. attest about individual community members.
***Social attestations**: These are attestations from one address about another. Eg zain.eth says kathy.eth is a colleague, kathy.eth says will.eth is a friend, etc.
Anyone can then take the graph of p2p attestations from the AttestationStation and run computations like EigenTrust over the set of data to derive identity sets on top of a purely subjective web of trust.
To build a robust, trustworthy identity network, these computations will be run iteratively. We can start with a purely subjective web of trust, and use that starting point to derive a larger web of trust, and so on — we can begin to establish a credibly neutral reputation that is entirely peer-to-peer.
#### How is the AttestationStation different from other attestation products?
The AttestationStation is deliberately dead simple and serves as an invite to ecosystem contributors to come build an open-source and permissionless attestation graph together.
Creating this system in a decentralized and open-source manner is important because it allows for greater inclusion and representation of different perspectives. This can help to ensure that the system is fair and accessible to all, and that it accurately reflects the diversity of the communities it serves.
#### How do I use the AttestationStation?
See [the tutorial](https://github.com/ethereum-optimism/optimism-tutorial/tree/main/ecosystem/attestation-station).
#### What are the contract addresses for the AttestationStation?
#### What products are built on the AttestationStation?
If your product is using the AttestationStation, make a PR including how you're using attestations to be added to the list 😊
*[AttestationStation Interface by sbvegan](https://attestationstation.xyz/)
*[Optimist Score by Flipside](https://science.flipsidecrypto.xyz/optimist/)
*[Optimism Attestor by Clique](https://provenance.clique.social/attestor/opattestor)
#### I am building on the AttestationStation but have some questions, where can I discuss these?
The best place to ask any dev related questions is the #dev-support channel on [the Optimism Discord](https://discord-gateway.optimism.io/). If you need additional support check out this [Help Article](https://help.optimism.io/hc/en-us/articles/9762044018843-How-do-I-get-project-support-marketing-integrations-etc-).
#### I want to apply for a grant to build on the AttestationStation, how can I do this?
You can learn more about the variety of grants program available at Optimism [here](allocations/#ecosystem-fund). As a reminder, your work should be published to a public GitHub repo.
#### What are some things I should build with the AttestationStation?
It will take a huge community effort to realize the potential that reputation has to transform web3. That’s why we started small with the AttestationStation and an open invite to come experiment with us. We can already think of a bunch of fun projects to build today like:
***EiganTrust**: Aggregate attestations from various communities and use techniques like [EigenTrust](https://en.wikipedia.org/wiki/EigenTrust) to derive reputation
***SybilRank**: Create a [SybilRank](https://users.cs.duke.edu/~qiangcao/sybilrank_project/index.html) calculator! (h/t Barry Whitehat for the suggestion)
***Data visualization**: Create data visualizations representing the different types of attestations in the AttestationStation
***Predictive attestations**: Instead of attesting “I trust XYZ”, try fun attestations like, “I believe XYZ will be considered trusted by a majority of node in the future”. Plus, what if we add a slashing condition to the predictive attestation?
***Attestation delegation**: Build a system which manages attestations automatically for users. This system should enable users to delegate some of their attestation assignment to a third party. For instance, users may opt-in to delegating their trust scores to a sybil detection court system. Another project is to build that sybil detection court system!
***Attestation import**: Write proxy contracts which import attestations of various formats into the standardized AttestationStation format so that they can be consumed by the standard AttestationStation tooling.
***Viral attestations**: Create systems which make it fun and easy for users to attest useful information about each other.
***Composable NFT allowlists**: Create a way for creators to easily build, manage, and share mint allowlists for upcoming NFT drops!
## Technical specifications
The following is the breakdown of Optimism's AttestationStation smart contract.
### State
#### attestations
The following is the nested mapping that stores all the attestations made.
```
mapping(address => mapping(address => mapping(bytes32 => bytes))) public attestations;
```
The following is a struct that represents a properly formatted attestation.
#### AttestationData
```
struct AttestationData {
address about;
bytes32 key;
bytes val;
}
```
### Events
#### AttestationCreated
This event is emitted when an attestation is successfully made.
```
event AttestationCreated(
address indexed creator,
address indexed about,
bytes32 indexed key,
bytes val
);
```
### Functions
#### attest
```
function attest(AttestationData[] memory _attestations) public
```
Records attestations to the AttestationStation's state and emits an `AttestationCreated` event with the address of the message sender, address the attestation is about, the bytes32 key, and bytes value.
The Citizens' House is a large-scale experiment in [non-plutocratic governance](https://vitalik.ca/general/2021/08/16/voting3.html) and retroactive funding of public goods.
The Citizens’ House will work alongside the Token House to govern the Optimism Collective.
**In its first stage, the Citizens’ House is solely responsible for voting on retroactive public goods funding (RetroPGF)**.
The initial set of Citizens in this stage is determined by (a) criteria set by the Optimism Foundation and (b) a special election from the Token House.
During this bootstrapping phase, the Optimism Foundation will determine the scope and amount of each funding round, as well as administer the voting process.
Holding a voting badge in this initial set of Citizens **does not guarantee permanent citizenship** or voting rights in all future rounds of RetroPGF.
In future stages, the Citizens’ House role will expand.
For example, in addition to voting on RetroPGF funding, the Citizens’ House will work alongside the Token House to govern allocation of protocol profit, collaborate on criteria for participation in the Citizens’ House, and engage in a system of checks and balances to enforce the Collective’s Codes of Conduct.
Funding for RetroPGF can come from:
-**[20% of the initial OP supply](./allocations.md#retroactive-public-goods-funding)**
- Redeployment of some profit generated by the Optimism protocol
Many values-aligned projects on Optimism have also chosen to contribute a portion of their revenue to retroPGF.
If your project wants to contribute funds, you can send ETH, ERC-20 tokens, or NFTs to the ENS address **retroPGF.eth**.
It is supported on **[Optimism](https://explorer.optimism.io/address/0x15dda60616ffca20371ed1659dbb78e888f65556)** as well as **[Ethereum mainnet](https://etherscan.io/address/0x15dda60616ffca20371ed1659dbb78e888f65556)**.
Everything donated retroPGF.eth will be allocated to a RetroPGF round.
**What is described here is an initial experiment for RetroPGF 2**. The specifics of this system will evolve as the Collective grows.
## How RetroPGF Works
RetroPGF stands for Retroactive Public Goods Funding.
This is a series of experiments where members of the Citizens’ House allocate protocol profits or portions of the token treasury to projects they deem have provided substantial public good along certain criteria.
RetroPGF is based on the idea that it’s easier to determine what *was* useful than to issue proactive grants for what *might* be useful.
In each round of RetroPGF, Citizens vote on how to allocate funding looking backwards over a prescribed time period.
These rewards create strong incentives for people to build public goods that benefit the Optimism Collective.
The aggregate effect is an ecosystem that is easier to build on, learn about, and connect to, in turn driving application usage and generating more demand for blockspace.
By funding public goods sustainably, the Collective can create a rich ecosystem and a better economy.
RetroPGF also provides possible exit liquidity for public goods projects, which opens up a market for early investment in those projects.
This means builders can:
- Be compensated for their positive contributions without generating direct revenue
- Raise capital to bootstrap based on the early potential and promise of their project
RetroPGF is core to Optimism’s value of `impact = profit`: the idea that that positive impact to the collective should be rewarded with profit to the individual.
In 2021, Optimism ran its [first round of RetroPGF](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c).
Community members voted to distribute $1 million across 58 open source software projects.
RetroPGF 2 takes place in Jan 2023. Read more [here](./retropgf-2.md).
## A Commitment to Experimentation
RetroPGF is a longterm bet to build the future Optimists want to see.
The Collective will conduct regular rounds of RetroPGF, each different from the last.
This is an emergent process that will take community participation to grow and prune.
RetroPGF has three core components, each with substantial surface area for experimentation.
1.**Impact scoping**: what should the Collective fund?
How is it defined and decided on?
1.**Impact scoring:** how does the Citizens’ House evaluate impact?
What units, process, or tools do we use?
1.**Impact settlement:** how does voting work?
For the first several rounds of RetroPGF, the Optimism Foundation will decide on scope and voting mechanics with input from the community.
Eventually the set of variables around what to fund, how much to fund, and how to vote will be up to the Citizens’ House, with checks and balances from the Token House.
Over time, the Collective aims to expand the scope of RetroPGF to support the production of public goods beyond the immediate Optimism ecosystem.
To get there, we must refine the tools and processes used for RetroPGF based on regular experimentation.
The Citizens’ House relies on the concept of identity-based governance.
This is distinct from the more common pattern of token-voting governance (as used in [Optimism’s Token House](./token-house.md)).
To start, the initial set of Citizens in this stage is determined by (a) criteria set by the Optimism Foundation and (b) a special election from the Token House.
Citizenship is conferred by a simple entry in the [AttestationStation](./attestation-station.md).
In future stages, the Token House and Citizens’ House together will collaborate on ongoing criteria for participation in the Citizens’ House.
This means the criteria for Citizenship will evolve over time.
Holding a voting badge in RetroPGF 2 does not guarantee voting rights in all future rounds of RetroPGF, as eventually membership will be determined by governance and may change.
How does this work?
- Optimism has a neutral, permissionless attestation contract called the [`AttestationStation`](./attestation-station.md)
- Optimism Governance (Token + Citizens’ House) has authority over a function that takes the AttestationStation as an argument and uses any data included to determine the set of Citizens.
Optimism governance can use any reputation data written to the AttestationStation contract to determine Citizenship in future iterations of the Citizens’ House.
This system is designed to be flexible and future-proof; rather than prescribe citizenship criteria at the outset, the Collective is keeping true to its principle of iterative governance.
For more information on Optimism's identity layer, visit the [AttestationStation documentation](./attestation-station.md).
## Becoming a Citizen
The Citizens’ House is initiated with the set of 90 voters in [RetroPGF 2](./retropgf-2.md).
Eventually, Citizenship is intended to be widely distributed to a large group of humans across the Optimism ecosystem with expertise in many different subcultures and industries.
Eventually, Optimism governance will have the power to set criteria for Citizenship.
This means voting eligibility may someday be subject to rules and restrictions unknown today.
**Voting in RetroPGF 2 does not guarantee permanent participation in the Citizens’ House and future iterations of RetroPGF.**
The next wave of Citizenships will be issued in advance of RetroPGF 3, later in 2023.
-[Identify your current delegate and view the delegate's voting record](https://help.optimism.io/hc/en-us/articles/6389519530779-How-do-I-see-how-my-delegate-voted-)
-[View information about specific delegates (their share of the votes, etc.)](https://dune.com/optimismfnd/optimism-op-token-house)
<!--
-[Delegate aggregate information (GINI coefficient, etc.)](https://app.flipsidecrypto.com/dashboard/optimism-governance-l5WXpo)
Participating in Token House governance can require a serious time commitment.
For this reason, people are able to delegate their OP to community members who have explicitly volunteered to play an active role in Token House governance.
Being a delegate is an important job that comes with a lot of responsibility.
Before deciding to become a delegate you should be familiar with:
* The [Working Constitution](https://gov.optimism.io/t/working-constitution-of-the-optimism-collective/55).
* The [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md).
* The [Delegate Code of Conduct](https://gov.optimism.io/t/delegate-code-of-conduct/3943)
## Ready to be a delegate?
This is the process to become a delegate:
### Step 1: Commit
* Read the delegate responsibilities
* Post a completed [delegate commitment form](https://gov.optimism.io/t/delegate-commitments/235).
If you have any questions about the form, ask in the [delegation questions feedback thread](https://gov.optimism.io/t/delegation-questions-feedback-thread/236)
* It is not required, but you probably also want to [delegate your OP tokens' voting power to yourself](https://app.optimism.io/delegates).
Please note that the expectation is that token grants **will not be** self-delegated to grant recipients.
### Step 2: Set up your profile
* Set up your delegate profile.
Please note that delegate avatars are taken from ENS.
[If you want to change your avatar, you’ll need to do it via ENS](https://medium.com/the-ethereum-name-service/step-by-step-guide-to-setting-an-nft-as-your-ens-profile-avatar-3562d39567fc).
The Optimism Foundation will add new profiles to the [delegate site](https://app.optimism.io/delegates) once per Season.
::: tip Notice: OP Airdrop #1 is now available to claim
[Click here to claim](https://app.optimism.io/airdrop/check)
*Airdrop #1 does not require payment.*
*Stay safe!*
:::
The Optimism Collective is based on the idea that healthy public goods create a thriving and valuable ecosystem.
The economics of this ecosystem are designed to generate value for three constituencies:
- Value accrues to **tokenholders** through the productive re-deployment of sequencer revenue.
Sequencer revenue is primarily directed to fund public goods, which creates ecosystem value and drives demand for blockspace.
- Value accrues to **contributors and builders** directly from retroactive public goods funding and the markets it enables.
Builders also benefit symbiotically: it’s better to build in an ecosystem with well-funded tools, education, apps, and infrastructure.
- Value accrues to **users and community members** from ongoing airdrops of OP, from project incentives made possible by OP ecosystem funding, and from the benefit public goods provide.
Funding for the OP economy comes from ownership of the Optimism network and the value of its blockspace.
Today, funding comes directly from the centralized sequencer, accruing to The Optimism Foundation for redistribution.
In the future, funding can accrue directly to the protocol by selling the right to participate in Optimism’s decentralized sequencing network.
Simply put: the right to blockspace is the sustainable source of revenue that drives OP’s economic model and grows with the network itself.
## Revenue is distributed to public goods
Communities benefit from all sorts of public goods, from education to city infrastructure to open source software.
But many markets fail to provide adequate funding and support for those public goods.
It’s here that Optimism takes a step forward, by building a sustainable funding source into the mechanisms of the network itself.
Direct or auctioned sequencer revenue is distributed back to the ecosystem primarily through Retroactive Public Goods Funding ([RetroPGF](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c)).
This creates strong incentives for individuals to build for the public good of the Optimism Collective.
To start, the Citizens’ House will vote quarterly on distributions of funds to individuals, teams, projects, or communities that have provided subjective value over a specified time period.
This directly rewards community members for the positive impact of their work.
RetroPGF also provides possible exit liquidity for public goods projects, which opens up a market for early investment in those projects.
This means builders can:
- Be compensated for their positive contributions without generating direct revenue.
- Raise capital to bootstrap based on the early potential and promise of their project.
In the long-term, the Foundation expects this mechanism to drive a wide range of pro-social downstream effects, which the Collective can capture and expand upon through frequent experimentation and iteration.
## Value from public goods drives demand for blockspace
Funding public goods drives growth — and therefore network revenues — from the ground up.
In our [first round](https://vitalik.ca/general/2021/11/16/retro1.html) of RetroPGF, Optimism funded a set of hugely valuable developer tools and core infrastructure.
The aggregate effect is an ecosystem that is easier to build on, learn about, and connect to, in turn driving application usage and generating more demand for blockspace.
But what value do these public goods provide, and for whom is it valuable?
This is a rich design space.
Optimism’s governance is designed to create conditions for experimentation around this question.
The Foundation draws heavily on the work of Ostrom, Vitalik, and others to make sure funding for public goods is maximally efficient, effective, and safe.
To start, Foundation governance is shared and divided through a two-house system, where network parameters for the amount of funding are controlled by both houses, but the governance of RetroPGF allocation is determined by a set of Citizens with local knowledge and skin in the game.
Thoughtful allocation of public goods funding will create longterm value for builders, users, tokenholders, citizens and the entire Optimism Collective.
This process is currently under construction for Season 3.
Check back soon for updated information.
:::
Thank you for being active in Optimism Token House Governance.
As a delegate, you should:
- Join the conversation in the below channels in our [Discord](https://discord-gateway.optimism.io/):
-[#gov-general](https://discord.com/channels/667044843901681675/968498307913637919): This channel is for general governance discussions.
-[#new-gov-temp-check](https://discord.com/channels/667044843901681675/1011238484373159956): This channel is where proposers post their proposal for early feedback.
As a delegate you should provide feedback on proposals consistently.
-[#token-house-gov](https://discord.com/channels/667044843901681675/991340698995544176): This announcement channel will help you keep up to date with big events in the governance process, such as when voting starts, meta-governance updates, etc
-[#delegate-discussion](https://discord.com/channels/667044843901681675/989611992295813241): If you are a delegate with more than 0.5% delegated voting power, join the conversation with other larger delegates to discuss proposals & the governance process.
- Provide feedback on draft proposals in the [Proposals Discussion](https://gov.optimism.io/c/proposals/38) section of the Forum
- If you have more than 0.5% of voting supply then you can also approve proposals.
Proposals need at least 2 approvals to move to a vote.
To approve a proposal post this phrase in a forum comment on Discourse:
> **I am an Optimism delegate with sufficient voting power and I believe this proposal is ready to move to a vote.**
- Vote on proposals via [Snapshot](https://snapshot.org/#/opcollective.eth).
Multi-sig support for votes coming soon.
- Post your voting rationale in a [Delegate Communications Thread](https://gov.optimism.io/c/governance/41)
- Join the community calls, which occur every other Tuesday at 1pm ET.
[The governance calendar](https://calendar.google.com/calendar/u/0/r?cid=Y180aHVpNzBpdG0wODllN3Q4cTUwaGVoMWtub0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t) shows which Tuesdays, and how to join the call.
- Stay up to date with voting cycles and general governance updates in the Governance section of the [Forum](https://gov.optimism.io/c/governance/41).
*[To discuss the Governance Fund, head to the Optimism governance forum](https://gov.optimism.io/t/governance-fund-discussion-thread/213)*.
## Overview
5.4% of the total initial token supply (231,928,234 OP) will be distributed to Optimism projects and communities via the Governance Fund.
The goal of the Governance Fund is to empower the OP community to proactively incentivize future growth of projects and communities in the Optimism ecosystem.
You can read more about the total allocation of OP in the [Allocations section](./allocations.md) of our [Governance docs](./README.md).
The purpose of the Governance Fund is to incentivize sustainable growth of projects and communities in the Optimism ecosystem.
This does not mean that all grants must be incentive programs.
The Token House is welcome to consider any and all proposals which would drive growth or address a gap in the Optimism ecosystem, including public goods projects.
Governance funds should come with an expectation of growth-related deliverables.
It is not the intended purpose of the governance fund to retroactively fund public goods without an expectation of future work.
There is [a distinct OP allocation](./allocations.md#retroactive-public-goods-funding) dedicated to this, which will be distributed via the Citizens' House at a later date.
## Phase 1
Phase 1 had begun after Airdrop #1 and distributes the remainder of the Governance Fund (approx. 196,128,233 OP) to projects in the Optimism ecosystem.
Phase 1 will continue until the Governance Fund is exhausted.
You can see how the Governance Fund has been distributed to date in [the Governance Tracker](https://docs.google.com/spreadsheets/d/1eaHOlWB34ij1KGsXdaNyTQg4tt1Pu2JurJsElBb6a8k/edit#gid=0).
Any project on Optimism can [submit a forum proposal](proposals.md) to request any amount of OP tokens.
The proposal must include a plan for how the tokens will incentivize growth on Optimism.
Proposals are reviewed and voted on by the [Token House](token-house.md).
When a project gets a proposal approved, they are still eligible to apply for further proposals.
The Optimism Foundation recommends that projects distribute their initial allocation of tokens before requesting further tokens.
Projects are also encouraged to reference data from the success of their initial distribution to strengthen their case in future proposals.
## Phase 0
Phase 0 was designed to reward existing projects that have driven growth of the Optimism ecosystem.
The amount of funding for each project was determined by a set of on-chain metrics, calculated via a snapshot of the Optimism chain on April 1, 2022 at 12:00am UTC.
To see live tracking on govFund allocations please see the [Public tracker spreadsheet](https://docs.google.com/spreadsheets/d/1eaHOlWB34ij1KGsXdaNyTQg4tt1Pu2JurJsElBb6a8k/edit#gid=0).
Participating in governance of the Optimism Token House can require a serious time commitment.
For this reason, people are able to delegate the voting power of their OP tokens to a community member who has explicitly volunteered to play an active role in Token House governance.
These volunteers are called delegates.
If you do not wish to delegate your voting power to a representative, you will still need to delegate *to yourself* in order to vote.
### How do I delegate my votes to a representative?
1.[Choose a delegate](https://app.optimism.io/delegates).
Take the time to read through delegate statements of interest, choosing your delegate is an important decision!
A healthy governance system is good for Optimism and for all OP holders. Choosing a good delegate is in each OP token holder's best interest.
This delegate will vote on your behalf.
You will not hold any voting power or execute your own votes but you will retain 100% ownership of your tokens, and can use them however you want.
View top delegates by voting weight on [Dune](https://dune.com/optimismfnd/optimism-op-token-house).
1.[Go to the delegates app](https://app.optimism.io/delegates) to see that you’ve delegated your tokens as intended.
Please note that delegation only becomes effective the next time [Snapshot](https://snapshot.org/#/opcollective.eth) measures how many votes each delegate has.
This happens at the start of every voting cycle, which is every three weeks.
1. Monitor how your delegate [has been voting on Snapshot](https://help.optimism.io/hc/en-us/articles/6389519530779-How-do-I-see-how-my-delegate-voted-).
Your delegate should also write up the reasoning behind their votes in a [Delegate Communications Thread](https://gov.optimism.io/c/governance/41).
Delegation is always in your control. You can return to the [delegation page](https://app.optimism.io/delegates) at any time to change your delegate selection, or to re-delegate voting power to yourself (more below).
### How do I delegate to myself?
Would you rather vote yourself?
No problem, but you’ll have to delegate to yourself first!
If you try to vote with your tokens but have not delegated to yourself, you will not be able to vote.
1.[Delegate to yourself](https://help.optimism.io/hc/en-us/articles/6296720540955-How-do-I-delegate-to-myself-).
1.[Go to the delegates app](https://app.optimism.io/delegates) to see that you’ve delegated your tokens to your own address.
Please note that delegation only becomes effective the next time [Snapshot](https://snapshot.org/#/opcollective.eth) measures how many votes each delegate has.
This happens at the start of the voting phase in a cycle, which is the last week of each cycle.
A new cycle starts every 3 weeks.
If you want to become a delegate that others delegate to you need to [follow this process](delegate.md#ready-to-be-a-delegate).
1. Once you’ve been added as a delegate in the next voting cycle, you can start [voting](https://snapshot.org/#/opcollective.eth)!
<!--
## Step 1: Claim or purchase OP tokens
To check your eligibility for Airdrop #1, scroll to the bottom of [this page](https://app.optimism.io/announcement).
If you didn’t qualify for Airdrop #1, don’t worry, there will be more.
Claim your tokens by visiting **[the airdrop app](https://app.optimism.io/airdrop/check).**
It doesn’t cost anything to claim the airdrop, except for gas fees.
You will need to make sure you have some ETH on the Optimism network to pay for gas (0.003 is usually enough).
[Learn here how to deposit ETH to Optimism](https://help.optimism.io/hc/en-us/sections/4413033248795-Deposit).
Didn’t qualify or just want more OP? OP is available to buy on all major exchanges deployed on Optimism.
## Step 2: Delegate your tokens (to someone else or yourself)
Participating in governance of the Optimism Token House will require a serious time commitment.
For this reason, The Optimism Foundation strongly encourages people to delegate the voting power of their OP tokens to a community member who has explicitly volunteered to play an active role in Token House governance.
If you do not wish to delegate your voting power to a representative, you will still need to delegate to yourself in order to vote.
*[Delegate your tokens](https://app.optimism.io/delegates).
[Here are directions if you wish to delegate them to yourself](https://help.optimism.io/hc/en-us/articles/6296720540955-How-do-I-delegate-to-myself-).
Comment in the [Proposal Discussion](proposals.md) section of the [Forum](https://gov.optimism.io/) and provide feedback on draft proposals.
::: tip
Make sure you understand and follow the Forum's [code of conduct](https://gov.optimism.io/t/code-of-conduct/5/4)
:::
## Step 4: Vote (if you are a delegate)
Go to [Snapshot](https://snapshot.org/#/opcollective.eth), connect your wallet, and vote.
There is no minimum OP holding voting requirement, but you will need to have the OP tokens you wish to delegate or vote with in your wallet when the voting snapshot is taken.
Tokens that are staked or LP’d when the snapshot is taken do not carry voting power.
This process is currently under construction for Season 3.
Check back soon for updated information.
:::
## Grant Proposals
::: tip
This information is here for your convenience.
The source of truth for all governance related processes is the [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#proposal-process--components-of-a-valid-proposal).
The operating manual is currently in the process of being updated to reflect changes being voted on during Special Voting Cycles.
:::
Projects may submit a Phase 1 proposal to request OP tokens from the Governance Fund.
The purpose of the Governance Fund is to incentivize sustainable growth of projects and communities in the Optimism ecosystem.
This does not mean that all grants must be incentive programs.
The Token House is welcome to consider any and all proposals which would drive growth or address a gap in the Optimism ecosystem, including public goods projects.
However, funding should come with an expectation of growth-related deliverables.
It is not the intended purpose of the governance fund to retroactively fund public goods without an expectation of future work.
There is a distinct OP allocation dedicated to this, which will be distributed via [the Citizens' House](citizens-house.md) at a later date.
When writing your proposal, please adhere to the [grant proposal template](https://gov.optimism.io/t/grant-proposal-template/3233).
The process for submitting a grant proposal is currently undergoing changes.
A Grants Council, which will process grant applications in Season 3 was recently approved.
Stay tuned for more information on how to submit a proposal to the Council shortly.
**You can expect grant proposals to begin being processed again via the Grants Council on January 26th.**
## Other proposal types
There are [other types of proposals](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types) that you can submit:
- Protocol Upgrade
- Inflation Adjustment
- Director Removal
There is no minimum holding requirement for submitting a proposal but your proposal must be approved by a delegate with sufficient voting power to move to a vote (as defined in [the operating manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md#valid-proposal-types)).
The process for submitting these proposals is very similar to the one for grants.
Where there are differences, they are noted in the table in the operating manual.
The Optimism Collective’s second round of Retroactive Public Goods Funding (RetroPGF) takes place in Q1 2023.
RetroPGF 2 will allocate 10m OP tokens to **fund public goods that support development and usage of the OP Stack.**
Optimism’s vision is to build a global system where positive impact to the collective is rewarded by profit to the individual.
RetroPGF is an experimental mechanism to realize this goal of **“impact = profit”**.
By funding public goods sustainably, the Collective can create a rich ecosystem and a better economy.
## Timeline
**Nomination window**: Jan 17 - Jan 31 19:00 GMT
**Project opt-in deadline**: Feb 14
**Voting window**: Feb 28 - Mar 14
## Scope of RetroPGF 2
**RetroPGF Round #2 will fund public goods that support development and usage of the OP Stack. This falls into three main categories:**
-**Infrastructure + Dependencies**: Software used to build or deploy the OP Stack; contributions to protocols or standards upon which the OP Stack runs; experiments that support future development of the core OP Stack protocol
-**Tooling + Utilities**: Work that helps builders create applications on Optimism mainnet, build on the OP Stack, interact with governance of the Collective, or use applications built on Optimism
-**Education**: Work to spread awareness and knowledge of how Optimism works, whether technically or socially
Today, the OP Stack refers to the OSS code powering Optimism. Today, this means the Optimism monorepo and its dependencies. Eligible projects **need not** be exclusive to the Optimism ecosystem, but there should be a connection. For example,
-**go-ethereum** is an important dependency of the OP Stack, but is not Optimism-specific.
-**Ethereum L2 explorer pages** which give stats on various L2s provide educational impact for the OP Stack, but are not Optimism-specific
RetroPGF 2 focuses on a narrow, Optimism-specific scope of impact to drive the core engine for ecosystem growth. In future rounds, this scope will expand.
## Nominations
Nominations will be open from **Jan 17 to Jan 31 19:00 GMT**. During this window, anyone can nominate a project for funding.
Here the term “project” can describe work that has been done by both an individual or a group.
Collections, a term used to describe projects without a single person or entity that can be verified via GitHub or Twitter, may only be nominated by the Optimism Foundation.
Nominations will take place on the [Optimism Governance Forum](https://gov.optimism.io/t/nominations-for-retropgf2/4636). Any community member can nominate a project by supplying:
- the project name
- A description of how the project has supported development and usage of the OP Stack
- a link to projects GitHub or Twitter
- (optional) contact info for the project or project lead
### You can nominate projects by category on the below forum posts
-[**Nominations for Infrastructure + Dependencies**](https://gov.optimism.io/t/infrastructure-dependencies-nominations-for-rpgf2/4637)
-[**Nominations for Tooling + Utilities**](https://gov.optimism.io/t/tooling-utilities-nominations-for-rpgf2/4639)
-[**Nominations for Education**](https://gov.optimism.io/t/education-nominations-for-rpgf2/4640)
## Funding Eligibility
Any project that has been nominated for RetroPGF 2 must complete a project profile on the **RetroPGF Application Manager** on the Optimism website in order to be eligible for voting.
The Application Manager will ask for information about your project, including authentication with Twitter or GitHub to prevent impersonations.
The Application Manager will also ask for information about team size, funding amount, impact provided to the Collective.
This information will help voters make choices about how to allocate funding.
After project nominations close, the Optimism Foundation will review completed profile submissions for spam and fraud.
Any project without a correctly verified GitHub or Twitter account, any project impersonating another team, or any project without a complete profile may be hidden from the voting round at the Foundation’s discretion.
For more information and guidance on the nomination and application process for projects, see the [**RetroPGF Project Manual**](https://www.notion.so/oplabs/Optimism-RetroPGF-2-Project-Manual-0a2e741133cd49b0b005ff759934b998).
## Voting Badge distribution
✨ Voting Badges for RetroPGF 2 will be distributed to a set of **90 community members.**
1.**One badge distributed to each voter from RetroPGF Round 1**, excluding full time employees of OP Labs or the Optimism Foundation. (14 badges, [list](https://docs.google.com/spreadsheets/d/1g4ilAByMNQsmlBC8cskQip7Ojd_qK6IhozJCyoVfU9k/edit#gid=0))
2.**One badge given to an individual selected by each of the previous voters in RetroPGF Round 1** (14 badges)
3.**One badge given to 10 Token House delegates, selected by a Token House vote.** (10 badges)
4.**One badge given to an individual selected by each of the badge-holding Token House delegates in (3) above** (10 badges)
5.**Twenty-one badges distributed to unaffiliated community contributors chosen by the Optimism Foundation**. (21 badges)
6.**Twenty-one badges distributed to individuals selected by each badge-holding community contributor in (5) above** (21 badges)
**Notes**
- Holding a voting badge for one round does not guarantee voting rights in subsequent rounds; Citizenship criteria are subject to change going forward
- Voting Badges in RetroPGF 2 are recorded as a simple attestation in the AttestationStation, not as a soulbound token. This approach preserves flexibility for future iterations
- Badgeholders are expected to adhere to the [Optimism Delegate Code of Conduct](https://gov.optimism.io/t/delegate-code-of-conduct/3943)
- An individual does not have to accept the voting badge. If an eligible person declines, the badge will not be distributed to someone else
- Anyone holding a Voting Badge will be able to mint an Optimist NFT – the inception of identity on Optimism
- Badgeholders with any participation or ownership stake in a project up for vote in RetroPGF 2 will be expected to not vote in favor of that project. Rules around conflicts of interest will be itemized in a forthcoming Badgeholder Manual
- Citizens’ House adheres to “one person one vote.” If an individual falls into more than one category above or is nominated more than once, they will still receive only one voting badge
Badgeholders will be added to a public channel on Discord for announcements and discussion.
## Voting
Each badgeholder will be asked to vote during a ten-day window from Feb 28 - Mar 14.
Voters will be able to filter, sort, and search projects.
Projects will be displayed with their answers to the application questions included in the project profile created via the RPGF Application Manager.
Votes will be aggregated as a simple weighted average, not as a quadratic vote.
Votes are submitted via a form and will only be accessible to the Foundation, which means an individual Citizen’s vote will not be public by default.
Once a vote is cast, the Citizen cannot update their vote.
Token House governance operates on a seasonal schedule.
Season two begins on August 25th, 2022, with Voting Cycle Five.
Seasons are separated with a three-week Reflection Period.
During each Season, Token House voting occurs via three-week voting cycles.
Voting Cycles begin on Thursday at 19:00p GMT (12p PST) and end on Wednesday at 19:00 GMT (12p PST).
At the beginning of a Season there may be a two-week voting cycle for policy and document proposals that come out of the previous Reflection Period.
During Reflection Periods, the Optimism Foundation will publish a proposed changelog to the Operating Manual and a set of governance proposals aimed at addressing the feedback received in the previous season.
There will be no active votes during Reflection Periods, so that delegates and the broader community have time to provide critical feedback to improve the next season.
Reflection periods are expected to be followed by two-week Special Voting Cycles during which we vote on proposals to modify the collective's structure.
You can see up to date information about the seasons and voting cycles in [the governance calendar](https://calendar.google.com/calendar/u/0/r?cid=Y180aHVpNzBpdG0wODllN3Q4cTUwaGVoMWtub0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t).
::: tip At the time of writing we in Season #2: August 25th - Nov 9th, 2022
Followed by:
- Reflection Period #2: Nov 10th - Nov 30th, 2022
- Season #3: Dec 1st, 2022 - Feb 15th, 2023
:::
## History
<!--
### Season #3: Dec 1st, 2022 - Feb 15th, 2023
* Voting system #12 (Jan 26th - Feb 15th)
* Voting system #11 (Jan 5th - Jan 25th)
* Voting system #10 (Dec 15th, 2022 - Jan 4th, 2023)
### Voting Cycle #9: Dec 1st - Dec 14th, 2022
### Reflection Period #2: Nov 10th - Nov 30th, 2022
Changes made during the Reflection Period are voted on during two-week Special Voting Cycles.
### Reflection Period #1
The reflection period was a break between season 1 and season 2 where the Optimism foundation, with the help of delegates and community members, updated and improved the governance process.
[The Working Constitution](https://gov.optimism.io/t/working-constitution-of-the-optimism-collective/55) outlines governing provisions and principles for the Collective.
It will remain in effect no more than four years from the date of its adoption.
After that, authority over governance will be ceded to a permanent Bedrock Constitution that incorporates the lessons of the Collective’s prior governance experiments.
The Collective’s [Operating Manual](https://github.com/ethereum-optimism/OPerating-manual/blob/main/manual.md) describes current governance processes for the Token House.
It will evolve, with the Collective, over time.
The version linked here, from [The Optimism Foundation's github repository](https://github.com/ethereum-optimism/OPerating-manual), is the authoritative one.
title:The Cannonical Transaction Chain (CTC) Format
lang:en-US
---
Every transaction submitted to Optimism is written to the mainnet Ethereum blockchain as call data, this is how Optimism inherits the availability and integrity guarantees of Ethereum.
This is also the cause of the majority of the cost of Optimism transactions.
At the time of writing it is cheaper to write a kilobytes to storage on Optimism than it is to add one byte to the calldata on Ethereum.
## Initial solution
The initial solution was to write a header with supporting data followed by a list of transactions.
To interpret a transaction, you can search for it on [Etherscan](https://etherscan.io/).
To interpret a CTC transaction you need to **Click to see more** to see the calldata (called "Input Data" by Etherscan):
For example, here are the fields and their values for this [initial solution CTC transaction](https://etherscan.io/tx/0xf5a2dd9d0815ad4dcee00063ff8f8f3fd44b3bd8ffc1f7f6c7f7f0b4b086c5a7/advanced):
| 15-17 | 3 | Transactions sent directly to L2 | 3 |
| 18-20 | 3 | Deposits with this context | 0 |
| 21-25 | 5 | Timestamp | 1646146436 | `block.timestamp` for transactions in this context (Tue Mar 01 2022 14:53:56 UTC)
| 26-30 | 5 | L1 block number | The L1 block number in this context, as obtained by calling [OVM_L1BlockNumber](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts/contracts/L2/predeploys/iOVM_L1BlockNumber.sol). ([14301739](https://etherscan.io/block/14301739)) |
| 31-46 | 14 | **Context 1** |
| 31-33 | 3 | Transactions sent directly to L2 | 8 |
| 34-36 | 3 | Deposits | 0 |
| 37-41 | 5 | Timestamp | 1646146451 | 15 seconds after the previous batch
| 42-47 | 5 | L1 block number | [14301739](https://etherscan.io/block/14301739)
| 16n+15-16n+30 | 14 | **Context n** |
| 16n+15-16n+17 | 3 | Transactions sent directly to L2 |
| 16n+18-16n+20 | 3 | Deposits with this context
| 16n+21-16n+25 | 5 | Timestamp
| 16n+26-16n+30 | 5 | L1 block number
This transaction has 15 batch contexts (numbered 0-14), so the first byte after the last context in this transaction, which starts the transaction list, is `16*15+15=255`.
Transactions are provided as a three byte length followed by the RLP encoded transaction.
Looking at locations 255-257, we see `0x00016e`, so the first transaction is 366 bytes long, at locations 258-623.
The next transaction length starts at byte 624, and the next transaction itself starts at byte 627.
## Additional batch types
The initial solution did not have a batch type.
However, to modify the format (for example, to add compression) a batch type is needed.
The solution is to set the timestamp of the first context to zero.
This does not create ambiguity because a timestamp of zero represents January 1st, 1970 (based on the UNIX convention), which cannot happen.
The block number then represents the transaction type.
## CTC transaction type zero
After the normal header and the first context, which has a timestamp of zero and a block number of zero, the other contexts contain the normal data.
After that the list of transaction lengths and transaction data is compressed using [zlib](https://nodejs.org/api/zlib.html).
In most ways Optimism is [EVM equivalent](https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306).
However, the are [a few differences](../developers/build/differences/), which sometimes require decentralized applications to access Optimism-specific services.
For example, decentralized applications might need to estimate gas costs.
The standard Ethereum tooling assumes that gas cost is proportional to the gas used by the transaction, which is correct on L1, but not on Optimism.
[Our gas costs are predominately the cost of writing the transaction to L1](../developers/build/transaction-fees.md), which depends on the transaction size, not the amount of processing required.
This difference requires us to have separate methods to provide gas estimates.
