THE METHODOLOGY

This document explains the findings, evidence coverage and receipt history shown by the scanner. It also describes the R2 categorical policy implemented behind a separate receipt-writing switch.

That switch is off by default. The default writer still uses the earlier methodology. Its categorical tier is preserved, not recalculated under R2. Read the methodology version on each receipt before comparing conclusions across versions.

A verdict reports what the available evidence says about a token at the time of the scan. Findings name their subjects and retain their measurements. The tier is a summary, not a substitute for reading them.

For R2 receipts, findings have explicit effects and coverage. Earlier receipts retain their original conclusions and internal verification payloads. The product presentation omits numerical ratings for both versions.

A verdict is not a prediction or financial advice. CLEAR means the scoped checks completed without an adverse conclusion under the recorded methodology. It never guarantees safety, future sellability, project quality or a return.

The checks address mechanical risks such as privileged contract powers, liquidity control, concentration and market activity. They cannot establish the intentions of the people behind a token.

Evidence comes from contract reads, transaction and event history, explorer data, market providers and the saved record. Each finding identifies its evidence. Sources may disagree or be unavailable.

A failed read is a limitation of this scan. It is not evidence that the token passed or failed the check.

In the prepared R2 policy, an ordinary finding carries one of three effects: danger, caution or none. A proved critical rule can require CRITICAL. The effect records the finding's consequence; coverage records whether its subject was adequately read.

The candidate tier follows the worst effect and any named rule that applies. Warnings do not pile up. Several disclosure-only warnings still have no adverse effect. An unavailable check never becomes evidence of safety because its effect is none.

Coverage and publication checks can prevent a candidate tier from being issued as a current receipt. When an R2 decision cannot be resolved, the product says UNRESOLVED.

R2 distinguishes control risks from context. Material liquidity-control failures, reachable privileged powers, upgrade control and fee manipulation can carry danger. Their applicable warnings can carry caution. A low-impact liquidity-custody warning is disclosure-only unless an independent material finding applies.

Holder concentration, shallow liquidity, unverified source, valuation relative to liquidity, turnover and paid promotion are contextual findings. Their adverse outcomes can carry caution. Ordinary warnings about age or market context do not accumulate.

Deployer history and funding connections remain visible disclosures. A separately proved critical funding-history rule is considered on its own evidence. Every check and exception must have a named effect rule; an unmapped finding cannot silently become none.

Consider an R2 receipt with a fully read shallow-liquidity finding carrying caution. Several age and market disclosures carry none. The candidate tier stays CAUTION. Adding more disclosure-only warnings does not turn it into DANGER.

If a material contract-control finding carries danger, the candidate becomes DANGER. If a named critical rule is proved, it becomes CRITICAL. Missing custody evidence remains a separate coverage limitation in every case.

Named critical rules address findings that cannot be offset by unrelated passing checks. These include a proved token-wide exit trap, attributed liquidity removal, a confirmed rug record, explorer scam evidence and a proved direct funding link to recorded rugs.

Each rule retains its own scope and proof requirements. A failed simulation on one route is not automatically a conclusion about every route. A precautionary critical finding is distinguished from a proved one.

R2 coverage rules consider unread subjects, material pool history and whether an exit was proved. They can require caution or withhold a receipt. These limits do not change an observed finding into a different fact.

A proved critical finding can bypass specified unrelated history, read-coverage or exit gaps. It does not bypass market or explorer infrastructure failures. A precautionary critical finding follows the ordinary publication gates.

1. 1

   RESOLVE FINDINGS

   Complete status, subject and applicability reconciliation before assigning each finding its effect.

2. 2

   DERIVE THE CANDIDATE

   Take the worst effect and apply the named critical rules. Disclosure-only warnings do not accumulate.

3. 3

   CHECK COVERAGE AND PUBLICATION

   Report missing evidence separately. Decide whether to append a receipt, reuse one or withhold publication.

A recorded honeypot mark remains part of the token's history when its current behavior changes. Under R2, an active prior-honeypot finding carries danger. A prior market-collapse mark is disclosure-only.

An admin can lift a verified false-positive mark. The lifted record retains its reason and date. A later confirmed trap can reactivate it.

Funding history follows recorded transfers and known deployer records. A direct link to a confirmed rug can meet a named critical rule. A longer connection is disclosed with its path and scope.

A connection does not establish who owns a wallet. Missing funding history is not a clean record.

Saved liquidity observations can flag a decline from a trailing peak for further review. A watch mark is not an indictment. A rug claim needs separately attributed liquidity-removal evidence under the recorded rug criteria.

A change in market value alone does not prove that an insider withdrew liquidity.

We analyse the contract's verified source when the deployer has published it, and its on-chain bytecode when they have not. If the token is a proxy: a shell that forwards to an upgradeable implementation: we follow it to the real code first, so an upgradeable token is judged on what it actually runs rather than on the empty husk in front of it.

Not function names: effects. We catalogue the capabilities that let an insider reach into a live market: minting or rebasing supply, pausing trading, blacklisting holders, changing fees or wallet and transaction limits, granting exemptions, rerouting the AMM, withdrawing liquidity, rescuing assets, redeeming custody, upgrading the code, or executing arbitrary calls.

Each is listed with the exact functions that carry it, so anyone can check the finding against the public contract.

A power that exists is not the same as a power that is loaded. For each capability we resolve the authority that gates it and ask whether that authority is live or neutralised.

A renounced owner does not mean safe. Renouncing closes only the doors that owner held. If the same power is gated by a different role, a dev wallet, a proxy admin or a multisig, it stays live: and we say so.

If the source is not verified, or a node times out mid-read, the audit can only go so far: and it reports exactly how far. An analysis that could not finish is never dressed up as a clean bill: the absence of a finding we could not look for is not evidence of safety.

Every capability also carries how firmly it is known: traced in source, likely through indirection, or a bytecode-only match.

The audit informs findings about reachable contract powers. Source analysis, authority reads and bytecode inspection have different limits. The finding must say which was available.

Under R2, a material reachable privileged power can carry danger. A warning can carry caution. The capability map and controlling addresses remain available alongside that summary. Unresolved authority or incomplete analysis stays visible as a limitation.

A failed probe is not a negative result. A timeout tells us nothing about the token. A contract revert can be an execution result, but it must be distinguished from a transport failure and interpreted within the tested route and conditions.

An empty pool list, missing template or absent funding record can support a negative conclusion only when the relevant search completed. Otherwise the answer is unknown.

Receipt publication checks whether the required evidence was available. A provider failure can prevent publication and leave the previous receipt as the last recorded conclusion. That earlier receipt is not a fresh answer.

A token that has never traded can make market checks inapplicable when discovery establishes that fact. An unavailable market read is different. Inapplicable means there is no subject for that check; unavailable means it could not be answered.

Coverage is assessed before a conclusion. Reading a fraction of a pool's holders cannot establish who controls the rest. A narrow passing check cannot erase an unread sibling subject.

R2 keeps finding effects, evidence coverage and publication eligibility separate. An adverse fact can remain valid while other evidence is missing. CLEAR requires the relevant scoped checks to be complete and never guarantees safety.

Each receipt has a versioned canonical payload with a fixed field order. Its hash binds the recorded conclusion to that payload. Earlier and R2 receipt formats use their own verification rules.

Internal legacy verification retains the original payload. Product display changes do not rewrite it. R2 payloads bind findings, effects, coverage, named rules and the effective policy version.

Each entry links its canonical payload to the previous entry's hash. Editing a historical payload changes its hash and the links that follow it. A reader who kept earlier hashes can compare them with the published record.

On-chain anchoring is planned and is not an available independent verification step today.

A result fingerprint identifies the decision under its recorded methodology. The receipt policy can reuse an existing receipt when the new decision has the same identity. That keeps repeated scans from creating duplicate records.

Receipt identity is separate from the latest scan attempt. Read the receipt timestamp and the scan's coverage before treating an older receipt as current evidence.

The Ledger exposes receipt identities and hash links. R2 verification uses its canonical categorical payload. Earlier receipts retain internal verification data that the product does not publish in full.

Do not reconstruct an earlier canonical payload from the reduced product response. The original integrity fields remain unchanged internally.

The swap trades through the same Uniswap pools and router as everyone else. What it adds is a set of checks around the trade, so you see what you are buying and why a trade can or cannot happen.

The token's security sits inside the swap. A quick check reads the contract's owner, pause and proxy settings when you review a buy. If the token has been scanned, its full verdict and findings are shown beside it, with the checks that failed. Neither check says a token is safe.

Every trade is tested on chain from your own wallet before the swap can be signed, as described below. A pool with a custom Uniswap V4 hook is used only after a buy and then a sell through it both pass that test, and the swap says what the hook can do.

When no route exists, we say why. Listed liquidity can lag the chain by minutes, so we read the token's main pools directly. If the main pool is empty, you are told that, how much liquidity is still listed for it elsewhere, and, when we saw it happen, the time it was removed.

Some pools charge a fee far above the usual 1%. The swap counts that fee as price impact, so a trade that would lose 15% or more to it asks you to confirm first.

V1 routes through Uniswap V2, V3 and V4 pools on Robinhood Chain, using the Uniswap Universal Router. It prices the pools it finds for the pair directly, and two-hop routes through a bridge asset (ETH, USDG, or a verified stock token).

When a token has many pools, the deepest ones are priced first, up to 12 per request. Pools skipped for this reason are listed in the trade details, never dropped silently. Pools with under $100 of known liquidity are skipped and listed as skipped.

Other venues (for example Sushi or PancakeSwap) can be switched on or off by the operator. A venue that was not searched is named as not searched.

Every trade is run on chain as a simulation from your own wallet, at the real gas price, before the swap can be signed. A quote that still waits on a token approval shows its price first and is tested once the approval is in place. The test run measures what you would actually receive and checks that the router kept nothing.

If the test run fails or cannot be completed, no trade is offered. A network problem on our side is reported as a network problem, never as a problem with the token. If your wallet does not hold enough of the token you are spending, you still see the price, but nothing is simulated and the trade cannot be sent. The same holds before a wallet is connected.

Pools with a Uniswap V4 hook are only used if a buy followed by a sell through the hook passes the test run. The swap lists what the hook is able to do before you confirm. Canonical stock tokens are checked on chain for an issuer pause before quoting. Tokens still on a launchpad bonding curve are not routed until they graduate to a DEX pool.

Swaps are non-custodial. The trade is sent from your own wallet. Token approvals go through Permit2. A wallet that supports batched calls can approve and swap in one confirmation.

Minimum received: in Auto mode it is set below the output measured in the test run by 0.5% plus half of how far the token's price typically moves in five minutes, judged from its last five minutes and its last hour, up to 5%. You can set your own slippage instead. A quote is valid for 45 seconds. After that it must be refreshed.

A route being offered is not a safety verdict on the token. The scanner verdict is shown separately. A successful buy test does not guarantee you can sell later.

The best route found is the best among the pools searched, not every pool that exists. If a trade would lose 15% or more to price impact, you have to confirm it before you can continue.

Methodology versions belong to receipts. An older conclusion is not silently reinterpreted under a later policy. Compare finding changes, coverage changes and methodology changes separately.

The R2 categorical receipt writer is implemented but off by default. The earlier writer remains the default until an explicit operator cutover. This page does not activate it.