Pre-register a call

Pre-registration records the hypothesis before its evaluation window. You deposit a canonical hypothesis; the service records its hash and acceptance time in an operator-published chained commitment. Evaluation later uses data strictly after that stored cutoff.

How does pre-registration work?

You submit a hypothesis and retain the returned commitment or published chain head; comparing that retained value with later publications makes a change detectable. The market then plays out, and the battery scores the stored call on strictly post-cutoff data. Registration and evaluation are separately metered at the amounts in the live pricing registry; waiting between them costs nothing. The steps are below.

Why is a sealed prediction the only honest track record?

Any backtest can be curve-fit after the fact; any screenshot can be cherry-picked. A retained pre-registration commitment gives a reviewer something concrete to compare with the later evaluation. It does not independently prove time or immutability while external_anchor is empty: an independent external anchor or independently retained chain head is required for that stronger claim. Registration and evaluation are two separately metered actions; read their current amounts from /v1/meta/pricing.

What do repeated calls build?

Every evaluation lands on your record. Ten sealed calls scored honestly say more than any pitch deck — and a certificate makes the record portable.

Can you seal the success criteria too?

Yes — and you should. A registration optionally carries a machine-readable hypothesis tuple: the pass threshold you commit to in advance (an annualised Sharpe), a hard cap on the evaluation window, the fee assumption and the trading calendar. The tuple is hashed into the same operator-published Merkle leaf as the spec, so a retained commitment covers both. Evaluation then enforces the seal: changed fee or calendar wishes are computed under the sealed values and named as goalpost_moved („success criteria chosen after seeing the data are not criteria"), and the window is cut hard at the sealed maximum — waiting longer than promised cannot improve the verdict, structurally. Whether your own sealed bar was met is reported as a descriptive fact; it is never a blessing from us.

Is the registered spec stored?

Yes — deliberately, and this is the one path where it is. A sealed claim must store what it seals: your spec is kept as canonical JSON so the post-cutoff evaluation can run against exactly what you committed, and its hash is included in the operator-published Merkle/JSONL chain. Withdrawing a registration does not unspend the trial — it still counts against the family budget, because register-ten-withdraw-nine is the oldest trick in the book. Ordinary validation calls do not store your rules: what is kept on each path, precisely.