Skip to content

docs: update transaction lifecycle page to comply with style guide #2785

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 17, 2025
Merged

docs: update transaction lifecycle page to comply with style guide #2785

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6b977ce
docs: update transaction lifecycle page to comply with style guide
anegg0 Oct 17, 2025
6be541c
Merge branch 'master' into fix-how-arbitrum-works-transaction-lifecycle
anegg0 Oct 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 27 additions & 26 deletions docs/how-arbitrum-works/02-transaction-lifecycle.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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 <a data-quicklook-from="arbitrum">Arbitrum</a> chain. We discuss the different pathways available—sending transactions to the <a data-quicklook-from="sequencer">Sequencer</a> or bypassing it by submitting transactions through the <a data-quicklook-from="delayed-inbox">Delayed Inbox</a> contract on the <a data-quicklook-from="parent-chain">parent chain</a>. 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 <a data-quicklook-from="transaction">Transaction</a> 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 <a data-quicklook-from="arbitrum">Arbitrum</a> chain. We'll discuss the different pathways available—sending transactions to the <a data-quicklook-from="sequencer">Sequencer</a> or bypassing it by submitting transactions through the <a data-quicklook-from="delayed-inbox">Delayed Inbox</a> contract on the <a data-quicklook-from="parent-chain">parent chain</a>. 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 <a data-quicklook-from="transaction">transaction</a> 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 <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> 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 <a data-quicklook-from="arbitrum-chain">Arbitrum chain</a> 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.

Expand All @@ -23,54 +24,54 @@ 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: <a data-quicklook-from="arbitrum-one">Arbitrum One</a>, <a data-quicklook-from="arbitrum-nova">Arbitrum Nova</a>, 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 <a data-quicklook-from="sequencer-feed">Sequencer Feed</a>.

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:

<ImageZoom
src="/img/haw-submit-tx-to-sequencer.svg"
alt="Submit transaction to the Sequencer"
className="img-600px"
/>

## 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.

<ImageZoom
src="/img/haw-bypassing-the-sequencer.svg"
alt="Bypassing the Sequencer"
className="img-600px"
/>

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.