SealedAudit
Everything on this site is checkable without trusting whoever put it here. Two mechanisms, and they are not the same thing.
What anyone can verify
No key, no permission, no cooperation from us. Clone the repository and run:
npx hardhat run scripts/verify-track-record.ts --network sepoliaIt exits non-zero if any parameter commitment no longer matches the handles the registry holds, if any published NAV fails to reproduce the on-chain rounding rule, or if a history ever goes backwards. The repository’s own test suite runs the same checker against deliberately tampered records — a rewritten commitment, a NAV nudged off its quantum, a reordered history — and asserts each rule fires.
recomputeCommitment(id) against the commitment written at registration. One hash comparison; if a parameter had ever changed, the handle would differ.
TrackRecord has exactly two write functions, no owner, and no path that deletes, amends, or reorders an entry.
strategiesOf(author) returns every strategy they ever registered. There is no deregistration path anywhere in the ABI.
Two contracts contain allowPublicDecryption: the crossing router, for the epoch net and quantized NAV, and disclosure, only when an author asks.
What an author can show you privately
A serious allocator will want to see the parameters before committing capital. An author can grant that — but the mechanism is stranger than it looks, and the strangeness is the interesting part.
The grant lands on a derived copy, never on the live handle. Adding an encrypted value and taking it straight back out leaves the number untouched and produces a new handle with its own ACL — one that nothing in the system depends on.
| Handle | Who can read it | Value |
|---|---|---|
| Live parameter | Nobody. Ever. | 0x0000aa36a723…3bce7ftargetWeightBps (live) This is all anyone can ever see. A handle is a 32-byte pointer to a ciphertext held inside the TEE — not the value, and not an encrypted form of it you could attack offline. Reading it needs an ACL grant that nobody here has. 0x0000aa36a723013e1968087f0566628c25cdfc39c4da1d3265610c2eee3bce7f |
| Disclosed snapshot | One auditor, permanently | 0x0000007a6923…d65d85targetWeightBps (snapshot) A derived copy. Same value, different handle, its own ACL. The grant on it is permanent — but it is scoped to a handle that is already dead, and rotating into a new strategy is what actually ends the auditor's access. 0x0000007a692301f47e951402c7d59610922ddb89d65d85 |
The author keeps control the only way an irrevocable ACL allows: the snapshot ages into a description of a strategy that no longer runs, and a new strategy produces new handles the old auditor cannot read.
And the door that only opens once
An author can unseal a strategy: publish its parameters to everyone, permanently. That call also retires it, in the same transaction.
Not a policy choice bolted on — it follows from the ACL. Public decryption cannot be undone, so a strategy that kept trading afterwards would be running with its edge on display, and every entry in its record after that point would mean something different from every entry before it. The seal breaks once.