Skip to content
LogoLogo

Base-layer security and operations: design

2026-10-18. Implements the four items agreed in LAYER_ARCHITECTURE.md: 51%-attack defence, long-term miner pay, ledger finishing work, and hardening and operations. The normative text is in core/PROTOCOL.md v1.2 (§3.1, §9.6–9.8, §11, §12.2, §12.6, §13). Both implementations pass the shared vectors in core/vectors/security.json.

Decisions (user, 2026-10-18)

TopicDecision
51% defenceMerged mining with Bitcoin (AuxPoW), plus an optional public checkpoint group
SupplyKeep the 21M halving schedule, plus a permanent tail of 0.6 ARRK per block
ScopeAll four items: defence, miner pay, ledger (fee bumping, coin snapshot, Falcon), hardening and operations

1. Merged mining: research and choices

How others do it.

  • Namecoin (since 2011), Dogecoin, Syscoin and Elastos accept an AuxPoW: a Bitcoin parent header that meets the child's target. The parent's coinbase commits to the child block through a small merkle tree of aux chains, so one pool can mine several chains. Pools drive it through createauxblock / submitauxblock (Syscoin's mining guide documents them).
  • RSK uses a different tag (RSKBLOCK:) with SHA-256 midstate compression of the coinbase. Its own documentation warns that the tag can appear by accident or maliciously in miner-chosen extranonce bytes.
  • Known weakness: research ("Merged Mining: Curse or Cure?", ePrint 2017/791) found merge-mined chains often run near the limits of Nakamoto security because a few pools dominate them. That is why a finality layer is added (§2).

What we built, and why it's better for us.

  • Namecoin's exact format. Pools that already merge-mine Namecoin, Dogecoin or Syscoin can add Arrekta with a config line, and their submissions are stored verbatim. A custom format would mean no pool support.
  • Stricter than Namecoin:
    • the fabe6d6d magic is required (Namecoin still accepts a legacy form without it in the first 20 bytes);
    • the magic must appear exactly once and immediately before the root;
    • 64-byte coinbases are rejected (merkle ambiguity);
    • the coinbase is capped at 32 KiB and must use the non-witness serialization.
  • One proof-of-work rule. Solo mining uses a standalone parent built from the same structure, with no second "native" hash. An attacker can't mine on a cheaper hash function than the pools use.
  • Chain id 0x0D07. Namecoin's slot function only mixes the nonce with the chain id, so two chains whose ids agree in the low bits collide in every tree size. Our low bits differ from Namecoin (1), Dogecoin (98) and Syscoin (16).
  • Post-quantum note: SHA-256d proof of work is quantum-safe (Grover only halves the security margin). The quantum risk lives in signatures, which stay ML-DSA.

Cost. Full headers now carry the proof, about 400–600 bytes for a typical pool. HEADERS replies stop at a 16 MiB budget, and P2P moved to protocol 3.

2. Signed checkpoints (finality)

How others do it.

  • Dash ChainLocks (DIP-0008, live since 2019): a long-living masternode quorum signs the first block it sees at each height. Nodes reject competing blocks at that height, so reorganisations below a ChainLock are impossible.
  • Zcash Crosslink (in development) adds a BFT finality layer next to PoW.
  • Liquid uses a federation of functionaries.

What we built. A post-quantum ChainLocks:

  • Group and threshold: a public signer group of up to 32 ML-DSA keys with an m-of-n threshold.
  • Signing: checkpoints every 10 blocks, 6 deep (configurable per signer). Signers sign independently. Partial signature sets merge over P2P (CHECKPOINT) or REST, and a checkpoint is final at m signatures.
  • Finality floor: a final block makes competing blocks invalid. A node that followed another branch rolls back and follows the checkpointed one, even if it has less work. No reorg crosses the floor.
  • Rotation without a release: a final checkpoint can hand over to a new group (next_set). New peers receive every hand-over plus the latest checkpoint after VERACK.
  • Optional by network: regtest has a public 2-of-3 test group. Mainnet and testnet have none until the genesis ceremony picks real signers.

Trust model. The group can make blocks final; it cannot create blocks, move coins or reverse checkpoints it already signed. If the group goes offline, the chain keeps going under plain proof of work. If the group turns malicious (m keys), it could finalise one honest-looking fork; that is why the group is public, multi-party and rotatable, and why "finality lagging" alerts exist.

3. Long-term miner pay: tail emission

Bitcoin's open question is whether fees alone will pay for security once the subsidy fades (see the 39C3 security-budget talk). Monero has paid a fixed 0.6 XMR per block since 2022.

We keep the halving schedule and add a floor: subsidy = max(10 ARRK >> halvings, 0.6 ARRK).

  • The floor starts at the 5th halving, about 20 years in.
  • Issuance then is about 158k ARRK a year, roughly 0.75% of 21M at first and shrinking as a share.
  • There is no hard cap; max_money becomes the encoding limit.

The user asked about a 100M supply. A bigger cap only changes the unit size; it doesn't fix the fee-only problem. Only a non-zero floor does.

4. Chain-state commitment and snapshots

How others do it.

  • Bitcoin's assumeutxo loads a UTXO snapshot whose hash is hard-coded in the client release, and validates history in the background. Its rolling set hash, MuHash3072, rests on a discrete-log problem that a quantum computer breaks.
  • Solana replaced its Merkle account hash with an accounts lattice hash (SIMD-0215). That is LtHash, a homomorphic hash whose security rests on lattice problems (Lewi et al., ePrint 2019/227).

What we built.

  • The hash: LtHash16 (1024 × u16 lanes, SHAKE256 expansion) over every UTXO, asset row and freeze entry, updated incrementally on every write and undone exactly on disconnect.
  • The commitment: every block commits to TH("utxo/commitment", lthash) of the state after block h − delay (100 on mainnet). The commitment is in the PoW-covered coinbase, not in the source code, so no release has to bless a snapshot. The delay lets miners commit to settled state and lets side branches validate normally.
  • Snapshots: arrekta-node snapshot export|import covers state, headers, filter header and the last delay commitments. Import checks every header's proof of work, rebuilds and matches the LtHash, and sets a finality floor at H.
  • Proof: block H + delay must commit to the state after H, so a forged snapshot is rejected by consensus.

Verified:

  • the Rust and Python exporters produce byte-identical snapshots;
  • each implementation imports the other's;
  • a Python node started from a Rust snapshot synced past H + delay;
  • a forged snapshot that imports cleanly is rejected when block H + delay arrives.

5. Fee bumping

Modelled on Bitcoin Core 28:

  • Full RBF with BIP 125's limits: at most 100 evictions, a higher fee rate, absolute fee ≥ replaced + incremental relay fee, no new unconfirmed inputs.
  • 1-parent-1-child package relay: a new P2P PACKAGE message and POST /v1/txs/package.
  • TRUC (BIP 431) for version 3 transactions, with sibling eviction.
  • Child-pays-for-parent through ancestor-package scoring in block templates.
  • Eviction uses descendant-package scores, so a low-fee parent isn't dropped while its child pays.

Post-quantum transactions are ~5.5 KB, so TRUC's limits are scaled from Bitcoin's 10,000 / 1,000 vB to 40,000 / 16,000 bytes. A child spending an anchor plus a fee input must fit.

6. Falcon (FN-DSA): reserved, not activated

FN-DSA-512 would make payments about 3× smaller. FIPS 206 is still not final (expected late 2026 or early 2027), and the maintained Python PQClean binding (pqcrypto 1.0) dropped Falcon in favour of FIPS-final algorithms only. Shipping a non-final signature encoding into consensus would risk a second migration. So scheme id 0x03 is reserved in the spec and both implementations. Activation is through the existing scheme schedule once FIPS 206 publishes, with shared vectors from two independent libraries (Rust candidates: fn-dsa, pqcrypto-falcon).

7. Hardening and operations

AreaDone
P2PInbound eviction (latency, block-relay and age protection, then the youngest of the biggest netgroup); ADDR token bucket (0.1/s, burst 1000); anchor peers across restarts; HEADERS byte budget; misbehaviour scores for bad AuxPoW, checkpoints and packages; fuzzed decoders for AuxPoW, checkpoints, snapshots and state items
MonitoringNew metrics: arrekta_finality_height, arrekta_checkpoints_pending, arrekta_last_reorg_depth, arrekta_txs_replaced_total. Prometheus config and alert rules in ops/monitoring/ (stall, low block rate, deep reorg, divergence, finality lag, few peers, reject spikes)
Releasestools/release/build-release.sh --check (reproducible container builds compared bit for bit); tools/release/sign_release.py (ML-DSA-65 co-signatures over SHA256SUMS with an m-of-n trust list)
DisclosureSECURITY.md, docs/AUDIT_SCOPE.md, docs/BUG_BOUNTY.md
Soakcore/tools/soak.py now also checks that all nodes share one finality floor that keeps up with the tip, and exercises RBF. The devnet runs the 2-of-3 signer group (node-1, node-2 Rust; node-3 Python)

External audits and the bounty need outside parties; the documents above prepare both.

Sources