Transaction Lifecycle

Understanding how transactions flow through the Mono Protocol API reveals the sophistication of its unified execution model.

Core Concepts: The numbers shown below are indicative and strongly depend on the use case conditions.

Execution Flow Walkthrough:

1. Initial Request Phase

  • User submits an intent (e.g., swap ETH aggregated across chains for SOL on Solana)

  • Backend handles the request, performing routing and other optimizations

  • Note that spending can happen from multiple chains within the same intent without affecting the flow

2. Providing the Quote

  • The solver system provides a quote that specifies pricing, including gas and swap fees

  • The user receives the quote and decides whether to proceed

  • The user signs the operation with their session key and sends it back to Backend

3. Validation and Security Phase

  • Backend forwards the signed operation to our LL Service

  • The LL Service verifies the user's request and provides security attestation

  • Based on security status, the transaction follows one of these paths:

  • Fast Path via same-chain execution

  • Fast Path via cross-chain execution (immediate execution with security guarantees)

  • Standard Path (execution after the escrow transaction is confirmed)

4. Execution Phase Backend submits operations and security guarantees to the solver. The execution then follows one of three paths:

Fast Path (Same Chain) Same-chain Fast Path is the quickest execution method, completing in seconds:

  1. Solver executes the operation on the target chain

  2. Backend verifies execution and confirms success to the user

  3. Backend executes the operation on the source chain

Fast Path (Cross-Chain) For cross-chain operations with Liquidity Lock guarantees

Standard Path For operations requiring traditional settlement confirmation

Fast Path Execution Criteria: A multichain intent leverages the Fast Path if it's routed on the same chain OR if all of the following conditions are met:

  1. User has enough finalized, non-pre-approved on-chain balance (aggregated across chains) that is not yet locked

  2. There is no source-chain swap in the execution flow

  3. LL Service does not exceed the total open position according to the risk policy

Last updated