WIP Reactflow interactive diagrams

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

@@ -7,15 +7,15 @@ user_story: "As a developer, I need to understand how transactions flow through
 content_type: concept
 ---
 
+import DrawioReactFlow from '@site/src/components/DrawioReactFlow';
+
 ## Transaction processing journey on Arbitrum
 
 As a developer initiating a <a data-quicklook-from="transaction">transaction</a> on <a data-quicklook-from="arbitrum">Arbitrum</a>, gaining a clear understanding of the end-to-end flow—from initial submission through to finality—is helpful, but it isn't required.
 
 This overview methodically traces the transaction lifecycle, emphasizing how Arbitrum’s architecture ensures precise, efficient, and secure handling at every stage. This article covers the complete <a data-quicklook-from="arbitrum-nitro">Arbitrum Nitro</a> stack, beginning with the <a data-quicklook-from="sequencer">Sequencer</a>, which is responsible for transaction ordering, advancing to the <a data-quicklook-from="state-transition-function">State Transition Function</a> (STF) for execution, and culminating in validation mechanisms that uphold integrity.
 
-<ImageZoom src="/img/haw-transaction-lifecycle.png" className="img-600px" alt="Transaction lifecycle">
-  Transaction lifecycle
-</ImageZoom>
+<DrawioReactFlow manifest="/diagrams/haw-transaction-lifecycle.manifest.xml" />
 
 Along the way, you'll learn about Arbitrum's ability to deliver security on par with Ethereum, while achieving fee reductions by a factor of ten and transaction speeds accelerated by a factor of 100 using optimized mechanisms.
 

docs/how-arbitrum-works/deep-dives/transaction-lifecycle.mdx

@@ -7,6 +7,8 @@ user_story: As a current or prospective Arbitrum user, I need to learn more abou
 content_type: concept
 ---
 
+import DrawioReactFlow from '@site/src/components/DrawioReactFlow';
+
 You can submit transactions to <a data-quicklook-from="arbitrum">Arbitrum</a> through two main pathways:
 
 1. **Through the [<a data-quicklook-from="sequencer">Sequencer</a>](/how-arbitrum-works/deep-dives/sequencer.mdx)**: The standard method for most transactions.
@@ -33,7 +35,7 @@ You can also submit transactions directly to the Delayed Inbox contract on the p
 
 The following diagram shows the different ways you can submit transactions to Arbitrum:
 
-<ImageZoom src="/img/haw-transaction-lifecycle.png" alt="Transaction lifecycle diagram showing various pathways for submitting transactions" className="img-600px" />
+<DrawioReactFlow manifest="/diagrams/haw-transaction-lifecycle.manifest.xml" />
 
 ## Submitting transactions to the Sequencer
 

docs/how-arbitrum-works/partials/_retryable-tickets-partial.mdx

@@ -0,0 +1,35 @@
+## Retryable tickets
+
+Retryable tickets are Arbitrum's canonical method for creating parent-to-child chain messages—parent-chain transactions that initiate a message to be executed on a child chain. A retryable is submittable for a fixed cost (dependent only on its calldata size) paid at the parent chain. Critically, the ticket's _submission_ on the parent chain is separable and asynchronous from its _execution_ on the child chain. This design provides atomicity for cross-chain operations: if the parent chain transaction to request submission succeeds (doesn't revert), then the execution of the retryable on the child chain has a strong guarantee to eventually succeed.
+
+For step-by-step instructions on creating retryable tickets, including parameter estimation and SDK usage, see [Creating retryable tickets](/build-decentralized-apps/bridging/cross-chain-messaging.mdx#ethereum-to-arbitrum-messaging).
+
+### Retryable ticket lifecycle
+
+The lifecycle of a <a data-quicklook-from="retryable-ticket">retryable ticket</a> involves three stages: submission, automatic redemption, and manual redemption.
+
+#### Submission
+
+Creating a retryable ticket is initiated with a call to the `createRetryableTicket` function of the inbox contract. Key parameters include the destination address, call value, gas limits, refund addresses, and calldata. The ticket requires sufficient funds to cover both submission costs and gas for child chain execution. Upon successful submission, a unique `TicketID` is created and the `ArbRetryableTx` precompile emits a `TicketCreated` event.
+
+#### Automatic redemption
+
+Upon successful ticket creation, the system checks if conditions are met for automatic redemption: the user's child chain balance must cover the gas costs, and the provided `maxFeePerGas` must meet or exceed the child chain base fee. If these conditions are met, the system automatically attempts to execute the ticket (auto-redeem).
+
+If auto-redemption succeeds, the ticket executes immediately with the original parameters, and excess fees are refunded. If auto-redemption fails (for example, due to insufficient gas or an increase in gas prices), the ticket remains in the retryable buffer for up to one week, allowing for manual redemption.
+
+#### Manual redemption
+
+If automatic redemption fails, anyone can manually redeem the ticket by calling the `ArbRetryableTx` precompile's `redeem` method. The manual redemption attempt donates its call gas to the execution, and the gas limit is not constrained by the original ticket parameters. This allows tickets to be retried with different gas conditions.
+
+Tickets remain in the retryable buffer for one week. If not successfully redeemed within this period, the ticket expires and is automatically discarded. However, tickets can be kept alive indefinitely by paying a fee to extend the lifetime for another full period before expiration.
+
+If a ticket expires without successful redemption, the escrowed `callValue` is refunded to the `callValueRefundAddress` specified during submission. This protects user funds even if execution never succeeds.
+
+#### Receipt types
+
+Retryable tickets produce two types of receipts:
+
+- **Ticket creation receipt**: Confirms successful ticket creation and includes a `TicketCreated` event with the `ticketId`
+- **Redeem attempt receipt**: Records each redemption attempt and includes a `RedeemScheduled` event
+  Only one successful redemption can occur per ticket. Multiple failed redemption attempts each produce a receipt until one succeeds.