How It Works

From intent to verified delivery

A single page describing the exact journey a payment takes, and what the system checks at each step.

The journey

  1. Connect a wallet. The app detects the account and its active network, and confirms it is Monad mainnet (chain id 143).
  2. Express the intent. Enter a recipient, an amount, and the token the recipient should receive — by form, or in plain English in the intent bar (for example, “Send $10 worth of USDC to 0x…”).
  3. Read reality. The app loads the wallet's real balances (on-chain-confirmed), prices the assets, and finds routes from the assets held to the asset requested.
  4. Choose the source. A deterministic engine picks which asset to spend and states why in plain language. If nothing is executable, it says exactly why.
  5. Prepare the transaction. The plan is built with a real on-chain minimum output (or maximum input) so the recipient cannot be short-changed by the route.
  6. Review. You see the recipient, what they receive, what you spend, the estimated network fee and any warnings. Advanced routing detail is available under an expandable section, hidden by default.
  7. Confirm and send. Your wallet is asked to authorize the exact prepared transaction.
  8. Follow status. The app tracks the real transaction, and reports success only after the receipt confirms and the recipient's transfer is verified.

Two intent modes

  • Recipient receives (default). You fix what they get; the app prices what you pay.
  • I spend. You fix what you pay; the app shows what they receive. A shortfall in “I spend” mode is expected; exact-payment protection only fires on over-delivery.

What happens between review and signature

The signing guard is the only path to a signature. Immediately before the wallet is asked to sign, it:

  1. reads the current canonical intent and captures its version key;
  2. fetches fresh balances and a fresh quote;
  3. rebuilds the transaction plan from those fresh values;
  4. re-reads the intent and confirms it did not change mid-preparation;
  5. confirms the quote is still fresh and the price impact is acceptable;
  6. confirms the balances still cover the payment and the MON network fee;
  7. confirms every swap step carries a real output bound;
  8. re-reads the wallet account and the intent one final time.

Any mismatch aborts with a specific, human-readable reason. Calldata is never reused from an earlier build.

Errors that recover, and errors that stop

  • Recoverable: a moved price, a stale quote, a drained balance, an account switch. The review stays in place, shows the specific reason, refreshes the quote, and offers a retry.
  • Stopping: no route, an unsupported token, a rejected signature, a network mismatch, insufficient MON. The app explains the problem before execution.
Never a silent resubmission
If a transaction may already have been broadcast, the app does not automatically resubmit it. An unprovable delivery is shown as unverified rather than as success.

A note on gas

Every payment is executed through your own injected wallet and the network fee is paid in native MON. There is no sponsored or ERC-20 gas path. If your wallet does not hold enough MON, the app tells you before you start, rather than implying gas will be covered another way. See /docs/litepaper §10.