59793981
60643336
block range, 849,356 blocks
Paste the fields as the launch shows them. The page compares the strings with every launch of one day and says what is shared, with how many, and since when. It reads strings, not the contract, and it never resolves an address.
What you paste stays in your browser. The table it is compared with is fetched once from this domain on the first check, so a first visit needs the network; nothing else is loaded and nothing leaves the page.
A diagram of the seven checks below, in the order the code runs them. The field names, the tables and the index contents are the real ones; the figures in stage four are a specimen and are marked as such.
Diagram of the process · not a chart, not ornament
as the launch shows them
two spellings, one resource
one day of launches
fetched once, first check
the only path across the boundary, and it points inward
sentences, not a score
snapshot ended .
Where this page is, and why a page like this exists here
Robinhood Chain is an Ethereum-compatible layer-two network built on Arbitrum and running Nitro. Its official documentation says it uses Ethereum blobs for data availability and ETH as its native gas token. Standard EVM wallets and tools can connect through the published network configuration.
The explorer named by Robinhood's official network configuration is Blockscout, at robinhoodchain.blockscout.com. Check an explorer link's host and chain before treating it as a view of this network.
Public network names, explorer links and endpoints are easy to imitate. The same ambiguity appears one level down, in what launches write about themselves: a familiar-looking name, ticker or link is still only a string. That is why this page compares those strings and refuses to tell you what they mean.
This page reads seven strings a launch publishes about itself and compares each with the same string on every launch of one day. It does not open the contract, price anything or resolve an address. Every comparison is on normalized text: trimmed, lowercased where case carries no meaning, and folded where the alias table says two spellings name one resource.
Each row says whether the value is shared, with how many launches, from how many deployers, and since when. That is the whole output.
None of this predicts anything. A shared ticker is a fact about strings, not a signal about a launch.
This reads strings, not the contract. It compares what a launch wrote about itself with what other launches wrote, nothing more.
A shared value is not proof of anything. Projects relaunch, teams share a channel, and copying a link takes a second. The page says what is shared, with how many, and since when, and stops there.
The window is one day, 2026-09-10 to 2026-09-11, its block range stated above. Absence from it means no other launch in that day carries the value. A count never says whether one of the launches counted is the one being pasted, because the page cannot tell.
Nothing here is a view on whether to enter, exit or size anything.
The shipped snapshot records the exact finalized block number and hash used for every identity read. Its printed index hash identifies the shipped bytes, and npm run verify can re-run that recorded state and window before comparing the rebuilt index hash.
npm run verifyStrict reproduction requires an endpoint that can read that historical state and the full recorded log range. If either read or the owned publication guard cannot be completed, the command refuses instead of calling the snapshot reproduced.
Shipped index hash 18cd4c4d6a3255f58b359f7d2c802888bb9d78f8f515f8b1c4d7013fb16ed665
Node for tests and builds. A historical-state RPC is required only for strict reproduction
The code, tests and page build run on your own machine with Node and no runtime dependency. The tests check the vendor table against every copied file, the token block in its three states, the engine, the ABI, the gate and the index schema. The build writes this page from the templates, the numbers file and the index, and refuses a digit that did not arrive by substitution. The current data bundle records the exact finalized identity state used by the collector.
The last command reads the state and window recorded with the current snapshot, rebuilds the index in a temporary directory and compares both hashes. It makes network requests only after checking the local artifacts; an endpoint that cannot serve the required historical state produces a refusal, not a match.
git clone https://github.com/Mnilax/lintcha-chainnpm testthe vendor table, the engine, the schema, the token statesnpm run buildthe page, from the templates and the indexnpm run verifyrebuild the recorded state; compare the index hashThis is the second site of lintcha. The first reads the text people put in AI bot profiles: the charter a bot publishes about itself, checked against a corpus of such charters, with no score.
The same method is pointed here at token launches, because both begin as small pieces of self-description that are easy to copy and easy to stop noticing: a name, a ticker, a description and a few links, set at launch and left as they are. Both sites read that text and stop.
The engine, the skeleton table, the alias table and the tests are written in lintcha and copied here unchanged; the index is built here, from this chain's launch log, on its own schedule.
Collected 2026-09-11 · index 888,039 bytes · 15,842 entries
This section states what the collector read, how each field is normalized before it is hashed, the two tables that fold spellings and hosts, the floor under every count, and what the index holds. The tables are written from the engine's own files at build time, so they cannot drift from the code that runs in your browser.
One day: the 24 hours ending at the latest finalised block at the time of the run, found by bisecting block timestamps, so the window is stated as a block range and two UTC timestamps, 2026-09-10 23:24 to 2026-09-11 23:24. A day was the window one pass over the launch log covered at the endpoint's sustained pace; a longer window would say more about strings and nothing more about launches.
For each guarded refresh, the code records one finalized block number and hash, makes one pass over the launch log of the pons factory on Robinhood Chain, then reads every identity field at that numeric state. Before the writer can run, an owned publication guard re-reads the events through two smaller page layouts with different boundaries, compares every canonical raw row, strictly re-reads sample transactions and identity returns, and must rebuild the same tables and summaries. These are alternate queries to the same configured endpoint, not an independent-provider proof. The snapshot printed on this page carries that identity-state record and passed the publication guard before it shipped. Addresses and raw strings remain inside the processes; a successful refresh writes only counted hashes and its own run figures.
www., trailing slashes and the fragment removed; the path keeps its case. Any other scheme is kept whole, whitespace collapsed only.^0x[0-9a-f]{40}$; checksum case is cosmetic. The zero address counts as empty; anything else that fails the pattern is not readable.An entry is kept when 2 launches or more carry the value, so absence reads as no other launch in the window carrying it. The fee recipient has a second floor, 2 deployers or more, because the same recipient under one deployer is a person relaunching, and that is neither shown nor stored.
Per namespace, the first eight bytes of the hash of the normalized value as sixteen hex characters, and against it three fields: n, how many launches carry it; d, from how many distinct deployers; first, the UTC date of the earliest. The two skeleton namespaces add v, the number of distinct spellings in the group. No address, no raw string, no timestamp beyond a date.
Everything with an axis, a scale or a number below is computed from the shipped index at build time and carries a snapshot badge. The last piece has no axis, no scale and no number, and is not data.
2,534 tickers are carried by two launches or more. The busiest row is 2 launches; the most carried ticker is on 119, from 109 deployers.
Of 2,548 ticker skeleton groups, 98 hold spellings that differ as strings; the largest holds 3. Name skeletons yield 41 such groups.
3,595 link values are carried by two launches or more. 514 of them come from a single deployer; the widest is carried by launches from 163 different deployers.
Where the name, the mark and the window came from
A linter reads a file and reports what is wrong with it without deciding whether the file is good. lintcha is a linter pointed at charters: the text an AI bot publishes about what it is, what it will do and what it will not touch. The name is those two words pushed together, and it stayed because nothing better turned up. This second site keeps it, because a launch is a charter too. A name, a ticker, a description and a few links, set at launch and easy to stop noticing afterward.
The mark is a caret with two strokes cut out of it. A caret is the character an editor puts under the exact spot where something went wrong, which is the whole job in one symbol: point at the place, say nothing about the person. It is acid on near black because a linter has to be legible in a row of tabs, and because the colour belongs to the site and to nothing on the page that carries meaning. Green here is never a verdict.
A day is the unit this page can show whole: one pass over the launch log, with no launch row sampled out of the comparison. The current snapshot was collected without a private feed, records its exact finalized identity state and passed the publication guard before it shipped. A longer window would say more about strings and nothing more about launches; the page will never widen it silently.
A score, a grade or a probability would become the product here. It would also be the part nobody could check without a model, a calibration and a public record of how often it was right. This page has none of those and is not building them. It says what is shared, with how many launches, from how many deployers, and since when, in a sentence, and then it stops. A count that looks like a judgement will be read as one, so there is no count that looks like one.
$LINTCHA is not active while this site's token file has no verified address. The Telegram bot can be live before that and answer commands that do not depend on the token; /ca, /price and /stats say the token does not exist yet, while holder verification and the token feed remain dormant. If $LINTCHA launches, it is intended to exist on the chain this page reads and to fund the endpoint, the hosting and the hours behind the index. It would carry no revenue share, no fee cut, no vote and no claim on anything here, and it could not gate the MIT-licensed code. Holding it would unlock only the bot's holder functions; it would never buy an earlier reading or a better one.
The browser reading, tests and build on this page are in the repository, served so that nobody has to install anything to look. No wallet, nothing to sign, no account. The printed hash identifies the exact index file the page uses, and the numbers artifact records its finalized identity state. The strict command re-reads that state and window and compares a rebuilt index hash; if it cannot complete the read and guard, it refuses. The site is a convenience, not the source: if it computes something the repository cannot, the repository has become decoration and the site has become a claim.
lintcha reads what a launch wrote about itself and says what those strings are shared with. It runs in a browser over a published index and makes no claim about any launch. The current index has an exact file hash and records the finalized identity state required for a strict rebuild; the verifier re-reads that state and window and refuses any gap in public. Here is what is in the tree, what comes next, and what will not get built at all. No dates.
The index is rebuilt by a weekly guarded run and can also be refreshed by a deliberate manual dispatch. Its age still varies when a run fails closed. The page states that age in words beside every result, as well as printing the block range and timestamps from which it was derived.
A count from a stale window is not wrong. It is a true statement about a day that has ended, and the page says which day. But somebody pasting a launch that happened this morning is comparing it with a set that does not contain this morning, and the sentence they read does not warn them. That is the gap, and it is ours, not the endpoint's.
What is in now: the age of the window beside every result and a state-pinned rebuild behind the published snapshot. The guarded refresh runs weekly and can also be dispatched manually. It can become more frequent only as often as a suitable endpoint sustains without weakening the guard. The window will not be widened to make the counts look bigger. If a rebuild fails, the page keeps the old window and says its age rather than showing a partial one.
A room on Telegram, and one bot in it. The bot can be live before the token and answer commands that do not depend on it. Until the site's token file carries a verified address, /ca, /price and /stats say the token does not exist yet, while holder verification and the token feed remain dormant. Once the address is verified, the bot reads finalized token transfers at the configured venue and queues a post for each buy it can prove; a gap is stated, never guessed. It answers with the contract and any price it can read, showing no figure when it cannot, and opens a holder check in a direct message for those who want one. It never messages anyone first, never asks for a key, a seed or an approval, and never holds funds. The holder check is a signature over a plain sentence that says in words that it moves nothing. Every market or holder figure it prints is read from the chain, and its code ships in this repository with the rest.
If $LINTCHA launches, creator fees from its trading are intended to go to one wallet, and that wallet is intended to pay for the endpoint plan, the box the bot runs on and the hours that go into the index. Until the token file carries an address, this is a plan, not a live flow. There would be nothing else attached: no share, no cut, no vote. It could not gate the MIT-licensed code, buy an earlier reading or buy a better one, because there is one published index for everyone.
Commits show what shipped and when. The hash printed above identifies the shipped index bytes, and the numbers artifact records the finalized identity state and window used to build them. The strict command re-reads that state and window, rebuilds the index and compares the hash; any incomplete read or failed guard is a refusal, not a reproduced result. The vendor table names every file copied from lintcha with its hash, and a test recomputes all of them on every push. If something here goes quiet for weeks, ask about it in public.
No dates. Shipped here means implemented and testable in the repository; deployment and a successful chain refresh are separate verified facts. Everything under later depends in part on people who are not us: the public endpoint, and the lintcha repository this one copies from.
No. It tells you whether the strings a launch publishes are shared with other launches of one day, how many, from how many deployers, and since when. Whether a launch is safe, honest or worth anything is not something strings can say, and this page does not say it.
No. It means the string is written by more than one launch in the window. The same ticker means one thing when a team relaunches under it and another when strangers converge on it, which is why the deployer count sits in the sentence and is never shown apart from it.
A day is what one pass over the launch log covers at a pace the endpoint sustained. It is stated on the page with its block range and timestamps. The published snapshot records the exact finalized identity state used for its reads; strict reproduction re-reads that state and refuses if the configured endpoint cannot serve it. A longer window would say more about strings and nothing more about launches.
The index uses the first eight bytes of each normalized value's hash as a key, with a count against it. That truncated key is a privacy and file-size choice, not a claim that collisions are impossible. A collision would merge counts and could not be separated from the published file, which keeps no raw strings. That is a stated limit of the current format.
Under 12 words after normalization, a description is too short to compare: short texts collide by coincidence and the count would say nothing. The check reports that it did not run rather than returning a figure it cannot stand behind.
No. What you paste stays in your browser, and the comparison runs there against the table it fetched. Nothing is stored and no cookie is set. The page does make one request: the first time you check, it fetches that table from this domain, and nothing after that.
Yes. The engine, the collector, the index writer, the tests and this page are in the repository linked in the footer. The engine is written in lintcha and copied here unchanged; a table in the repository names every copied file with its hash.
The same person who runs lintcha, linked above. This site is not affiliated with Robinhood, pons or any launchpad, and it uses none of their marks.
A score would need a model, a calibration and a public record of how often it was right. This site has none of those and is not building them. It reports what the strings share and stops, because a number that looks like a judgment would be read as one.
No. The comparison stays pinned to the published snapshot and its exact window. The separate live wall shows only publishable self-declared names and tickers read after that boundary; it changes no count here and makes no judgment.
No. It answers after you open it, or posts in the public room where it was added. A direct message that starts without you opening the bot is not this bot.
A signature proves that the browser controls the wallet address it checks. The signed message names chain.lintcha.com and the one-time mark from that link, so it cannot be reused with another verification link. It is not a transaction; it requests no approval and spends no gas. Read it in the wallet before signing.