QALS↔qAUD exchange, identity-login, the decentralisation ladder · content/exchange-feasibility.md
The Exchange — feasibility, identity-login, and the decentralisation ladder
Author: qalcode (GLM 5.3) · Date: 2026-09-12 · Companions: tokenomics paper · qalx (the live engine) · AU law playbook · identity architecture
Executive summary
Technically, the exchange is 80% built — the qalx AMM runs today (64/64 assertions: escrowed swaps, LP shares, slippage guards, receipt-anchoring), and the QALS identity system gives us something no external DEX has: login without passwords, trading keys with owner-set spend caps (loopd-enforced today; on-chain migration on the cap-raise checklist), and revocable sessions. Legally, "decentralised, open, immutable, no founder control" is not a switch you flip — it's a ladder with four rungs, and the top rung (true immutability with third-party front-ends) is achievable technically (published Move packages are immutable by default) but does NOT dissolve Australian obligations for whoever builds, operates, or promotes the venue. The honest plan: build the internal exchange + identity-login NOW, register the VASP, then open the protocol and step back rung by rung.
1. The two-token exchange design (QALS ↔ qAUD, post-threshold)
What exists vs what's missing:
| Piece | Status | Gap |
|---|---|---|
| AMM pools (x·y=k, escrowed legs, fee split) | LIVE (qalx :8843, 64/64) | none for the core loop |
| qAUD token (mint-on-AUD-deposit / burn-on-redeem) | designed (qal_reserve pattern, live code to fork) | ~days: re-point reserve to AUD PSP attestations |
| QALS/qAUD bootstrap pool | n/a | seed with treasury; peg held by redeem desk (oracle-free — the 1:1 redemption IS the oracle) |
| Order book (CLOB) for large trades | deferred (DeepBook v3 port, Apache-2.0, budgeted in corpus) | post-VASP |
| Fee model | AMM live (configurable; currently 0) | fee-share language only — never "yield" (MIS trap, law playbook) |
The exchange is therefore an extension of a running system, not a new build. The hard part was never the matching engine — it's everything below.
2. Identity-login for the exchange (the genuine differentiator)
Yes — the QALS identity system should be the exchange's login, and it's better than what external DEXes ship:
visitor exchange front-end Qalnet
│ 1. "Sign in" ─────► shows QR / handle prompt │
│ 2. wallet signs ─► nonce challenge (qalid prove) ──► │ verifies sig vs ANCHORED DID
│ 3. session key ◄─ tiered account created │ (chain-checked, ~2s revocation)
│ 4. trading key optional: on-chain-capped key — │
│ (the killer) can TRADE, cannot WITHDRAW above │
│ its daily cap — enforced by │
│ the chain, not by us │
What users get that no password-exchange has: - no exchange-held credential to phish (the exchange never holds a secret; it verifies signatures against anchored DIDs); - spend-capped API keys — a trading bot key that literally cannot drain the account (bytecode cap), the thing that would have prevented every "API key drained my exchange account" incident in history; - revocable in ~2 seconds (DID revocation, already live); - auditable who-did-what — every session action is attributable to a chain-verifiable identity.
- visitor — clicks Sign in
- QR / handle prompt — front-end shows challenge
- wallet signs — nonce challenge (qalid prove)
- verify — sig vs ANCHORED DID on-chain
- session created — tiered account
- trading key — on-chain daily cap · ~2 s revocation
Honest limits: this authenticates identity, not personhood — sybil tiers still need the graduated KYC ladder from the tokenomics paper §4; and key custody remains user-side (seed phrase responsibility — that's the trade).
3. The decentralisation ladder — technical truth vs legal truth
Technical truth: published Move packages on our chain are immutable by default (no upgrade authority unless we grant one — we haven't). Anyone can run a front-end against the RPC. The pools don't care who queries them. "No founder control" over the protocol is a deployment choice we can make unilaterally.
Legal truth (AU, from the playbook): AUSTRAC's net catches whoever operates the facility — immutability of code doesn't immunise the entity that builds, hosts, or promotes the exchange for Australians. "I don't control it anymore" is an argument, not a shield, and it's weakest at the moment of launch.
| Rung | What | Tech | Legal |
|---|---|---|---|
| 1 — Internal (today) | exchange for ecosystem credit, identity-login, no public on/off-ramps | ✅ running | clean (prepaid posture; no VASP trigger while closed-loop) |
| 2 — Registered venue | public QALS↔qAUD (+ qUSD) with AUD rails | identity-login + qAUD + VASP registration | the mapped path; application quality is the gate |
| 3 — Open protocol, licensed fronts | we publish the immutable protocol; partners run licensed front-ends | ✅ possible at Move-publish time | obligations shift to the front-operators; ours narrows to protocol maintenance + disclosures |
| 4 — Immutability + step-back | no qalarc front-end at all; third-party UIs | possible (protocol rung 3 + we exit operations) | the "no control" defence gets its best form — strongest AFTER rung 2/3 established legitimacy; weakest if attempted first |
USDT pairs: only meaningful at rung 2+ (listing a third-party stable on a registered venue). Never as the internal unit (own qAUD/qUSD are cleaner — see tokenomics paper §6).
4. Recommended staged plan
- Now (rung 1): finish qAUD paper-token + QALS/qAUD pool on the internal qalx; ship the identity-login exchange UI as a demo (clearly labeled, closed-loop). This is legal today and de-risks everything.
- VASP application (rung 2 gate) — the paperwork in the playbook, with the identity-login + owner-set spend-cap design (loopd-enforced; chain migration on the cap-raise checklist) as the compliance differentiator (regulators like auditable, capped, revocable systems).
- At threshold (per tokenomics paper §5): pricing flips to qAUD; the exchange becomes THE public venue rung-2.
- Post-legitimacy (rungs 3–4): publish immutable protocol packages, invite partner front-ends, sunset ours only when others genuinely operate.
5. The one-line answers
- Can the exchange use QALS identity login? — Yes, and it's the best feature we can ship; ~days of work on live parts.
- Decentralised/open/immutable, no control? — Technically yes (Move immutability + open RPC); legally it's a ladder — climb it in order, don't jump.
- Own stable variants vs USDT? — qAUD always, qUSD on demand, no yuan, USDT only on registered venues.
- Is it feasible? — The engine is already running; the gates are legal, not technical.
Positions argued; the law playbook remains the compliance reference (not legal advice).