Transaction Finality Explainer #987
Conversation
✅ Deploy Preview for docs-optimism ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
WalkthroughThe pull request introduces a new key-value pair in the JSON metadata for transactions and adds a new documentation file focused on transaction finality within the OP Stack. The JSON file now includes the key Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (1)
pages/stack/protocol/rollup/finality.mdx (1)
1-87: Excellent documentation on transaction finality.This document provides a comprehensive and well-structured explanation of transaction finality in Ethereum and OP Stack. The content is informative, clear, and adheres to the provided coding guidelines. The use of Callout components and bullet points enhances readability and helps to highlight important information.
As a final step, I recommend a thorough proofread of the entire document to catch any minor issues that might have been overlooked. Pay special attention to the grammar correction suggested earlier in the "Finality on Ethereum" section.
🧰 Tools
🪛 LanguageTool
[grammar] ~17-~17: With the plural noun ‘transactions’, the verb inflection ‘achieves’ is not correct.
Context: ...rk conditions, transactions on Ethereum achieves finality in about 15 minutes. * Conse...(NNS_IN_NNP_VBZ)
[uncategorized] ~46-~46: The preposition ‘of’ seems more likely in this position.
Context: ...hereum to establish a view of the state on an OP Stack chain: * Rollup nodes po...(AI_HYDRA_LEO_REPLACE_ON_OF)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
⛔ Files ignored due to path filters (1)
public/img/op-stack/protocol/tx-finality.pngis excluded by!**/*.png
📒 Files selected for processing (2)
- pages/stack/protocol/rollup/finality.mdx (1 hunks)
- words.txt (1 hunks)
✅ Files skipped from review due to trivial changes (1)
- words.txt
🧰 Additional context used
📓 Path-based instructions (1)
pages/stack/protocol/rollup/finality.mdx (1)
Pattern
**/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for headers, buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- Use sentence case for H1, H2, and H3 headers, capitalizing only the first word and any proper nouns.
- For all headers (H1, H2, H3), do not change the capitalization of proper nouns; keep them as they are.
"
🪛 LanguageTool
pages/stack/protocol/rollup/finality.mdx
[grammar] ~17-~17: With the plural noun ‘transactions’, the verb inflection ‘achieves’ is not correct.
Context: ...rk conditions, transactions on Ethereum achieves finality in about 15 minutes. * Conse...(NNS_IN_NNP_VBZ)
[uncategorized] ~46-~46: The preposition ‘of’ seems more likely in this position.
Context: ...hereum to establish a view of the state on an OP Stack chain: * Rollup nodes po...(AI_HYDRA_LEO_REPLACE_ON_OF)
🔇 Additional comments (5)
pages/stack/protocol/rollup/finality.mdx (5)
1-11: LGTM: Metadata and introduction are well-structured and informative.The metadata provides clear information about the document's content, and the introduction offers a concise definition of transaction finality. The language used is appropriate and adheres to the provided guidelines.
27-42: LGTM: Clear explanation of OP Stack finality.This section effectively explains how OP Stack derives security from Ethereum and clearly defines the three stages of finality. The use of the Callout component adds valuable information about the OP Stack's security measures.
44-52: LGTM: Clear explanation of the settlement layer.This section effectively explains how Ethereum establishes a view of the state on an OP Stack chain. The use of bullet points helps in presenting the information clearly.
Regarding the static analysis suggestion to replace "on" with "of" in the phrase "state on an OP Stack chain", the current preposition "on" is correct and more appropriate in this context. It accurately conveys the idea of the state existing on the OP Stack chain, rather than being a property of it.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~46-~46: The preposition ‘of’ seems more likely in this position.
Context: ...hereum to establish a view of the state on an OP Stack chain: * Rollup nodes po...(AI_HYDRA_LEO_REPLACE_ON_OF)
54-62: LGTM: Clear explanation of sequencer reliability.This section effectively addresses concerns about centralized sequencers and explains how consensus rules and network nodes ensure reliability. The information is presented clearly and concisely using bullet points.
64-87: LGTM: Comprehensive explanation of the challenge period.This section provides a clear and detailed explanation of the 7-day withdrawal challenge period in OP Stack rollups. It effectively clarifies the distinction between transaction finality and the challenge period, which is crucial for understanding the system. The use of bullet points and the Callout component enhances the presentation of this complex information.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
pages/stack/protocol/rollup/_meta.json (1)
6-6: Remove trailing space in "Transaction Finality "There's an extra space at the end of the value for the "transaction-finality" key. While this won't affect functionality, it's best to remove it for consistency and cleanliness.
Here's the suggested change:
- "transaction-finality": "Transaction Finality ", + "transaction-finality": "Transaction Finality",
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (2)
- pages/stack/protocol/rollup/_meta.json (1 hunks)
- pages/stack/protocol/rollup/finality.mdx (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- pages/stack/protocol/rollup/finality.mdx
🧰 Additional context used
🔇 Additional comments (1)
pages/stack/protocol/rollup/_meta.json (1)
6-6: LGTM: New entry for transaction finality added.The addition of the "transaction-finality" entry aligns well with the PR objectives to enhance documentation on transaction finality in the OP Stack. Its placement in the file is logical within the context of the rollup process flow.
|
I have a doubt regarding the explanation posted above: As far as I understand optimistic rollups:
Quoting docs "The transaction needs to be written to L1 (Ethereum). This is typically performed by op-batcher, but any user can send an L1 transaction to submit an L2 transaction, in which case op-batcher is bypassed." Again quoting from the explanation: A successful challenge can also be for a batch that has been posted not necessarily withdrawals. (A batch is posted every 10 minutes) and would definitely cause a reorg- as far as I understand. @zainbacchus @sbvegan can you confirm If I am correct? |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (4)
pages/stack/protocol/rollup/finality.mdx (4)
12-12: Avoid using personal pronouns in technical documentation.Replace "we" with a more formal tone to maintain consistency in communal documentation.
-OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, we piggyback off Ethereum's consensus. +OP Stack rollup is an extension of the consensus mechanism in Ethereum, where instead of running an entirely separate consensus protocol, it leverages Ethereum's consensus.
93-93: Remove unnecessary comma.There's an unnecessary comma after "proof system".
-The proof system, is entirely separate from the core OP Stack protocol. +The proof system is entirely separate from the core OP Stack protocol.
135-135: Remove redundant wording in conclusion.The phrase "additional layer" is redundant.
-Transaction finality on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds an additional layer of validation for app-level functionality. +Transaction finality on the OP Stack depends heavily on Ethereum's consensus mechanism. The OP Stack ensures that rollups inherit Ethereum's finality guarantees, while the proof system adds a layer of validation for app-level functionality.🧰 Tools
🪛 LanguageTool
[style] ~135-~135: This phrase might be redundant. Consider either removing or replacing the adjective ‘additional’.
Context: ...lity guarantees, while the proof system adds an additional layer of validation for app-level functionali...(ADD_AN_ADDITIONAL)
97-97: Provide more context for state hash example.The example using
XYZas a state hash is not very informative. Consider using a more realistic example.-A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `XYZ`. +A claim in the context of rollups built on the OP Stack is a statement that asserts the state of the system at a specific block height. For example, a claim might assert that at block 1,000,000, the state hash is `0x1234...abcd`.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
- pages/stack/protocol/rollup/finality.mdx (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
pages/stack/protocol/rollup/finality.mdx (1)
Pattern
**/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for headers, buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- Use sentence case for H1, H2, and H3 headers, capitalizing only the first word and any proper nouns.
- For all headers (H1, H2, H3), do not change the capitalization of proper nouns; keep them as they are.
"
🪛 LanguageTool
pages/stack/protocol/rollup/finality.mdx
[grammar] ~22-~22: The verb after “to” should be in the base form as part of the to-infinitive. A verb can take many forms, but the base form is always used in the to-infinitive.
Context: ...ability and ordering are fundamental to ensuring the integrity of the system. ## Consen...(TO_NON_BASE)
[grammar] ~28-~28: Are you sure this verb form is correct? The progressive tense may be more appropriate here.
Context: ...nsaction ordering and finality. ## Why piggybacking on Ethereum? By publishing rollup bloc...(MISSING_IS)
[uncategorized] ~34-~34: This verb does not appear to agree with the subject. Consider using a different form.
Context: ...of this approach include: * OP Stack inherit Ethereum's security and ordering proper...(AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
[uncategorized] ~46-~46: The verb “is” doesn’t seem to fit in this context, “are” is probably more formally correct.
Context: ...ansaction. * Finalized: Transactions is finalized once more than (>65) L1 block...(AI_HYDRA_LEO_CPT_IS_ARE)
[uncategorized] ~89-~89: You might be missing the article “a” here.
Context: ...same transactions 4. System returns to consistent state after reprocessing ## The role o...(AI_EN_LECTOR_MISSING_DETERMINER_A)
[uncategorized] ~116-~116: The grammatical number of this noun doesn’t look right. Consider replacing it.
Context: ...tive value of the bridged assets. ## 7 days challenge period in OP Stack The 7 day...(AI_EN_LECTOR_REPLACEMENT_NOUN_NUMBER)
[uncategorized] ~118-~118: The grammatical number of this noun doesn’t look right. Consider replacing it.
Context: ...ays challenge period in OP Stack The 7 days challenge period exists to give time fo...(AI_EN_LECTOR_REPLACEMENT_NOUN_NUMBER)
[uncategorized] ~122-~122: When a number forms part of an adjectival compound, use a hyphen.
Context: ...fects the system. ### Why 7 days? The 7 day period is a reasonable time frame to al...(MISSING_HYPHEN)
[style] ~135-~135: This phrase might be redundant. Consider either removing or replacing the adjective ‘additional’.
Context: ...lity guarantees, while the proof system adds an additional layer of validation for app-level functionali...(ADD_AN_ADDITIONAL)
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (6)
pages/stack/transactions/_meta.json (1)
6-6: Maintain consistent capitalization and naming conventions.
- The title "Transaction finality" should be capitalized as "Transaction Finality" to match the capitalization pattern of other entries (e.g., "Transaction Fees", "Transaction Flow").
- Consider using camelCase for the key to match the existing pattern (e.g., "transactionFinality" instead of "transaction-finality").
Apply this diff to maintain consistency:
- "transaction-finality":"Transaction finality", + "transactionFinality": "Transaction Finality",words.txt (1)
305-305: Consider adding transaction finality related terms.While the current additions are good, consider adding these relevant terms to support the transaction finality documentation:
- finality
- challenge-period
- sequencer-policy
- fault-proof
- withdrawal-window
These terms appear to be central to the concepts being documented in the PR.
Would you like me to provide a properly formatted diff with these additions?
🧰 Tools
🪛 LanguageTool
[duplication] ~305-~305: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ... REQUIREDBLOCKS requiredblocks rollouts Rollups rollups Routescan rpckind RPCPREFIX rpcprefix r...(GERMAN_WORD_REPEAT_RULE)
pages/stack/transactions/transaction-finality.mdx (4)
1-5: Enhance the description metadata for better SEO and clarity.The current description is quite brief. Consider expanding it to better explain the unique aspects of OP Stack's transaction finality model and its relationship with Ethereum.
-description: Learn about finality in OP Stack and the steps to achieve transaction settlement. +description: Learn how OP Stack achieves transaction finality by leveraging Ethereum's consensus mechanism, including the roles of sequencers, fault proofs, and challenge periods.
14-15: Maintain formal tone in technical documentation.The current phrasing could be more formal while maintaining clarity.
-OP Stack is an extension of Ethereum's consensus mechanism. Instead of running an entirely separate consensus protocol, the OP Stack leverages Ethereum's consensus. +OP Stack extends Ethereum's consensus mechanism. Rather than implementing a separate consensus protocol, OP Stack utilizes Ethereum's existing consensus.
43-49: Use precise terminology for technical processes.The sequencer steps could be more technically precise.
-1. Pre-publishing Distribution: +1. Pre-confirmation Distribution: * The sequencer receives transactions from users. - * It creates blocks containing these transactions. + * It constructs blocks containing these transactions. * It distributes these blocks to network nodes before L1 publication. - * Nodes mark these blocks as "unsafe." + * Nodes designate these blocks with "unsafe" status.
75-75: Enhance image accessibility attributes.The image component should include proper dimensions and a more descriptive alt text.
-<Image src="/img/op-stack/protocol/tx-finality.png" alt="Transaction Finality Diagram." width={0} height={0} sizes="100vw" style={{ width: '100%', height: 'auto' }} quality={100} /> +<Image src="/img/op-stack/protocol/tx-finality.png" alt="Diagram showing the progression of transaction states from Unsafe to Safe to Finalized, with approximate timelines and dependencies on L1 confirmation." width={800} height={600} sizes="100vw" style={{ width: '100%', height: 'auto' }} quality={100} />
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
- pages/stack/transactions/_meta.json (1 hunks)
- pages/stack/transactions/transaction-finality.mdx (1 hunks)
- words.txt (2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
pages/stack/transactions/transaction-finality.mdx (1)
Pattern
**/*.mdx: "ALWAYS review Markdown content THOROUGHLY with the following criteria:
- Use proper nouns in place of personal pronouns like 'We' and 'Our' to maintain consistency in communal documentation.
- Avoid gender-specific language and use the imperative form.
- Monitor capitalization for emphasis. Avoid using all caps, italics, or bold for emphasis.
- Ensure proper nouns are capitalized in sentences.
- Apply the Oxford comma.
- Use proper title case for headers, buttons, tab names, page names, and links. Sentence case should be used for body content and short phrases, even in links.
- Use correct spelling and grammar at all times (IMPORTANT).
- Use sentence case for H1, H2, and H3 headers, capitalizing only the first word and any proper nouns.
- For all headers (H1, H2, H3), do not change the capitalization of proper nouns; keep them as they are.
"
🪛 LanguageTool
pages/stack/transactions/transaction-finality.mdx
[grammar] ~111-~111: The usual collocation for “independently” is “of”, not “from”. Did you mean “independently of”?
Context: ...tion-level constructs. * They operate independently from the core OP Stack protocol. * Bridge ...(INDEPENDENTLY_FROM_OF)
[style] ~140-~140: This phrase might be redundant. Consider either removing or replacing the adjective ‘additional’.
Context: ...lity guarantees, while the proof system adds an additional layer of validation for app-level functionali...(ADD_AN_ADDITIONAL)
words.txt
[duplication] ~305-~305: Möglicher Tippfehler: ein Wort wird wiederholt
Context: ... REQUIREDBLOCKS requiredblocks rollouts Rollups rollups Routescan rpckind RPCPREFIX rpcprefix r...(GERMAN_WORD_REPEAT_RULE)
🔇 Additional comments (1)
words.txt (1)
19-19: LGTM!The term is properly added with consistent casing variations and correct alphabetical sorting.
| @@ -3,5 +3,6 @@ | |||
| "transaction-flow": "Transaction Flow", | |||
There was a problem hiding this comment.
| "transaction-flow": "Transaction Flow", | |
| "transaction-flow": "Transaction flow", |
There was a problem hiding this comment.
Let's just apply sentence case uniformely
| @@ -3,5 +3,6 @@ | |||
| "transaction-flow": "Transaction Flow", | |||
| "deposit-flow": "Deposit Flow", | |||
There was a problem hiding this comment.
| "deposit-flow": "Deposit Flow", | |
| "deposit-flow": "Deposit flow", |
| @@ -3,5 +3,6 @@ | |||
| "transaction-flow": "Transaction Flow", | |||
| "deposit-flow": "Deposit Flow", | |||
| "withdrawal-flow": "Withdrawal Flow", | |||
There was a problem hiding this comment.
| "withdrawal-flow": "Withdrawal Flow", | |
| "withdrawal-flow": "Withdrawal flow", |
| @@ -3,5 +3,6 @@ | |||
| "transaction-flow": "Transaction Flow", | |||
| "deposit-flow": "Deposit Flow", | |||
| "withdrawal-flow": "Withdrawal Flow", | |||
| "transaction-finality":"Transaction finality", | |||
| "forced-transaction": "Forced Transaction" | |||
There was a problem hiding this comment.
| "forced-transaction": "Forced Transaction" | |
| "forced-transaction": "Forced transaction" |
|
|
||
| # Overview | ||
|
|
||
| This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. |
There was a problem hiding this comment.
| This guide explains how transaction finality works in OP Stack, covering the fundamental concepts of Fault Proofs and Challenges. | |
| This guide explains how transaction finality works in the OP Stack and addresses common misconceptions around transaction finality and the Fault Proof System. |
| ### What Is a Claim? | ||
|
|
||
| A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. | ||
|
|
||
| ### Fault Proofs and Challenges | ||
|
|
||
| Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. | ||
|
|
||
| ## 7-Day Challenge Period in OP Stack | ||
|
|
||
| The 7-day challenge period provides time for challenges to be raised and resolved. | ||
| Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: | ||
|
|
||
| 1. It allows time to validate and dispute the correctness of batches posted to Ethereum by the op-batcher, particularly important in scenarios like 51% attacks. | ||
| 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. | ||
|
|
||
| ### Why Seven Days? | ||
|
|
||
| The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. |
There was a problem hiding this comment.
| ### What Is a Claim? | |
| A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. | |
| ### Fault Proofs and Challenges | |
| Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the app-level functionality and does not alter the OP Stack protocol. | |
| ## 7-Day Challenge Period in OP Stack | |
| The 7-day challenge period provides time for challenges to be raised and resolved. | |
| Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: | |
| 1. It allows time to validate and dispute the correctness of batches posted to Ethereum by the op-batcher, particularly important in scenarios like 51% attacks. | |
| 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. | |
| ### Why Seven Days? | |
| The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. | |
| ### The role of proof system | |
| The following is a quick refresher on the Fault Proof System. It is a system designed to ensure the accuracy of certain claims about the transaction state on the L2. | |
| A claim in the context of OP Stack is a statement asserting the state of the system at a specific block height. For instance, a claim might assert that at block 1,000,000, the state hash is `XYZ`. If other participants believe this claim to be incorrect, they can challenge it. | |
| Challenges focus on proving whether a given claim is valid. The outcome of a challenge does not impact the underlying chain. For example, if a claim about the transaction state at a specific block is proven wrong, it only affects the application level functionality and does not alter the OP Stack protocol. | |
| The challenge period provides time for challenges to be raised and resolved. | |
| Although OP Stack finalizes transactions quickly (within 20 minutes), the 7-day challenge window serves two critical purposes: | |
| 1. It allows time to dispute the correctness of output state roots posted to Ethereum by the proposer. | |
| 2. It provides a security period for withdrawal processing, ensuring the integrity of cross-chain operations. |
|
|
||
| The 7-day challenge period is a reasonable time frame that allows participants to organize a response, potentially even initiating a L1 hard fork to address critical issues. In the OP Stack, this challenge period also serves as a safeguard for app-level bridges and custom designs that may be built on top of the core protocol. | ||
|
|
||
| ### Bridge Independence |
There was a problem hiding this comment.
| ### Bridge Independence | |
| ### Bridge independence |
| ### Example: Custom Bridges in OP Stack | ||
|
|
||
| A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. |
There was a problem hiding this comment.
| ### Example: Custom Bridges in OP Stack | |
| A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. | |
| For example, a custom bridge might be developed to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. |
|
|
||
| A custom bridge might be developed by a user to allow ERC-20 tokens to move between layers. However, this bridge is application-level and not native to the OP Stack. If there is an issue with the bridge, such as incorrect proof validation, it does not impact the protocol itself but affects the subjective value of the bridged assets. | ||
|
|
||
| ### Withdrawal Delays vs. Finality |
There was a problem hiding this comment.
| ### Withdrawal Delays vs. Finality | |
| ### Withdrawal delays vs. finality |
|
|
||
| ### Withdrawal Delays vs. Finality | ||
|
|
||
| One common misconception is confusing withdrawal delays with transaction finality: |
There was a problem hiding this comment.
This is a big misconception, lets bump it towards the top of this section
Description
Created a section on the docs to cover the nuances of transaction finality, sequencer policy and challenge periods to debunk the belief that OP Stack chains take 7 days for transaction finalization.
Tests
Additional context
Metadata
Include a link to any github issues that this may close in the following form: