docs: tw-1009-stf-deep-dive

docs/how-arbitrum-works/01-inside-arbitrum-nitro.mdx

@@ -29,7 +29,7 @@ Transactions first enter the Inbox, serving as the primary gateway into the ecos
 
 The deterministic model ensures that identical inputs will always produce the same outputs, among honest nodes, forming the bedrock of Arbitrum’s security. It supports efficient fraud proofs and dispute resolution, enabling verification of execution correctness without re-running entire transactions, thereby minimizing computational overhead.
 
-For foundational concepts about the STF, see the [State Transition Function gentle introduction](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx).
+For foundational concepts about the STF, see the [State Transition Function deep dive](/how-arbitrum-works/deep-dives/stf.mdx).
 
 ## Step 1: Submitting a transaction
 
@@ -63,7 +63,7 @@ For a deeper look at how the Sequencer orders, batches, and posts transactions,
 
 With ordering and batching complete, execution shifts to the State Transition Function (STF), the core of Arbitrum's processing engine.
 
-For foundational concepts about how the STF works, see the [State Transition Function gentle introduction](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx).
+For foundational concepts about how the STF works, see the [State Transition Function deep dive](/how-arbitrum-works/deep-dives/stf.mdx).
 
 Arbitrum ensures full Ethereum Virtual Machine (EVM) compatibility via a three-layer architecture. At the base, the <a data-quicklook-from="geth">Geth</a> core handles EVM execution, aligning behaviors with Ethereum and drawing on its extensively tested code for security.
 
@@ -174,7 +174,7 @@ In this overview, you've learned about the complete transaction journey through
 - [Transaction Lifecycle](/how-arbitrum-works/deep-dives/transaction-lifecycle.mdx): Detailed transaction lifecycle from submission to finality
 - [Sequencer](/how-arbitrum-works/deep-dives/sequencer.mdx): How the Sequencer orders, batches, and posts transactions
 - [Gas and fees](/how-arbitrum-works/deep-dives/gas-and-fees.mdx): Gas pricing, fee calculations, and adaptive pricing algorithm
-- [State Transition Function: Gentle Introduction](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx): Foundational concepts of the STF
+- [State Transition Function](/how-arbitrum-works/deep-dives/stf.mdx): Foundational concepts of the STF
 - [Geth](/how-arbitrum-works/reference/geth.mdx): Geth core and EVM compatibility
 - [ArbOS](/how-arbitrum-works/deep-dives/arbos.mdx): Arbitrum Operating System features and capabilities
 - [State Transition Function inputs](/how-arbitrum-works/reference/stf-inputs.mdx): Message types and STF processing mechanics

docs/how-arbitrum-works/deep-dives/arbos.mdx

@@ -7,7 +7,7 @@ user_story: As a current or prospective Arbitrum user, I need to learn more abou
 content_type: concept
 ---
 
-ArbOS is the child-EVM virtual machine monitor (VMM—aka hypervisor) for the Arbitrum chain, providing the execution environment for the chain. It acts as a trusted “system glue” component within the [State Transition Function (STF)](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx).
+ArbOS is the child-EVM virtual machine monitor (VMM) for <a data-quicklook-from="arbitrum-nitro">Arbitrum Nitro</a>. It's a trusted system component that lives inside the [State Transition Function (STF)](/how-arbitrum-works/deep-dives/stf.mdx) and provides the execution environment for the chain. Unlike a conventional operating system, ArbOS is not a process running beside the chain—it's ordinary Go code compiled into the STF, so every node (and <a data-quicklook-from="fraud-proof">fraud prover</a>) can replay it deterministically.
 
 ArbOS is responsible for:
 

docs/how-arbitrum-works/deep-dives/assertions.mdx

@@ -40,7 +40,7 @@ For more details on how the Rollup chain works under <a data-quicklook-from="bol
 
 :::note Validators and proposers serve different roles
 
-Validators validate transactions by computing the next <a data-quicklook-from="chain-state">chain state</a> using the chain's [STF](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx), whereas proposers can also assert and challenge the chain state on the parent chain.
+Validators validate transactions by computing the next <a data-quicklook-from="chain-state">chain state</a> using the chain's [STF](/how-arbitrum-works/deep-dives/stf.mdx), whereas proposers can also assert and challenge the chain state on the parent chain.
 
 :::
 

docs/how-arbitrum-works/deep-dives/batchposter.mdx

@@ -0,0 +1,51 @@
+---
+title: The batch poster
+description: 'Learn the fundamentals of the Arbitrum batch poster.'
+author: pete-vielhaber
+sme: Mehdi
+user_story: As a current or prospective Arbitrum user, I need to learn more about the batch poster.
+content_type: reference
+---
+
+Batch posting is a fundamental process for the <a data-quicklook-from="sequencer">Sequencer's</a> operation in Arbitrum. It involves collecting multiple <a data-quicklook-from="child-chain">child chain</a> <a data-quicklook-from="transaction">transactions</a>, organizing them into <a data-quicklook-from="batch">batches</a>, compressing the data to reduce size, and sending these batches to the <a data-quicklook-from="sequencer-inbox">Sequencer Inbox</a> contract on the <a data-quicklook-from="parent-chain">parent chain</a>. This mechanism securely records transactions on the parent chain while optimizing for costs and performance.
+
+## How it works
+
+<ImageZoom src="/img/batchposter-path.svg" alt="Batch poster path. The batch poster pulls sequenced messages from the `TransactionStreamer`, builds a block, routes the data to a data availability provider, encodes the parent chain transaction as calldata or blobs with a delay proof, verifies the batch, posts the transaction, and lands it in the parent chain SequencerInbox contract. Building a block expands into four substeps: compute the parent chain block bounds, fill batch segments and compress them with adaptive Brotli, decide whether to post now or wait, and CloseAndGetBytes to recompress at a higher level, which returns to building the block. Posting expands into three substeps: fee calculation, nonce management, and sign and send, which returns to posting the transaction." className="img-600px" />
+
+#### 1. Messages arrive (upstream handoff)
+
+A transaction’s journey into the <a data-quicklook-from="batch-poster">batch poster</a> begins after it’s already been [sequenced](/how-arbitrum-works/deep-dives/sequencer.mdx). The poster pulls ordered child chain messages from the `TransactionStreamer`—that’s a handoff into the batch poster; sequencing, [execution](/how-arbitrum-works/deep-dives/stf.mdx), and [soft finality](/how-arbitrum-works/reference/finality-and-reorgs.mdx#the-three-confirmation-levels) all happened before this point and live outside of the batch poster.
+
+#### 2. The poster decides where it stands
+
+The main loop (`MaybePostSequencerBatch`) first does a safety check (refuse to post if a prior batch reverted), then asks “what batch number and the parent chain nonce am I on?” and establishes the parent chain time/block window the batch will use. That window comes from reading the parent chain SequencerInbox contract’s `MaxTimeVariation`—a read-only handoff out to the parent chain.
+
+#### 3. Messages become a compressed batch
+
+The poster receives messages in order, turning each into typed segments (the transaction itself, plus small bookkeeping notes for <a data-quicklook-from="delayed-inbox">delayed-message</a> markers and time/block advances) and streaming them through Brotli. It watches size and segment-count caps, and adapts compression effort to how far behind it is—more compression when calm, less when backlogged. When it decides the batch is ready (full enough, old enough, or a delayed message is about to expire), it seals and recompresses it. This is the core work done inside the batch poster.
+
+#### 4. The data is routed to storage (DA handoff)
+
+The sealed bytes are handed to a data availability (DA) provider—an offchain <a data-quicklook-from="data-availability-committee-dac">AnyTrust</a>/<a data-quicklook-from="data-availability-server-das">DAS</a> committee or a custom backend—via the small Writer.Store interface, with a fallback to putting data directly on Ethereum (calldata or <a data-quicklook-from="blob">blobs</a>). What comes back is either a <a data-quicklook-from="data-availability-certificate">certificate</a> (offchain) or the raw data (EthDA). The committee aggregation, <a data-quicklook-from="bls-signature">BLS signing</a>, and blob KZG cryptography all happen behind that interface—handoffs that the batch poster isn’t involved in.
+
+#### 5. The batch is wrapped for the parent chain and self-checked
+
+The poster builds calldata for the right `SequencerInbox` method (calldata vs. blobs, with or without a delay proof) and—as a correctness gate—replays the whole batch through the `InboxMultiplexer` (the same read/decode machinery used to consume batches) to confirm it decodes back to the exact original messages before anything is sent.
+
+#### 6. The transaction is shipped to the parent chain (`DataPoster` handoff)
+
+The batch poster hands the calldata, blobs, and gas estimate to the `DataPoster`—the “shipping department.” From here, nonce selection, fee bidding, signing, queue persistence, and replace-by-fee-if-stuck are the `DataPoster`’s job, deliberately kept separate so the batch poster never has to deal with Ethereum gas mechanics. The `DataPoster` ultimately submits the transaction to the parent chain `SequencerInbox` contract.
+
+#### 7. Finality and feedback
+
+Once the parent chain transaction confirms, the transactions cross from the Sequencer’s soft finality into [hard finality](/how-arbitrum-works/reference/finality-and-reorgs.mdx) anchored on the parent chain. The poster updates its backlog estimate (feeding back into compression effort and fee urgency), and a background revert watcher monitors the parent chain—if a posted batch ever fails onchain, it halts all posting for operator intervention.
+
+## Related resources
+
+- [The Sequencer and censorship resistance](/how-arbitrum-works/deep-dives/sequencer.mdx#posting-to-the-parent-chain): batching, compression, and the Sequencer Inbox methods.
+- [Sequencer transaction flow](/how-arbitrum-works/deep-dives/sequencer-transaction-flow.mdx): what happens before the handoff, from the queue to block creation.
+- [Gas and fees](/how-arbitrum-works/deep-dives/gas-and-fees.mdx#parent-chain-gas-pricing): how the parent chain pricer reimburses batch posting costs.
+- [Finality and reorgs](/how-arbitrum-works/reference/finality-and-reorgs.mdx): what parent chain finality guarantees, and the failure modes around posting.
+- [AnyTrust protocol](/how-arbitrum-works/deep-dives/anytrust-protocol.mdx): what the DAC does with the data behind the DA handoff.
+- [Run a batch poster](/launch-arbitrum-chain/run-a-node/batch-poster.mdx) and [Batch poster troubleshooting](/launch-arbitrum-chain/operate/batch-poster-troubleshooting.mdx): the operator view.

docs/how-arbitrum-works/deep-dives/gas-and-fees.mdx

@@ -16,7 +16,7 @@ There are two parties a user pays when submitting a transaction:
 
 The parent chain component is the product of the <a data-quicklook-from="transaction">transaction</a>'s estimated contribution to its <a data-quicklook-from="batch">batch</a>'s size—computed using [Brotli](/how-arbitrum-works/deep-dives/sequencer.mdx#posting-to-the-parent-chain) on the transaction alone—and the child chain's view of the parent chain data price. This value dynamically adjusts over time to ensure the batch poster is ultimately fairly compensated.
 
-The child chain component consists of the traditional fees <a data-quicklook-from="geth">Geth</a> would pay to bonders in a vanilla parent chain, such as the computation and storage charges that apply to the [<a data-quicklook-from="state-transition-function">State Transition Function</a> (STF)](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx). [<a data-quicklook-from="arbos">ArbOS</a>](/how-arbitrum-works/deep-dives/arbos.mdx) charges additional fees for executing its child-chain-specific [precompiles](/arbitrum-essentials/precompiles/overview.mdx), whose fees are dynamically priced based on the resources used during execution.
+The child chain component consists of the traditional fees <a data-quicklook-from="geth">Geth</a> would pay to bonders in a vanilla parent chain, such as the computation and storage charges that apply to the [<a data-quicklook-from="state-transition-function">State Transition Function</a> (STF)](/how-arbitrum-works/deep-dives/stf.mdx). [<a data-quicklook-from="arbos">ArbOS</a>](/how-arbitrum-works/deep-dives/arbos.mdx) charges additional fees for executing its child-chain-specific [precompiles](/arbitrum-essentials/precompiles/overview.mdx), whose fees are dynamically priced based on the resources used during execution.
 
 The following sections detail how parent and child chain fees are calculated. For a practical guide on estimating gas for your transactions, see [How to estimate gas in Arbitrum](/arbitrum-essentials/how-to-estimate-gas.mdx).
 

docs/how-arbitrum-works/deep-dives/sequencer.mdx

@@ -27,7 +27,7 @@ Once the Sequencer has a finalized ordering, it calls the ExecutionEngine, which
 
 <VanillaAdmonition type="note" title="Handoff: execution belongs to ArbOS and the STF">
 
-Everything from this point of execution—iterating the ordered transactions, applying pre- and post-execution filters, running each transaction against chain state, metering child- and parent-chain gas, and computing the resulting state—is the job of the [State Transition Function](/how-arbitrum-works/deep-dives/01-stf-gentle-intro.mdx) and [ArbOS](/how-arbitrum-works/deep-dives/arbos.mdx). The Sequencer supplies the ordered input and receives a produced block in return; it does not decide execution outcomes.
+Everything from this point of execution—iterating the ordered transactions, applying pre- and post-execution filters, running each transaction against chain state, metering child- and parent-chain gas, and computing the resulting state—is the job of the [State Transition Function](/how-arbitrum-works/deep-dives/stf.mdx) and [ArbOS](/how-arbitrum-works/deep-dives/arbos.mdx). The Sequencer supplies the ordered input and receives a produced block in return; it does not decide execution outcomes.
 
 </VanillaAdmonition>