QALS Wiki · the qalarc networkgenerated 2026-09-06 · qalcode autonomous research

IOTA EVM / Sui DeFi / DeepBook analysis · 05_defi_trading/DEFI_PLAN.md

Qalx — DeFi Trading System for the Qals Ecosystem (DEFI_PLAN.md)

Client: qalarc (Australia) · Chain: QALS chain (fork of iotaledger/iota — Sui-derived Move L1 + EVM, Delegated PoS) Date: 2026-09-06 · Author: research+design agent · Status: DRAFT v1 for review Companion docs: 03_qals_architecture/ (token), 04_credit_token_platform/ (qAUD), 10_roadmap/

1. Executive Summary

The Qals ecosystem needs trading infrastructure for three asset classes: QALS (native gas/staking token), qAUD (future AUD-pegged stablecoin), and bridged external assets (BTC/ETH/stables via the fork's EVM layer). Research verdicts:

  1. The IOTA DeFi market is tiny and therefore winnable. DefiLlama (2026-09-06) shows IOTA EVM TVL ≈ $604k, IOTA native listing ≈ $1.48M (api.llama.fi/v2/chains). The flagship DEX, Pools Finance, is an audited (Zokyo, Hacken) AMM-style DEX with smart routing (iota.org showcase). A treasury-seeded venue on the Qals fork can credibly be "day-one DeFi" for the ecosystem rather than a late entrant.
  2. DeepBook V3 (MystenLabs) is Apache-2.0 licensed — verified in the local clone (github.com/MystenLabs/deepbookv3): full Apache-2.0 LICENSE, SPDX-License-Identifier: Apache-2.0 headers in sources, zero BUSL text anywhere. Forking it commercially is permitted. This de-risks Phase B massively.
  3. Recommended path: Phase A = simple Move AMM (Uniswap-v2 logic) + React UI on @iota/dapp-kit (verified to exist for IOTA). Phase B = "Qalbook" = DeepBook fork with DEEP tokenomics stripped and replaced by QALS. Phase C = router/aggregator + RFQ intents; perps later (licensing analysis first).

2. Research: State of DeFi (2026)

2.1 DeFi on IOTA today

2.2 Sui DeFi stack (reference architecture)

2.3 Order-book vs AMM for a bootstrapping ecosystem

The chicken-and-egg problem: a CLOB needs professional market makers quoting tight spreads; MMs need volume; volume needs tight spreads. With TVL targets under ~$5M, there is rarely enough organic MM interest on day one. An AMM bootstraps from one passive treasury deposit — anyone can be an LP, depth exists from block 1, and price discovery is automatic (pool ratio = price).

Dimension AMM (v2-style) CLOB (DeepBook-style)
Bootstrap Treasury seeds pool → instant depth Needs 2+ committed MMs or the book is empty
Capital efficiency Low (passive, full-range) High (concentrated quotes)
Fees/pricing Flat %, price impact on big orders Spread + priority; near-zero impact for makers
MEV Sandwich risk (mempPool-dependent) Sui/IOTA-style chains have no public mempool; on-chain matching reduces sandwiching
Ops burden ~1k lines Move ~15k+ lines Move + indexer + keepers

Hybrid models: UniswapX (intent-based auctions: user signs an off-chain intent, fillers compete, settlement on-chain; RFQ for size) solves both bootstrap and large-order slippage — the DEX protocol itself doesn't need inventory [UNVERIFIED — design knowledge; see uniswap.org/blog/uniswapx]. Recommended hybrid for Qalx: AMM = base layer of always-on liquidity; Qalbook CLOB = price discovery + large orders once MMs exist; RFQ/intents = bridge for whale flow in between.

Sui-style object CLOB vs EVM CLOBs (verified against code): custody is in a shared BalanceManager object (owner + up to 1000 delegated traders) or ephemeral coins for swaps — not an EOA-approved allowance; matching runs deterministically in Move inside consensus (match_against_book in book.move) — there is no off-chain matching operator with discretion (contrast dYdX-v4-style appchains / most EVM CLOBs where an operator sequences matches); flash loans exist natively in DeepBook v3 (borrow_flashloan_base/quote) — an EVM CLOB needs a separate Aave-style dependency for the same trick; shared-object contention serializes trades per pool — throughput is bounded by consensus, mitigated by Sui/IOTA parallel execution across different pools.

Note on "epoch-based matching / batch auctions": the v2 DeepBook whitepaper described matching at epoch boundaries (batch auctions) as an MEV mitigation [UNVERIFIED — whitepaper not fetched]. v3 does not do batch auctions: I grepped book/book.move — no epoch/batch tokens; matching is per-transaction, while epochs govern fee/rebate settlement and per-pool parameter votes (taker fee, maker fee, stake required).

2.4 Australia compliance snapshot (brief — agent H owns detail)

Running a swap front-end from Australia: exchanging digital currency (including crypto-to-crypto) for another digital currency is a designated service under the AML/CTF Act 2006 → AUSTRAC DCE registration + AML program, KYC/ID verification, transaction reporting (ITR/SMR) have applied to exchange-like businesses since 2018; the 2024 AML/CTF reforms (phased 2025–2026) broadened the designated-service net, and AUSTRAC's stated posture is that a business which facilitates swaps (front-end taking fees) can be in scope even if contracts are permissionless [UNVERIFIED specifics — agent H to confirm current instrument wording]. Perps/derivatives (Phase C+) are financial products under the Corporations Act → AFS licence territory; ASIC Info Sheet 225 governs crypto-asset disclosure. Design consequence: front-end fees should accrue via an AUSTRAC-registered qalarc entity; interface ships geo/AML gating hooks from day one.

3. DeepBook Code Review (local clone repos/deepbook = MystenLabs/deepbookv3 @ 1c968f9, 2026-09-04)

3.1 Repo structure

3.2 Pool shared object design

Pool<BaseAsset, QuoteAsset> shared object = three internal parts (per README + code): Book (crit-bit tree of price levels; fills and places orders), State (per-user data, volumes, historic volumes, governance, EWMA), Vault (settlement of funds). BalanceManager = separate shared object holding one account's balances (owner + up to 1000 traders; traders can place/cancel but not withdraw). PoolRegistry gates pool creation (permissioned at launch; create_permissionless_pool also exists). Admin surface: adjust_tick_size_admin, update_allowed_versions, pause controls.

3.3 Order types & matching

From pool.move public API: place_limit_order, place_post_only_limit_order, place_market_order (taker), modify_order, cancel_order(s), cancel_all_orders, withdraw_settled_amounts(_permissionless). Events: OrderPlaced/Filled/Modified/Canceled/Expired/FullyFilled + Fill records (maker/taker attribution). Aggregator path: swap_exact_base_for_quote(_with_manager), swap_exact_quote_for_base(_with_manager), swap_exact_quantity(_with_manager) — plain Coin in/out. Matching is book::match_against_book per transaction (see §2.3 epoch note).

3.4 Fees

Fees are DEEP-denominated (both maker and taker pay in DEEP; alternative input-token payment costs ~20% more per Sui docs). Per-pool TradeParams { taker_fee, maker_fee, stake_required } — defaults set at pool creation, adjustable by epoch governance: staked users propose per-pool taker/maker fees + stake threshold; quorum = ½ of stake; effects next epoch. Staked takers reach 0.25 bps (stable) / 2.5 bps (volatile); staked makers earn rebates paid at epoch end; accumulated excess DEEP is burned (burn_deep). Whitelisted pools (DEEP/SUI, DEEP/USDC) trade at 0% so users can acquire fee tokens cheaply. vault/deep_price.move maintains the DEEP↔base/quote conversion via price points (min 1 minute apart, max age 1 day, max 100 points) — a bounded TWAP oracle.

3.5 Whitepaper v3 features vs repo reality

Whitepaper-listed v3 features: flash loans, governance, improved account abstraction, matching-engine enhancements, DEEP tokenomics (deepbook.tech whitepaper [UNVERIFIED — PDF not fetched; features cross-confirmed in code]). Repo adds beyond-classic features: referral program (mint_referral, multipliers, claimable rewards), margin + liquidation packages, prediction markets (predict/propbook) with a Pyth-style oracle lane, all actively developed as of 2026-09-04. "Dynamic fees" = the epoch-governed per-pool TradeParams; "passive liquidity" ≈ maker rebates for resting orders; "orderbook composition" [UNVERIFIED mapping — plausibly the registry/multi-pool + propbook feed composition; not confirmed against whitepaper text].

3.6 LICENSE VERDICT — Apache-2.0 (CRITICAL CHECK: PASSED)

4. Design: "Qalx" — Phased Trading System

4.0 Principles

Move-native first (matches the fork's native asset model + object UX), EVM for bridged assets second; treasury seeds liquidity it later monetizes; every venue exposes a swap API the router can compose; fees accrue to the qalarc treasury via an AUSTRAC-registered entity (§2.4).

4.1 Phase A (weeks) — Qalx AMM + basic UI

Contract: qalx_amm Move package (Uniswap-v2 constant-product logic in Move; Cetus-style single-hop pools). Interface:

module qalx::pool {
    public entry fun create_pool<Base, Quote>(admin: &qalx_treasury::TreasuryCap, ctx: &TxContext)
        // creates shared object Pool<Base,Quote> + LP type LP<Base,Quote>
    public fun swap_exact_base_for_quote<Base, Quote>(
        pool: &mut Pool<Base, Quote>, coin_in: Coin<Base>,
        min_out: u64, deadline: u64, ctx: &TxContext): Coin<Quote>
    public fun swap_exact_quote_for_base<Base, Quote>(...): Coin<Base>
    public entry fun add_liquidity<Base, Quote>(
        pool: &mut Pool<Base, Quote>, base: Coin<Base>, quote: Coin<Quote>,
        min_lp_minted: u64, ctx: &TxContext): Coin<LP<Base, Quote>>   // LP coin = owned object
    public entry fun remove_liquidity<Base, Quote>(
        pool: &mut Pool<Base, Quote>, lp: Coin<LP<Base, Quote>>,
        min_base: u64, min_quote: u64, ctx: &TxContext)
}

4.2 Phase B — "Qalbook" CLOB (DeepBook fork)

License permits this (§3.6). Concretely, Apache-2.0 allows us to copy book/, state/, vault/, helper/ (fixed_math, crit-bit big_vector), balance_manager, registry, modify freely, and run it commercially as Qalbook, provided we keep the Apache-2.0 + copyright notices, mark our changes, and rebrand (no DeepBook marks).

4.3 Phase C — Aggregator + RFQ intents; perps later

4.4 Token flow diagram

                 ┌────────────────────────── Qalx (qalarc) ──────────────────────────┐
                 │                                                                    │
  Users ──wallet──▶  Qalx UI (React + @iota/dapp-kit)                                 │
   │                 │            │            │                                      │
   │        AMM swap │     CLOB order     RFQ intent                                  │
   ▼                 ▼            ▼            ▼                                      │
 Coin<QALS> ──▶ Qalx AMM ──▶ Qalbook (DeepBook fork) ──▶ RFQ filler                    │
 Coin<qAUD>    Pool<QALS,qAUD>  Pool shared objects       │                            │
 Coin<wBTC>    (20bps→LPs,      (taker/maker fees        │ (quote fee to              │
 Coin<wUSDC>    5bps→Treasury)   in QALS → Treasury)      ▼  filler)                   │
   │                 │            │                                                 │
   │                 └────────────┴───────► qalarc Treasury (multisig) ◄─────────────┘
   │                                              │
   │                        ┌─────────────────────┼──────────────────────┐
   │                        ▼                     ▼                      ▼
   │                 LP/maker incentives     QALS buyback&burn     Protocol ops
   │                 (liquidity mining,      (deflationary           (audits, legal,
   │                  vesting escrow)         pressure)               market making)
   │
   └── Bridged assets enter via EVM bridge ──▶ EVM DEX (UniswapV2 fork) ──▶ Router aggregates

4.5 Fee & revenue model (qalarc treasury)

Venue Gross fee LPs/makers Treasury Notes
AMM volatile pairs 25 bps 20 bps 5 bps Fee-switch enforced on-chain
AMM stable pairs 5–10 bps 4–8 bps 1–2 bps qAUD/wUSDC
Qalbook taker (default) 10 bps vol / 5 bps stable (DeepBook-style, governed) — 100% of taker fee minus maker rebates Pay-in-QALS gets 20% discount → drives QALS demand
Qalbook maker 0 bps + up to 1–2 bps rebate rebate — Rebates funded from taker fees
RFQ/intents 5–15 bps spread capture filler 2–5 bps settlement fee Phase C

Illustrative: $10M monthly volume at blended 15 bps gross ≈ $15k/mo revenue at bootstrap scale — meaningful only with token buyback framing; volume is the KPI, fees the byproduct. Treasury also retains protocol-owned liquidity (§4.6) earning the LP share.

4.6 Liquidity bootstrap plan

  1. Treasury seed: qalarc deposits initial two-sided liquidity (e.g., target $250–500k notional across QALS/qAUD + QALS/wBTC; comparable to the entire IOTA EVM TVL today). Liquidity stays as protocol-owned liquidity (POL) — treasury earns its own LP fees forever.
  2. Liquidity mining: QALS emissions to LPs/makers, 6–12 month linear vesting, capped per pool per epoch, weighted by fee contribution not raw deposit (fee-earning = real volume). Anti-farm: min 24h stake before claim.
  3. Maker program on Qalbook: rebate kickbacks for MMs quoting within X% of a Pyth reference price, Y hours/day, funded from taker fees + a fixed QALS grant.
  4. Success metric: 1% depth on QALS/qAUD ≥ $100k and effective spread ≤ 30 bps before scaling emissions down (bond/LST flywheel later).

4.7 Oracle plan

5. Risks & open questions

  1. Port cost (biggest technical risk): DeepBook targets Sui's framework (sui:: modules, Move 2024.beta edition, Move.lock pinned deps). Our IOTA fork uses iota::/std equivalents with API drift — every touched call site across ~15k lines must be reconciled, and any silent mismatch is consensus-critical. Budget: 2–3 Move engineers × ~2 months + external audit (~$150–400k) before mainnet Qalbook.
  2. Shared-object throughput ceiling on the fork (all QALS/qAUD trades serialize on one Pool object) — monitor; sharded pool design is a known future escape hatch.
  3. Liquidity chicken-egg at smaller scale than assumed (if qAUD launch slips, seed QALS/wBTC first).
  4. Regulatory: DCE registration timeline; perps = AFS decision; geo-gating plan needed at UI level.
  5. DEEP-tokenomics removal touches fee settlement at epoch boundaries — the trickiest code to rewrite safely.

6. Sources

← Shimmer & Data TransferBank & Exchange →