Note

Pay-Once Is Not a Subscription: Autonomi Upload Payment vs Retrieval

Autonomi's documentation describes one payment event at write time, no recurring storage charge, and no fee to read.

2026-10-12 · autonomi, decentralized-storage, payment-model, pay-once, immutable-storage, ant, read-only, external-signer, data-residency, civil-liberties

Most storage people use is rent: pay monthly, stop paying and the account goes dark, read too often and egress fees appear. Autonomi's documentation describes a different contract with a different shape: one payment event at write time, no recurring storage charge, and no fee to read. That is not a discount on rent. It is a design where the thing you pay for — an immutable, content-addressed write — cannot be renewed, edited in place, or metered on the way out.

This note is the third in a CryptoDecentral Autonomi series. The self-encryption and Data Map note covers how bytes become encrypted chunks. The immutable chunks note covers why chunks are the only storage primitive and how public addresses differ from private DataMaps. Here the question is narrower: what exactly is paid for, when, by whom, and what does payment not buy?

Educational only. No token pitch, no prices, no migration coaching.

The contract: one write, one payment event

The payment model is stated plainly: you pay in Autonomi Network Token (ANT), the network's payment token for storage writes, when you upload, then retrieve later "without ongoing storage charges or download fees." The docs frame this as immutable storage "rather than renewable storage leases."

That framing only makes sense because of the storage model underneath. The data-types page says all stored data is "permanent and unchangeable," and calls that immutability "what makes the pay-once economic model work." A chunk's address is derived from the BLAKE3 hash of its encrypted content. There is no path you hold a lease on, so there is nothing to renew. Change the content and you get new chunks at new addresses — which means an update is a new upload and a new payment event, not a lease extension on the old name.

The network-economics key properties page draws the sharper consequence: because payment is a one-time write fee rather than an ongoing account, the system does not need to track data ownership, and nobody is given the ability to delete files. A subscription needs a subscriber record. Pay-at-write does not.

How a paid write actually happens

"Pay once" sounds like a slogan until you look at the write path. The documented steps are concrete:

Wallet context is required for writes. antd reads AUTONOMI_WALLET_KEY; the ant CLI and ant-core use SECRET_KEY or an attached Wallet. Without one, direct-wallet write endpoints fail. The keys, addresses, and DataMaps page is explicit that this key is about payment, not decryption.
Close peers quote. The client asks nodes near the target addresses for signed storage quotes, validates them, and builds an on-chain payment from them.
Quotes are load-shaped, and checkable. Node-side pricing follows BASELINE + (n * n * K) / (D * D), where n is the key_count in the node's signed storage commitment and K and D are fixed constants. A non-zero baseline acts as a spam floor; the quadratic term rises as a node fills, nudging new writes toward less-loaded parts of the network. Crucially, the client recomputes the expected price from the same committed key count before paying, so a node cannot simply name a figure. (The quote calculations page publishes the calibrated curve; this site deliberately does not reproduce numbers.)
Settlement runs on an EVM network. The CLI exposes arbitrum-one, arbitrum-sepolia, and local as settlement choices for payment proofs. Two costs are distinct: ANT covers storage; gas covers the transaction itself.
Batching is a mode, not a price trick. auto picks Merkle batch payment for larger batches and single payments otherwise; merkle forces batching (at least two chunks); single forces per-chunk payment. In ant-core the Merkle threshold is 64 chunks. Batching cuts transaction count; it does not change what is paid for.
Nodes verify before storing. Each write arrives with a payment proof. Nodes check signatures, verify the on-chain payment, and validate the record before it enters the chunk store. No valid proof, no stored chunk.

One quiet consequence of content addressing: the external-signer guide notes that if a chunk is already stored, prepare returns already_stored: true with its existing address and no payment to make. Identical encrypted content is the same chunk. You pay for new bytes on the network, not for the act of asking.

Estimates are estimates

antd exposes POST /v1/data/cost and POST /v1/files/cost, which return a structured estimate: cost, file size, chunk count, estimated gas, and the payment mode that would be used. Estimation needs no wallet and spends nothing.

The cost-estimation guide is unusually candid about limits. Storage pricing is extrapolated from at most five sampled chunk addresses. The gas figure is a heuristic, not a live oracle. A public data upload also pays for storing the DataMap chunk, which the in-memory estimate does not count. Final payment can differ because availability and quotes change. And a failed storage attempt can still have spent funds. Pay-once means one payment event per successful write — not a guarantee that every attempt is free of cost.

The read path has no meter

The read-only features guide lists what retrieval does not need: no ANT, no gas, no wallet, no upload permissions. Public content comes back from a 64-character address; private content from a caller-held DataMap. The guide recommends keeping wallet configuration out of read-only apps entirely, so dashboards and content browsers never touch payment keys.

That separation is the practical meaning of "no retrieval fees." It also exposes the one thing payment never buys: access. The same guide notes that private content still requires the DataMap "even though the storage payment has already happened." Lose the DataMap and the chunks you paid for remain on the network as unreadable fragments. Payment and retrieval are different jobs held by different material.

Who holds the paying key

Because writes need a wallet, the trust boundary sits wherever that key lives. The external-signer flow lets antd run without AUTONOMI_WALLET_KEY: it prepares an upload, returns the quotes and contract addresses, an outside signer submits payment, and antd finalizes with the transaction hashes. The guide also flags that the OpenAPI description and runtime behaviour are not fully aligned for public external-signer preparation, so read the supported-operations list before integrating.

A second boundary is worth naming: in the direct-wallet path, antd grants the configured payment vault an unlimited token allowance when the existing allowance is too low. That is documented behaviour, not a hidden flaw, but it belongs in any reasoning about the paying key.

Rent versus a write receipt, beyond any one country

Recurring storage rent fails in a specific way when power is uneven. A card gets declined, a payment processor withdraws, an account is suspended for policy reasons, a currency becomes hard to spend abroad — and an archive goes dark not because anyone deleted it, but because the lease stopped. Independent journalists, diaspora archives, clinics, cooperatives, and civic groups under platform pressure know versions of this.

Pay-at-write changes which failure you plan for. The dependency becomes a one-time payment at upload plus custody of addresses and DataMaps afterwards, rather than an unbroken billing relationship. That is not immunity. It is a different shape of risk, and the honest question is whether your threat model fears losing a lease more than losing a DataMap.

What this is not

It is not an investment case for ANT, a price note, or a cost comparison. No figures are quoted on purpose. It is not a ranking against IPFS, Filecoin, Arweave-style designs, or conventional clouds, and not advice to move anything anywhere. It is not personalised wallet or custody guidance. It does not claim "permanent" is metaphysics: immutability is a protocol property, while durability still depends on nodes staying online and honest, software staying correct, and the incentive design holding up over time. It does not say reads cost nobody anything — serving data still consumes node resources; the docs place payment at write time rather than on the reader. And it does not repeat the self-encryption or chunk-model notes.

Educational takeaway: if you can say what triggers payment (a new immutable write), what checks it (client-recomputed quotes and node-verified proofs), what it does not cover (reads, access, deletion), and where the paying key lives, you are reading Autonomi's storage contract as documentation, not as marketing.