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)

• Discrepancy guard: monthly reconciliation delta > 0.5% → mint auto-pauses.
• Flash-loan resistance: parity logic reads Reserve state (not pool price) as the source of truth for mint/redeem.

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 epoch cap; chain-enforced (no off-chain trust).
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).