How a finding is reached. And where it stops.

A finding is never a bare sentence. Each one is an evidence record with a stable identifier, the network it belongs to, the source that was asked and the method used, the address or transaction it is about, the slot or block, the time the event happened and the separate time NagBot read it, the window that was examined, an explanation, its limits, and an explorer link.

How a statement is known

Observed

Read from chain data as it is.

Inferred

A documented rule applied to observed facts. It can be wrong.

Provider-reported

A figure a data provider reports. NagBot did not recompute it.

User-supplied

Entered by you on this device. NagBot did not verify it.

How much attention it asks for

Informational

A fact that describes the token or wallet.

Needs attention

A control or pattern worth reading closely. Not a verdict.

Material finding

A finding that changes how the rest of the report should be read.

Unknown

The data needed to say anything was missing.

How complete a section is

Complete for the stated window

Everything inside the stated window was read.

Partial coverage

Part of the window could not be read, and the section says which part.

Limited by the data source

The source itself only offers part of the picture, such as a provider’s figures or the largest accounts.

Unavailable

Nothing could be read. The section shows no result.

Labels use a word and a mark as well as a color, so they read the same without color vision and in both themes. Token amounts are computed in whole base units with integer arithmetic; a share of supply always states the supply it was divided by.

On Solana the mint account is read once, together with its metadata account, at one slot. NagBot reports the mint authority and the freeze authority, the supply and decimals, and each Token-2022 extension it knows how to describe: transfer fees, the permanent delegate, transfer hooks, default account state, non-transferable tokens, pausable configuration, the mint close authority, interest-bearing and scaled-amount configuration, confidential transfers, and the metadata and group pointers. An extension the node reports that NagBot does not interpret is listed by name as not interpreted. It is never silently dropped.

An authority address is tested against the ed25519 curve. An address that is off the curve has no private key, so a program controls it, and the report says so. Text that is not an address at all is an error, never a “program-derived” result.

Names, symbols and metadata links are untrusted labels chosen by whoever controls the metadata. They are shown as plain text with invisible and direction-changing characters removed; the address is the identity. NagBot shows a metadata link and how it is addressed. It does not open it.

A token account is not a holder, and an owner is not a person. Balances are summed per owner address, and each owner is put in a category from what the chain says about the address: a system-owned account at a valid key is a wallet; an account another program owns is program-controlled; an off-curve address is program-derived; an address the market provider lists as a pool is a liquidity venue account.

Two figures are always shown side by side: all owners, and wallet owners only. A pool or a bonding curve holding most of a supply is what a pool is for, so concentration asks for attention on the wallets-only figure. Every share is of total supply as read from the mint in the same request; no balance is removed from the denominator.

Full account census

Every token account of the mint is read and summed. Attempted when the token index reports at most 25,000 holders, or as a bounded stream when there is no count to go by.

Top accounts observed

Only the 20 largest token accounts, where the endpoint serves that method. Labeled as not a census: shares are a lower bound for the largest owners.

Unavailable

Neither reading was possible on this endpoint. No figure is shown and nothing is estimated.

The 50 largest owners are listed and classified. A provider’s own holder count, when one is shown, is labeled provider-reported and is not used in any computed figure.

NagBot does not recognise individual exchange instructions. It reads how every balance changed in a transaction and applies the rules below. An outgoing transfer is not a sale: a movement is called a purchase or a sale only when a program known to exchange assets ran in the same transaction and a quote asset moved the other way for the same signer.

Decoded swap (buy)

The token balance of a signer went up and a quote asset left the same signer, in a transaction that invoked a program known to exchange assets.

Decoded swap delivered to another address

The token balance of this address went up in a transaction that invoked a trading program, while a different signer paid a quote asset.

Decoded swap (sell)

The token balance of a signer went down and a quote asset reached the same signer, in a transaction that invoked a program known to exchange assets.

Venue side of a trade

The balance of a non-signing account moved opposite to a signer in a transaction that invoked a trading program. Treated as the venue’s side of the trade.

Liquidity-like movement

The token and a quote asset moved in the same direction for a signer in a transaction that invoked a trading program. Consistent with adding or removing liquidity; not classified as a trade.

Transfer

The token moved between owners in a transaction that invoked no known trading program.

Mint

A mint instruction for this token credited an account of this owner.

Burn

A burn instruction for this token debited an account of this owner.

Unknown purpose

The balance changed in a way none of the documented rules explains.

Quote assets are SOL, wrapped SOL, USDC and USDT. The list of programs known to exchange assets is a curated registry with a source for every label; a venue that is not in it produces “unknown purpose”, never a guessed trade. “Unknown” is a result, not a failure.

The scan finds a token’s first transactions, decodes a bounded window of them, and lists every wallet with a decoded purchase in the order it first bought. On the key-free endpoint the window is the first 60 successful transactions and history is paged back up to 12,000 signatures; a configured endpoint raises both, and the status page shows this deployment’s numbers.

If the first transaction is not reached within the budget, the scan reports “earliest history not reached” and lists no early buyers at all. Buyers from a window that does not start at the beginning would be the earliest observed, not the first, and are labeled that way when the creation is missing.

Patterns are listed with the caveat that belongs to each:

Same-slot purchases

Three or more wallets whose first purchase shares one slot. Same-slot activity alone does not establish a bundle or a common owner.

Identical amounts

Three or more first purchases for exactly the same number of base units. A shared bot preset or a platform’s fixed options produce this too.

Signed together

Two early buyers that signed one transaction. The keys cooperated in that transaction; that does not say who holds them.

Jito tip paid

The transaction pays one of the published Jito tip accounts. It does not show which other transactions, if any, shared a bundle.

Only transactions that reference the mint address are found, so a transfer made with the older instruction that does not name the mint is outside the window.

Two kinds of statement are kept apart all the way to the screen. An observed link is something one transaction shows as it is: a SOL transfer, a token transfer, two signatures on one transaction. An inferred link is a documented rule applied to observed facts, drawn differently and labeled “Inferred”.

co-signed

Two early buyers signed the same transaction. Confidence: high.

direct-funding

One early buyer sent SOL directly to another before its first purchase. Confidence: moderate; high when their first purchases are also within two slots of each other.

direct-token-transfer

One early buyer transferred the token directly to another inside the examined window. Confidence: moderate.

shared-funder

Two or more early buyers received SOL from the same address before their first purchase. Low when the source is a high-activity address or the funding is more than seven days older than the purchase; moderate when the transfers fall within one hour of each other; high when, in addition, the source is the first funder of every wallet or their first purchases are within two slots.

The thresholds are fixed: funding transfers count as close in time within one hour; funding older than 7 days before the purchase is old history; purchases within 2 slots are adjacent. A funding source is called high-activity when a full page of 1,000 of its signatures spans 3 days or less.

Funding is read for a stated number of buyers. For the others no link is drawn because none was looked for, and the map says how many were examined. The layout is deterministic: the same data always draws the same map.

For a group of wallets you choose, NagBot reads the history of each wallet’s token accounts for the mint and accounts for the group’s net change transaction by transaction. A transfer from one tracked wallet to another is counted once, as movement within the group, and never as an exit.

Still held

Balances read from the chain now. Unknown when any balance could not be read.

Moved within the group

Tokens that changed hands between tracked wallets.

Decoded swaps

Outflows the swap rule recognises as sales.

Transferred outside

Plain transfers to owners that are not in the group. Not followed further.

Burned

Outflows through a burn instruction.

Unknown purpose

Every other outflow.

With complete history the categories are reconciled against the balances and any remainder is reported as not explained. With partial history they are lower bounds and are not reconciled. No profit or loss is computed: that needs a cost basis and complete trade coverage, which this does not claim.

A creation transaction can involve four different parties: the fee payer, the address given mint authority, the launch program that ran, and the wallet the creation can be attributed to. They are listed one by one. A launch program is shared by everyone who uses it and is never named as a token’s creator.

A creator is attributed only when exactly one wallet signed the creation apart from the mint’s own key, and the basis is stated with the caveat that a signer can be a relayer or a launch service. In every other case the page reads “Creator attribution unavailable.” and stops there.

For an attributed creator, NagBot lists other mints initialized in transactions that wallet signed, with what the chain says about each now, and the first SOL transfer into the wallet when its history start was reached. A past token is never judged by its price or by inactivity.

Pools and their figures come from the market data provider and are labeled provider-reported. NagBot does not read pool accounts itself, does not estimate slippage, and says nothing about whether liquidity is locked.

Liquidity is defined as the pair of pooled reserves, not the dollar figure, because a dollar figure moves with price. Reserves that both fall are consistent with liquidity being withdrawn; reserves that move in opposite directions are what trading against the pool does. A pool the provider stops listing is “unknown”, not “removed”.

The LARP Check sets a project’s public statements beside the evidence for them. It asks one question of each claim: what can actually be shown? There is no score. Each claim has one of five statuses and a reviewer, and the reviewer is always named: you, or an automated rule. No analyst review is provided.

Supported by reviewed evidence

Someone reviewed evidence that backs the claim and recorded why.

Partially supported

Part of the claim checks out. The rest was not shown.

Unverified

No evidence was found or offered. That does not make the claim false.

Conflicting evidence

Evidence was found that disagrees with the claim.

Not assessed

Nobody has reviewed this claim yet.

What does and does not count, by category

Published product

A functioning website alone does not verify a product. Look for: A feature you can use end to end, on-chain activity from the product’s own program, or a public release with a history.

Published source repository

A repository alone does not establish deployed functionality. Look for: Commits over time by identifiable maintainers, a build that matches what is deployed, a verified program build.An automated rule exists for this category. It states exactly what it checked and what it did not.

Published contract address

Anyone can copy a name and symbol. Only the address published by the project identifies its token. Look for: The same address on a channel the project controls.An automated rule exists for this category. It states exactly what it checked and what it did not.

Claimed audit

An audit badge alone does not verify an audit. Look for: The report on the auditor’s own site, naming the program address or commit that was reviewed.

Claimed partnership

Partnership claims need evidence from the relevant parties. Look for: An announcement from the named partner’s own channel, not only from the project.

The contract-address rule compares the address you entered with the token the report examines; a match is “partially supported” until you have seen that address on a channel the project controls. The repository rule reads public facts about a GitHub repository; a repository alone does not establish deployed functionality.

NagBot ships no database of influencer wallets and infers none. Every entry is typed in by the person using the app and stays on their device. The label on an entry is computed from what was entered:

Verified public disclosure

You confirmed that the linked source, published by the named account, shows this wallet address.

Source linked, not reviewed

A source by the named account is linked, but you have not confirmed that it shows this address.

Third-party attribution

Someone other than the named account says this wallet belongs to them. That can be wrong.

User label

A label you chose, with no public source behind it.

Posts in a call timeline are added by hand and labeled “manually supplied”: no social network is read. Holdings come from two readings of the wallet; a token missing from a partial reading is “not comparable”, not “gone”. Posting about a token and holding it are two public facts that show timing, not intent.

A snapshot records what one scan read, when, at which slot or block, and with which coverage. Up to 20 are kept per token, on your device. Two snapshots of a token are compared under three rules:

Missing is unknown

A value absent from one side is “unknown”, never zero. An owner that left the recorded list is not assumed to hold nothing.

Unlike is not compared

A full census is not compared with a top-accounts list, and figures made under different methodology versions are not compared at all. The comparison says why.

Both times are shown

A difference between two readings says something changed in between. It does not say when.

Checks run while this app is open. There is no server-side scheduler and no delivery outside the app. Each rule keeps its own memory (where it last looked, or the level it last recorded), and a check that cannot read its data ends as “insufficient data” and leaves that memory untouched.

Selected wallet has a decoded sell

Checks the wallet’s new transactions and fires when one is decoded as a swap that sold a token. Plain transfers do not fire it.

Observed group holdings fall below a threshold

Sums the token balances of the wallets you list and fires when the sum drops below your threshold. If a balance cannot be read the check reports insufficient data instead of assuming zero.

Pooled reserves change by a threshold

Compares the pooled reserves DexScreener reports for one pool with the last recorded level and fires when either reserve moves by your threshold. The event says whether both reserves fell together.

Token authority changes

Compares the mint’s authorities and Token-2022 controls with the last recorded reading.

New direct funding connection appears

Fires when the wallet sends SOL to, or receives SOL from, an address it has not exchanged SOL with since the rule was created.

Besides Solana, NagBot reads Ethereum, BNB Smart Chain, Robinhood Chain, Elysium. These networks get the core checks; early buyers, the wallet map, supply exits and decoded activity are built for Solana only so far, and a report on an EVM network says “not available on this network” for them instead of showing a partial result.

One block

Every read of one token is pinned to a single block a little below the tip, so the values describe one state. A node that does not have the block is a failed read, never an answer.

Owner and pause

What the contract answers to owner() or getOwner() and to paused(). Whether the owner is itself a contract is read from its code.

Proxy

The EIP-1967 implementation, admin and beacon slots, the older OpenZeppelin slots and the EIP-1167 minimal proxy pattern are read from storage and bytecode. An upgradeable token can change its logic; the report names the address that can.

Functions present

Selectors for minting, pausing, blocking an address, changing fees or transfer limits, transferring ownership and granting roles, found in the bytecode. This is inferred and labeled so: a selector in bytecode shows a function may exist, not who can call it.

Source verification

Whether Sourcify or the network’s Blockscout instance holds verified source. Provider-reported.

Holders and creation

The largest holders and the creation record come from a Blockscout indexer where a key-free one exists. Where none does, both report “unavailable”.

The exact depth per section and network is in the capability matrix.

• That a token is safe, or that it is a scam. A report lists what was read and what was not; the judgment is yours.
• Complete visibility into bundles. No bundle provider is queried, so NagBot reports a visible Jito tip and never states that transactions shared a bundle.
• Who owns a wallet. Transaction patterns show transfers between addresses, not the people behind them.
• That it identified insider trading. An inferred group is a pattern in public transfers with a confidence label.
• A partnership, an audit or a product on a project’s behalf. Claims are recorded with the evidence that was shown, and “unverified” is not “false”.
• Complete history where the data was not read. A partial window is labeled partial, and a section that could not be read contributes no finding in either direction.
• Zero risk, a price target or a return.

NagBot is read-only. It never asks for a wallet connection, a signature, a seed phrase or a token approval, and it is not financial advice.