Parity rail, FloorBot, receivables vault, safety · 05_defi_trading/QALX_DEFI_PLATFORM.md

Qalx — The qalarc DeFi Platform & Safety/Verification Systems

Parent: 03_qals_architecture/QALS_ARCHITECTURE.md • Companions: QALS_BACKING_DESIGN.md, 05_defi_trading/DEFI_PLAN.md (research base) • Date: 2026-09-06

1. What Qalx is

Qalx is the financial layer of the Qals system: the place where B-QALS (AU$1-backed credit), G-QALS (growth token), qAUD (future stablecoin) and compute receivables meet markets — an internal DeFi platform first, a registered exchange surface later (per 06_bank_exchange/ Phase 2 VASP registration).

Two-sided design: - Inside the wall (Phase 1): internal credit ledger + sponsored exchange — apps settle, treasury manages liquidity, agents pay each other. No public speculation. - Outside the wall (Phase 2+): registered spot venue for QALS/qAUD pairs, KYC-tiered, with the same safety stack.

2. Market stack (three layers)

2.1 Parity rail — B-QALS ⇄ qAUD

• 1 B-QALS is redeemable at the Reserve for AU$1 − 0.5%; qAUD redeems 1:1. Arbitrage pins the pair within a few basis points.
• Implementation: the Reserve redemption desk itself + a minimal "parity pool" (concentrated liquidity around $1). Volume here ≈ total credit throughput — Qalx earns 1–5 bps on money the business already moves.

2.2 Utility discovery — G-QALS/qAUD (and G-QALS/B-QALS)

• Constant-product AMM to start (qalx::pool, 0.25% fee: 20 bps LPs / 5 bps treasury — per DEFI_PLAN.md Phase A), upgradable to concentrated liquidity.
• FloorBot: the always-on bid from FloorVault at floor − ε (see backing doc §3). The floor is therefore not a promise — it's a visible order.
• Liquidity: treasury-seeded (10% allocation), then protocol-owned liquidity bought with FloorVault excess.

2.3 Receivables finance — compute & credit markets (the differentiated DeFi)

• ComputeReceipt lending: lenders supply qAUD/B-QALS into a vault; borrowers post ComputeReceipt NFTs (07_compute_marketplace/) as collateral. A receipt is an on-chain, attested, escrowed future payment — LTV 60–80% by provider reputation. Default path: the job's escrow already sits on-chain; the vault simply claims it. Liquidation = claiming escrow. No oracle guesswork about "what's this NFT worth" — it's worth the escrow minus time-risk.
• Invoice finance (endispute tie-in): escrowed dispute settlements → same vault pattern. Australia's invoice-factoring market on-chain rails.
• Credit-balance proof (future): with user consent (SD-JWT from 09_identity_ai/), a B-QALS balance is a verifiable prepaid asset → underwriting data for licensed partners (agent H's Phase 3).

2.4 Order book (Phase B — "Qalbook")

• Port/adapt DeepBook v3 (verified Apache-2.0 in DEFI_PLAN.md): shared-object CLOB, BalanceManager per trader, limit/post-only/market + swap_exact_* router endpoints, native flash loans, epoch-governed fees.
• Trigger: when utility-pool volume justifies a book (>AU$1M/mo internal flow or external users post-VASP).
• Risk flagged: sui→iota framework drift port is consensus-critical → 2–3 Move engineers + external audit before mainnet.

3. Safety & verification systems (the spine)

3.1 Who watches the money

3.2 Invariant enforcement (on-chain, not policy)

// Reserve entry points enforce, structurally:
assert!(reserve.aud_cents >= b_qals_supply * 100);   // mint gate
entry fun mint_against_deposit(...) cap AUD_DAILY_LIMIT; // rate limit
entry fun redeem(...) enforce TIMELOCK_10K;          // large-redemption fraud window
// FloorVault ratchet: floor_new >= floor_old — enforced by typestate (Ratchet struct)

(2026-09-15: the on-chain twin is being redesigned from mint-gated to genesis-preminted + transfer-gated at the cap-raise checklist — live issuance transfers from the endowed issuer wallet qals:issuer.) - Discrepancy guard: monthly reconciliation delta > 0.5% → issuance auto-pauses. - Flash-loan resistance: parity logic reads Reserve state (not pool price) as the source of truth for issuance/redemption.

3.3 Verification systems (productised)

1. Proof-of-Reserves dashboard (wiki page + API): live B-QALS supply, attested AUD balance, coverage ratio, history chart. Anyone can verify the invariant.
2. Job attestation registry: every compute settlement publishes provider-signed telemetry + output anchors; sampling verifier re-runs high-value jobs (see 07_compute_marketplace/ §4).
3. Identity tiers: Qal ID DID + KYC VC tiers gate sizes (tier 0: AU$500; tier 1: AU$10k; tier 2: AU$100k+ per partner-KYC — Tokenized-KYC pattern from 09_identity_ai/).
4. Agent spend proofs: every agent payment co-signed per owner-set cap (optional, uncapped by default); loopd-enforced today, on-chain cap code written + tested.
5. Audit trail product (IOTA Audit-Trails pattern): every admin action, pause, parameter change lands in an append-only trail anchored to public IOTA monthly.

3.4 Audit & disclosure ladder

• Internal: Move unit/property tests + fuzzing in CI (fork inherits IOTA/Sui test suites — keep them green).
• Pre-revenue: one external Move audit of qal_* packages (~US$30–80k).
• Pre-external-trading: full audit + bug bounty (QALS-denominated) + published disclosure policy.

4. Revenue model (Qalx as a business line)

5. Build order

1. v0 (with core contracts): parity redemption desk + Reserve mirror + Proof-of-Reserves page. Everything else can wait; trust comes first.
2. v1: qalx::pool AMM (G-QALS/B-QALS) + FloorBot + dApp-kit trade UI.
3. v2: receivables vault (compute receipts), identity-gated tiers.
4. v3: Qalbook CLOB, external venue (post-VASP), perps/insurance fund (last, optional).

6. IMPLEMENTED: the QALS exchange slice (2026-09-12, paper mode)

Built in qalx/qalx.py (same service as the swap engine; isolated test instance :8875 via bash qalx/test_exchange.sh). What actually exists:

• qAUD ledger (PAPER): internal sub-ledger balances_qaud (cents) + ops_reserve_qaud. qAUD is operator-minted paper — a 1:1 AUD claim, NOT backed by real AUD today; every mint is logged and labelled. qAUD is a separate unit from loopd cents (which are B-QALS credit = the QALS leg).
• QALS/qAUD AMM: constant-product, fee-on-input 0.3% all-to-LP (accrues in reserves, k strictly grows), integer deci-unit math, drain guard, slippage min_out with atomic revert (both legs internal → refund = re-credit). One RLock end-to-end. Pool seeded by admin from a user's deposited QALS + ops-reserve qAUD. Endpoints: GET /pool/get, GET /pool/quote, POST /swap/exact-in, POST /pool/add-liquidity, POST /pool/remove-liquidity.
• Identity login (qalid): POST /session/start → qalid challenge; user signs with their qalchat identity key (qalid.py prove); POST /session/verify → qalid verifies against the anchored DID doc (chain-checked, single-use nonce) → qalx HMAC session token (v1.<exp>.<nonce>.<sig>, 1h). Endpoints take X-Session: <handle>:<token> or the legacy qalx HMAC. Handle mapping: exchange handle == qalchat handle == did:qal:\<handle>.
• Custody (v1 — operator-trusted, honest): deposits = user's own HMAC-signed loopd transfer to the exchange escrow agent, memo qalx:deposit:<handle>, polled from loopd receipts (5s + on-demand), receipt consumed once (replay-proof); mis-memo'd transfers parked in unmatched_deposits, never credited. Swaps/LP move internal sub-ledgers only — no user secret ever reaches qalx. Withdrawals: user queues, admin approves (qals → loopd escrow payout; qaud → paper burn, no external rail). Conservation invariant, proven per test run: escrow loopd balance == Σ qals sub-ledgers + pool qals reserve + queued withdrawals + parked unmatched.
• Graduation story: GET /program = loopd /report passthrough → 500k-QALS cap headroom for the UI.
• Trade log: qalx/data/trades.jsonl append-only; every swap/LP/seed record anchored on qalnet via qalpipe (qalx/data/anchors/exch_*.json, verify → PASS).

Honest limitations: operator can mint qAUD at will and holds the escrow (upgrade: Move escrow + PSP rails per QALS_BACKING_DESIGN.md); deposits rely on loopd's 50-receipt window (poller keeps it short; used-receipt set prevents double credit); qAUD has no external rail in Phase 1; live qalx :8843 must be restarted to serve the exchange endpoints.