Qalnet: the fork, the fleet, the design · 03_qals_architecture/QALS_ARCHITECTURE.md

QALS — The qalarc Chain: Architecture Blueprint

Project: QALS / Qalnet — qalarc's own IOTA-derived coin, data-transfer network, and token economy Author: qalcode autonomous research session Date: 2026-09-06 Status: v1 draft (synthesised from live research + cloned IOTA source; see companion docs)

1. Vision

qalarc runs a family of applications (qalarc.com AI services, tradez.au, doof.ing, endispute.com.au, the Signal/WhatsApp agent hub, GPU compute rigs across a Tailscale fleet). Today these apps share no common ledger: credits, bills, data receipts, agent permissions and compute accounting all live in silos.

QALS is the connective tissue: one fast, fee-subsidised, object-based chain — forked from IOTA's own open-source node (itself Sui-lineage) — that lets every qalarc app, device, AI agent and user share:

1. A currency — QALS, used as pre-paid service credit, gas, and settlement rail.
2. A data layer — tamper-evident transfer and provenance of data between apps/agents.
3. An identity layer — DIDs for humans and AI agents, with verifiable permissions.
4. A compute ledger — escrow, tracking and settlement of compute jobs (GPU-hours as tradeable goods).
5. A market — DeFi trading interface (Qalx), NFTs, and later a credit/stablecoin system (qAUD).

The original IOTA dream was "the backbone of IoT — machines paying machines, transferring data and value feelessly." That dream failed as a public network for many reasons (see 01_iota_deep_research/), but as a private/company network the exact same architecture is not just viable — it's ideal: we control the validator set, we subsidise gas for our users, and we inherit five years of hardened open-source engineering for free.

2. Naming system (qalarc brand theme)

Total supply proposal: 4,600,000,000 QALS (9 decimals, smallest = doof) — a deliberate homage to IOTA's own rebased supply of 4.6B, and a comfortable size for credit-denominated usage (a doof of compute ≈ a micro-inference).

3. Strategic options — how to get an "IOTA-like" chain of our own

Decision: A → B. Start by deploying QALS on public IOTA (Move + EVM) as a live pilot with real tooling; in parallel fork the node into Qalnet and run it across the fleet; bridge Qalnet↔IOTA when the time comes. This mirrors exactly what IOTA itself did when it "rebased" onto Sui's design — we're rebasing onto theirs.

4. What we're forking (verified 2026-09-06)

repos/iota in this project = the live IOTA mainnet client. Key verified facts:

• It is a Sui fork. IOTA's own docs footer states the documentation is "adapted from the SUI Documentation, © 2024 SUI Foundation" and links MystenLabs/sui. The object-centric model, Move dialect, dApp-kit, and DeepBook-lineage tooling all carry over.
• Consensus: Mysticeti-class DAG BFT, now hardened as Starfish (whitepaper: https://eprint.iacr.org/2025/567, IOTA Foundation authors, last revision Apr 2026; live on IOTA mainnet since April 2026). Starfish makes uncertified DAG-BFT provably live (Push/Lazy-Push pacemakers), decouples payload from metadata via Reed-Solomon erasure coding + Data Availability Certificates (order-optimal linear payload communication), and carries full safety/liveness proofs. Slow parties "catch up" safely — exactly the property we want for a validator fleet that includes home machines on residential internet.
• Dual execution: native Move (objects, resources, safe assets) as the day-one VM, with EVM compatibility as a phased add-on — IOTA runs a fully EVM-compatible surface on its public network (chain 8822, "Magic Smart Contracts" bridgeless native↔ERC, LayerZero bridging, free RNG), but the EVM stack is not inside the iotaledger/iota repo (component map §fork notes): it's integrated separately (the wasp repo demonstrates the EVM-as-core-contract + JSON-RPC sidecar pattern at L2). Qalnet decision: Move-first; EVM surface in Phase 4+ via the same pattern if/when Solidity compatibility is actually needed.
• Tokenomics primitives: Delegated PoS with validator subsidy minting, gas partially burned, optional tips, storage deposits refundable on object deletion — a neat fit for Qalnet where "data you anchor costs a deposit, deleting it refunds you".
• Product suite we inherit for free: Gas Station (sponsored transactions), Notarization, Audit Trails, Identity (DID/VC), Hierarchies (trust delegation: root authority → federation → accreditation → attestation, validatable off-chain via Rust/WASM).
• License: Apache-2.0 (Sui lineage; [component map doc] confirms — do not ship without re-checking LICENSE in the fork).

5. Qalnet design

5.1 Genesis parameters (proposal)

5.2 Supply allocation (4.6B QALS)

Legal note: QALS starts life as a prepaid service credit (buy QALS → spend on compute/AI services inside qalarc apps). That framing keeps Phase 1 inside "prepaid services" territory rather than "financial product" territory. Any public trading/listing is deliberately deferred until the AUSTRAC/licensing work in 06_bank_exchange/ says it's safe. Not legal advice — take the plan to a fintech lawyer before any public sale.

5.3 The Fleet — validators on hardware we already own

Ops notes: validators behind Tailscale for p2p consensus traffic (private, authenticated, NAT-free — the fleet is already a mesh), with a public full-node/RPC gateway in the cloud for apps. Docker-compose per node from the fork's docker/ — the IOTA repo ships single-node/local-network tooling we keep intact for qalnet-dev-1.

5.4 Object model = our data model (why this chain, not an EVM L2)

The object-centric model means every business concept is a first-class on-chain object with an ID, owner, and version history:

// sketches — full module specs in companion docs
public struct DataAnchor has key, store {
    id: UID,                     // object address
    owner: address,              // app or agent DID-controlled address
    content_hash: vector<u8>,    // sha3-256 of payload
    uri: String,                 // where the (possibly encrypted/off-chain) payload lives
    mime: String,                // "application/json", "model/qal-tensor"...
    anchored_at_ms: u64,
    signature: vector<u8>,       // producer's signature over hash (provenance)
}

public struct ComputeJob has key { /* see 07_compute_marketplace */ }
public struct CreditAccount has key { /* see 04_credit_token_platform */ }
public struct AgentCredential has key { /* see 09_identity_ai */ }

Objects can be owned (transfer like an NFT), shared (all apps read/write via consensus), or immutable (data anchors). Deletion refunds the storage deposit — so ephemeral data (job payloads) is cheap, permanent records (invoices, receipts) cost a small deposit forever. This is the "tangle spirit" — pay for data presence, not per-byte compute — reborn in an object ledger.

5.5 Data transfer layer ("the tangle for our data")

End-to-end pattern for app→app data with integrity + confidentiality:

1. Payload (any bytes) stays off-chain: in Tailscale-hosted object storage (MinIO on the fleet) or on the sending machine.
2. DataAnchor object goes on Qalnet: hash + URI + mime + producer signature (+ optional recipient). Consumers verify integrity and provenance without trusting the transport.
3. Streams-style encryption (IOTA Streams is archived — we rebuild the pattern, not the code): per-channel key broadcast via the hub, payload keys derived per recipient; only the anchor is public. (See 01_iota_deep_research/SHIMMER_AND_DATA_TRANSFER.md for the full options analysis.)
4. Audit Trails product pattern: every anchor into an append-only per-subject trail → compliance-grade history (who saw what, when, signed by whom).
5. Anchoring to public IOTA: a light relayer posts Qalnet checkpoint roots to IOTA mainnet → our private data ledger inherits public tamper-evidence. This is the modern replacement for IOTA's old "anchoring to Bitcoin" idea, done in-house.

5.6 Trust framework: Hierarchies for humans, agents and devices

We fork the IOTA Hierarchies pattern (their Rust/WASM libs are open source — component map will confirm; if usable directly, we embed them):

• Root Authority: qalarc issuer service (controls role definitions at genesis).
• Federation: "qalarc-apps" federation = {qalarc.com, tradez, doof, hub, compute}.
• Accreditations: e.g. agent.hub.can-send-signal, agent.spend-cap: 50 QALS/day, device.minirig.can-run-jobs, user.kyc.tier-2 (VC-anchored on Qalnet).
• Attestations: every completed job/report/receipt emits one.

Off-chain WASM validation = apps check permissions locally in µs without a chain round-trip; on-chain validation only where money moves. This is exactly how we make AI agents safely hold wallets (see 09).

5.7 Move first, EVM later

• Move = system contracts (QALS, credits, compute, identity anchors, Qalx core). It's in the fork, day one.
• EVM = a compatibility surface for Solidity devs and MetaMask users, deliberately deferred (not in the base repo — see §4). When needed: deploy the EVM-as-core-contract pattern (as wasp demonstrates) so an ERC-20 QALS representation exists without a token bridge.
• Rule of thumb we adopt: value-creation logic in Move; compatibility shims in EVM.
• Value model note (see QALS_BACKING_DESIGN.md): the native unit splits into B-QALS (minted only against AU$1 in the segregated Reserve, redeemable, burns on consumption) and G-QALS (growth allocation, FloorVault-supported). Phase 1 B-QALS are non-transferable credit — transferability is a legal gate (doc 06), not a technical one.

5.8 Wallets & UX

• Embed the IOTA dApp Kit (TS SDK) in every qalarc web app — "Connect Qal ID" button becomes as normal as "Sign in with Google".
• Mobile: qalarc apps embed wallet SDK; key material in Stronghold (IOTA's open-source secure storage — battle-tested by their wallet) wrapped by OS secure enclave.
• Qal Pass (our Gas Station): user transactions in-app are sponsored by the treasury bucket → users never see gas. Gaslessness inside our own ecosystem was the founding IOTA promise; in a private chain we can actually keep it.

6. Build plan (fork execution)

Step 0 — Recon (done): clones in repos/, component map in 01_iota_deep_research/IOTA_COMPONENT_MAP.md.

Step 1 — Local devnet (1–2 weeks): - git clone repos/iota → qalnet ; rename crates/chains (their repo has crates/iota-..., network config, genesis builder). IOTA's own tooling for local multi-node networks is the starting point (docker compose + iota start-style commands — component map documents exact entry points). - Custom genesis: 4.6B QALS to treasury address, validator keys for The Fleet, epoch params, EVM enabled. - Ship: qalnet-dev-1 single node on superlocal, faucet CLI, explorer (fork IOTA's explorer).

Step 2 — The Fleet (2–4 weeks): - Validators on superlocal + minirig + bb-mini + 1 cloud VM; consensus over Tailscale; public RPC via cloud gateway; monitoring (Prometheus/Grafana — IOTA node exports metrics). - Publish qalctl (small CLI wrapping iota CLI with Qalnet config baked in).

Step 3 — Core contracts (4–8 weeks): Move packages: qal_framework (QALS utils), qal_data (DataAnchor + trails), qal_credit (accounts, metering, subscription streams), qal_compute (escrow + jobs), qal_id (DID anchoring + status lists), qal_pass (gas sponsorship rules).

Step 4 — Apps integrate (parallel): dApp-kit in qalarc web properties; hub agents get DID wallets; compute jobs start settling on-chain (they already have the GPU hardware and agents to do this).

Step 5 — Qalx + NFTs (after 04/05/08 docs): AMM → CLOB → aggregator; Doofs NFT drop as first consumer surface.

Step 6 — Public surfaces (when compliance clears): Doofnet public testnet, IOTA-mainnet deployment of QALS as bridged asset, qAUD stablecoin work per 06_bank_exchange/.

7. Risks & mitigations

8. What "Qals" inherits from IOTA vs what we drop

9. Immediate next actions (this week)

1. ✅ Research corpus cloned (repos/, 16 repos, ~550MB) + org metadata in data/.
2. Read 01_iota_deep_research/IOTA_COMPONENT_MAP.md → confirm license + private-network tooling entry points.
3. qalnet fork repo init on GitHub (private), CI from upstream.
4. Stand up qalnet-dev-1 single-node on superlocal (docker).
5. Write qal_data::DataAnchor Move package + anchor the first real payload from the agent hub.
6. Decision memo: QALS-on-public-IOTA pilot (Phase 0) — yes/no.

Companion documents: 01 (IOTA research), 02 (ternary), 04 (credit platform), 05 (Qalx DeFi), 06 (bank/exchange), 07 (compute), 08 (NFTs), 09 (identity/AI), 10 (roadmap).