EVERY NIGHT AT MIDNIGHT ET, EACH APEX UNIT LOCKS THE DAY THAT JUST ENDED INTO WRITE-ONCE STORAGE AND PUBLISHES ITS FINGERPRINT. NOBODY, US INCLUDED, CAN EDIT OR DELETE A SEALED DAY, AND ANYONE CAN CHECK ONE.
Trading results are easy to dress up. A screenshot can be edited, a bad week can be left out, and old numbers can be changed after the fact. A live page only shows what's true today.
APEX has posted every settled result live since October 30, losses included. The seal covers the past: once a day is over, its record is locked so it can't be rewritten later, not even by the person who runs APEX.
Just after midnight Eastern time, each unit builds a record of the day that just ended: every position that settled that day, the day's numbers (settled, won, win rate and return on stake), running totals, a count by market, the engine versions that ran and the day's public events.
The record is a plain-text file in a fixed format. Its fingerprint is the file's SHA-256 hash, a 64-character code that changes completely if even one character of the file changes.
If any of the day's results are still out, the unit waits for them, up to two hours. After that it seals what it knows and marks the day as not complete. A result that arrives after its day was sealed goes into a later file, marked as carried in, so every position appears in exactly one sealed file. A day sealed more than three hours after midnight is marked late.
Days are sealed in order. A unit never seals today, never seals from a failed database read, and won't seal at all if its clock is more than five minutes off from the storage service's clock. Each unit seals its own file, so every day has two fingerprints, one for APEX1 and one for APEX2.
Sealed days go into a separate storage bucket on Amazon S3 with Object Lock in compliance mode, set to five years. In compliance mode, nobody can overwrite or delete a stored file until its lock runs out, including the account's owner. The lock can be made longer, never shorter.
Two more rules sit on top of the lock. The bucket refuses every delete, and it only accepts a file under a name that isn't taken yet. We tested that with the account's root login, the most powerful one there is: a plain write, the kind that could replace a file, was refused. In the archive, the units themselves can only add a new day and read days back.
If a unit ever tries to seal a day that's already there, the storage refuses it, and the unit keeps the archived copy as the truth.
The fingerprints also leave our servers. The live page and the daily record show them, and starting with the first weekly email, each week's fingerprints go out to subscribers too, so copies sit in inboxes we don't control.
certutil -hashfile apex1-2026-10-31.json SHA256shasum -a 256 apex1-2026-10-31.jsonsha256sum apex1-2026-10-31.jsonBy design, a day file never holds dollar amounts, balances, open positions or settings. It holds returns on stake, win rates and counts, the same numbers as the live page.
Like the rest of APEX, the sealing code was written by AI, with one person directing the work. So nothing in it was taken on trust.
Before release, a separate AI agent that hadn't seen the work read the code cold and found ten problems. Among them: a result that arrived after its day was sealed could have ended up in no file at all, a server clock running fast could have sealed a day that hadn't ended, and a failed database read could have sealed stale numbers. All ten were fixed before the code went live.
32 automated tests check it, including a simulated week with results arriving late, after midnight, where every position had to end up in exactly one sealed file. The tests were also run against 47 deliberately broken copies of the code, and they caught every one.
2653e1f8abb7b9e2a63ff1a8cd4af455a10d5347572b8825c4b18710cb42b2c4
SEALED 00:00:03 ET · NOV 1 · ON TIME, COMPLETE
1ae5e3c43df1fbe76aa5904c97bf5dec1ded4ad1e0ff706a72bf1f293f056ba9
SEALED 00:00:02 ET · NOV 1 · ON TIME, COMPLETE
Every day since is listed in the daily record, newest first, with its files.