AlphaAssay $ test my signal

What we keep

This page is the complete retention inventory of AlphaAssay — everything the service keeps, per path, and everything it never keeps. It exists because the strongest attack on any validator is „they can see your strategy — they could trade on it." The honest answer is not a promise of good behaviour; it is an inventory you can size yourself, an architecture with no trading arm, and proofs you can run. If you ever find this page contradicted by the live service, that finding is exactly what we ask you to hunt for.

The retention ledger, path by path

pathkeptnever kept
free demonothing — the demo runs on a throwaway store that is deleted when the call endseverything
validation calls
(signal · backtest · gauntlet · forensics · falsify · batch)
a one-way fingerprint, the verdict with its cause of death, summary statistics (Sharpe, sample length, period), a 32-number compressed sketch of the return profile (family accounting), and the family's structural label with its parameter coordinatesraw candles, trade lists, return/equity series, rules, code
assay_pbonothing from the matrix — the trial matrix is processed in memory and not persistedthe matrix itself
assay_reproduceno ledger entry at all — an arithmetic audit is not a new trialtrades, candles, claimed metrics
pre-registrationthe sealed spec in full (canonical JSON) plus the sealed success criteria, Merkle-anchored — sealing a claim means storing it
x402 paymentsper settled payment: the payment nonce, the paying wallet address, the transaction id, an input digest and the full signed response (no expiry — one payment buys one result, forever)raw inputs — responses never contain them
certificatespurchased certificates in full (signed, incl. trial disclosure), account-bound for re-delivery
operationsusage charges (tool + cents), per-minute tool statistics, sanitised error messages, rate-limit buckets, request logs (id, timestamp, endpoint, status)payloads — an automated canary proves on every release that raw inputs reach no log, error store, metric or alert

The same inventory, with legal bases, is in the privacy policy. The 32-number sketch is bucket means of the return series — far too coarse to reconstruct trades or rules; its only job is proving two variants were near-duplicates so the family budget can count them as one.

Could you front-run what you see during a trial?

Head-on: during the seconds a trial runs, the engine necessarily holds your derived evidence in memory — a remote examiner that sees nothing can test nothing. What makes that window worthless to us is architecture, not virtue. There is nothing to trade with: no exchange connectivity, no order path, no execution logic, no custody — the capability does not exist in the system (the three walls). There is nothing tradeable left afterwards: the retention ledger above keeps statistics about the trial, not the substance of the strategy. And there is no honeypot: verdicts are demote-only, so no list of „verified winners" exists to raid — the graveyard holds anonymised statistics about failed families.

What about the one path where we DO store your strategy?

Pre-registration stores the sealed spec — that is the product, and it has a built-in defence: the seal is a public Merkle anchor with your timestamp. If anyone — including us — ever traded a sealed idea, the anchor is standing public proof of who committed it first, datable to the day. Storing your claim and handing you the priority proof in the same motion is what makes the storage safe to accept: abusing it would manufacture evidence against the abuser.

How do you check any of this, instead of trusting it?

Run the golden specimens (free, known answers, bit-identical). Pull the daily calibration record — signed, demote-only, impossible to retouch. Verify any certificate offline against the published key. Apply the falsification protocol to us before anyone else. And hold this page against the privacy policy and the live service — one truth, or it is a finding.