You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update LINK token faucet and bridge info
* Correct Polygon zkEVM testnet faucet
* Base Sepolia LINK
* Update decommissioned/deprecated testnets
* Edits and add Base Sepolia faucet link
* Update VRF supported networks
* Update L2 sequencers
* Update Automation supported testnets
* Remove Base Goerli testnet from Data Feeds lists
* Change Base title case
* Update Base network status URL
* Update zksync status page URL
---------
Co-authored-by: Karim <[email protected]>
@@ -43,9 +44,9 @@ The diagram below shows how these feeds update and how a consumer retrieves the
43
44
44
45
If the Arbitrum network becomes unavailable, the `ArbitrumValidator` contract continues to send messages to the L2 network through the delayed inbox on L1. This message stays there until the sequencer is back up again. When the sequencer comes back online after downtime, it processes all transactions from the delayed inbox before it accepts new transactions. The message that signals when the sequencer is down will be processed before any new messages with transactions that require the sequencer to be operational.
45
46
46
-
## Optimism, BASE, and Metis
47
+
## Optimism, BASE, Metis, and Scroll
47
48
48
-
On Optimism, BASE, and Metis, the sequencer's status is relayed from L1 to L2 where the consumer can retrieve it.
49
+
On Optimism, BASE, Metis, and Scroll, the sequencer's status is relayed from L1 to L2 where the consumer can retrieve it.
@@ -69,7 +70,7 @@ On Optimism, BASE, and Metis, the sequencer's status is relayed from L1 to L2 wh
69
70
70
71
1. Consumers can then read from the `AggregatorProxy` contract, which fetches the latest round data from the `OptimismSequencerUptimeFeed` contract.
71
72
72
-
### Handling outages on Optimism, BASE, and Metis
73
+
### Handling outages on Optimism, BASE, Metis, and Scroll
73
74
74
75
If the sequencer is down, messages cannot be transmitted from L1 to L2 and **no L2 transactions are executed**. Instead, messages are enqueued in the `CanonicalTransactionChain` on L1 and only processed in the order they arrived later when the sequencer comes back up. As long as the message from the validator on L1 is already enqueued in the `CTC`, the flag on the sequencer uptime feed on L2 will be guaranteed to be flipped prior to any subsequent transactions. The transaction that flips the flag on the uptime feed will be executed before transactions that were enqueued after it. This is further explained in the diagrams below.
0 commit comments