spec: fix typos (#2867)

Co-authored-by: Matthew Slipper <me@matthewslipper.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

spec: fix typos (#2867)
Co-authored-by: Matthew Slipper <me@matthewslipper.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
861ae315 · Luca Donno · GitHub · 8a335b7b · 861ae315 · 861ae315
Commit 861ae315 authored Jun 29, 2022 by Luca Donno Committed by GitHub Jun 29, 2022
13 changed files
--- a/specs/bridges.md
+++ b/specs/bridges.md
@@ -4,8 +4,9 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Token Depositing](#token-depositing)
+- [Standard Bridges](#standard-bridges)
- [Upgradability](#upgradability)
+  - [Token Depositing](#token-depositing)
+  - [Upgradability](#upgradability)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

--- a/specs/deposits.md
+++ b/specs/deposits.md
@@ -22,21 +22,22 @@ with the authorization and validation conditions on L2.
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [The Deposited Transaction Type](#the-deposited-transaction-type)
+- [Deposits](#deposits)
-  - [Source hash computation](#source-hash-computation)
+  - [The Deposited Transaction Type](#the-deposited-transaction-type)
-  - [Kinds of Deposited Transactions](#kinds-of-deposited-transactions)
+    - [Source hash computation](#source-hash-computation)
-  - [Validation and Authorization of Deposited Transactions](#validation-and-authorization-of-deposited-transactions)
+    - [Kinds of Deposited Transactions](#kinds-of-deposited-transactions)
-  - [Execution](#execution)
+    - [Validation and Authorization of Deposited Transactions](#validation-and-authorization-of-deposited-transactions)
-    - [Nonce Handling](#nonce-handling)
+    - [Execution](#execution)
- [L1 Attributes Deposited Transaction](#l1-attributes-deposited-transaction)
+      - [Nonce Handling](#nonce-handling)
- [Special Accounts on L2](#special-accounts-on-l2)
+  - [L1 Attributes Deposited Transaction](#l1-attributes-deposited-transaction)
-  - [L1 Attributes Depositor Account](#l1-attributes-depositor-account)
+  - [Special Accounts on L2](#special-accounts-on-l2)
-  - [L1 Attributes Predeployed Contract](#l1-attributes-predeployed-contract)
+    - [L1 Attributes Depositor Account](#l1-attributes-depositor-account)
-    - [L1 Attributes Predeployed Contract: Reference Implementation](#l1-attributes-predeployed-contract-reference-implementation)
+    - [L1 Attributes Predeployed Contract](#l1-attributes-predeployed-contract)
- [User-Deposited Transactions](#user-deposited-transactions)
+      - [L1 Attributes Predeployed Contract: Reference Implementation](#l1-attributes-predeployed-contract-reference-implementation)
-  - [Deposit Contract](#deposit-contract)
+  - [User-Deposited Transactions](#user-deposited-transactions)
-    - [Address Aliasing](#address-aliasing)
+    - [Deposit Contract](#deposit-contract)
-    - [Deposit Feed Contract: Reference Implementation](#deposit-feed-contract-reference-implementation)
+      - [Address Aliasing](#address-aliasing)
+      - [Deposit Feed Contract: Reference Implementation](#deposit-feed-contract-reference-implementation)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
@@ -254,8 +255,8 @@ feed contract][deposit-feed-contract] on L1.
 The deposit contract is deployed to L1. Deposited transactions are derived from the values in
 the `TransactionDeposited` event(s) emitted by the deposit contract.
-The deposit contract is responsible for maintaing the [guaranteed gas market](./guaranteed-gas-market.md),
+The deposit contract is responsible for maintaining the [guaranteed gas market](./guaranteed-gas-market.md),
-charging deposits for gas to be used on L2, and ensuring that the total amount of guaranted
+charging deposits for gas to be used on L2, and ensuring that the total amount of guaranteed
 gas in a single L1 block does not exceed the L2 block gas limit.
 The deposit contract handles two special cases:

--- a/specs/exec-engine.md
+++ b/specs/exec-engine.md
@@ -4,17 +4,18 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Deposited transaction processing](#deposited-transaction-processing)
+- [L2 Execution Engine](#l2-execution-engine)
-  - [Deposited transaction boundaries](#deposited-transaction-boundaries)
+  - [Deposited transaction processing](#deposited-transaction-processing)
- [Engine API](#engine-api)
+    - [Deposited transaction boundaries](#deposited-transaction-boundaries)
-  - [`engine_forkchoiceUpdatedV1`](#engine_forkchoiceupdatedv1)
+  - [Engine API](#engine-api)
-    - [Extended PayloadAttributesV1](#extended-payloadattributesv1)
+    - [`engine_forkchoiceUpdatedV1`](#engine_forkchoiceupdatedv1)
-  - [`engine_newPayloadV1`](#engine_newpayloadv1)
+      - [Extended PayloadAttributesV1](#extended-payloadattributesv1)
-  - [`engine_getPayloadV1`](#engine_getpayloadv1)
+    - [`engine_newPayloadV1`](#engine_newpayloadv1)
- [Networking](#networking)
+    - [`engine_getPayloadV1`](#engine_getpayloadv1)
- [Sync](#sync)
+  - [Networking](#networking)
-  - [Happy-path sync](#happy-path-sync)
+  - [Sync](#sync)
-  - [Worst-case sync](#worst-case-sync)
+    - [Happy-path sync](#happy-path-sync)
+    - [Worst-case sync](#worst-case-sync)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

--- a/specs/glossary.md
+++ b/specs/glossary.md
@@ -4,6 +4,7 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
+- [Glossary](#glossary)
 - [General Terms](#general-terms)
  - [Layer 1 (L1)](#layer-1-l1)
  - [Layer 2 (L2)](#layer-2-l2)
@@ -200,7 +201,7 @@ all deposit-related terms.
 Notably, a *deposit* can refer to:
- A [deposited transaction][deposited] (on L2) that is part of a [deposite block][deposit-block].
+- A [deposited transaction][deposited] (on L2) that is part of a [deposit block][deposit-block].
 - A [depositing call][depositing-call] that causes a [deposited transaction][deposited] to be derived.
 - The event/log data generated by the [depositing call][depositing-call], which is what the [rollup driver] reads to
  derive the [deposited transaction][deposited].

--- a/specs/guaranteed-gas-market.md
+++ b/specs/guaranteed-gas-market.md
@@ -4,9 +4,10 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Gas Stipend](#gas-stipend)
+- [Guaranteed Gas Fee Market](#guaranteed-gas-fee-market)
- [Limiting Guaranteed Gas](#limiting-guaranteed-gas)
+  - [Gas Stipend](#gas-stipend)
- [Rationale for burning L1 Gas](#rationale-for-burning-l1-gas)
+  - [Limiting Guaranteed Gas](#limiting-guaranteed-gas)
+  - [Rationale for burning L1 Gas](#rationale-for-burning-l1-gas)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

--- a/specs/introduction.md
+++ b/specs/introduction.md
@@ -4,20 +4,21 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Foundations](#foundations)
+- [Introduction](#introduction)
-  - [What is Ethereum scalability?](#what-is-ethereum-scalability)
+  - [Foundations](#foundations)
-  - [What is an Optimistic Rollup?](#what-is-an-optimistic-rollup)
+    - [What is Ethereum scalability?](#what-is-ethereum-scalability)
-  - [What is EVM Equivalence?](#what-is-evm-equivalence)
+    - [What is an Optimistic Rollup?](#what-is-an-optimistic-rollup)
-  - [🎶 All together now 🎶](#-all-together-now-)
+    - [What is EVM Equivalence?](#what-is-evm-equivalence)
- [Protocol Guarantees](#protocol-guarantees)
+    - [🎶 All together now 🎶](#-all-together-now-)
- [Network Participants](#network-participants)
+  - [Protocol Guarantees](#protocol-guarantees)
-  - [Users](#users)
+  - [Network Participants](#network-participants)
-  - [Sequencers](#sequencers)
+    - [Users](#users)
-  - [Verifiers](#verifiers)
+    - [Sequencers](#sequencers)
- [Key Interaction Diagrams](#key-interaction-diagrams)
+    - [Verifiers](#verifiers)
-  - [Depositing and Sending Transactions](#depositing-and-sending-transactions)
+  - [Key Interaction Diagrams](#key-interaction-diagrams)
-  - [Withdrawing](#withdrawing)
+    - [Depositing and Sending Transactions](#depositing-and-sending-transactions)
- [Next Steps](#next-steps)
+    - [Withdrawing](#withdrawing)
+  - [Next Steps](#next-steps)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

--- a/specs/messengers.md
+++ b/specs/messengers.md
@@ -4,12 +4,13 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Message Passing](#message-passing)
+- [Cross Domain Messengers](#cross-domain-messengers)
- [Upgradability](#upgradability)
+  - [Message Passing](#message-passing)
- [Message Versioning](#message-versioning)
+  - [Upgradability](#upgradability)
-  - [Message Version 0](#message-version-0)
+  - [Message Versioning](#message-versioning)
-  - [Message Version 1](#message-version-1)
+    - [Message Version 0](#message-version-0)
- [Backwards Compatibility Notes](#backwards-compatibility-notes)
+    - [Message Version 1](#message-version-1)
+  - [Backwards Compatibility Notes](#backwards-compatibility-notes)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
@@ -19,7 +20,7 @@ the ability to replay cross domain messages and sit directly on top of the lower
 level system contracts responsible for cross domain messaging on L1 and L2.
 The `CrossDomainMessenger` is extended to create both an
-`L1CrossDomainMessenger` and well as a `L2CrossDomainMessneger`.
+`L1CrossDomainMessenger` and well as a `L2CrossDomainMessenger`.
 These contracts are then extended with their legacy APIs to provide backwards
 compatibility for applications that integrated before the Bedrock system
 upgrade.

--- a/specs/overview.md
+++ b/specs/overview.md
@@ -4,18 +4,19 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Architecture Design Goals](#architecture-design-goals)
+- [Optimism Overview](#optimism-overview)
- [Components](#components)
+  - [Architecture Design Goals](#architecture-design-goals)
-  - [L1 Components](#l1-components)
+  - [Components](#components)
-  - [L2 Components](#l2-components)
+    - [L1 Components](#l1-components)
-  - [Transaction/Block Propagation](#transactionblock-propagation)
+    - [L2 Components](#l2-components)
- [Key Interactions In Depth](#key-interactions-in-depth)
+    - [Transaction/Block Propagation](#transactionblock-propagation)
-  - [Deposits](#deposits)
+  - [Key Interactions In Depth](#key-interactions-in-depth)
-  - [Block Derivation](#block-derivation)
+    - [Deposits](#deposits)
-    - [Overview](#overview)
+    - [Block Derivation](#block-derivation)
-    - [Epochs and the Sequencing Window](#epochs-and-the-sequencing-window)
+      - [Overview](#overview)
-    - [Block Derivation Loop](#block-derivation-loop)
+      - [Epochs and the Sequencing Window](#epochs-and-the-sequencing-window)
-  - [Engine API](#engine-api)
+      - [Block Derivation Loop](#block-derivation-loop)
+    - [Engine API](#engine-api)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
@@ -56,7 +57,7 @@ deposits.
 token deposits (tokens are locked on L1, then minted on L2 via a deposited transaction).
 - **BatchInbox**: An L1 address to which the Batch Submitter submits transaction batches.
  - Transaction batches include L2 transaction calldata, timestamps, and ordering information.
-  - The BatchInbox is a regular EOA address. This lets us pass on gast cost savings by not executing any EVM code.
+  - The BatchInbox is a regular EOA address. This lets us pass on gas cost savings by not executing any EVM code.
 - **L2OutputOracle**: A smart contract that stores [L2 output roots](./glossary.md#l2-output) for use with withdrawals
 and fault proofs.
@@ -91,7 +92,7 @@ Since the EE uses Geth under the hood, Optimism uses Geth's built-in peer-to-pee
 propagate transactions. The same network can also be used to propagate submitted blocks and support snap-sync.
 Unsubmitted blocks, however, are propagated using a separate peer-to-peer network of Rollup Nodes. This is optional,
-however, and is provided as a convnience to lower latency for verifiers and their JSON-RPC clients.
+however, and is provided as a convenience to lower latency for verifiers and their JSON-RPC clients.
 The below diagram illustrates how the sequencer and verifiers fit together:
@@ -175,7 +176,7 @@ derivation function performs the following steps:
 3. Submits the payload attributes to the Engine API, where they are converted into blocks and added to the canonical
 chain.
-This process is then repeated with incrementing epohcs until the tip of L1 is reached.
+This process is then repeated with incrementing epochs until the tip of L1 is reached.
 ### Engine API

--- a/specs/predeploys.md
+++ b/specs/predeploys.md
@@ -4,20 +4,21 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Overview](#overview)
+- [Predeploys](#predeploys)
- [OVM\_L2ToL1MessagePasser](#ovm%5C_l2tol1messagepasser)
+  - [Overview](#overview)
- [OVM\_DeployerWhitelist](#ovm%5C_deployerwhitelist)
+  - [OVM\_L2ToL1MessagePasser](#ovm_l2tol1messagepasser)
- [OVM\_ETH](#ovm%5C_eth)
+  - [OVM\_DeployerWhitelist](#ovm_deployerwhitelist)
- [WETH9](#weth9)
+  - [OVM\_ETH](#ovm_eth)
- [L2CrossDomainMessenger](#l2crossdomainmessenger)
+  - [WETH9](#weth9)
- [L2StandardBridge](#l2standardbridge)
+  - [L2CrossDomainMessenger](#l2crossdomainmessenger)
- [SequencerFeeVault](#sequencerfeevault)
+  - [L2StandardBridge](#l2standardbridge)
- [OptimismMintableTokenFactory](#optimismmintabletokenfactory)
+  - [SequencerFeeVault](#sequencerfeevault)
- [L1BlockNumber](#l1blocknumber)
+  - [OptimismMintableTokenFactory](#optimismmintabletokenfactory)
- [OVM\_GasPriceOracle](#ovm%5C_gaspriceoracle)
+  - [L1BlockNumber](#l1blocknumber)
- [Reserved System Address 1](#reserved-system-address-1)
+  - [OVM\_GasPriceOracle](#ovm_gaspriceoracle)
- [Reserved System Address 2](#reserved-system-address-2)
+  - [Reserved System Address 1](#reserved-system-address-1)
- [L1Block](#l1block)
+  - [Reserved System Address 2](#reserved-system-address-2)
+  - [L1Block](#l1block)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->
@@ -161,7 +162,7 @@ interface iOVM_ETH {
 ```solidity
 interface WETH9 {
    function name() public returns (string);
-    funcion symbol() public returns (string);
+    function symbol() public returns (string);
    function decimals public returns (uint8);
    event  Approval(address indexed src, address indexed guy, uint wad);
@@ -254,7 +255,7 @@ interface iOVM_L1BlockNumber {
 The `OVM_GasPriceOracle` is pushed the L1 basefee and the L2 gas price by
 an offchain actor. The offchain actor observes the L1 blockheaders to get the
 L1 basefee as well as the gas usage on L2 to compute what the L2 gas price
-should be based on a congenstion control algorithm.
+should be based on a congestion control algorithm.
 Its usage to be pushed the L2 gas price by an offchain actor is deprecated in
 Bedrock, but it is still used to hold the `overhead`, `scalar`, and `decimals`
@@ -273,7 +274,7 @@ interface OVM_GasPriceOracle {
    function l1BaseFee() public returns (uint256);
    /**
-     * @dev Returns the amortized cost of 
+     * @dev Returns the amortized cost of
     * batch submission per transaction
     */
    function overhead() public returns (uint256);
@@ -336,7 +337,7 @@ Reserved for future use.
 [l1-block-predeploy]: glossary.md#l1-block-predeployed-contract
 The [L1Block](l1-block-predeploy) was introduced in Bedrock and is responsible for
-mainting L1 context in L2. This allows for L1 state to be accessed in L2.
+maintaining L1 context in L2. This allows for L1 state to be accessed in L2.
 ```solidity
 interface L1Block {

--- a/specs/proposals.md
+++ b/specs/proposals.md
@@ -9,13 +9,14 @@
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Proposing L2 Output Commitments](#proposing-l2-output-commitments)
+- [L2 Output Root Proposals Specification](#l2-output-root-proposals-specification)
- [L2 Output Commitment Construction](#l2-output-commitment-construction)
+  - [Proposing L2 Output Commitments](#proposing-l2-output-commitments)
- [L2 Output Oracle Smart Contract](#l2-output-oracle-smart-contract)
+  - [L2 Output Commitment Construction](#l2-output-commitment-construction)
- [Security Considerations](#security-considerations)
+  - [L2 Output Oracle Smart Contract](#l2-output-oracle-smart-contract)
-  - [L1 Reorgs](#l1-reorgs)
+  - [Security Considerations](#security-considerations)
- [Summary of Definitions](#summary-of-definitions)
+    - [L1 Reorgs](#l1-reorgs)
-  - [Constants](#constants)
+  - [Summary of Definitions](#summary-of-definitions)
+    - [Constants](#constants)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

--- a/specs/rollup-node-p2p.md
+++ b/specs/rollup-node-p2p.md
@@ -29,34 +29,35 @@ and are adopted by several other blockchains, most notably the [L1 consensus lay
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [P2P configuration](#p2p-configuration)
+- [Rollup-node P2P interface](#rollup-node-p2p-interface)
-  - [Identification](#identification)
+  - [P2P configuration](#p2p-configuration)
-  - [Discv5](#discv5)
+    - [Identification](#identification)
-    - [Structure](#structure)
+    - [Discv5](#discv5)
-  - [LibP2P](#libp2p)
+      - [Structure](#structure)
-    - [Transport](#transport)
+    - [LibP2P](#libp2p)
-    - [Dialing](#dialing)
+      - [Transport](#transport)
-    - [NAT](#nat)
+      - [Dialing](#dialing)
-    - [Peer management](#peer-management)
+      - [NAT](#nat)
-    - [Transport security](#transport-security)
+      - [Peer management](#peer-management)
-    - [Protocol negotiation](#protocol-negotiation)
+      - [Transport security](#transport-security)
-    - [Identify](#identify)
+      - [Protocol negotiation](#protocol-negotiation)
-    - [Ping](#ping)
+      - [Identify](#identify)
-    - [Multiplexing](#multiplexing)
+      - [Ping](#ping)
-    - [GossipSub](#gossipsub)
+      - [Multiplexing](#multiplexing)
-      - [Content-based message identification](#content-based-message-identification)
+      - [GossipSub](#gossipsub)
-      - [Message compression and limits](#message-compression-and-limits)
+        - [Content-based message identification](#content-based-message-identification)
-      - [Message ID computation](#message-id-computation)
+        - [Message compression and limits](#message-compression-and-limits)
-    - [Heartbeat and parameters](#heartbeat-and-parameters)
+        - [Message ID computation](#message-id-computation)
-    - [Topic configuration](#topic-configuration)
+      - [Heartbeat and parameters](#heartbeat-and-parameters)
-    - [Topic validation](#topic-validation)
+      - [Topic configuration](#topic-configuration)
- [Gossip Topics](#gossip-topics)
+      - [Topic validation](#topic-validation)
-  - [`blocks`](#blocks)
+  - [Gossip Topics](#gossip-topics)
-    - [Block encoding](#block-encoding)
+    - [`blocks`](#blocks)
-    - [Block signatures](#block-signatures)
+      - [Block encoding](#block-encoding)
-    - [Block validation](#block-validation)
+      - [Block signatures](#block-signatures)
-      - [Block processing](#block-processing)
+      - [Block validation](#block-validation)
-      - [Block topic scoring parameters](#block-topic-scoring-parameters)
+        - [Block processing](#block-processing)
+        - [Block topic scoring parameters](#block-topic-scoring-parameters)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->

--- a/specs/rollup-node.md
+++ b/specs/rollup-node.md
@@ -44,6 +44,7 @@ currently only concerned with the specification of the rollup driver.
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
+- [Rollup Node Specification](#rollup-node-specification)
 - [L2 Chain Derivation](#l2-chain-derivation)
  - [From L1 Sequencing Window to L2 Payload Attributes](#from-l1-sequencing-window-to-l2-payload-attributes)
    - [Reading L1 inputs](#reading-l1-inputs)
@@ -329,7 +330,7 @@ after the L1 block that generated it. This is a duration of approximately 7 days
 as the "fault proof window", as after this time the block can no longer be challenged by a fault proof.
 L1 Ethereum reaches [finality][l1-finality] approximately every [12.8 minutes][consensus-time-params]. L2 blocks
-generated from finalized L1 blocksare "safer" than most recent L2 blocks because they will never disappear from the
+generated from finalized L1 blocks are "safer" than most recent L2 blocks because they will never disappear from the
 chain's history because of a re-org. However, they can still be challenged by a fault proof until the end of the fault
 proof window.

--- a/specs/withdrawals.md
+++ b/specs/withdrawals.md
@@ -33,18 +33,19 @@ finalization.
 <!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
 **Table of Contents**
- [Withdrawal Flow](#withdrawal-flow)
+- [Withdrawals](#withdrawals)
-  - [On L2](#on-l2)
+  - [Withdrawal Flow](#withdrawal-flow)
-  - [On L1](#on-l1)
+    - [On L2](#on-l2)
- [The L2ToL1MessagePasser Contract](#the-l2tol1messagepasser-contract)
+    - [On L1](#on-l1)
-  - [Address Aliasing](#address-aliasing)
+  - [The L2ToL1MessagePasser Contract](#the-l2tol1messagepasser-contract)
- [The Optimism Portal Contract](#the-optimism-portal-contract)
+    - [Addresses are not Aliased on Withdrawals](#addresses-are-not-aliased-on-withdrawals)
- [Withdrawal Verification and Finalization](#withdrawal-verification-and-finalization)
+  - [The Optimism Portal Contract](#the-optimism-portal-contract)
- [Security Considerations](#security-considerations)
+  - [Withdrawal Verification and Finalization](#withdrawal-verification-and-finalization)
-  - [Key Properties of Withdrawal Verification](#key-properties-of-withdrawal-verification)
+  - [Security Considerations](#security-considerations)
-  - [Handling Successfully Verified Messages That Fail When Relayed](#handling-successfully-verified-messages-that-fail-when-relayed)
+    - [Key Properties of Withdrawal Verification](#key-properties-of-withdrawal-verification)
- [Summary of Definitions](#summary-of-definitions)
+    - [Handling Successfully Verified Messages That Fail When Relayed](#handling-successfully-verified-messages-that-fail-when-relayed)
-  - [Constants](#constants)
+  - [Summary of Definitions](#summary-of-definitions)
+    - [Constants](#constants)
 <!-- END doctoc generated TOC please keep comment here to allow auto update -->