The current state of the Autonomi codebase — an independent code + on-chain analysis (with honest speculation)

Development RFCs
1

▎ Disclosure first: I didn’t write this — I had Claude (Anthropic’s AI) clone the public repos and query Arbitrum One directly, then write it up. The analysis and any ▎ mistakes are the AI’s, and the credit is its. I’m posting it because the weekly updates have thinned and threads like “Is anyone actually using the network?” ▎ deserve an evidence-based answer. All from public repos + chain as of 19 Jun 2026. Devs — please correct anything wrong; much of this is inference. Links to verify ▎ everything are at the bottom. TL;DR - 2.0 is a ground-up rewrite in a new org, WithAutonomi (Autonomi · GitHub) — post-quantum, libp2p replaced by an in-house saorsa transport, relicensed MIT/Apache. - Big and heavily tested: ~215k lines of Rust, ~42% tests; the new transport (~126k LoC) is bigger than the whole 1.0 monorepo. - The network is genuinely in use: ~1.2 TiB uploaded in 30 days on-chain. - Durability is enforced by a randomised storage-audit challenge — but it’s 7× replication, no erasure coding. - Looks like a small, senior, AI-amplified team (~4 very active committers). [measured] = from code/chain. [speculation] = inference.

  1. The shift: 1.0 → 2.0 [measured] Live work is in WithAutonomi (Autonomi · GitHub), not maidsafe/autonomi (GitHub - maidsafe/autonomi: Autonomi combines the spare capacity of everyday devices to form a new, autonomous, data and communications layer of the Internet · GitHub) (whose main is still ant-node 0.4.17): ant-node 0.13.x (GitHub - WithAutonomi/ant-node: Pure quantum-proof network node for the Autonomi decentralized network · GitHub), saorsa-transport (GitHub - WithAutonomi/saorsa-transport: Shared transport abstraction for the Saorsa ecosystem · GitHub) (QUIC+NAT, replaces libp2p), saorsa-core (DHT phonebook, stores no data), ant-client, ant-protocol 2.x, saorsa-pqc/ant-keygen (ML-KEM-768 / ML-DSA-65), plus indelible (Go+Vue enterprise gateway). Post-quantum by default, ~35% leaner deps.

  2. What’s implemented [measured] Only the immutable Chunk type is live — no Register/Pointer/Scratchpad/GraphEntry, no archive/directory in node or client. So today it’s a permanent, immutable, content-addressed blob store (file → self-encrypted chunks + DataMap → one address). The mutable/named-data layer for updatable sites/apps is designed but not yet ported. 3. Size & quality [measured] ~215k Rust lines / 621 files, ~42% tests; saorsa-transport is the bulk (~126k, ~50k of it tests) and carries ~137 of the ~172 unsafe blocks (OS socket/FFI for NAT). Governance is uneven — saorsa-transport has full CI/lint/security gating; ant-node/evmlib are thinner.

  3. Is anyone actually using it? — yes [measured] Decoding every payment event on the Arbitrum One payment vault (https://arbiscan.io/address/0x9A3EcAc693b699Fc0B2B6A50B5549e50c2320A26) for the last 30 days: ┌──────────────────────┬────────────────────────────────────┐ │ Metric (30d) │ Value │ ├──────────────────────┼────────────────────────────────────┤ │ Uploaded │ ~1.22 TiB (312,042 chunks × 4 MiB) │ ├──────────────────────┼────────────────────────────────────┤ │ ANT paid │ 2,891 (≈ 2.4 ANT/GiB) │ ├──────────────────────┼────────────────────────────────────┤ │ Transactions │ 9,876 │ ├──────────────────────┼────────────────────────────────────┤ │ Daily average / peak │ ~40.6 GiB/day / 96 GiB peak │ └──────────────────────┴────────────────────────────────────┘ The two payment modes both show up clearly: single-node pay_for_quotes accounts for ~151k chunks (the long tail of small uploads), while Merkle-batched pay_for_merkle_tree accounts for ~161k chunks across only ~1,130 trees (big uploads, batched ≤256 chunks/tx). Gas is trivial on Arbitrum (≈0.02 gwei): Merkle batching costs ~3,100 gas/chunk (≈ $0.05/GiB) vs ~42k gas/chunk single — so storage payment (ANT) dwarfs gas by orders of magnitude. Volume is bursty (96 GiB peak → ~1.4 GiB quiet day), i.e. real lumpy demand, not a synthetic stream. Caveat: with 2.0 still in testing, this is likely mostly 1.0 traffic through the shared vault — but it is real, paid usage, and anyone can re-derive it from the vault address above.

  4. Durability — enforced, not assumed [measured] replication/audit.rs (ant-node/src/replication/audit.rs at main · WithAutonomi/ant-node · GitHub) runs a randomised challenge-response storage audit: a challenger picks a nonce + keys a peer should hold; the peer must return a digest proving possession (“anti-outsourcing”); failures feed a trust/reputation engine. Each chunk targets 7 holders (quorum 4), repaired every 10–20 min, pruned only after a 3-day replication-confirmed delay. Gap: it’s spot-check sampling (not compact proof-of-retrievability), and it’s pure replication — no erasure coding (7× overhead vs ~1.5× for erasure codes).

    1. Node reachability behind home NAT — better than 1.0, honestly [measured + speculation] This is where 1.0 hurt, so it’s worth detail. The transport (saorsa-transport (GitHub - WithAutonomi/saorsa-transport: Shared transport abstraction for the Saorsa ecosystem · GitHub)) escalates through four layers, integrated into the QUIC handshake rather than bolted on: 1. NAT-type detection + per-OS local-address discovery (netlink/getifaddrs/GetAdaptersAddresses). 2. UPnP/IGD port mapping, plus IPv6/dual-stack (which sidesteps NAT entirely where ISPs provide it). 3. Coordinated QUIC hole-punching (synchronised PUNCH_ME_NOW).
    1. MASQUE relay fallback with an elegant “unconditional relay acquisition” model — no fragile self Public/Private classification; every node just tries to grab a relay and learns which peers are reachable by dialling them. Their own README success rates: ┌─────────────────┬────────┬───────────────────┐ │ NAT type │ Rate │ Method │ ├─────────────────┼────────┼───────────────────┤ │ Full cone │ >95% │ direct │ ├─────────────────┼────────┼───────────────────┤ │ Restricted cone │ 80–90% │ coordinated punch │ ├─────────────────┼────────┼───────────────────┤ │ Port-restricted │ 70–85% │ port-specific │ ├─────────────────┼────────┼───────────────────┤ │ Symmetric │ 60–80% │ port prediction │ ├─────────────────┼────────┼───────────────────┤ │ CGNAT │ 50–70% │ relay fallback │ └─────────────────┴────────┴───────────────────┘ Two honest caveats from the code. First, the symmetric-NAT port_prediction.rs (saorsa-transport/src/connection/port_prediction.rs at main · WithAutonomi/saorsa-transport · GitHub) is basic — linear delta extrapolation, two guesses, and the “dense search” fallback is explicitly unimplemented; it catches sequential-allocating NATs and misses random ones, so I read 60–80% as “connects at all (often via relay),” not strong direct punching. Second, relay-serving is on by default for any reachable node (default caps: 1,000 sessions, 100 MB/s), and I found no payment for relaying — only a rate limiter. So the hard-NAT tail leans on uncompensated public-node bandwidth. [speculation] Net: ~70–85% of home nodes should work with no configuration — a real step up from 1.0’s port-forwarding misery — but the relay-dependent tail’s health hinges on enough public nodes existing, which is exactly where 1.0’s relay layer struggled.
    1. Who controls the contracts? [measured] The vault’s (https://arbiscan.io/address/0x9A3EcAc693b699Fc0B2B6A50B5549e50c2320A26) owner() is a single externally-owned account (0xeeb3…6ae4 (https://arbiscan.io/address/0xeeb3e0999d01f0d1ed465513e414725a357f6ae4)) — not a multisig/timelock. It doesn’t use standard EIP-1967 proxy slots (so likely not a standard upgradeable proxy — mildly reassuring). The verified source isn’t public to me, so I can’t enumerate owner’s powers; payment vaults usually forward funds to node reward addresses rather than custody them, which would limit risk — but a single-key owner on the contract clearing all storage payments is a centralisation point worth clarifying.
    1. Security & legal notes [measured] - PQC is pure, no hybrid. saorsa-pqc 0.5 (young, in-house lineage), with no classical fallback — bolder than the TLS/NIST norm of hybrid during the transition. No audit evidence in the repos. - No deletion. Permanent immutable storage, no user/network erasure path — a real GDPR/right-to-erasure tension and a question about operator liability for un-inspectable chunks.
    1. Development & team [speculation — handle with care] Commit history reads as a small, senior core (~4 very active committers), steady at ~4–6 distinct humans all year, plus heavy AI augmentation (AI co-authorship on a large share of commits) — plausibly how so few shipped this much. Trend: foundational libraries cooling (infra largely done) while indelible ramps — effort shifting to the product.
    1. Honest speculation The bet looks like post-quantum + frictionless home nodes + a sellable enterprise product (Indelible). Owning the whole transport in-house is high-risk but only sensible if libp2p was a hard ceiling. Immutable-first scope + cooling infra commits + the Indelible ramp read to me as “stabilise and build something to sell before re-expanding” — though a leaner-team / runway-pressure reading can’t be ruled out from outside. —

  13. Verify it yourself - Code: WithAutonomi org (Autonomi · GitHub) · ant-node (GitHub - WithAutonomi/ant-node: Pure quantum-proof network node for the Autonomi decentralized network · GitHub) · saorsa-transport (GitHub - WithAutonomi/saorsa-transport: Shared transport abstraction for the Saorsa ecosystem · GitHub) · 1.0 monorepo (GitHub - maidsafe/autonomi: Autonomi combines the spare capacity of everyday devices to form a new, autonomous, data and communications layer of the Internet · GitHub) - Chain (Arbitrum One): payment vault (https://arbiscan.io/address/0x9A3EcAc693b699Fc0B2B6A50B5549e50c2320A26) · ANT token (https://arbiscan.io/address/0xa78d8321B20c4Ef90eCd72f2588AA985A4BDb684) · vault owner EOA (https://arbiscan.io/address/0xeeb3e0999d01f0d1ed465513e414725a357f6ae4) - Method: git history, scc line counts, direct Arbitrum JSON-RPC event decoding. Single snapshot, heuristic in places, not a security audit. Written by Claude (Anthropic). Posted by a community member who ran the analysis. Corrections very welcome — especially on the vault owner’s privileges and PQC audit status. —

3 Likes
2

Honestly, point #5 really resonates with me

2 Likes
3

and I have the 7th point… :slight_smile:

4

Has anyone tried point 13 - ask yor own AI to do the analysis?

In any case well done @Erik_Hedin :clap: :clap: :clap: