From 6b977cece695f3d339646580c5092aa8dbe49862 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ga=C3=ABl=20Blanchemain?= Date: Thu, 16 Oct 2025 19:01:43 -0700 Subject: [PATCH] docs: update transaction lifecycle page to comply with style guide - Convert all headers to sentence case - Replace 'users' with direct address 'you' throughout - Add missing sidebar_label to frontmatter - Update content_type from 'get-started' to 'concept' - Fix user_story format in frontmatter - Use contractions for friendlier tone (we'll, you'll, doesn't, isn't) - Improve link text to be more descriptive - Maintain consistent terminology (sequencer, parent chain, transaction) --- .../02-transaction-lifecycle.mdx | 53 ++++++++++--------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/docs/how-arbitrum-works/02-transaction-lifecycle.mdx b/docs/how-arbitrum-works/02-transaction-lifecycle.mdx index f7622ecc94..50c28e9c96 100644 --- a/docs/how-arbitrum-works/02-transaction-lifecycle.mdx +++ b/docs/how-arbitrum-works/02-transaction-lifecycle.mdx @@ -1,19 +1,20 @@ --- -title: Sequencing, Followed by Deterministic Execution -description: 'Learn the fundamentals of the Arbitrum Transaction Lifecycle, sequencing, and deterministic execution.' -author: pete-vielhaber -sme: Mehdi -user_story: As a current or prospective Arbitrum user, I need to learn more about the transaction lifecycle. -content_type: get-started +title: 'Sequencing, followed by deterministic execution' +sidebar_label: 'Transaction lifecycle' +description: 'Learn the fundamentals of the Arbitrum transaction lifecycle, sequencing, and deterministic execution.' +author: 'pete-vielhaber' +sme: 'Mehdi' +user_story: 'As a current or prospective Arbitrum user, I want to understand the transaction lifecycle' +content_type: 'concept' --- import ImageZoom from '@site/src/components/ImageZoom'; -This section explores the various methods users can employ to submit transactions for inclusion on the Arbitrum chain. We discuss the different pathways available—sending transactions to the Sequencer or bypassing it by submitting transactions through the Delayed Inbox contract on the parent chain. By outlining these options, we aim to clarify how users can interact with the network, detail the processes involved in each method, and identify the modules responsible for handling these transactions. This overview will enhance your understanding of the initial steps in Arbitrum ecosystem's Transaction lifecycle and prepare you for a detailed exploration of transaction inclusion mechanisms in the subsequent sections. +This section explores the various methods you can use to submit transactions for inclusion on the Arbitrum chain. We'll discuss the different pathways available—sending transactions to the Sequencer or bypassing it by submitting transactions through the Delayed Inbox contract on the parent chain. By outlining these options, we'll clarify how you can interact with the network, detail the processes involved in each method, and identify the modules responsible for handling these transactions. This overview will enhance your understanding of the initial steps in Arbitrum's transaction lifecycle and prepare you for a detailed exploration of transaction inclusion mechanisms in the subsequent sections. -The first subsection, [Submitting Transactions to the Sequencer](#submitting-transactions-to-the-sequencer), presents four different methods users can utilize to send their transactions to the sequencer: via Public RPC, Third-Party RPC, Arbitrum Nodes, and the Sequencer Endpoint. Transactions sent through the first three pathways will route through our Load Balancer before reaching the sequencer. In contrast, the Sequencer Endpoint allows transactions to bypass the Load Balancer and be sent directly to the sequencer. +The first subsection, [Submitting transactions to the Sequencer](#submitting-transactions-to-the-sequencer), presents four different methods you can use to send your transactions to the sequencer: via Public RPC, Third-Party RPC, Arbitrum Nodes, and the Sequencer Endpoint. Transactions sent through the first three pathways will route through our Load Balancer before reaching the sequencer. In contrast, the Sequencer Endpoint allows transactions to bypass the Load Balancer and be sent directly to the sequencer. -The second subsection, [Bypassing the Sequencer](#bypassing-the-sequencer), describes an alternative method where users can include their transactions on the Arbitrum chain without relying on the sequencer. By sending transactions directly to the Delayed Inbox contract on the parent chain, users gain additional flexibility, ensuring that their transactions can be processed even if the sequencer is unavailable or if they prefer not to use it. +The second subsection, [Bypassing the Sequencer](#bypassing-the-sequencer), describes an alternative method where you can include your transactions on the Arbitrum chain without relying on the sequencer. By sending transactions directly to the Delayed Inbox contract on the parent chain, you gain additional flexibility, ensuring that your transactions can be processed even if the sequencer is unavailable or if you prefer not to use it. This diagram illustrates the various pathways for submitting transactions to the Arbitrum chain. It highlights the options for sending transactions through the sequencer or bypassing it and using the Delayed Inbox contract on the parent chain. @@ -23,33 +24,33 @@ This diagram illustrates the various pathways for submitting transactions to the className="img-600px" /> -## Submitting transactions to the Sequencer +## Submitting transactions to the sequencer -This section outlines the different methods for users to submit transactions to the sequencer on the Arbitrum chain. There are four primary ways to do this: Public RPC, Third-Party RPCs, Arbitrum Nodes, and the Sequencer Endpoint. We will explore these methods in detail, explaining when to choose one over the other and how to use each to effectively submit transactions to the Arbitrum sequencer. +This section outlines the different methods you can use to submit transactions to the sequencer on the Arbitrum chain. There are four primary ways to do this: Public RPC, Third-Party RPCs, Arbitrum Nodes, and the Sequencer Endpoint. We'll explore these methods in detail, explaining when to choose one over the other and how to use each to effectively submit transactions to the Arbitrum sequencer. ### 1. Public RPC Arbitrum provides public RPCs for its main chains: Arbitrum One, Arbitrum Nova, and Arbitrum Sepolia. Due to their rate-limited nature, these RPC endpoints are suitable for less resource-intensive operations. Public RPCs can be an accessible option for general use cases and light interactions with the network. -For more details on the specific RPC endpoints for each chain, please see [this section](https://docs.arbitrum.io/build-decentralized-apps/reference/node-providers#arbitrum-public-rpc-endpoints) of the documentation. +For more details on the specific RPC endpoints for each chain, please see [the Arbitrum public RPC endpoints section](https://docs.arbitrum.io/build-decentralized-apps/reference/node-providers#arbitrum-public-rpc-endpoints) of the documentation. -### 2. Third-Party RPC +### 2. Third-party RPC -Users also have the option to interact with Arbitrum's public chains using third-party node providers. These providers are often the same popular ones used for Ethereum, making them reliable choices for resource-intensive operations. We recommend using these third-party providers when performance and scalability are critical. +You also have the option to interact with Arbitrum's public chains using third-party node providers. These providers are often the same popular ones used for Ethereum, making them reliable choices for resource-intensive operations. We recommend using these third-party providers when performance and scalability are critical. -You can find a list of supported third-party providers [here](https://docs.arbitrum.io/build-decentralized-apps/reference/node-providers#third-party-rpc-providers). +You can find [a list of supported third-party providers](https://docs.arbitrum.io/build-decentralized-apps/reference/node-providers#third-party-rpc-providers) in our documentation. -### 3. Arbitrum Nodes +### 3. Arbitrum nodes Another approach for sending transactions to the sequencer is through self-hosted Arbitrum nodes. Running a node gives you direct control over your transactions, which go to the sequencer via the Sequencer Feed. -Please see the [Arbitrum Node](https://docs.arbitrum.io/run-arbitrum-node/overview) documentation to learn more about setting up and running a node. +Please see the [Arbitrum node documentation](https://docs.arbitrum.io/run-arbitrum-node/overview) to learn more about setting up and running a node. -### 4. Sequencer Endpoint +### 4. Sequencer endpoint -The Sequencer Endpoint is the most direct method for users looking to minimize delays in their transactions reaching the sequencer. Unlike standard RPC URLs, the Sequencer Endpoint supports only `eth_sendRawTransaction` and `eth_sendRawTransactionConditional` calls, bypassing the load balancer entirely. This endpoint makes it an optimal choice for users who require the quickest transaction processing time. +The Sequencer Endpoint is the most direct method if you're looking to minimize delays in your transactions reaching the sequencer. Unlike standard RPC URLs, the Sequencer Endpoint supports only `eth_sendRawTransaction` and `eth_sendRawTransactionConditional` calls, bypassing the load balancer entirely. This endpoint makes it an optimal choice if you require the quickest transaction processing time. -The diagram below shows different ways to submit transactions to the Sequencer: +The diagram below shows different ways to submit transactions to the sequencer: -## Bypassing the Sequencer +## Bypassing the sequencer -This section delves into an alternative method for submitting transactions to the Arbitrum chain, bypassing the Sequencer. This page focuses on how users can send their transactions directly to the Delayed Inbox contract on the parent chain rather than through the Sequencer. This method offers two distinct paths a transaction can take, with each route interacting with the network differently to achieve transaction inclusion. This approach provides users with greater flexibility and ensures that transactions can still be processed if the Sequencer is unavailable or if users choose not to depend on it. This section highlights these alternative submission mechanisms and underscores the robustness and decentralization features inherent in the Arbitrum network. +This section delves into an alternative method for submitting transactions to the Arbitrum chain, bypassing the sequencer. This page focuses on how you can send your transactions directly to the Delayed Inbox contract on the parent chain rather than through the sequencer. This method offers two distinct paths a transaction can take, with each route interacting with the network differently to achieve transaction inclusion. This approach provides you with greater flexibility and ensures that transactions can still be processed if the sequencer is unavailable or if you choose not to depend on it. This section highlights these alternative submission mechanisms and underscores the robustness and decentralization features inherent in the Arbitrum network. -In **Diagram 3**, we demonstrate how users can submit their transactions using the Delayed Inbox contract to bypass the Sequencer. As illustrated in the diagram, there are two possible paths for transaction handling. When a transaction is submitted to the Delayed Inbox, the Sequencer may automatically pick it up, include it as an ordered transaction, and send it to the Sequencer feed. However, if the Sequencer does not process the transaction within 24 hours, users have the reliable option to call the `forceInclude` function on the `SequencerInbox` contract. This action ensures that the Sequencer to picks up the transaction and includes it in the ordered transaction list, providing users with a sense of security about their transactions. +In **Diagram 3**, we demonstrate how you can submit your transactions using the Delayed Inbox contract to bypass the sequencer. As illustrated in the diagram, there are two possible paths for transaction handling. When a transaction is submitted to the Delayed Inbox, the sequencer may automatically pick it up, include it as an ordered transaction, and send it to the sequencer feed. However, if the sequencer doesn't process the transaction within 24 hours, you have the reliable option to call the `forceInclude` function on the `SequencerInbox` contract. This action ensures that the sequencer picks up the transaction and includes it in the ordered transaction list, providing you with security about your transactions. -To send a transaction to the Delayed Inbox instead of submitting it to the sequencer, users can construct their transaction and then call the [`sendL2Message`](https://github.com/OffchainLabs/nitro-contracts/blob/fbbcef09c95f69decabaced3da683f987902f3e2/src/bridge/AbsInbox.sol#L150) function, passing the data of the serialized signed transaction as an argument. This function allows users to send a generic child chain messages to the chain, suitable for any message that does not require parent chain validation. +To send a transaction to the Delayed Inbox instead of submitting it to the sequencer, you can construct your transaction and then call the [`sendL2Message`](https://github.com/OffchainLabs/nitro-contracts/blob/fbbcef09c95f69decabaced3da683f987902f3e2/src/bridge/AbsInbox.sol#L150) function, passing the data of the serialized signed transaction as an argument. This function allows you to send generic child chain messages to the chain, suitable for any message that doesn't require parent chain validation. -If the sequencer is not back online within 24 hours or decides to censor the transaction, users can invoke the [`forceInclusion`](https://github.com/OffchainLabs/nitro-contracts/blob/fbbcef09c95f69decabaced3da683f987902f3e2/src/bridge/SequencerInbox.sol#L284) function on the `SequencerInbox` contract. This action ensures their transaction is included on the chain, bypassing the sequencer's role. +If the sequencer isn't back online within 24 hours or decides to censor the transaction, you can invoke the [`forceInclusion`](https://github.com/OffchainLabs/nitro-contracts/blob/fbbcef09c95f69decabaced3da683f987902f3e2/src/bridge/SequencerInbox.sol#L284) function on the `SequencerInbox` contract. This action ensures your transaction is included on the chain, bypassing the sequencer's role. -Additionally, the Arbitrum SDK provides the [`InboxTools`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L64C14-L64C24) class, which simplifies the process of submitting transactions to the Delayed Inbox. Users can utilize the [`sendChildSignedTx`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L401C16-L401C33) method to send the transaction and the [`forceInclude`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L367) method to ensure its inclusion. The SDK also offers helper methods like [`signChildTx`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L429) to assist with signing the transaction during the creation of the serialized signed transaction hex string, streamlining the entire process. +Additionally, the Arbitrum SDK provides the [`InboxTools`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L64C14-L64C24) class, which simplifies the process of submitting transactions to the Delayed Inbox. You can use the [`sendChildSignedTx`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L401C16-L401C33) method to send the transaction and the [`forceInclude`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L367) method to ensure its inclusion. The SDK also offers helper methods like [`signChildTx`](https://github.com/OffchainLabs/arbitrum-sdk/blob/792a7ee3ccf09842653bc49b771671706894cbb4/src/lib/inbox/inbox.ts#L429) to assist with signing the transaction during the creation of the serialized signed transaction hex string, streamlining the entire process.