NavoSwap
App

Architecture & lifecycle

NavoSwap is a coordinator: we sit between users, liquidity backends, and routing so swaps finish reliably while we leak less data than a typical "connect wallet and broadcast" flow. This page is the engineering sketch—how we want the system to behave, not a formal spec.

Goals

  • No wallet connect for the public swap path—you shouldn't have to sign a message just to see a route.
  • Harder graph linking between "user sent X" and "user got Y" when private routing is on.
  • Predictable states—every order should be in a nameable phase with a clear timeout story.
  • Many chains without forcing you into a tiny liquidity island.
  • Ops that don't deanonymize—support shouldn't need your life story to debug a stuck deposit.

Trust & data

Rules of thumb we follow in design:

  • The public frontend shouldn't need your wallet history.
  • Deposit addresses are one-shot so you can't reuse them as a fingerprint.
  • Internal jobs key off order IDs, not marketing profiles.
  • We trim logs so we're not sitting on correlation junk we don't need.

What we skip on purpose for anonymous swaps:

  • Mandatory accounts
  • Wallet connection to quote
  • Storing full wallet histories
  • Publishing identity metadata

Lifecycle (happy path)

  1. Quote — user picks pair, amount, destination; we return window and fees.
  2. Order created — id + single-use deposit address; parameters are frozen for that ticket.
  3. Awaiting deposit — monitors watch the chain until funds land.
  4. Confirmed — enough confirmations for us to trust the inbound tx.
  5. Routing — privacy-oriented pathing when enabled (the "Navo" segment).
  6. Execution — aggregation picks a route; backends fill the trade.
  7. Payout — outbound tx to the address the user gave us.
  8. Done — terminal success state.

Side paths: timer expires with no deposit, execution fails and we refund or escalate per policy, manual review on edge cases. Privacy breakpoints sit around one-time deposits, segmented routing, and separating payout timing from deposit timing where we can.

Swap execution lifecycle (happy path)
Quote requestedpair, amount, destinationOrder createdorder ID, deposit addressAwaiting depositmonitor inbound fundsDeposit confirmedfinality reachedNavo phaseprivacy-oriented routingExecution phaseaggregate liquidity, swapPayout initiatedsend to destinationCompletedorder finalized

Failure paths include timeout while awaiting deposit, refunds per policy, and execution retries. See State machine (reference) on this page.

When it breaks

  • Wrong tx — wrong asset/chain/amount: order sits until timeout; user verifies hash and address.
  • Slow confirmations — status shows progress; we don't race ahead of finality.
  • Slippage / route blow-ups — executor may re-quote inside tolerance; outside that, we pause or fail loud per rules.
  • LP flake — we fall through the provider list instead of wedging the user forever.
  • Payout delay — you still see "payout in flight" with a chain tx to watch.

Every order has timeouts and internal logs keyed by order id. Refunds, when they exist, shouldn't require you to "prove who you are" beyond what the chain already shows.

Privacy knobs

  • Single-use deposits
  • Split knowledge between subsystems so no one box sees the whole graph
  • Room for timing/batching improvements later
  • Short log retention and scrubbing of identifiers we don't need

We're aiming for practical discretion—real liquidity, real completion rates—not a science project that breaks every time gas spikes.