Skip to content
This repository was archived by the owner on Apr 6, 2026. It is now read-only.
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion notes/actions.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,4 +16,4 @@ Runs once per day.

The `tutorials.yml` workflow runs several of the tutorials within these docs.
Most tutorials take the form of JavaScript files that are imported within the content of the docs.
Same files can be executed individually to make sure that the tutorial actually works and isn't broken for one reason or another.
The same files can be executed individually to make sure that the tutorial actually works and isn't broken for one reason or another.
2 changes: 1 addition & 1 deletion notes/content-reuse.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ Text before
Text after
```

### How to Use a Multiple Reusable Content Components
### How to Use Multiple Reusable Content Components

1. You can create a `index.js` file in the `content` directories and export
the components like this:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -87,7 +87,7 @@ The process for bridging a native token involves a few steps.
{<h3>The Standard Bridge locks the transferred tokens</h3>}

When the user triggers the `bridgeERC20To` function while transferring a native token, the Standard Bridge will pull the `_amount` of `_localToken` tokens from the user's address and lock them inside of the bridge contract.
Comment thread
nnsW3 marked this conversation as resolved.
A record of all locked tokens are stored within a [`deposits` mapping](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L41-L42) that keeps track of the total number of tokens deposited for a given `_localToken` and `_remoteToken` pair.
A record of all locked tokens is stored within a [`deposits` mapping](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L41-L42) that keeps track of the total number of tokens deposited for a given `_localToken` and `_remoteToken` pair.

Since a native token may have more than one bridged representation, the `deposits` token must keep track of the deposit pools for each `_localToken`/`_remoteToken` pair independently.

Expand Down
2 changes: 1 addition & 1 deletion pages/builders/app-developers/contracts/optimization.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Gas optimization can reduce the amount of gas used by a contract and make your a

OP Mainnet contracts can be gas optimized to reduce overall transaction costs, just like contracts on Ethereum.
However, OP Mainnet transactions must also pay for another fee called the L1 Data Fee which accounts for the cost of publishing transaction data to Ethereum.
At the time this guide was written, this L1 Data Fee makes up the majority of the cost of most transactions on OP Mainnet.
At the time this guide was written, this L1 Data Fee made up the majority of the cost of most transactions on OP Mainnet.
Comment thread
nnsW3 marked this conversation as resolved.

Because the L1 Data Fee tends to be larger than the execution gas fee, **OP Mainnet contracts can be further optimized by increasing the amount of storage/execution used in order to decrease the amount of user-provided data in each transaction.**
Comment thread
nnsW3 marked this conversation as resolved.
This is the basic premise that makes OP Mainnet contract optimization slightly different than on Ethereum.
Comment thread
nnsW3 marked this conversation as resolved.
Expand Down
2 changes: 1 addition & 1 deletion pages/builders/notices/fp-changes.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ If you experience difficulty at any stage of this process, please reach out to [
<Callout type="error">
**Important Notice for Bridges and Users**

**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete.
**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reprovened after the upgrade is complete.
Comment thread
cpengilly marked this conversation as resolved.
Outdated

* Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again.
* Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window.
Expand Down