The honest limits

A trust product that hides its limits has none. So this page collects, in one place and in plain order, everything the seal and the Bitcoin anchor do not prove — the caveats a sharp critic would raise, written by us first. None of these breaks the core guarantee; all of them are worth knowing before you rely on it.

Start from what is proven: a prediction you can see was committed at its stated time and hasn't been altered, and — once anchored — you can prove that with zero trust in us. Now the edges.

What anchoring proves — and what it doesn't

Anchoring proves existence and time, not completeness. Committing a fingerprint to Bitcoin proves this prediction existed by that block, unchanged. It does not cryptographically prove that we've surfaced everything — anchoring is proof of inclusion, never proof of exclusion. It can't, by itself, prove we didn't quietly drop some other record that was never published or anchored. Our defence there is a policy one, not a cryptographic one: the store is append-only with no delete path. That's a promise about how we operate, and you should read it as exactly that.

What does protect you completely is holding your own proof bundle: once you've downloaded it, no action of ours — deletion, downtime, disappearance — can take away your ability to prove your call. The guarantee lives in your hands, not our servers.

The residual window before anchoring

Between the instant you publish and the next batch anchor, immutability still rests on our records. Batches run frequently and resolution horizons are days to years — far longer than the wait — so this window is small, but it exists, and during it the strongest thing backing your prediction is the seal in our database, not Bitcoin. The anchor status (unanchored → pending → bitcoin) always tells you the truth about where a given prediction stands.

Granularity is the block, not the second

Bitcoin proves your prediction existed no later than a particular block, which is looser than the precise timestamp we record. For markets this is the fact that matters — you committed before the outcome, and horizons dwarf the anchoring delay — but the trustless claim is block-level, and we won't dress it up as second-level precision.

Backfilled history carries two dates honestly

Predictions made before anchoring launched were anchored later, in one initial pass, so their anchor time is after their creation time. Their fingerprint was still sealed at creation; only the Bitcoin attestation is retroactive. The proof shows both dates rather than hiding the gap — read them as what they are.

Resolution is judged on the horizon price

When a call resolves, aiternam reads the price at the horizon from the sealed source. For a target call, that means we check whether the target was reached at the deadline — we do not trace the intraday path to see whether the price touched your level at some moment in between and fell back. It's a deliberate simplification: one objective, sealed reference point instead of a disputable "did it ever touch" that depends on which feed's ticks you trust. Know that a mid-window spike through your target that doesn't hold won't count.

Scores are derived and revisable — the prediction is not

Only the prediction is immutable by nature: you committed before the outcome was known. The score is derived from it afterward, and it is honestly revisable. The scoring constants — the noise threshold, the ranking's conservatism, the decay rate — may be tuned after launch as we learn, and any such change re-flows through rollups recomputed after it. What never moves is the difficulty sealed into each past call: its entry price, its drift and volatility, its price source. So your reputation number can shift as the method improves, but the sealed facts of every prediction you ever made cannot. (This is also why we don't anchor scores as immutable truth — doing so would freeze the methodology forever.)

The auditable SQL log is a best-effort mirror

We keep an append-only copy of predictions and anchor proofs in a data warehouse for SQL auditing. That mirror is best-effort — the authoritative record is the canonical store plus the proof bundle you can download, not the warehouse copy. Don't treat the analytics mirror as the source of truth; treat your bundle as the source of truth.

The block explorer is a convenience

The link we provide to view a prediction's Bitcoin block goes to a read-only third-party explorer. It's for your convenience — the proof itself never depends on it. For a genuinely zero-trust check, verify the .ots against your own Bitcoin node rather than any explorer, ours included.

The point of this page is that you found our caveats already written down. To exercise the parts that are trustless, see Verify it yourself.