Methodology

Calling a bluff means asking for verifiable evidence. It doesn't declare anyone fraudulent. BLUFF checks one specific, falsifiable claim at a time and publishes what it observed, what it couldn't confirm, and where every receipt came from.

Finding labels

Each claim gets exactly one label. Labels are computed by code from the receipts, never written by a model, and BLUFF never averages them into a score for a project or a person.

Supported: Independent receipts corroborate the essential behaviour of the narrow claim. It says nothing beyond that claim.
Partly supported: Some of the claim has independent receipts, but an essential part doesn't. For agent claims this is usually who initiated the action.
Contradicted: A reliable source explicitly shows the opposite. Missing evidence never earns this label. These findings are held for an editor before publication.
Not demonstrated: BLUFF looked where the claim points and found nothing observable that supports it. That is not the same as proving it false.
Inconclusive: A source was unavailable or the data was ambiguous, so the claim couldn't be resolved in this run.

Evidence levels

Every receipt carries a level. A supported finding needs at least one independent level A or B receipt; the evaluator refuses anything less.

Level A, independently observed
Read by BLUFF directly: an RPC answer pinned to a block number and hash, or a properly scoped official API response.
Level B, source-controlled but checkable
Controlled by the claimant but independently viewable, like the name and symbol a token contract reports about itself.
Level C, self-reported
Self-reported: project statements, owner-supplied screenshots or logs. Establishes what was claimed, not whether it's true.
Level D, inference or context
Interpretation or third-party commentary. Never enough on its own for an adverse finding.

What each check reads, and what it can't show

A contract is deployed at this address

“Our agent's contract is live on Robinhood Chain at 0x…”

Bytecode at the address, read from the network at a pinned block
Whether the address has sent transactions

What the contract does or whether it is safe
Who deployed or controls it
Whether its source matches any published repository

The agent acts onchain from this address

“Our AI agent trades autonomously from 0x…”

Whether the address is a contract or a plain account
How many transactions it has sent, at a pinned block

Who or what initiated the transactions. Onchain data shows the sending address, not whether an AI decided to send
That this address belongs to the agent, unless the project says so in a public source
Whether activity is continuous or ongoing

The agent executed this transaction

“Here's the agent's first trade: 0x…”

Whether the transaction exists on the chosen network
Whether it succeeded, which block included it, and who sent it

Who or what decided to send it. A transaction alone does not prove AI initiation
That the sending address belongs to the agent

This token is an official Stock Token

“Trade the official TSLA Stock Token at 0x…”

The official Stock Token list published by Robinhood, matched by contract address and network
The token's own name, symbol and decimals, read from the contract

Anything about price, liquidity, or investment safety
Who is promoting it or why

This website is live

“Our product is live at app.example.com”

Whether the address serves a real page, read with BLUFF's own fetcher (and a sandboxed browser for script-built pages)
Redirects, HTTP status, page title and a hash of the content, with the page's robots.txt respected

That the product behind the page works, or does what the page says
Who runs the site
Anything the page says about onchain activity; check those claims against their addresses

The code is public on GitHub

“We're open source: github.com/…”

The repository through GitHub's official API: visibility, default branch, latest commit, licence and latest release
For a commit link, whether that exact commit exists in the repository

That this code is what's deployed or running
That the project works, or that the code is safe
That stars, a README or recent commits mean the product exists

An official Stock Token match means Robinhood's list includes that exact address on that chain. It isn't a safe investment, and holding a Stock Token isn't the same as owning the underlying share.

When a source can't be read

Limits are shown on the case in plain words. A missing source makes a finding inconclusive; it never becomes evidence against anyone.

Source unavailable: A source didn't answer or answered in an unexpected shape.
X access denied: X didn't allow the post to be read. BLUFF doesn't log in or work around access controls.
Chain data delayed: The RPC endpoint was rate-limiting, slow, or erroring. BLUFF retries with backoff before giving up.
Browser timed out: A page didn't finish loading inside the time budget.
Cannot link wallet to agent: Nothing public ties the wallet to the agent the claim is about.
Recheck pending: A newer check has been requested and hasn't finished.
Explorer unavailable: The block explorer's API refused automated access, so verified-source status is unknown.
Post content unavailable: BLUFF reads X posts only through the official X API, which isn't connected, so the post itself wasn't read.
Site asked not to be read: The site's robots.txt asks automated readers like BLUFF not to fetch this page, so it wasn't read.
Blocked by safety policy: The address pointed somewhere BLUFF never fetches, such as a private network, a non-web port, or an oversized or unsupported file.
Source rate-limited: The source asked BLUFF to slow down. A recheck later may succeed.

Sources

Robinhood Chain JSON-RPC, mainnet (chain 4663) and testnet (chain 46630), at the endpoints listed in Robinhood Chain's documentation. Every endpoint must report the expected chain ID before BLUFF uses it.
Robinhood's official Stock Token list, matched by contract address and chain ID. A matching ticker at a different address is never treated as official.
The mainnet block explorer's API blocks automated access with a challenge page. BLUFF doesn't try to get around it, so verified-source status isn't reported on mainnet yet.

Integrity and corrections

Each receipt stores the SHA-256 of the exact payload a source returned. Receipts, run events and revisions can't be edited or deleted; a correction is a new receipt in a new revision.
A finding that may contradict a claim is held until an editor reviews it. While held, the receipts are public and the label isn't.
BLUFF only reads. It holds no keys and has no code path that signs or sends a transaction.
Rechecks, owner responses and appeals are being built. Until they ship, nothing adverse is published without editor review.