This page works through the numbers that decide whether keeping a contract alive actually happens. The short version: maintenance costs real money, someone has to be paid to do it, and the tip has to exceed the cost or no keeper will run. Everything below is worked from measured testnet figures, not estimates.
There are two ways to extend a contract's time-to-live, and they cost very different amounts. These are real fees from testnet transactions against the deployed contracts.
| Operation | What it does | Fee |
|---|---|---|
extend_all (via contract) |
Runs contract logic, extends declared keys and instance storage, can restore archived entries | ~1.92 XLM |
Raw extendFootprintTtl |
Extends specified ledger keys directly, no contract logic | ~0.0049 XLM |
The gap is large and it is not noise. Calling extend_all invokes the contract, which means the transaction pays for contract execution and, when an entry has already been archived, for restoring it. The raw footprint extension does none of that — it touches ledger keys directly and runs no code.
The extend_all path is the one that matters for the economic model, because it is the only path that records maintenance and therefore the only path a keeper can be paid for.
A keeper is not a charity. It calls extend_all, pays the ~1.92 XLM fee out of its own account, and then claims a tip from the contract's vault. For the keeper to keep running, the tip has to be worth more than the fee it just paid.
If the tip is set below the extend_all cost, the keeper loses money on every maintenance and stops. The contract's keys then drift toward expiry with no one maintaining them — the vault exists, it is funded, and it still fails, because no rational keeper will touch it.
So the rule for anyone opening a vault:
Set the tip above the
extend_allcost, with margin. A tip that only just covers the fee leaves the keeper no reason to prefer your contract over any other.
A workable starting point on testnet, given a ~1.92 XLM cost: a tip of 2.5–3 XLM covers the fee and leaves the keeper a clear margin. On mainnet, measure the actual extend_all cost for your contract first — it varies with how many keys you declare and whether restoration is involved — and set the tip from that measurement, not from this page.
A vault also sets a minimum interval between payouts. Its job is to bound how often a keeper can be paid, so a keeper cannot call extend_all repeatedly and claim a tip each time.
The interval should be set from the contract's own maintenance need, which is extend_to - threshold — the window between when a key becomes eligible for extension and when it would expire. Setting the interval shorter than this does not make the contract safer; it just lets the keeper claim more tips for the same protection, because extend_all records a maintenance run whether or not any key actually needed extending. The deployed example uses a threshold of 100,000 ledgers and an extend-to of 500,000, giving a maintenance window of 400,000 ledgers — and the vault interval is set to match.
The vault cannot confirm that a maintenance was necessary — only that it happened, who did it, and that the interval elapsed. In economic terms this means a keeper can, at most, collect one tip per interval for maintenance that may not have been needed. The vault owner controls the exposure: the tip size, the interval length, and the total balance are all theirs to set, and they can withdraw at any time. The bound on loss is one tip per interval, capped by the balance. It is a rate limit, not a guarantee that every paid maintenance was required.
The cost numbers above assume an honest contract. A keeper running the daemon against the whole registry faces a different exposure: a contract registered specifically to be expensive to maintain. Registration is permissionless, and the keeper's daemon does not, by default, cap what it will pay to maintain any single contract. A costly-but-genuine extension looks productive by every signal available. This is a real limitation of the current keeper, documented in Running a keeper and Security. Until a per-extension fee ceiling exists, do not run the daemon against a funded key you are not prepared to expose to that risk.