Reference · read from the network, not from documentation
What the network says about archival
The configuration below is read live from testnet when the page loads. Rent is not a flat per-byte rate — the CLI prices it by simulating against the network precisely because that formula does not hold, so no such rate appears here.
| Parameter | Ledgers | About |
|---|---|---|
| max_entry_ttl | 3,110,400 | No entry lives past this. Any figure above it is a live impossibility. |
| min_persistent_ttl | 120,960 | Fresh instance, code and persistent entries start here — about seven days. |
| min_temporary_ttl | 720 | Fresh temporary entries start here — about an hour. Two orders of magnitude below the rest. |
Committed with this build, read at ledger 4,821,849. Refreshing live…
What happens at zero
An entry is still live at its final ledger — remaining zero means one ledger left, not expired. Past it, instance, code and persistent entries are archived: unusable until someone pays to restore them, slower and more expensive than a normal read. Temporary entries are deleted outright and cannot be restored at any price. Reporting those two fates the same way is a serious interface bug, so they are never the same chip anywhere on this site.
Measured, not read from documentation
Ledger close 5.000000 s, ± 0.000050 — sampled from 11 testnet closes 2,000 ledgers apart and run through the same measurement the CLI uses. The precision is the finding: across a full maximum TTL the uncertainty band is over an hour wide, so wall-clock dates are estimates and ledgers are the truth.
Temporary floor: the configured minimum is 720 ledgers, about an hour; our own temporary entry had 688 left when first sampled — the ~57 minutes. Those are two different things and they are stated together so they are not conflated.
Durability, not size: persistent rent measured about 1.95× temporary at byte-identical size. The price follows what the entry is, not only how big it is — which is itself the argument for simulating rather than computing.