Track record

The service checks new launches on Base by itself, without anyone asking, keeps each signed answer exactly as it was given, and looks again an hour, a day and a week later to see what became of the token. Anyone can read it, and check it.

What is in it

• Which launchesTokens checked 10 to 60 minutes after their first Uniswap V4 pool appeared. Not every launch: up to 48 a day, the one with the most money a seller can reach (at least $1,000), and one pick in three a copy of a known honeypot hook.
• The answerThe same check a caller gets, signed, kept as it was given.
• What happenedAn hour, a day and a week later: was the pool emptied, pulled, forged or turned into a trap?

The figures, as they stand: Evidence.

Reading it

• GET /v1/track-recordThe totals by answer, what became of the tokens after 1 hour, 24 hours and 7 days, and the newest answers.
• GET /v1/track-record/<id>One answer, exactly as it was signed.
• GET /v1/track-record/pagesThe numbered pages the answers are listed on.
• GET /v1/track-record/pages/<n>One page: plain text, one line per answer, naming the page before it.
• GET /v1/track-record/pages/<n>.otsThat page's proof that it existed before a Bitcoin block.

Why the dates can be trusted

A signature proves who gave an answer, not when. So each run's answers are listed on a numbered page, and the page's fingerprint (its SHA-256) is handed to independent OpenTimestamps calendar servers within seconds. Within a few hours it is sealed in a Bitcoin block. Nobody, us included, can then claim we said something earlier than we did, or change a page. Each page names the one before it, so a proof for one page covers every page before it too. A Bitcoin block's time is right to within a couple of hours: the proof settles the day and roughly the hour, not the minute.

Checking a page yourself

With the standard OpenTimestamps client, save the page and its proof side by side, then verify:

The client names the Bitcoin block that holds the page. Each line on the page gives the time, chain, token, answer id and verdict, and the SHA-256 of the answer exactly as /v1/track-record/<id> returns it, so any answer can be matched to its line.