Cross-chain Workflow

This section describes the cross-chain operation execution pipeline model. Batching parameters and routing rules are determined by the set of supported networks and integrations.

Key points:

• An operation is decomposed into steps, each step has a network and artifacts (txHash, sometimes messageId).
• Each step is idempotent and can be repeated without double effect.
• Statuses are updated based on network data and read services (RPC, indexers).

In this chapter, workflow is considered as a deterministic state machine. Requirements for step idempotency, status observability, and recovery from failures of the client environment, RPC, and cross-chain interaction are considered.

Cross-chain operations in SAI Wallet are described as workflows of steps. Each step is linked to a specific network and has recordable execution artifacts. Such a model allows executing one user scenario (e.g., “transfer USDT and place in strategy”) as a sequence of observable stages.

Workflow State Model

A workflow starts with preparation and quota, then transitions to sending steps in the source network and, if necessary, to cross-chain delivery and execution in the destination network.

Below is a simplified set of states:

• Created - workflow formed and validated;
• Quoted - fees and expected results calculated;
• SourceSubmitted - transactions sent in the source network;
• MessageDispatched - cross-chain delivery initiated (if the route is cross-chain);
• DestinationExecuted - actions executed in the destination network;
• Completed - result confirmed and recorded.

States reflect the observable reality of execution: transitions are confirmed by transaction receipts and events.

Mechanisms for cross-chain message delivery and classes of applied solutions are discussed in the Messaging and Alternatives section.

Stopped is used as a terminal state if the operation does not transition to the next stage due to a reason recorded in the receipt or execution rules (e.g., rejection due to slippage limit).

Idempotency and Step Connectivity

Cross-chain execution requires stable connectivity between stages. In the operation model, the following are used:

• operationId - workflow identifier at the SAI Wallet level;
• txHash_source - source transaction hash;
• messageId - message identifier (if supported by the selected implementation);
• txHash_destination - destination network transaction hash (if applicable).

Idempotency is achieved by the fact that message re-delivery does not lead to repeated state changes. At the contract and receiver level, this is usually expressed by checking nonce/messageId and a registry of processed operations.

Batching

Batching is combining several actions into one transaction where the network and protocol support it. In EVM networks, batching is often implemented through multicall or through a router that executes a chain of calls in one tx.

Practical meaning of batching in SAI Wallet:

• reducing the number of user confirmations;
• reducing total fees if multiple calls are executed in one tx;
• simplifying the status model for the intra-network part of the route (one receipt instead of several).

However, batching is limited by network boundaries: a cross-chain operation cannot be made “one transaction” in the strict sense, because steps are executed in different networks.

Group Operations (optional)

A group operation is a workflow in which the same route is applied to multiple recipients or multiple positions. At the model level, this is expressed as a set of sub-operations that share a common quota and common network context but record separate amounts and destination addresses.

Group operations are useful for fund distribution scenarios and batch position management, but their cost depends on the number of actions and the possibility of batching in a specific network.

Operation Completion and Stop Reasons

An operation is considered completed when the result is confirmed in the corresponding networks and reflected in the portfolio and position aggregator. If a workflow stops, the reason is recorded at the level of a specific step and linked to the execution artifact (receipt, RPC error code, contract event).

Common stop reasons include: insufficient fee in the step network, rejection due to slippage limit, execution deadline expiration, contract rejection during parameter validation, as well as finality differences and cross-chain delivery delays. These reasons are used in SAI Wallet as part of the operation status, without turning the chapter into a diagnostics section.