Architecture & lifecycle

NavoSwap is engineered as a privacy-preserving execution system that prioritizes minimal data exposure while maintaining high reliability across multiple chains. This section summarizes architectural goals, trust boundaries, the swap lifecycle, failure handling, and correlation resistance.

Architectural goals

The system is designed to satisfy the following goals simultaneously:

• Wallet-free user experience: Users should not connect wallets, sign messages, or expose holdings to initiate swaps.
• Graph discontinuity: Input and output should not be trivially linkable through public transaction graph analysis.
• Deterministic execution: The swap system must behave predictably, with clear status states and recoverable execution.
• Interoperability: Support multiple chains and assets while accessing deep liquidity.
• Operational safety: Handle failures, delays, and congestion without exposing identity data or creating ambiguous outcomes.

Trust model and data minimization

NavoSwap is designed so that no single component (and ideally no single operator) can easily reconstruct the full story of a swap.

Trust boundary principles

• The frontend should not learn wallet identity or full wallet history.
• Deposit addresses are single-use to prevent behavioral linking.
• Internal services operate on order IDs, not user profiles.
• Logs are minimized and scrubbed of sensitive correlation data.

What NavoSwap intentionally does not do

• Does not require user accounts
• Does not require wallet connections
• Does not store complete wallet histories
• Does not publish user identity metadata

Execution lifecycle

The swap lifecycle is modeled as a deterministic state machine. High-level states include:

1. Quote requested: User selects input asset, output asset, amount, and destination address. The system returns quote window, fees, and estimated completion time.
2. Order created: Coordinator generates order ID and single-use deposit address. The order is locked to parameters (assets, destination, time window).
3. Awaiting deposit: Deposit monitor watches for inbound funds. Order remains inactive until required confirmations are reached.
4. Deposit confirmed: Funds confirmed with chain-specific finality rules. Execution window opens.
5. Navo phase (routing): Value is routed through privacy-preserving paths. Graph discontinuity is introduced.
6. Execution phase (swap + settlement): Liquidity aggregation selects execution route; swap executor completes conversions and prepares output delivery.
7. Payout initiated: Output funds are sent to the destination address.
8. Completed: Order is finalized and marked complete.
9. Expired / refunded (conditional): If deposit is not received in time or execution fails under defined conditions, refund logic may apply based on chain support and policy.

State machine (reference)

Primary path: Quote requested → Order created → Awaiting deposit → Deposit confirmed → Navo phase → Execution phase → Payout initiated → Completed.

Failure paths may include: awaiting deposit → expired; deposit confirmed → refunded (policy-dependent); execution phase → retry / manual review (policy-dependent). Privacy breakpoints are annotated at single-use deposit address, routing phase segmentation, and output delivery separation.

Failure handling and recovery

Privacy systems must be resilient. Users should never be forced into identity exposure to resolve operational issues.

Common failure scenarios

• Deposit not detected: Wrong amount, asset, chain, or delayed propagation. Order remains in “awaiting deposit” until timeout; user can verify deposit address and chain transaction hash.
• Deposit detected but not confirmed: Congestion or reorg risk. Status reflects confirmation progress; execution begins only after finality thresholds.
• Route / execution slippage exceeded: Executor re-quotes within tolerance; if outside tolerance, swap may pause for retry within defined windows.
• Liquidity provider failure: Fallback providers; best-path selection prioritizes reliability.
• Output delivery delayed: Payout remains in “payout initiated” with chain transaction tracking.

Deterministic recovery rules

• Every order has a clear timeout policy.
• Every state transition is logged internally by order ID.
• Users receive status updates without providing identity.
• Where refunds exist: refund destination is policy-defined; refunds do not require wallet connection and may use proof such as transaction hash plus deposit address.

Privacy controls and correlation resistance

NavoSwap reduces correlation risk through layered controls:

• Single-use deposit infrastructure to prevent deposit reuse patterns
• Segmentation of routing knowledge so no subsystem has full context
• Timing noise / batching options (future) to reduce timing correlation
• Minimal log retention with scrubbing of sensitive correlation identifiers

NavoSwap aims to provide practical transaction discretion while preserving reliability and usability.