NOXI Protocol

NOXI introduces a routing layer between deposit and settlement.

Instead of requiring a direct sender-to-recipient transfer, each NOXI Route uses an isolated deposit before settlement to its destination.

The protocol is designed around one simple idea:

A NOXI transfer follows this path:

SENDER
  → ISOLATED DEPOSIT
  → NOXI ROUTING LAYER
  → SETTLEMENT
  → RECIPIENT

NOXI is privacy infrastructure for Solana. It provides isolated deposit routes, a dedicated routing layer, separated settlement, and no site-side wallet connection.

1. Create Route — enter destination and amount. NOXI creates a dedicated route.
2. Isolated Deposit — send SOL to the deposit address generated for that route.
3. Route Through NOXI — the deposit is detected and confirmed before entering the routing layer.
4. Private Settlement — NOXI settles to the destination without a direct sender-to-recipient transfer.

Every transfer is a NOXI Route — a dedicated path with its own isolated deposit, route state, and settlement destination.

Routes are created from the Transfer surface. No wallet connection to the site is required to create or monitor a route.

Each NOXI Route is assigned a dedicated deposit address. Funds enter through that address before routing continues.

One route. One deposit. The address is specific to that transfer lifecycle.

After deposit detection and confirmation, the transfer enters the NOXI routing layer.

Ingress, route state, and egress are handled as distinct stages before private settlement begins.

Settlement is a separate stage from deposit. Once the route is ready, NOXI settles on-chain to the destination.

Protocol fee and network cost are accounted for before the recipient receives the routed amount.

NOXI privacy comes from architecture: isolated deposit routes, separation between deposit and settlement, and no required wallet connection to the site.

Traditional transfers create a direct on-chain path from one wallet to another. NOXI changes the route. Each transfer enters through an isolated deposit address and is settled separately to its destination.

Settlement remains on-chain. The product value is a different path — private routing through the NOXI Protocol — not a claim of absolute invisibility.

Routes advance through a typed state machine:

CREATED
  → AWAITING_DEPOSIT
  → DETECTED
  → CONFIRMING
  → READY
  → PAYOUT_PENDING
  → PAYOUT_SENT
  → COMPLETED

Additional states:
  EXPIRED · UNDERPAID · OVERPAID
  FAILED · MANUAL_REVIEW · NETWORK_DELAY
  INVALID_RECIPIENT · CANCELLED

Each route accounts for:

• Protocol fee — calculated per route
• Network cost — Solana network cost
• Recipient receives — deposit minus protocol fee and network cost

Demo mode uses simulated fee values. Production fee calculation will be server-side and persisted with each route record.

The current build is demo-only. No production custody keys are generated in the client. The frontend never stores private keys and never initiates real payouts.

Operators should treat deposit addresses as single-use route surfaces and enforce TTL, amount matching, and confirmation depth before settlement.

Planned production components:

• Supabase / PostgreSQL — route persistence and status history
• Solana RPC — deposit confirmation and settlement observation
• Deposit address service — isolated address generation (server)
• Transaction watcher — deposit detection loop / webhooks
• Settlement worker — payout queue after READY
• Fee engine — protocol fee and network cost calculation
• Secure key management — HSM/KMS; never client-exposed