Coordinator, backing, hacking — the recurring questions · content/faq.md

FAQ — the questions that keep coming back

Date: 2026-09-08

"Didn't IOTA need a centralised node for security?"

Yes — until 2025. You're remembering the Coordinator. The original Tangle (2016–2025) couldn't finalise transactions safely on its own, so the IOTA Foundation ran a Coordinator: a central node issuing "milestones" that determined the canonical ledger. It was honest training-wheels, but it was centralisation — and together with the 2019 MIT-DCI hash break (Curl-P collisions) and the 2020 Trinity-hack network shutdown, it's a large part of why the IOTA token lost the market's trust (−99% from ATH; see the IOTA vs QALS page).

The Rebased upgrade (mainnet 5 May 2025) deleted the Coordinator entirely. Modern IOTA is a Delegated-Proof-of-Stake BFT chain with Starfish consensus (live April 2026, IACR eprint 2025/567) — the same family of provably-live DAG-BFT that Sui uses, hardened for lagging validators.

Qalnet forks the post-Coordinator code. Our chain has no central signer: 4 validators (growing to 7), 3f+1 Byzantine fault tolerance, sub-second finality. The "centralised tangle" critique is exactly why we didn't fork the old node — we forked the one that fixed it. (Our devnet currently runs a single validator for convenience — that's a devnet choice, not an architecture limit; Phase 1 is the 4-validator Fleet.)

"Is QALS backed by anything?"

Two classes: credit Qals (B-QALS — backed Qals, the AU$1 credit) were pre-endowed at genesis in the issuer wallet qals:issuer and reach you by transfer when you buy (AU$1 of segregated reserve stands behind each), are redeemable for any qalarc service (no cash-out in Phase 1–2 — deliberate legal positioning), transferable inside the ecosystem, issued-on-purchase, used-up-on-spend (retired), provable monthly (the chain is the liability ledger). Rewards Qals (G-QALS) (team/growth allocation) carry no redemption claim; they sit under a revenue-funded FloorVault whose coverage is published monthly, however small it honestly is. See the AU$1 Backing page.

"How is this different from just running a database?"

Caps that bytecode enforces (a compromised AI agent physically cannot overspend), receipts that third parties can verify without trusting us (chain + anchoring), escrow whose accounting the compiler checks (Move linear types), and an upgrade path to public verifiability (checkpoint anchoring to public IOTA) that no database has. See the Security page.

"Could someone hack it?"

Read the Security & Threat Model page — scored by attack, with mitigations. Short version: agents are bounded by the VM, money can't be printed, and the realistic risks are operational (keys, ports, supply chain) with a 10-item hardening backlog already written.

"Why a quoll?"

Australian, Q-alliterative (qalarc · QALS · Quoll), and its white spots are the system: every spot is a backed coin. "Spotted. Backed."

"When can people outside qalarc use it?"

Phase gates: closed-loop prepaid now → AUSTRAC VASP registration (A$150–400k path) for external transferability + qAUD → licensed credit later. Nothing public until the legal path says so. Not legal advice.

"Why is the smallest unit called a doof — and what's the not-for-profit?"

1 Qals = 1,000,000 doofs (the IOTA-style million-multiple homage; humans read Qals, machines count doofs). And the doof earns its keep: doof.ing is being set up as a not-for-profit that receives "doof rounding" — the invisible dust from metered payments, donated by default with an opt-out. At scale that's tens of thousands of dollars of frictionless micro-giving, fully auditable on-chain. The Qoll guards the coins; the doofs go to good causes.

"So legally, QALS is just our own platform's token system?"

Yes — that is precisely the posture. Phase 1 QALS is closed-loop prepaid platform credit: spendable only on qalarc services, no external transferability, no cash-out, no yield, no public sale. That's what keeps it inside the prepaid carve-out (see the AU Token Law Playbook). Practical to-do list that follows from it: Terms of Use describing QALS as prepaid credit for qalarc services (non-refundable except as required by law, no secondary market), marketing that never frames it as an investment, and the lawyer memo on the closed-loop boundaries (internal transfers included) before anything broadens.

"How is this even working between just two nodes?"

Honest topology, as of 2026-09-10 — because "two nodes" is exactly what it is, and the trick is that almost nothing needs a "node":

superlocal (the hub machine)                    cachyos-x8664 (Fleet node #2)
├── Qalnet chain (single validator, devnet)     ├── qalchat relay #2 (:8840, systemd)
├── loopd, qmarket, qalpub, bazaar,             └── (provider/monitor ready)
    redeem, claim, qalmcp, relay #1 (:8830)
└── your wallet + agents
         └──────── Tailscale (WireGuard) ────────┘

• Messages/files don't need consensus. qalchat is store-and-forward: clients encrypt end-to-end (keys never leave devices) and push ciphertext to ANY reachable relay; recipients pull from any relay holding their mail. Relay #2 on the second machine is just another mailbox — that's why it's genuine decentralisation of transport without a second validator.
• Money doesn't need the chain (yet). loopd is the ledger of record (paper phase) with the on-chain twin published and proven; it lives on one machine, signed orders fly over Tailscale.
• Anchoring is one-way. Receipts/hashes go chain-ward; nothing on the chain needs the second machine.
• What a second node buys today: relay redundancy (send via A, read via B — tested), file-transfer practice across machines (tested), monitoring, provider compute. What it doesn't buy yet: consensus redundancy — that's the 4-validator Fleet milestone (the chain still finalises on one validator; killing it halts anchoring, nothing else).
• The missing piece for "real two-node everything": a validator + fullnode on cachyos-x8664 (the installer's next role) — then killing either machine leaves the chain standing.

"How could this be hacked?" (current-topology edition)

The full model lives on the Security & Threat Model page; the honest delta for today's two-machine setup: 1. Relay #2 is a new attack surface: it's keyserver+mailbox — a malicious relay can withhold/drop mail (detected: hash-chain gaps), attempt TOFU key substitution for NEW contacts (blocked by invite-pins — always exchange QRs out-of-band), or refuse service. It canNOT read mail (ciphertext), forge senders (ed25519), or touch money. 2. Tailscale is the perimeter: compromise of either machine's Tailscale identity reaches every service. Mitigation: services bind localhost where possible, ACL review (SECURE_OPS), keys-per-service. 3. The chain is one validator: whoever controls superlocal's validator key is consensus for the devnet — fine while value is paper, unacceptable before real money (the 4-validator milestone). 4. The bridge token = read-access to served files only (namespaces are read-only whitelists; traversal refused) — steal it and you get the whitepaper, not the wallets. 5. Donation phishing: someone impersonating doof-donations. Defence: the Church's qoll-code + pinned invite (published in the docs), and receipts on-chain. 6. The reaper lesson (from today's tests): processes dying silently is an availability attack vector even without an attacker — hence heartbeat monitors on every Fleet node now. Every one of these is bounded, loud, or on the roadmap — which is the design philosophy: attacks should cost more than they steal.

"What would Signal-grade encryption take?"

Today, every message is sealed with its own key — but if a session key leaks, that session's past messages can be read. Signal-grade is stricter: a new key exchange on every message, so yesterday stays secret even if today's key leaks (the "double ratchet", or MLS — its modern equivalent for group chats). Add the QR contact verification we already have — scan a contact's code and confirm it's really them — and that's the whole package. It's the biggest crypto upgrade on the queue: roughly 2–3 weeks of work plus an audit. Until it lands, the honest line is: our chat is encrypted, not yet Signal-grade.

"How is it able to always remain on?" (the persistence stack)

Four layers, each catching what the previous misses: 1. systemd — every service runs as a user unit (qal-target.target group: chain, loopd, relay, market, pub, bazaar, redeem, claim, id, pay, bridge) with Restart=on-failure + 5s backoff. Crash → back in seconds. Reboot → everything returns (units are enabled). 2. The fleet monitor (qal-monitor.service) probes all 14 endpoints every 60s and Signal-alerts on state change — a service can't silently die; you get "🚨 DOWN" then "✅ BACK UP". 3. Tailscale — machines find each other across networks without port-forwarding; the WireGuard mesh IS the WAN. (Honest note: residential links DERP-fallback sometimes — the third-relay item on the queue hardens that.) 4. Deliberate state design — ledgers are append-only JSONL + periodic atomic writes; the chain rebuilds from genesis.blob; identities derive from mnemonics. Losing a process never loses money or history.

"Is a display of the tangle visible? Do things work?"

Yes — the live tangle view polls the chain's real RPC: checkpoints stream in as DAG nodes with digests, the anchor feed shows DataAnchors landing, latency and chain-id in the header (SIMULATED mode only when the chain is unreachable from wherever it's embedded). And "do things work" is proven continuously: every anchor → verify round-trip in the test suites, plus the standing liveness anchor. The chain is doing real, visible work.

"How do we ensure the coin supply is fixed? Can we release more? How does it work?"

The supply has three locks, by design: 1. Code lock (live now): loopd's /topup refuses any sale past cap_cents = 50,000,000 (500K Qals). The sellable supply was pre-endowed in the issuer wallet qals:issuer (2026-09-15) — a purchase is a transfer out of it, and when the wallet is empty sales answer 402 "sellable supply exhausted". The program ledger (/report, /issuer/status) shows sold/remaining to the cent. The hold (500M) and vault (—) aren't sellable at all — there is no code path that issues them. 2. Policy lock: releasing more is a deliberate multi-step act: change loopd/data/program.json (file change → git-visible), announce, and (when live) a timelocked governance vote — never a quiet edit. 3. Chain lock (the graduation): the on-chain cap package (qal_reserve) — the on-chain twin is being redesigned from mint-gated to genesis-preminted + transfer-gated at the cap-raise checklist, so even a compromised operator machine can't create credit past what was endowed. That's the next milestone for exactly this reason. So: can we release more? Yes — intentionally, transparently, after the re-evaluation you specified at the cap. The system is designed so it can never happen by accident or silently.

"The API-key ↔ Qals exchange" (qalkeys — the new subsystem)

Three modes live: metered gateway (sell AI/upstream API usage priced per-call/per-1k-tokens in Qals — buyers get qk_ keys, sellers' secrets never exposed, usage billed via holds), escrowed key resale (prepaid third-party credits sold safely — escrow not credential-pooling; note the research warning: providers ban credential sharing, so this mode positions as metered-value transfer, not key sharing), and company usage tracking (org issues per-team keys, same metering, cost-centre reports). See qalkeys/ + the AI Token Market research page.

"Can we make a DeFi exchange where people exchange with IOTA?"

Yes — split into what's legal now vs later: - Now (built): the swap ENGINE. qalx (:8843) runs constant-product pools (0.25% fee: 20bps LPs / 5bps treasury) with escrowed base legs, slippage guards, LP shares, and anchored swap receipts — fully tested in the paper phase. The quote side of the IOTA pair is an IOTA-COUPON ledger behind a swappable gateway interface: when the licensed phase arrives, the coupon gateway is replaced by a real IOTA gateway (deposit address monitoring + withdrawals via iota-sdk — already cloned in repos/), and the pool math doesn't change by a single line. - Later (the gate): the real IOTA leg. Swapping QALS↔IOTA for the public is a crypto-to-crypto exchange service — squarely within AUSTRAC VASP scope (law playbook §2) and it converts the prepaid-credit posture into a regulated activity. So: engine now, coupons internally, real IOTA at the VASP gate — the same sequencing as every other public surface. The exchange floor UI (Qalx boards) already visualizes the pairs.

"Should we be careful about language — 'qal credits'?"

Yes — deliberately so. The standing vocabulary (use it verbatim in all public material):

The rule: describe mechanisms, never market outcomes. "Credit you prepay, escrow that holds it, receipts that prove it, a cap that stops it." That sentence is legally boring — which is exactly the goal.

Glossary — old term → plain term

"How should keys work on the ledger?"

Public keys on the ledger, private keys never. Every identity (person, agent, device) publishes its public keys via an anchored DID — the chain is the phone book that can't be lied to (key substitution is detectable, registration requires proof-of-possession). The private keys never touch the chain: they live on your devices, derived from your seed phrase. Rotating a key = publish the new public key + a signature from the old one, anchored — the ledger proves the succession, so a stolen-then-changed key is visible to everyone. That's the design already running; Signal-grade upgrade keeps ratchet secrets local and anchors only key-succession events.

"Should encryption be optional?"

Default-on for private chats, plaintext-by-design for public channels — not a per-message toggle. Optional E2E encryption is how people get burned (one wrong toggle leaks a conversation forever, and nobody can tell which messages were protected). Public channels are already signed-plaintext — that's their point. If a business wants readable internal traffic for compliance, that's an export/audit feature on the receiver side, not turning encryption off. Keep the floor solid: private = encrypted, always.

"If the network never charges, what about proving who you are?"

Value can act as proof of identity — worth it case by case, and it costs nothing. For high-stakes verifications (a large claim, a high-value unlock), a tiny round-trip value transfer — send a little credit to a challenge address and get exactly that back — proves control of the key that sent it (the qalid prove pattern). It is optional, decided case by case, never a default requirement. The value returns in full: it is a proof mechanism, not a fee, and nothing is kept. The canonical fee statement stays what it is: the network never charges.