Publishing daily numbers is easy. Publishing daily numbers that you cannot quietly go back and improve is the harder problem, and it is the one that decides whether any of the other figures on a site are worth reading.
This board solves it in two layers, and each layer fixes a specific hole in the one below it.
Layer one: the chain
At the end of each day, the day's counters are frozen into a payload and hashed together with the hash of the day before it. That link is stored. The next day links to it, and so on.
hash(day N) = sha256( hash(day N-1) + payload(day N) )
The property this gives you is simple: change any figure in any past day and every hash after it stops matching. You cannot edit one Tuesday. You would have to rebuild every day since that Tuesday.
The whole chain is published at `/stats/chain.json`, so verifying it is a loop anybody can write in ten lines: take each day's payload, hash it with the previous link, compare.
The hole in layer one
Rebuilding every day since that Tuesday is exactly what an operator with a database and an afternoon can do.
A hash chain proves internal consistency. It cannot prove when it was built, because every timestamp inside it was also written by us. Nothing inside a system can prove the system is not younger than it claims to be.
That is not a small caveat. It is the entire weakness of every self-published audit log, and most projects that publish one do not mention it.
Layer two: a timestamp from outside
So each seal is submitted to OpenTimestamps, which aggregates it into a Bitcoin transaction.
Once a calendar confirms it, the proof says that this exact hash existed before that Bitcoin block was mined. Bitcoin blocks are expensive, public and not ours. A rebuilt chain would have to produce timestamps that already exist in a blockchain somebody else paid for, and it cannot.
The console shows how many days are sealed, how many have been sent to a calendar, and how many a calendar has confirmed, because the useful question is not "is there a timestamping system" but "is it actually running this week".
What this does and does not prove
It proves the numbers you are reading today are the numbers that were recorded on those days, and that the record existed at the time it says it did.
It does not prove the numbers were correct when they were recorded. If the counter is wrong, the chain faithfully preserves a wrong number forever. Nothing about anchoring fixes a measurement error, and anybody claiming otherwise is overselling the technique.
That limit is why the stats page also says plainly what the counters can and cannot see: that a visit is a request and not a person, that crawlers are counted separately because a modern crawler carries a full browser user agent, and that no amount of chaining makes an integer into a headcount.
Why bother for a directory
Because this board sells positions, and a board that sells positions has an obvious incentive to inflate the numbers a buyer uses to decide what a position is worth.
Removing our own ability to do that quietly is worth more than any promise on an about page. The receipts tie the income to the Monero chain, the seals tie the daily figures to each other, and the timestamps tie the seals to a chain nobody here controls.
None of it asks to be trusted. That is the point of doing it this way.