Arrekta layer architecture: a solid settlement network

2026-10-18. Question: what does each layer need for Arrekta to be a network as solid as the major chains? Ethereum and Solana are used as references for quality, not as feature targets. Companion to L1_GAP_ANALYSIS.md.

Decision: stay a settlement chain

Arrekta's position is a quantum-safe settlement layer for issued assets. For that role, the benchmark for "solid" is Bitcoin and Liquid, not Ethereum and Solana: a simple, conservative base layer that does a few things and never breaks.

Not planned on layer 1:

The door stays open: reserved lock kinds 16–127 and the deployments framework mean any of these can arrive later as a soft fork, if the market asks.

What "solid" means here:

1. Nobody can rewrite history cheaply (consensus security).
2. The rules never change by accident (spec, two implementations, vectors, audits).
3. The network stays up under attack (P2P robustness, DoS limits).
4. Miners keep being paid enough to secure it, forever (economics).
5. Operators can run it with confidence (testnet, soak, monitoring, releases, incident process).

1. The stack

┌────────────────────────────────────────────────────────────────────────┐
│ L3  Products     indexer, gateway, wallet, issuer, streams (✓)         │
│                  SDKs, explorer, wallet apps, Mesh, faucet (✓)          │
├────────────────────────────────────────────────────────────────────────┤
│ L2  Off-chain    payment channels for ARRK and assets (✓ arrekta-channeld)│
├────────────────────────────────────────────────────────────────────────┤
│ L1  Ledger       UTXO multi-asset, issuer controls, policy locks, PST,  │
│                  filters, soft-fork path (✓)                            │
│                  fee market, UTXO commitment (✓); FN-DSA (regtest)      │
│     Consensus    PoW + ASERT, merged mining, checkpoints (✓)            │
├────────────────────────────────────────────────────────────────────────┤
│ L0  Network      PQ transport, headers-first, compact blocks (✓)        │
│                  eclipse/DoS hardening, Tor, I2P, DNS seeds (✓)         │
└────────────────────────────────────────────────────────────────────────┘
Cross-cutting: post-quantum crypto (✓, ahead of every major chain), two independent
implementations (✓), interop by swaps and finality proofs (✓, INTEROP.md), security budget,
operations and release engineering

2. What is left, by importance

2.1 Consensus security — the biggest real risk

A new PoW chain's main danger is rented hashpower. Ethereum Classic was hit by four 51% attacks in 2019–2020. The worst reorganised 4,236 blocks and double-spent about $5.6M, using rented hashpower that cost about $204k. Bitcoin Gold lost about $18M in 2018 the same way. Hashrate markets can't detect this abuse. For a chain that settles issued securities and stablecoins, one deep reorg would end trust.

The options must be decided before mainnet:

Recommendation: A, with C as an optional finality overlay for issuers who need a settlement-final answer (delivery-versus-payment). Whatever the choice, publish a confirmation-depth guide per value tier, as exchanges did after the ETC attacks. Also add reorg and hashrate monitoring with alerts to the gateway's event streams; the reorg retractions already exist.

2.2 Economics: the security budget

The current schedule: 10 ARRK per block, halving every 1,050,000 blocks (about 4 years at 120 s), with a 21M cap. This is Bitcoin's model, so it carries Bitcoin's open question: once the subsidy fades, will fees alone pay for security? Research (a 2025 CCC talk on fee markets) questions chains without a minimum reward. Monero has paid a tail emission of 0.6 XMR per block since 2022 as a deliberate hedge.

Decide before mainnet: keep the hard cap, or add a small tail emission. Issued-asset transfers do give Arrekta a fee base Bitcoin lacks; we should model it, not assume it. This is a genesis-parameter decision.

2.3 Ledger completeness (L1)

1. Fee market (policy, no fork): replace-by-fee and child-pays-for-parent with package relay and a TRUC-style (v3) rule against pinning, as Bitcoin Core 28 shipped. Wallets and the issuer need this to unstick payments.
2. UTXO-set commitment in the coinbase (MuHash), plus snapshot sync in the style of Bitcoin's assumeutxo. Without it every new node must re-verify every post-quantum signature since genesis, which gets slow as the chain grows.
3. Falcon-512 as an opt-in scheme: payments become about 3× smaller (~1.9 KB vs 5.5 KB), which roughly triples capacity. Crypto-agility already supports it. The cost is careful constant-time signing.
4. Capacity decision: today's ceiling is about 12 TPS (8 MB per 120 s, 5,474 B per payment). That's comparable to Ethereum's own L1, and fine for settlement. With Falcon it is about 35 TPS. Raise block size or interval only with benchmarks: propagation time, stale-block rate, and validation time on modest hardware. Keeping full nodes cheap is part of being solid.
5. STARK signature aggregation (later, a soft fork): the long-term answer to post-quantum signature size, the same open problem Ethereum names as its main post-quantum blocker. Not needed for launch.

2.4 Network robustness (L0)

• Bucketed address manager with gossip, eclipse-attack defences (already tracked in the plan).
• Per-peer resource limits, misbehaviour scoring review and a DoS test suite (oversized messages, header floods, slow peers).
• Tor and I2P support and DNS seeds operated by more than one party.
• Erasure-coded block relay only if blocks grow.

2.5 Implementation quality

• Done: normative spec, two independent implementations agreeing on shared vectors, fuzzing of decoders, a differential live check between the implementations.
• To do:
  • external security audits (consensus, P2P, cryptography integration, PST, issuer);
  • continuous fuzzing (cargo-fuzz or OSS-Fuzz);
  • reproducible builds and signed releases;
  • a vulnerability disclosure process with a bug bounty;
  • consensus-change review rules (two reviewers, vectors required).

2.6 Operations

• Public testnet with a faucet and explorer, run for months before mainnet.
• The deferred 7-day soak, then longer soaks with chaos (restarts, partitions, reorgs).
• Monitoring dashboards and alerts (hashrate, reorgs, mempool, peer counts, version-bit signals).
• Runbooks: incident response, emergency soft fork, key rotation, release.
• Genesis ceremony and launch checklist (the plan's §11).

2.7 Products (L3)

• Built: indexer, gateway, wallet service, issuer, live streams.

• To do:

  • SDKs (TypeScript, Python, Rust) with light-client support through the committed filters;
  • an explorer;
  • wallet apps with policy-lock templates (vault, vesting, HTLC);
  • issuer onboarding docs.

• Built (2026-10-27): payment channels for ARRK and issued assets, on the HTLC and relative-lock primitives already in consensus, so no fork was needed. The parts:

  • the arrekta-channels library and the arrekta-channeld node;
  • post-quantum onion routing, gossip and watchtowers;
  • SDK clients, plus wallet support on desktop and mobile.

  See CHANNELS.md and CHANNELD.md.

3. Order of work

Items 1, 2, 4 and 5 change consensus or genesis. They are free now, because devnet and testnet restart from a new genesis, and very expensive after mainnet.

4. Decisions (made 2026-10-18) and status

1. 51% defence: merged mining with Bitcoin (AuxPoW, Namecoin format), plus a public, rotatable post-quantum checkpoint group. Built.

2. Supply: 21M halving schedule plus a permanent 0.6 ARRK tail. Built.

3. Falcon (FN-DSA-512): built and scheduled on regtest only (2026-10-28). It is implemented in Rust (the fn-dsa crate) and verified independently in Python, with shared vectors. Testnet and mainnet schedule it only once FIPS 206 is final and the encoding has been re-checked (PROTOCOL.md §3.1).

4. Interop: built (2026-10-28). A SHA-256 policy hashlock (op 9) makes atomic swaps with Bitcoin and Ethereum possible, and finality proofs (/v1/txs/{txid}/proof) let other systems check Arrekta settlement against the checkpoint group alone. The SDKs have swap helpers. Multisig bridges are ruled out as canonical. See INTEROP.md. For Ethereum: an HTLC contract for the swap leg, and a light client that checks finality proofs through an SP1 zkVM program running arrekta-core's own verifier. The production proof backend (Groth16 now, or STARK / ML-DSA precompile later) is the one open choice.

Fee bumping, the coin snapshot, P2P hardening, Tor and I2P transport, monitoring and signed reproducible releases are built too. See SECURITY_LAYER_DESIGN.md for details. The public testnet, the 7-day soak and external audits remain.

Appendix: how the major chains compare (references only)

The earlier research on smart-contract VMs, data availability and rollups is summarised in the sources below, in case those directions are revisited.

Sources

• 51% attacks:
  • 51% attacks explained (ETC, BTG)
  • Rented hash power
  • ETC Labs on rented hash power
  • 51% attack glossary
  • How coins protect against 51% attacks
• Security budget:
  • Tail emission
  • Monero tail emission
  • The Bitcoin security budget (39C3 talk)
• Fee market:
  • TRUC / v3 relay (Bitcoin Optech)
  • Bitcoin Core 28 wallet guide
  • Package relay comparison
• Post-quantum signature cost:
  • Aggregation is the real blocker
  • Lattice PQ settlement layer
  • BNB Chain PQC report
  • Falcon
  • PQ proposals for Bitcoin
• Ethereum (reference):
  • Quantum resistance
  • Future-proofing
  • Glamsterdam
  • PeerDAS
  • L1-zkEVM roadmap
  • EVM → RISC-V
• Solana (reference):
  • Alpenglow
  • Firedancer
• Other references:
  • Zcash Crosslink
  • Kaspa 10 BPS
  • Aptos vs Sui
• Measured locally: a signed 1-input, 2-output payment is 5,474 bytes; the mainnet ceiling is about 12 TPS (arrekta_core params, 2026-10-18).