Architecture

System Architecture

Auron is structured as five independent layers. Each is replaceable without touching the others — the blockchain is infrastructure, not the product.

Layers

Settlement lifecycle

Every payment moves through a deterministic, persisted state machine. No payment skips a state. No settlement fires on an unverified transaction.

Every transition is atomic (both transactions and status_history update together), immutable (history rows are never updated or deleted), and recoverable (failure classification determines retry, provider switch, or auto-refund automatically).

Internal ledger

Auron maintains a financial ledger independent of blockchain state — the same pattern used by Stripe, Razorpay, and Wise to manage payment state across unreliable external systems.

Blockchain finality ≠ settlement finality. A confirmed Solana transaction does not mean a merchant received INR.

Replayable receipts

Every completed payment produces a cryptographically verifiable receipt. The receipt_hash is a SHA-256 of canonical fields — anyone can independently recompute it and verify Auron's records have not been altered.

{
  "payment_id": "pay_8x92kL",
  "on_chain_hash": "5KtPxQ...wR2",
  "usdc_amount": 5.41,
  "inr_amount": 450,
  "fx_rate": 83.18,
  "merchant_upi": "merchant@paytm",
  "utr": "YESB178011620946032853",
  "receipt_hash": "sha256:a3f9...",
  "audit_trail": [
    { "state": "initiated",  "at": "T+0.0s" },
    { "state": "verified",   "at": "T+2.1s" },
    { "state": "settling",   "at": "T+2.4s" },
    { "state": "completed",  "at": "T+14.2s" }
  ]
}

Receipts are available at GET /api/receipt/:paymentId — permanently, without authentication.

Failure & recovery

When a settlement fails, the failure system answers three questions automatically — no manual intervention required.

Additional guards

Liquidity model

Every payment goes through a pre-payment liquidity gate before a Solana transaction is even built.

C8F135">"color:#3F3F46">// Pre-payment gate — checked BEFORE Phantom is invoked
const MIN_RESERVE_USDC   = 50        C8F135">"color:#3F3F46">// always keep in treasury
const MAX_IN_FLIGHT_USDC = 10_000    C8F135">"color:#3F3F46">// max concurrent exposure
const MAX_PAYMENT_USDC   = 5_000     C8F135">"color:#3F3F46">// per-transaction cap
const MIN_PAYMENT_USDC   = 0.5       C8F135">"color:#3F3F46">// minimum viable payment

C8F135">"color:#3F3F46">// Decision:
C8F135">"color:#3F3F46">// amount < 0.5 USDC                    → reject
C8F135">"color:#3F3F46">// amount > 5,000 USDC                  → reject
C8F135">"color:#3F3F46">// treasury < (reserve + amount)        → reject (503)
C8F135">"color:#3F3F46">// inFlight + amount > 10,000           → reject
C8F135">"color:#3F3F46">//                                      → ALLOWED

Reserve alerts fire at 2× minimum. Critical alert at 1× minimum. Both are surfaced at GET /api/stats. In-flight USDC is tracked across all non-terminal payments in the Zustand store and cross-checked against the Supabase ledger.

Settlement providers