Deploying to gh-pages from @ 9759111 🚀

interop/derivation.html

@@ -279,14 +279,15 @@ <h2 id="replacing-invalid-blocks"><a class="header" href="#replacing-invalid-blo
 that a block contains an <a href="./messaging.html#invalid-messages">invalid message</a>, the block is replaced
 by a block with the same inputs, except for the transactions included. The transactions from the
 original block are trimmed to include only deposit transactions plus an
-<a href="#optimistic-block-deposited-transaction">optimistic block info deposit transaction</a> which is appended
+<a href="#optimistic-block-deposited-transaction">optimistic block info deposit transaction</a>, which is appended
 to the trimmed transaction list.</p>
 <h3 id="optimistic-block-deposited-transaction"><a class="header" href="#optimistic-block-deposited-transaction">Optimistic Block Deposited Transaction</a></h3>
-<p>An [L1 attributes deposited transaction][g-l1-attr-deposit] is a deposit transaction sent to the zero address.</p>
+<p>An <a href="../protocol/deposits.html#l1-attributes-deposited-transaction">L1 attributes deposited transaction</a>
+is a deposit transaction sent to the zero address.</p>
 <p>This transaction MUST have the following values:</p>
 <ol>
 <li><code>from</code> is <code>0xdeaddeaddeaddeaddeaddeaddeaddeaddead0002</code> (the address of the
-[L1 Attributes depositor account][depositor-account])</li>
+<a href="../protocol/deposits.html#l1-attributes-depositor-account">L1 Attributes depositor account</a>)</li>
 <li><code>to</code> is <code>0x0000000000000000000000000000000000000000</code> (the zero address as no EVM code execution is expected).</li>
 <li><code>mint</code> is <code>0</code></li>
 <li><code>value</code> is <code>0</code></li>

interop/fault-proof.html

@@ -184,7 +184,7 @@ <h1 id="fault-proof"><a class="header" href="#fault-proof">Fault Proof</a></h1>
 </ul>
 <h2 id="cascading-dependencies"><a class="header" href="#cascading-dependencies">Cascading dependencies</a></h2>
 <p>Deposits are a special case, synchronous with derivation, at enforced cross-L2 delay.
-Thus deposits cannot reference each others events intra-block.</p>
+Thus deposits cannot reference each other's events intra-block.</p>
 <p>No changes to the dispute game bisection are required. The only changes required are to the fault proof program itself.
 The insight is that the fault proof program can be a superset of the state transition function.</p>
 <h2 id="security-considerations"><a class="header" href="#security-considerations">Security Considerations</a></h2>

interop/messaging.html

@@ -255,8 +255,8 @@ <h3 id="message-identifier"><a class="header" href="#message-identifier">Message
 exact state of the block templates between multiple chains together.</p>
 <h2 id="messaging-ends"><a class="header" href="#messaging-ends">Messaging ends</a></h2>
 <h3 id="initiating-messages"><a class="header" href="#initiating-messages">Initiating Messages</a></h3>
-<p>Each <a href="https://github.com/ethereum/go-ethereum/blob/5c67066a050e3924e1c663317fd8051bc8d34f43/core/types/log.go#L29">Log</a> (also known as <code>event</code> in solidity) forms an initiating message.
-The raw log data from the <a href="#message-payload">Message Payload</a>.</p>
+<p>Each <a href="https://github.com/ethereum/go-ethereum/blob/5c67066a050e3924e1c663317fd8051bc8d34f43/core/types/log.go#L29">Log</a> (also known as <code>event</code> in solidity) forms an initiating message,
+with the raw log data coming from the <a href="#message-payload">Message Payload</a>.</p>
 <p>Messages are <em>broadcast</em>: the protocol does not enshrine address-targeting within messages.</p>
 <p>The initiating message is uniquely identifiable with an <a href="#message-identifier"><code>Identifier</code></a>,
 such that it can be distinguished from other duplicate messages within the same transaction or block.</p>
@@ -282,7 +282,7 @@ <h2 id="messaging-invariants"><a class="header" href="#messaging-invariants">Mes
 message MUST be lower than the initiating message timestamp (as defined in the <a href="#message-identifier"><code>Identifier</code></a>) + <code>EXPIRY_TIME</code>.</li>
 </ul>
 <h3 id="timestamp-invariant"><a class="header" href="#timestamp-invariant">Timestamp Invariant</a></h3>
-<p>The timestamp invariant ensures that initiating messages is at least the same timestamp as the Interop upgrade timestamp
+<p>The timestamp invariant ensures that initiating messages have at least the same timestamp as the Interop upgrade timestamp
 and cannot come from a future block than the block of its executing message. Note that since
 all transactions in a block have the same timestamp, it is possible for an executing transaction to be
 ordered before the initiating message in the same block.</p>
@@ -342,8 +342,8 @@ <h3 id="intra-block-messaging-cycles"><a class="header" href="#intra-block-messa
 may have dependencies on one another.</p>
 <h3 id="resolving-cross-chain-safety"><a class="header" href="#resolving-cross-chain-safety">Resolving cross-chain safety</a></h3>
 <p>To determine cross-chain safety, the graph is inspected for valid graph components that have no invalid dependencies,
-while applying the respective safety-view on the blocks in the graph.</p>
-<p>I.e. the graph must not have any inward edges towards invalid blocks within the safety-view.</p>
+while applying the respective safety-view on the blocks in the graph.
+I.e., the graph must not have any inward edges towards invalid blocks within the safety-view.</p>
 <p>A safety-view is the subset of canonical blocks of all chains with the specified safety label or a higher safety label.
 Dependencies on blocks outside of the safety-view are invalid,
 but may turn valid once the safety-view changes (e.g. a reorg of unsafe blocks).</p>

interop/predeploys.html

@@ -391,7 +391,7 @@ <h2 id="l2tol2crossdomainmessenger"><a class="header" href="#l2tol2crossdomainme
 <p>The <code>L2ToL2CrossDomainMessenger</code> is a higher level abstraction on top of the <code>CrossL2Inbox</code> that
 provides general message passing, utilized for secure transfers ERC20 tokens between L2 chains.
 Messages sent through the <code>L2ToL2CrossDomainMessenger</code> on the source chain receive both replay protection
-as well as domain binding, ie the executing transaction can only be valid on a single chain.</p>
+as well as domain binding, i.e. the executing transaction can only be valid on a single chain.</p>
 <h3 id="relaymessage-invariants"><a class="header" href="#relaymessage-invariants"><code>relayMessage</code> Invariants</a></h3>
 <ul>
 <li>The <code>Identifier.origin</code> MUST be <code>address(L2ToL2CrossDomainMessenger)</code></li>
@@ -415,16 +415,16 @@ <h3 id="no-native-support-for-cross-chain-ether-sends"><a class="header" href="#
 sending <code>ether</code> between chains. <code>ether</code> must first be wrapped into WETH before sending between chains.
 See <a href="./superchain-weth.html">SuperchainWETH</a> for more information.</p>
 <h3 id="interfaces"><a class="header" href="#interfaces">Interfaces</a></h3>
-<p>The <code>L2ToL2CrossDomainMessenger</code> uses a similar interface to the <code>L2CrossDomainMessenger</code> but
+<p>The <code>L2ToL2CrossDomainMessenger</code> uses a similar interface to the <code>L2CrossDomainMessenger</code>, but
 the <code>_minGasLimit</code> is removed to prevent complexity around EVM gas introspection and the <code>_destination</code>
 chain is included instead.</p>
 <h4 id="sending-messages"><a class="header" href="#sending-messages">Sending Messages</a></h4>
 <p>The following function is used for sending messages between domains:</p>
 <pre><code class="language-solidity">function sendMessage(uint256 _destination, address _target, bytes calldata _message) external returns (bytes32);
 </code></pre>
 <p>It returns the hash of the message being sent,
-used to track whether the message has successfully been relayed.
-It emits a <code>SentMessage</code> event with the necessary metadata to execute when relayed on the destination chain.</p>
+which is used to track whether the message has successfully been relayed.
+It also emits a <code>SentMessage</code> event with the necessary metadata to execute when relayed on the destination chain.</p>
 <pre><code class="language-solidity">event SentMessage(uint256 indexed destination, address indexed target, uint256 indexed messageNonce, address sender, bytes message);
 </code></pre>
 <p>An explicit <code>_destination</code> chain and <code>nonce</code> are used to ensure that the message can only be played on a single remote
@@ -465,12 +465,12 @@ <h4 id="relaying-messages"><a class="header" href="#relaying-messages">Relaying
     end
 </pre>
 <p>When relaying a message through the <code>L2ToL2CrossDomainMessenger</code>, it is important to require that
-the <code>_destination</code> equal to <code>block.chainid</code> to ensure that the message is only valid on a single
+the <code>_destination</code> be equal to <code>block.chainid</code> to ensure that the message is only valid on a single
 chain. The hash of the message is used for replay protection.</p>
 <p>It is important to ensure that the source chain is in the dependency set of the destination chain, otherwise
 it is possible to send a message that is not playable.</p>
-<p>A message is relayed by providing the <a href="./messaging.html#message-identifier">identifier</a> to a <code>SentMessage</code>
-event and its corresponding <a href="./messaging.html#message-payload">message payload</a>.</p>
+<p>A message is relayed by providing the <a href="./messaging.html#message-identifier">identifier</a> of a <code>SentMessage</code>
+event along with its corresponding <a href="./messaging.html#message-payload">message payload</a>.</p>
 <pre><code class="language-solidity">function relayMessage(ICrossL2Inbox.Identifier calldata _id, bytes calldata _sentMessage) external payable returns (bytes memory returnData_) {
     require(_id.origin == Predeploys.L2_TO_L2_CROSS_DOMAIN_MESSENGER);
     CrossL2Inbox(Predeploys.CROSS_L2_INBOX).validateMessage(_id, keccak256(_sentMessage));
@@ -503,7 +503,7 @@ <h2 id="optimismsuperchainerc20factory"><a class="header" href="#optimismsuperch
 <h3 id="optimismsuperchainerc20"><a class="header" href="#optimismsuperchainerc20">OptimismSuperchainERC20</a></h3>
 <p>The <code>OptimismSuperchainERC20Factory</code> creates ERC20 contracts that implements the <code>SuperchainERC20</code> <a href="token-bridging.html">standard</a>,
 grants mint-burn rights to the <code>L2StandardBridge</code> (<code>OptimismSuperchainERC20</code>)
-and include a <code>remoteToken</code> variable.
+and includes a <code>remoteToken</code> variable.
 These ERC20s are called <code>OptimismSuperchainERC20</code> and can be converted back and forth with <code>OptimismMintableERC20</code> tokens.
 The goal of the <code>OptimismSuperchainERC20</code> is to extend functionalities
 of the <code>OptimismMintableERC20</code> so that they are interop compatible.</p>
@@ -666,12 +666,12 @@ <h4 id="createstandardl2token"><a class="header" href="#createstandardl2token"><
 <h3 id="events-1"><a class="header" href="#events-1">Events</a></h3>
 <h4 id="optimismmintableerc20created"><a class="header" href="#optimismmintableerc20created"><code>OptimismMintableERC20Created</code></a></h4>
 <p>It MUST trigger when <code>createOptimismMintableERC20WithDecimals</code>,
-<code>createOptimismMintableERC20</code> or <code>createStandardL2Token</code> are called.</p>
+<code>createOptimismMintableERC20</code> or <code>createStandardL2Token</code> is called.</p>
 <pre><code class="language-solidity">event OptimismMintableERC20Created(address indexed localToken, address indexed remoteToken, address deployer);
 </code></pre>
 <h4 id="standardl2tokencreated"><a class="header" href="#standardl2tokencreated"><code>StandardL2TokenCreated</code></a></h4>
 <p>It MUST trigger when <code>createOptimismMintableERC20WithDecimals</code>,
-<code>createOptimismMintableERC20</code> or <code>createStandardL2Token</code> are called.
+<code>createOptimismMintableERC20</code> or <code>createStandardL2Token</code> is called.
 This event exists for backward compatibility with legacy version.</p>
 <pre><code class="language-solidity">event StandardL2TokenCreated(address indexed remoteToken, address indexed localToken);
 </code></pre>
@@ -728,7 +728,12 @@ <h3 id="invariants"><a class="header" href="#invariants">Invariants</a></h3>
 valid <code>OptimismSuperchainERC20</code> corresponding to the same remote token.</li>
 </ul>
 <h3 id="conversion-flow"><a class="header" href="#conversion-flow">Conversion Flow</a></h3>
-<pre class="mermaid">sequenceDiagram
+<pre class="mermaid">---
+config:
+  theme: dark
+  fontSize: 28
+---
+sequenceDiagram
   participant Alice
   participant L2StandardBridge
   participant factory as OptimismMintableERC20Factory
@@ -793,7 +798,12 @@ <h4 id="relayederc20"><a class="header" href="#relayederc20"><code>RelayedERC20<
 </code></pre>
 <h3 id="diagram"><a class="header" href="#diagram">Diagram</a></h3>
 <p>The following diagram depicts a cross-chain transfer.</p>
-<pre class="mermaid">sequenceDiagram
+<pre class="mermaid">---
+config:
+  theme: dark
+  fontSize: 48
+---
+sequenceDiagram
   participant from
   participant L2SBA as SuperchainTokenBridge (Chain A)
   participant SuperERC20_A as SuperchainERC20 (Chain A)
@@ -858,7 +868,7 @@ <h3 id="invariants-1"><a class="header" href="#invariants-1">Invariants</a></h3>
 </li>
 <li>Bridge Events:
 <ul>
-<li><code>sendERC20()</code> should emit a <code>SentERC20</code> event. `</li>
+<li><code>sendERC20()</code> should emit a <code>SentERC20</code> event.</li>
 <li><code>relayERC20()</code> should emit a <code>RelayedERC20</code> event.</li>
 </ul>
 </li>

interop/superchain-weth.html

@@ -307,11 +307,14 @@ <h2 id="ethliquidity"><a class="header" href="#ethliquidity">ETHLiquidity</a></h
 <h3 id="invariants-1"><a class="header" href="#invariants-1">Invariants</a></h3>
 <h4 id="global-invariants"><a class="header" href="#global-invariants">Global Invariants</a></h4>
 <ul>
-<li>Initial balance must be set to <code>type(uint248).max</code> (wei). Purpose for using <code>type(uint248).max</code> is to guarantees that
-the balance will be sufficient to credit all use within the <code>SuperchainWETH</code> contract but will never overflow on calls
-to <code>burn</code> because there is not ETH in the total ETH supply to cause such an overflow. Invariant that avoids overflow is
-maintained by  <code>SuperchainWETH</code> but could theoretically be broken by some future contract that is allowed to integrate
-with <code>ETHLiquidity</code>. Maintainers should be careful to ensure that such future contracts do not break this invariant.</li>
+<li>Initial balance must be set to <code>type(uint248).max</code> (wei).
+The purpose for using <code>type(uint248).max</code> is to guarantee that
+the balance will be sufficient to credit all use within the <code>SuperchainWETH</code> contract,
+but will never overflow on calls to <code>burn</code> because there is not enough ETH
+in the total ETH supply to cause such an overflow.
+The invariant that avoids overflow is maintained by  <code>SuperchainWETH</code>, but could theoretically
+be broken by some future contract that is allowed to integrate with <code>ETHLiquidity</code>. Maintainers should be careful to
+ensure that such future contracts do not break this invariant.</li>
 </ul>
 <h4 id="burn"><a class="header" href="#burn"><code>burn</code></a></h4>
 <ul>