If Agined stops operating

1. The short answer#

Your receipts do not depend on us. A receipt you hold, together with the public key it names, verifies offline with standard cryptography, whether or not Agined still exists. What would stop is the Service itself: new receipts, scheduled checks and watches, the dashboard, the API, the MCP server and our stored copies of receipts.

In plain language: export what matters and keep our public key with it. Then nothing that happens to us can take your evidence away.

2. What keeps working without us#

3. What stops#

• Issuing new receipts, and every tool call that produces one.
• Scheduled checks, DNS and certificate watches, webhook deliveries and the hourly digests.
• The dashboard, the API, the MCP server and the /verify page.
• Our stored copies of receipts. A receipt that exists only in our database cannot be fetched once the Service is gone.
• The published key set at its usual addresses, unless it is kept up as described in section 4.

4. What we commit to if we wind the Service down#

If we decide to stop operating the Service, we will:

1. give at least 30 days' notice by email to every account owner and on the status page, as section 12.3 of the Terms of Service provides, and refund the unused part of any prepaid fee;
2. keep exports working for the whole notice period, on every plan, so you can download your receipts with their key set;
3. publish the final key set in at least one place that does not depend on our infrastructure, such as a release of @agined/verify that bundles it, and say on the status page where it is; and
4. stop signing before we stop publishing: no receipt will be signed after the final key set is published.

If the business is sold or merged instead, the buyer takes over the Terms of Service, which we may assign with notice to you, and our Privacy Policy protections for your data continue.

There is no third-party escrow of keys or source code today.

5. What you can do today#

1. Export regularly. Use the receipt export in the dashboard, which produces a ZIP with the receipts, the key set, verify.mjs, a manifest.json and SHA256SUMS, or list receipts with GET /api/v1/tools/receipts. Keep the result in your own storage, and export before a receipt passes your plan's retention window in any case.
2. Pin the keys. Store the kid and x of the keys you rely on, as Key management explains.
3. Record receipts when you receive them, in a system you control with its own clock, so you can show when you held each one.
4. Keep a verifier you control, whether verify.mjs from an export, a pinned version of @agined/verify, or a few lines of your own code following Verifying receipts.

6. How we keep the Service running meanwhile#

On the Free, Starter, Pro, Pro+ and Team plans, receipts and the rest of each workspace's data are stored in Cloudflare D1 in the workspace's region. Cloudflare's point-in-time recovery (D1 Time Travel) lets us restore those databases to any minute of the last 30 days; we keep no separate backups of them. On the Scale and Enterprise plans, and with the isolation add-on, they are stored in the workspace's own Amazon Aurora database on Amazon Web Services, in the AWS region the workspace chose, where a hash of each receipt is also filed hourly in a write-once batch row in that same database, which its triggers keep from being changed or deleted for seven years. The signing keys, one per data region, are held as encrypted Cloudflare Worker secrets. Self-serve plans carry no uptime commitment; Enterprise customers have the Enterprise SLA.

7. Changes and contact#

We update this page if any of these arrangements change. Questions: support@agined.com.