Transaction Lifecycle

This guide walks through every step of a swap transaction β€” from requesting a quote to receiving on-chain confirmation β€” with error handling and edge cases at each step.


Overview

A complete swap involves three services and twelve distinct steps:

Client          arb-algo              mx-relayer          MultiversX
  β”‚                β”‚                     β”‚                    β”‚
  β”‚ 1. GET /quote  β”‚                     β”‚                    β”‚
  │───────────────▢│                     β”‚                    β”‚
  │◀───────────────│                     β”‚                    β”‚
  β”‚  txData, amountOutMin               β”‚                    β”‚
  β”‚                                     β”‚                    β”‚
  β”‚ 2. subscribe tx-status/{hash}       β”‚                    β”‚
  │────────────────────────────────────▢│                    β”‚
  β”‚                                     β”‚                    β”‚
  β”‚ 3. relay action                     β”‚                    β”‚
  │────────────────────────────────────▢│                    β”‚
  β”‚                              4. validate + co-sign       β”‚
  β”‚                                     β”‚ 5. P2P broadcast   β”‚
  β”‚                                     │───────────────────▢│
  β”‚                                     β”‚           6. execute tx
  β”‚                                     │◀───────────────────│
  β”‚                              7. SaveBlock from notifier  β”‚
  β”‚                                     β”‚                    β”‚
  β”‚ 8. tx-status event                  β”‚                    β”‚
  │◀────────────────────────────────────│                    β”‚

Step-by-Step Guide

Step 1: Get a swap quote

Call the arb-algo quote endpoint with the tokens and amount to swap. The response includes txData (the ready-to-use transaction payload) and amountOutMin (the slippage-protected minimum output).

Error handling at this step:

Error
Cause
Action

unknown token_in

Token identifier is not recognized

Check token format (TICKER-hexcode); use pair-config to validate

routing failed: no path between tokens

No liquidity path exists between the two tokens

Try routing via an intermediate token (e.g., WEGLD) manually

specify either amount_in or amount_out, not both

Both amountIn and amountOut were provided

Provide exactly one

HTTP 429

Rate limit exceeded (100 req/s)

Add backoff

What to extract from the response:

circle-exclamation

Step 2: Connect to the relayer WebSocket

Open a WebSocket connection and wait for it to be ready.


Step 3: Subscribe to gas statistics

Subscribe to gasStats before building the transaction. Use the per-shard percentiles to set a competitive gasPrice β€” see Gas Optimization for the full strategy.


Step 4: Determine relayer address for the sender's shard

Each MultiversX shard has a dedicated relayer wallet. Use the relayer address that matches the sender's shard, and ensure the user signs the transaction with the relayer field present.


Step 5: Build and sign the transaction

Construct the transaction with the relayer field set before signing. The user must sign after the relayer field is included.

circle-exclamation

Step 6: Subscribe to tx-status BEFORE sending

Compute the transaction hash from the signed transaction and subscribe to tx-status/{hash} before sending the relay action. The relayer emits the status event exactly once and never replays it β€” subscribing after the block finalizes means missing the event.


Step 7: Send the relay action

Wait for the relay acknowledgment (relayer accepted and broadcast the transaction) separately from the tx-status confirmation (transaction executed on-chain):

Relay acknowledgment errors:

Error
Cause
Action

invalid relayer address

Wrong relayer for sender's shard

Recalculate shard and select correct address

relayer field missing

Transaction built without relayer field

Rebuild transaction with relayer included

invalid user signature

Signed before adding relayer field

Re-sign with relayer field present

nonce too low

Nonce already used

Fetch current nonce from network and retry

nonce too high

Gap in nonce sequence

Submit earlier nonces first


Step 8: Wait for on-chain confirmation


Complete Example

The following self-contained example performs all steps in sequence.


Edge Cases

tx-status TTL expiry

tx-status/{hash} subscriptions expire after 60 seconds. If a transaction takes longer β€” due to network congestion or cross-shard execution with many metachain rounds β€” the subscription expires without delivering an event.

When this happens:

  1. Poll the MultiversX API: GET https://api.multiversx.com/transactions/{hash} until the status changes from pending.

  2. Re-subscribe to tx-status/{hash} on the relayer immediately β€” the relayer may still receive the event if the block finalizes shortly after your subscription expired.

Cross-shard transactions

When the sender and the aggregator contract are on different shards, the transaction requires two block times: one on the sender's shard and one on the receiver's shard. The tx-status event fires after the receiver's shard processes the cross-shard message, not after the sender's block.

Expect cross-shard swaps to take roughly twice the block time of the slower shard. The networkStats stream exposes shard block times under blockTimeMsP50ByShard β€” see Gas Optimization for details.

Smart contract revert

If the actual swap output falls below amountOutMin β€” because price moved between quote and execution β€” the aggregator smart contract reverts. The transaction hash still appears on-chain with a fail status, and token balances are unchanged. Request a new quote and retry.


Last updated

Was this helpful?