How Calibr checks a coin

Method version 0.12.1. This page describes exactly what the software in this repo does today. When a check changes what it reports, the version goes up and the change is listed at the bottom.

What a check is, and is not

Calibr reports which of a coin's own claims are backed by evidence anyone can open.

It does not say whether a coin is a good buy, whether it is safe, or what its team intends. "Not verified" means no evidence was found in this check. It does not mean the claim is false.

Who makes a card

Software. Code reads the chain, the site and the code; an AI model (Claude) marks the project's claims; and code checks every mark against its quote and its evidence (the rules under Claims). No person reviews a card before it is shown, including a card someone asked for. Every card, whether it is on the site or drawn live while a check runs, says so:

Made by software: code reads the chain, the site and the code, an AI model marks the claims, and code checks every mark against its quote and its evidence. No person reviews a card before it is shown.

A card can still be put right. Anyone can contest a finding or a claim with evidence, as Disputes below describes; the contest and its outcome are public, and every change is listed on the corrections page.

Where the evidence comes from

Nothing else is read. Older X posts, replies, Telegram groups, Discord servers, other chains and wallets beyond those named below are not checked in this version.

Findings

A finding is one fact with a link to its evidence. Each has a status:

Launch

How the exempt wallets are read

Pons charges a snipe tax on buys in the first three seconds of a launch. It always exempts the coin's deployer and its fee wallet, and lets a creator name up to 32 more wallets that skip it. Naming wallets is a feature of the launchpad, so an exemption alone is not flagged. What the wallets did with it is on the chain, and that is what the finding reports.

• A buy is a transfer of a positive amount of the coin out of the bonding curve. Anyone can make the curve emit a transfer of zero, so those are not buys.
• The window is the tax itself: every block whose timestamp is less than three seconds after the launch block's (the factory's setting, read on 2026-10-02). It is found by reading the blocks that hold buys, not by counting blocks, because blocks do not come at a fixed pace.
• The buy bundled into the launch transaction is left out, because it has a finding of its own. So is the hand-over when a coin graduates: the curve sends the rest of the supply (2/7 of it) to the Pons factory, which seeds the pool. If a coin graduates while the tax is still on, the finding says so: buys from its pool after that are not counted.
• Many wallets trade through a contract that takes delivery for them, so the receiving address is often not the buyer. A buy counts as a wallet's when that wallet sent the transaction or received the tokens. When the tokens went to another address, the finding says so. Who sent each transaction is read from its block, so there is no limit on how many buys can be read.
• Each listed wallet counts once, however often the launch call lists it.
• Tokens delivered to an exempt address in a buy that another wallet sent are counted apart, because an exempt address can be a contract that buys for many people. The finding says how much went that way and how many wallets sent those buys, and does not call it the exempt wallets' own buying. The flag counts both.
• The deployer and the fee wallet are read the same way, for buys outside the launch transaction. This is only done for a coin launched straight through Pons: through another contract, the recorded deployer is that contract.
• "Hold now" is the balance of the exempt wallets' own addresses at the time of the check. Tokens held for them by another contract are not seen.
• The finding is flagged when the listed wallets, or the deployer and the fee wallet, bought 5% of supply or more while the tax was on. Below that it is a plain fact, and an exemption nobody used is reported as exactly that.
• Tokens sold back and bought again within the window count each time they are bought.
• If the blocks or the balances cannot be read, the finding says what was bought could not be read. It does not guess.
• Each block gets a second try. If one still cannot be read, the read stops there and keeps the unbroken run of blocks before it. The figures then say "at least", the finding says how far into the tax the read got, and it is marked not fully read unless the floor alone reaches the 5% flag.

The first-minute numbers count tokens each time the curve sells them, so tokens sold back and bought again are counted twice. The address that received the most is often a trading contract used by many wallets; the finding says when it is a contract.

Coins from Pons version 1

Pons's first launchpad (two factories, the ones its documentation calls legacy and active, from 2026-06 to 2026-07) made coins another way, and the PONS token itself is one of them. There is no bonding curve: the factory minted the whole supply into a Uniswap v3 pool against WETH in the launch transaction, and a Pons locker holds the pool position. A card for such a coin says so, and reads what that launchpad kept instead:

• A coin counts as a version 1 coin only when one of the two Pons factories launched it, which its launch record on that factory confirms. A launchpad that runs the same code but is not Pons's is not Pons, and its coins are turned away.
• The trading terms are the pool's fee (1%) and the split of the pool's fees, fixed in the locker when the coin launched: 90% to the creator and 10% to Pons for the legacy factory, 70% and 30% for the active one. There is no creator tax.
• Pons marks a coin graduated when the WETH held as principal in its locked position reaches the factory's threshold (4.2 WETH). Nothing moves on graduation, so the card reports the mark as what it is.
• The launch's protection replaces the snipe tax. For a number of Ethereum blocks after launch (Robinhood Chain counts the window in Ethereum blocks, about 12 seconds each), the coin's own code refused any buy from the pool that would leave a wallet holding more than a share of supply, or buying more than a share in total, and in the launch block it let only the bundled buy through. The card states the limits from the coin's settings, finds the last block of this chain in which they were on, and counts what the pool sold to how many addresses while they were on, the bundled buy left out. Who sent each buy is not read here, so the receiving address stands for the buyer, as in the first-minute finding.
• The buy bundled into the launch is read from the launch record and the launch call: the launch wallet paid it in ETH, and the factory sent the tokens to the fee wallet the call named, or to the launch wallet when it named none. When the launch came through another contract, the recipient is read from the launch transaction's own transfer out of the pool.
• Fees are not swept and there is no escrow. The pool's fees sit in the locked position until someone claims them: the creator, the deployer, Pons's owner, or Pons's own collectors, which claim for a creator who does not. A claim pays the fee wallet and Pons their shares at once, in both the pair asset and the coin. The card adds up the claims, says how many were sent by the fee wallet or the deployer, and asks the position what a claim would pay out now, as what is waiting.
• The fee wallet is the redirect set on the locker, or the deployer when none is set; the deployer can change it at any time, and the card says so.
• The deployer's other coins are counted on the same factory, as for v2.

The two factories' coins are read the same way. Which of the two made the coin only changes what the card can say about the locker: the active factory's locker has published source with no function to withdraw a position; the legacy locker's source is not published, so the card says that Pons calls the liquidity locked for good and that the check could not confirm it from the code.

Money

Two limits to know:

• The fee escrow keeps one balance per wallet. Claims and waiting balances cover every coin that pays that wallet.
• Tokens sent to the bonding curve were sold: the curve accepts tokens no other way. Tokens sent to the Uniswap pool manager were sold or added as liquidity, and the finding says so.

Site, code and identity

The page is read in a browser as a visitor sees it, after its JavaScript runs. The read waits until the text holds still, and waits out a loading screen for up to eight seconds. Its visible text is what the checks and the claims stage read, and a picture of its first screen is kept with the card. Links count when the browser shows them, and also when the HTML as delivered holds them, so a footer that fades in on scroll or a menu that opens on hover is still the site's. The plain read, the HTML as delivered, stands instead in these cases:

• No browser could read the page. A site that only renders with JavaScript is then reported as not read, and nothing is concluded from it.
• The browser was shown a bot check ("Just a moment...", "Access denied", "Vercel Security Checkpoint"). It is not the site, so no picture is kept either.
• The browser showed far less text than the HTML holds, under a third of it, as when a sign-in box covers the page or the text sits in closed tabs. The plain read's words stand for the checks. The picture is kept, as what a visitor sees, only if it is of the same page.

Some hosts turn away automated readers. The plain read tells from the answer when that is what happened: Vercel's bot protection says so in its x-vercel-mitigated header (challenge or deny), Cloudflare's in its cf-mitigated header or with a challenge page, other hosts with a 403 or 503 whose page is a bot check, and a request limit with status 429. A 403 or 503 counts too when the browser was then shown a bot check. If the browser did not get the page either, the card says the website turned away the checker, names who and the status, and reports the site as not read, never as a flag: a person's browser passes such a check, so the site is up, and Calibr does not try to get past it. Nothing on such a site is read, so nothing is concluded from it. A site whose domain has no address does not load for anyone: it is flagged, and the card says the domain has no address and may have lapsed.

A page that shows the browser almost no text (under 400 characters) and runs scripts is reported as barely read, like an app the plain read could not read: nothing is concluded from what it does not show, because its address may sit in a button or a picture. When a script sends the browser to another page, the card names the page the browser ended on, the picture records which page it shows, and the hash of the HTML as delivered is left out, because it belongs to the first page.

A link-in-bio page is recognized after the browser read too, because some of them turn away the plain fetcher.

A project's first page is rarely where it says everything, so the check reads more of the site:

• Parts of the first page. A link that jumps to a part of the same page (#tokenomics, #products) is followed: the browser scrolls there and takes a picture, up to four parts, in the page's order. A part that already shows on the first screen, or sits so close to one already taken that the picture would be the same, is skipped. The page's scripts run for a moment after each scroll, so a part that fades in as it comes into view is shown.
• Other pages. Up to four more of the site's own pages are read: pages on the site's host, or on a host under it (docs.example.com for example.com). A neighbour on a shared host is someone else's (other.vercel.app is not part of project.vercel.app), and so is any other site, however its link is worded. Pages are taken in order of what their link's words and address say they hold: a white paper, tokenomics or the token first; then docs, a manifesto, an about page or how it works; then a roadmap, the team, products, features, FAQ, audits, security, staking, buybacks or burns; then an app, a launch, the ecosystem, a blog or news; then anything else. Terms, privacy, cookie and legal pages, sign-in pages, careers, contact, press kits and status pages are never read, nor files such as PDFs. A page that sends the reader off the site, or back to one already read, is left out, and so is a link to a port of its own. A site listed on a host shared by many people's pages (GitHub, Medium, Mirror, Substack, Notion, X and the like) or on a launchpad, an explorer or a chart is read as one page with its parts, as before: the host's other pages are not the project's.
• Time. The first page and its parts get 55 seconds, the other pages one minute between them (30 seconds at most each), started one at a time while there is time left; fetching a page counts against its time, redirects included. A page that did not load is listed as such. A check has seven minutes in all, and one near its end reads fewer pages and takes fewer close-ups, so its card is delivered rather than stopped with it.

The other pages' text goes to the claims stage with the first page's, and a page that shows the coin's address counts as the site pointing back. The address is outlined where that page shows it when the first page does not, on the same page the point-back finding names. The outline is drawn on the picture afterwards, never on the project's page, so the page cannot move or hide it.

Each finding that rests on something a visitor can see carries a picture of it: the site's first screen in the website finding; where the site shows the coin's address, outlined in red, in the point-back finding; each linked repository's page on GitHub in its own finding; and the link-in-bio page that led to the site. The parts of the first page and the site's other pages are shown together under the card's header, each named by the words of the site's own link to it. A claim quoted from the site carries a close-up of where the site says it (see Claims). X profiles are not photographed: X's rules forbid scripted browsing, and the profile is read through X's API. A picture taken after a check, for a card made before checks kept their own, says when it was taken.

A domain holding page is flagged when the page is short, says what registrars and sellers say (the domain is for sale, was recently registered with a named registrar, or is parked), and also names who parked it: a registrar, a marketplace or a parking service, in its words or its links. A page that says its own domain is for sale counts by itself. The finding quotes the words. A project about domains that uses the same words is not flagged.

Anyone can list any website or X account when launching a coin. The two "point back" findings are what show whether the site or the account acknowledges this coin. When neither does, the claims that follow belong to the site, and nothing read shows they belong to the coin.

A site points back at a coin in one of two ways, and no other:

• It shows the coin's contract address in text a visitor can see, or links to it, on the page the coin lists or on another of the site's own pages that was read. An address in hidden text, a comment or a script does not count. Neither does one that is already in the link the coin listed, or in the address of the page it shows on, because a page can show that just by repeating its own address; and when the listed link holds the address, nothing else on the same host counts either. An address shown in a filled-in box, such as one with a copy button, counts like text.
• It links to the X account the coin lists, and that account shows the coin's address. A real project's site will not link to an impostor's account.

A repository the site links to is treated as the project's own only when the site points back and the repository names the site or the coin, in its homepage field, its README or its description. Otherwise the finding says it may be someone else's code.

Text hidden with an inline style, the hidden attribute or aria-hidden is removed before a page is read. Text hidden by a stylesheet cannot be told apart without drawing the page, and is still read.

About the X account:

• Only the profile and its pinned post are read, through X's own API. Calibr never scripts x.com.
• When the coin lists no website, the site its X profile links to is read instead, and the findings say so.
• A link-in-bio page (linktr.ee, bio.site and the like) lists a project's links and is not its site. It is followed once, to the first link on it that could be a site: not a social network, chart, launchpad, explorer or code host. The site found that way still has to point back at the coin by itself. The card names the link page it went through, and a link page that lists no site is reported as exactly that, never graded as the website.
• Follower counts are reported, never judged. They can be bought.
• An X community is not an account and is not read.
• The read costs about 1.5 cents. If the API key is missing, out of credit or refused, the report says the account was not read.

Contracts the project names

Many projects point at a contract of their own: a registry, a vault, a staking contract. Calibr reads up to five of the addresses a project writes in its page text, links to from its page, or lists in its README, leaving out the coin's own launch contracts.

How the source and the settings are read (method 0.11.0):

• Published source. Sourcify is asked for the contract. "Matches it exactly" means the published source yields the deployed code byte for byte; "matches it" means only the compiler metadata differs. The deployer and the deployment transaction come from the same record. When nothing is published, the card says so, and only the common getters below are asked. When Sourcify could not be asked, the card says that instead, which is not the same thing.
• What a privileged address can do. Among the functions the deployed contract exposes (by its ABI, so a sibling contract in the same build is not read as this one), every write whose header carries a modifier that restricts its caller. A modifier counts as such when the common libraries use it that way (onlyOwner, onlyRole, restricted, auth, requiresAuth), when its own definition in the published files checks the caller against a stored address, an owner or a role, or, for a modifier defined where this check cannot see, when its name begins with "only". A modifier whose definition only checks that the caller is a plain account (onlyEOA) is not one, nor are the libraries' state and lifecycle modifiers (nonReentrant, whenNotPaused, initializer). Each restricted function is sorted by its name into what it plainly says it does: replace the code, mint new tokens, pause, block or freeze accounts, take tokens out, change fees, hand over ownership, appoint or remove privileged addresses, change settings, or something else, which is named as it is. The card groups them by modifier: "Its owner can: ..." for onlyOwner, "Whoever passes its X check can: ..." for any other. This is a reading of names, not of what the functions do: a function restricted by a check inside its body rather than a modifier is not seen, and the words say what the source allows, never what anyone intends. Library files are read for this too, so an owner's power to hand over ownership shows when the contract inherits it. Comments and string literals are blanked first, so a comment marker inside a string opens no comment. The card says exactly what was read: when no exposed function carries such a modifier it says that and that body checks are not seen, never that nothing is restricted, and it names the other modifiers those functions use that this rule did not read as restrictions. When owner() answers the zero address, the card says ownership was renounced or never set, and that nothing restricted to the owner can now be called. The contract's own file is read wherever it sits in the published tree; when the project's files are longer than this check keeps (120,000 characters), the source is not read for this, and the card says so.
• Settings. Every public getter in the ABI that takes nothing and answers one number, address, flag or short text is called (the common ones first, then up to 120 of the contract's own), and its answer printed under its own name, the token basics left out; 30 are printed, constants (named in capitals) last, and the card counts the rest. The name is the project's word for it. A number named in basis points is also shown as a percentage. Total supply and total assets are printed in their tokens' units; every other number is in the contract's own smallest unit, and the model is told never to match one to an amount the project states. An address is named for what it is to this coin: the owner, the wallet that launched the coin, its fee wallet, the coin, the contract itself, or none set, and each address a setting names is also given in full as evidence. A contract with no published source is asked only the common getters: owner, pending owner, paused, asset, total assets, total supply, implementation.
• Proxies. The EIP-1967 storage slots are read. A contract that holds an implementation, admin or beacon there is a proxy: its code can be replaced by its admin or whoever controls the beacon. The source and settings described are the implementation's, the code in place now, and the deployment is the proxy's own. A contract with those slots empty is then read for whether its code can hand a call to another contract's code (a DELEGATECALL in its bytecode, the compiler's trailing metadata left out): when it cannot, the card says it is not a proxy and its code cannot be replaced; when it can, the card says so and draws no conclusion, because this check does not follow such calls. When the slots could not be read, the card says nothing about proxies. What an owner can still change is listed with the contract's powers and settings. A beacon proxy's implementation is read from its beacon.
• Holdings. The contract's balance of this coin, of the asset the coin is paired with, and of the asset the contract itself holds when it is a vault (its asset() getter), with their symbols and decimals as the tokens report them.
• Where contracts come from. Up to five addresses the project names: on the page the coin links to, on the site's other pages that were read, or in its README. They are read two at a time, and the deeper read of one gets 25 seconds; past that, the card keeps what was read by then. An address whose code is a delegation (EIP-7702) is a wallet, not a contract of the project's, and the card says so. "Created in a transaction sent by" names the sender of the creating transaction, which a factory or a relayer may have sent for someone else. A contract the chain itself ties to the coin, created in a transaction sent by the wallet that launched the coin, is treated as the coin's own wherever it was named, even when the site does not point back. Only that counts: ownership can be handed to anyone, and the fee wallet is the creator's own choice, so neither proves whose contract it is.
• What this is not. Not an audit. Nothing here says whether the code is correct, safe, or does what its names suggest. Events are still counted, not read. Roles beyond the owner (access-control roles and their holders) are not enumerated.

Limits to know:

• Events are counted, not interpreted. "120 SealWritten events" shows the contract is in use. It does not show a seal is correct.
• A contract can change its storage without emitting an event. "No events in seven days" is what was seen, not proof nothing happened.
• Only Robinhood Chain is read. A contract on Base or Ethereum is reported as "not read", never as missing.
• The chain node returns at most 10,000 events for one request. A busier contract is counted over two days, three hours or seventeen minutes, and the finding says which. One too busy even for that is reported as too busy to count.
• An event type missing from the public database is counted but not named.
• An address that only appears in the page's source, such as inside an image URL or a script, is not treated as something the project named.

Claims

After the findings are built, a model reads them together with the coin's own description, the text of the site's pages that were read, README, the published source of the contracts the project names, and the bio and pinned post of its X account. The site's other pages come after the X profile, 6,000 characters each, and the contract source comes last, 4,000 characters a contract and 10,000 in all, so a long pack cuts the source first: the findings already carry what the source showed. It lists the concrete claims the project makes and gives each one a status:

"Not checked" is a limit of this version, not a mark against the project. Each one names what would have to be read, and that list is what the next versions add.

A claim with two reasonable readings is never marked verified on one of them. "Now on Robinhood" could mean Robinhood Chain or the Robinhood app, and a coin trading on the chain shows only the first. The reason says which reading the findings show, and the status follows the other one: "not checked" when its evidence was not read, "not verified" when it was read and showed nothing.

Choosing between "not verified" and "not checked" comes down to one question: did this check read the place where the proof would be? If a listed X account, an app or a contract was not read, a claim that depends on it is "not checked", however little else was found.

What some findings do not show, so a claim that depends on it is "not checked":

• A contract the project names: the check reads its published source, its deployer and owner, whether it is a proxy, what its source lets a privileged address do, its settings and what it holds (see Contracts the project names). A setting's name is the project's word for it, so the model matches a setting to a claim only when the name and the value plainly say the same thing (performanceFeeBps 1,000, shown as 10%, is a 10% performance fee; treasury 0x... is the address the contract calls its treasury, not proof that anything is sent there), and cites the contract's finding; a number setting is in the contract's own smallest unit unless a symbol follows it, so it is never matched to an amount the project states; where the owner can change the setting, the reason says so. The source itself verifies nothing: the model marks verified only what the finding's own sentence shows. The check does not read what events say, balances of tokens the finding does not name, anything off chain (what a custodian does with funds), or whether the code is correct or safe. A contract whose source is not published shows only its common getters, so a claim about its rules is "not checked".
• The fee wallet: the check follows this coin's tokens and the Pons fee escrow. It does not follow where the wallet sends the ETH it withdrew.
• A claim to be the first, the only, the biggest or the best compares the project with other projects' public records. It is "not checked", not "not checkable".

"Verified" covers every part of the project's quoted words: who or what does it, and properties such as autonomous, immutable, audited or open source. If any part is not shown, the claim is not verified, and the status comes from that part. "An autonomous agent claims its own creator fees" is not verified by a wallet withdrawing the fees, because who controls the wallet cannot be seen from outside. "Open source" means readable code under an open-source license, so a repository finding states the license GitHub detects, and the claim is verified only when both are shown.

The coin's own contract address, its ticker or a "CA:" line is not a claim: the link-back findings already say whether the project's pages show the address. A claim's restated text says no more than the project's words and keeps their tense: a plan stays a plan.

Rules enforced by code, not by the model:

1. Quote check. Each claim carries the project's exact words. If those words are not found in the stored source, the claim is dropped and never published. A quote from the site is looked for page by page: the claim names the page it was found on, and words that would only be found by running the end of one page into the start of another are dropped.
2. Finding check. "Verified" and "contradicted" must cite a finding that exists. Otherwise the claim becomes "not verified".
3. At most eight claims a coin.
4. The project's text is data. The description, site, README, contract source (its comments included) and X profile are passed to the model as fenced, labelled material. Published source is evidence about what a contract does, never a source of claims. A fence tag written inside that text is broken up first, so the text cannot end its own block and start one that looks like findings. Text in them that addresses the model is treated as something the project said.
5. Words. Reasons describe evidence. They never use scam, fake, rug, fraud or larp. The model is told so, and code checks: a reason that uses one is replaced with a neutral sentence that points at the findings.
6. Strings the project chose. A page title, a listed link, a token symbol and an event name are the project's own text even when a finding quotes them. Each is cut down to one short plain line first, and the host of a link is only named when it is a known block explorer.
7. Plain typography. A long dash in anything a report quotes is shown as a hyphen. Nothing else in a quote is changed.
8. Two-way link. Anyone can list someone else's site. A claim that cites anything found on a site that does not point back at the coin, or in a repository that names neither the coin nor the site, is never marked verified, even if it also cites a chain fact. It becomes "not verified" and the reason says why. The coin's own X account naming the coin does not make a listed site the coin's: the site has to point back itself. What the chain shows about the coin is not affected.
9. No credit for the address. A claim marked verified that cites only the findings about whether the coin's links point back (the site and X account findings, and the list of links) is left off the card. It is the coin's own address said again, not something the project built or does.
10. Full addresses. A finding's sentence shortens addresses for a reader. The model is given every address in full, so a match it makes against an address in the project's text is exact.

The model can only read what it is handed. It cannot browse, post, pay or sign.

Once the claims are marked, the check opens again each of the site's pages that a quote came from and finds the words where a visitor reads them, across bold, links and line breaks, compared the way the quote check compares them. The words are brought into view, the page's scripts run for a moment so a part that fades in is shown, and a close-up is kept with them outlined in red. A copy a visitor cannot see is skipped: one kept invisible, or squeezed to a pixel for screen readers. Only pages of the site that the check read are opened, 45 seconds in all and 30 at most a page. A quote the page no longer shows, or one that only sits in the page's title or description, gets no picture; the claim stands either way.

Fetching other people's pages

The page fetcher refuses anything that is not public http or https on a standard port, refuses private and reserved network addresses at the moment of connecting (and this machine's own addresses, the network around its IPv6 address, and names with no dot, which are looked up on the local network), re-checks every redirect, stops after 1.5 MB or 20 seconds, and identifies itself as CalibrBot.

The browser read uses the Chrome installed on the machine, started fresh for each page, with its sandbox on, and closed after it. Chrome resolves no names itself: every request it makes, from the page or anything the page loads, goes through a proxy in Calibr's own process, which opens only public addresses on ports 80 and 443 and checks each address at the moment of connecting, as the fetcher does. Before each read the browser proves it is using the proxy by asking it for a path only the proxy answers; if it does not, nothing is read. Once the browser is running (starting it may take up to 15 seconds more), a page gets the time given above (30 to 55 seconds), then the read is given up whatever the page is doing, and 30 MB and 500 connections in all, counting what it sends as well as what it receives; requests sent down an open https connection count with it, because the proxy cannot see inside one. Downloads, popups, dialogs and service workers are refused or closed, nothing is clicked or typed, and the browser's name ends in CalibrBot. Only the page's text is read before its pictures; a picture after the first is taken only while the read has time left, so a slow picture never costs the text. The reader's own scripts run in a world of their own on the page, so the page's scripts cannot change what they return, and everything they return is cut to size before it leaves the page. A page that ends on an address the fetcher would not open is not read. Chrome is started without the worker's API keys and tokens in its environment. A picture is published only with the card it belongs to.

A router's own address on the internet side, when this machine sits behind one, cannot be told apart from any other public address, so it is not refused. On a server, the browser runs as a user other than root, which its sandbox needs.

Checks on request

Anyone can ask for a check of a Pons coin that has no card, from the box on the site. The check runs at once, in line with others; the chain record, the site, the code and the pictures show as soon as they are read, and the claims when they are marked. The limits: 100 a day for everyone together, handed out through the day; one a day per visitor; a separate daily budget for the model; past it, the card is made without the claims stage and says so. A coin with a card is not checked again on request. A card made on request is labelled as such and kept out of search results. How it runs is in docs/REQUESTS.md.

Disputes

Anyone can contest a finding or a claim with evidence. Within 48 hours it is marked "under review" on the coin's page and on its card image, and the coin is checked again. When the re-check is approved, the contest is settled and listed on the corrections page with its outcome, changed or not, and the reason. A change to a mark or a flag also goes into the corrections log with what it was and what it is now. What the contest said is kept, but not published.

Changes