External audit scope
What an external security audit of Arrekta should cover, in priority order, and how to get started. The audit should happen before the public testnet freezes and again before mainnet.
System summary
Arrekta is a proof-of-work, multi-asset UTXO chain with post-quantum cryptography:
- ML-DSA signatures and an ML-KEM-768 hybrid P2P transport;
- SHA-3 tagged hashes and merged mining with Bitcoin (AuxPoW);
- signed checkpoints and a lattice-hash state commitment.
There are two independent implementations:
node-rs/(Rust): the production node.core/(Python): the reference.
They must agree byte for byte on every vector in core/vectors/.
Threat model
- Adversaries:
- a rented-hashpower miner (up to and beyond 50% of Arrekta's merged-mined hashrate);
- malicious peers (eclipse, DoS, malformed messages);
- malicious transaction and package submitters (mempool DoS, pinning);
- a minority of checkpoint signers (fewer than m);
- malicious snapshot providers;
- compromised or curious platform-service clients.
- Assets to protect:
- consensus safety (no invalid state accepted, no split between the implementations);
- finality (no reorg below a final block);
- coin and asset balances, and issuer controls (freeze, clawback, restrictions);
- node availability;
- user keys in wallet tooling.
Priority 1: consensus
| Component | Files | Focus |
|---|---|---|
| AuxPoW | core/arrekta_core/auxpow.py, node-rs/crates/arrekta-core/src/auxpow.rs | Parent-coinbase parsing, magic/root search, merkle ambiguity, index function, size limits, the two implementations behaving identically on odd inputs |
| State commitment | lthash.*, state.*, chainstate connect/disconnect | Every state write hashed exactly once; disconnect restores the exact hash; delay anchor on reorgs; item encodings |
| Checkpoints and finality | checkpoint.*, chainstate add_finality / submit_checkpoint | Rotation logic, signature merging, rollback below a floor, interaction with snapshots |
| Snapshots | snapshot.*, load_snapshot | Header verification, partial or forged state, floor setting, behaviour until H + delay |
| Transactions and scripts | tx.*, validation.*, policy.*, locks.* | Policy locks, relative locks, expiry, asset rules, issuer controls, sighash |
| Fork choice and reorgs | chainstate process_block / activate_best_chain | Atomicity, invalid-branch handling, undo data |
| Monetary policy | params.* | Subsidy with tail; overflow at MAX_AMOUNT boundaries |
Priority 2: network and policy
- P2P: transport handshake (X25519 + ML-KEM-768), message decoders (fuzz targets exist), eviction, ADDR limits, anchors, headers-first sync, compact blocks, HEADERS byte budget.
- Mempool: RBF rules (the eviction bound, free-relay and pinning vectors), package acceptance, TRUC, ancestor-package selection, rebuild after reorgs.
Priority 3: services and tooling
arrekta-gateway: authentication, quotas, webhooks, streams.arrekta-wallet: PST handling, policy engine.arrekta-issuer: governed controls, quorum and time lock.arrekta-indexer.- Release tooling: reproducibility, signature verification.
Getting started
cd core && .venv/bin/python -m pytest -q # reference suite, includes the vectors
cd node-rs && cargo test --workspace # Rust suite: vectors, fuzz (proptest), interop
core/.venv/bin/python core/tools/gen_vectors.py # regenerate vectors (must stay identical)
Design documents:
Known limitations
- The checkpoint group is a trusted-for-finality set by design (see the design doc).
- Snapshot imports are not proven by PoW until H + delay.
- FN-DSA (Falcon) is reserved, not implemented.
- Merged-mining security depends on pool participation.