DON'T TRUST THE BAG.
CHECK THE RECEIPTS.

Exact numbers, not rounded for a headline. Every rule in force, every data source, every security claim below links to where you can check it yourself.

Product receipts

Rules in force

v0.6.0

Archetypes, badges, verdicts, and how confident a reading is allowed to look. See the methodology.

Aura

v0.3

The Bag Aura score itself. Rules v0.6.0 changed how Aura is computed for the first time: up to 1,000 of the 10,000 points now come from how much $BAGGY a wallet holds, so Aura moves to v0.3. The bonus is added after the behavioural score is normalised, so a wallet holding none scores exactly what it scored before, and every result carries the holdings points as their own line — subtract them and you have the behavioural score. It counts tokens held, never their dollar value. Archetypes, badges and verdicts are decided on behaviour alone and are not affected.

Data sources

Blockscout · Alchemy fallback

Observed 2026-09-03. Blockscout is the primary source — holdings, prices, 24h volume and reputation in one call, reached with a browser User-Agent (a default agent gets a Cloudflare interstitial). Robinhood Chain's public RPC answers instantly over curl and is unreachable from Cloudflare's edge, so it is the fallback rather than the first call. Alchemy is the fallback for holdings when the explorer stalls — it carries balances but no prices, no 24h volume and no reputation, and its per-contract metadata is budgeted, so a fallback read is a sample and is scored as one.

Stored results

Stamped v20

A completed check is stored permanently, so the block tag on a first check stays put and the card a friend opens is the card that was shared. It is not frozen: every stored result carries the methodology stamp it was scored under (currently v20) and the rules version (currently 0.6.0), and a result stamped with anything else is re-scored rather than re-served. A result read from the fallback provider is never re-served at all — it records a provider outage, not a wallet, and the explorer recovering is the normal case. Re-scoring keeps the original block tag and does not count the address twice.

Security

Read the architecture

Full write-up of what this app can and cannot touch.

read /security

Read-only guarantee

No signing, ever

Read-only. BAG CHECK never asks for your seed phrase, private keys, token approvals, or transaction signatures.

Report method

Large-holder sample

Sampled top holders per community, published with the method and the raw counts.

see /communities

EXACT COUNTS SINCE THE LEDGER STARTED

This page prints the exact count, however small — that is what it is for. The homepage shows the ruleset instead until a count would mean something. Same ledger, two jobs.

Addresses checked

49

Checks

110

Checks today

0

Community reports

4

Token receipts

Every $BAGGY fact below is labeled by how sure we are of it. PLANNED is a stated intention, not a fact. CONFIGURED means an operator set it, unverified. VERIFIED ONCHAIN means a trusted explorer or launchpad confirms it. A row with no source is not verified, no matter how confident it sounds.

Launchpad

Pons V2CONFIGURED

Paired with

ETHCONFIGURED

Supply

1,000,000,000VERIFIED ONCHAIN

verify source

Liquidity

permanently locked Uniswap v4 poolPLANNED

Contract

0x9f450FEA96aB124a735733C36237c8D7E04f409fVERIFIED ONCHAIN

verify source

Pool

0x96ee1fd211044ebf7ddd824cdb08458e834d5392CONFIGURED

Launch tx

not decidedPLANNED

Launch time

not decidedPLANNED

Graduation time

not decidedPLANNED

Creator fee

None — traders pay the 1.00% platform fee only, with no founder surcharge on topVERIFIED ONCHAIN

verify source

Fee recipient

0xBccA…fE6E — the deploying wallet, which also made the launch buyCONFIGURED

Buyback

not decidedPLANNED

Full plan and $BAGGY’s own page: /baggy.

Changelog

Every policy call, methodology change and correction, newest first. Entries are never deleted — a wrong entry gets a correction under it.

1. 2026-09-04methodology

   Pricing: a second source for the coin's own rate, and the batch budget bounds only the batch

   Two limits met the same wallets. The coin's own dollar rate came from the explorer alone, and under load the explorer answers a challenge page instead; with no rate the native balance was a hole and the on-chain curve pricing skipped the bag entirely. A second source now supplies the rate when the explorer does not. And the batch budget for the first price source was cutting the list every later source was allowed to see, so a two-hundred-token wallet reported fifty tokens beyond coverage that the chain list and the curve could have priced for free. The budget now bounds that one source; the rest see the whole bag. A token no source can reach is still reported as unreached. Every stored read that carried either gap is re-derived on its next visit.

2. 2026-09-04methodology

   Reading: a bag can be 400 tokens deep

   Two hundred and fifty was not enough either. The most active wallets on the chain came back with two hundred and fifty tokens seen and the read still capped. The read now goes eight pages deep, four hundred tokens, and a wallet past that is still reported as partly unseen rather than scored as if it were whole. Every stored read that carried the earlier cap is re-derived on its next visit.

3. 2026-09-04methodology

   Reading: a dropped page is retried once, and a bag can be 250 tokens deep

   The explorer serves fifty tokens a page. The read stopped at three pages, so any wallet past a hundred and fifty tokens was flagged truncated and scored MYSTERY BAG, and a single dropped page on a heavy wallet did the same at fifty. The read now goes five pages deep and retries a dropped later page once after a short pause before it reports the bag as partly unseen. A page that fails twice is still reported honestly. Every stored read that carried either flag is re-derived on its next visit.

4. 2026-09-04methodology

   Pricing: a fresh Pons launch is priced from its own curve, on chain

   The most active wallets on the chain hold fifty to a hundred and fifty freshly launched tokens. No price service lists a token that launched this morning, so those bags scored MYSTERY BAG with a receipt reading that dozens of tokens could not be priced. A token still on its Pons bonding curve has a price that lives on the chain itself: the curve's reserves. The check now asks the Pons factory which curve a token belongs to and reads that curve's reserves, two batched calls for the whole bag, and prices it from the same numbers the curve uses to trade. Only tokens still on their curve are priced this way; a graduated token trades on the open market and is priced by the market. A token the factory has never heard of stays unpriced rather than guessed. Every stored read that carried that gap is re-derived on its next visit.

5. 2026-09-04methodology

   Pricing: the whole chain's list in one call, for bags of fifty fresh launches

   The most active wallets on the chain hold fifty to ninety freshly launched tokens each. The first price source lists almost none of them, the second rate-limits the server this site runs on, and three single-token calls to the third cannot read a bag like that, so those wallets scored MYSTERY BAG with a receipt reading that dozens of tokens could not be priced. The third source also publishes the chain's whole token list with prices, in one call. That list now runs before the one-at-a-time step, which is left for what the list lacks. Absence from the list is still not an answer. Every stored read that carried that gap is re-derived on its next visit. No rule, archetype, verdict or badge changed; only what can be seen did.

6. 2026-09-04methodology

   Pricing: a third source, because the site could not read its own token

   A wallet holding $BAGGY came back MYSTERY BAG with the reason printed on the receipt: one token could not be priced. The token was $BAGGY. The first price source has no listing for it yet, and the second answers a laptop but rate-limits the server this site runs on. So a wallet's largest position could be the one thing the read could not see. A third source now answers last, one address at a time and capped, for what the first two did not. It supplies a price and nothing else: depth and volume stay unknown rather than zero. Every stored read that carried this gap is re-derived on its next visit. No rule, archetype, verdict or badge changed; only what can be seen did.

7. 2026-09-04methodology

   Rules v0.6.0 — holding $BAGGY now raises Bag Aura

   This reverses the rule BAG CHECK was built around, and it is being written down in full rather than shipped quietly. Until today, token ownership could not affect a score at all: the scoring modules were forbidden from importing the token config and a build-failing test enforced it. From v0.6.0, holding $BAGGY adds points to Bag Aura — 250 above a 100,000 token floor, 600 above 25,000,000, and 1,000 for the single largest holder among checked wallets. The maximum is 1,000 of the 10,000 point scale, so up to a tenth of any score can now be obtained by buying the token. Four things were kept, because without them the change would be dishonest rather than merely commercial. First, the bonus is ADDITIVE and applied after the behavioural score is normalised — it never enters the denominator — so a wallet holding no $BAGGY scores exactly what it scored under v0.4.1 and nobody was re-scored downward to make room. Second, it counts TOKENS HELD and never their dollar value, so Aura does not rise and fall with the market and does not become a measure of wealth. Third, it reaches Aura only: the archetype, the badges, the roast and the receipts are still decided on wallet behaviour alone, so what a card SAYS about a wallet cannot be purchased — the largest $BAGGY holder on the chain is still told its bag could not be read, because it could not be read. Fourth, every result carries the holdings points as their own named line and as a separate field, so subtracting them recovers the behavioural score exactly. What this costs, stated plainly: the bonus is gameable. The holder floor was worth about $0.93 the day this shipped, so anyone can buy in, check, screenshot and sell. Community reports computed under v0.6.0 therefore measure a mix of behaviour and purchase, and reports carry the rules version they were computed under so earlier ones remain readable as what they were. Every surface that previously promised holdings could not move the score was corrected in the same change — the /about FAQ, the /methodology page and the site-wide Aura disclaimer now state the size of the effect and the cap. A test fails the build if any of them reverts. AURA_VERSION moves to 0.3, the first time the Aura arithmetic itself has changed; CACHE_VERSION moves to v14, so every score computed under the old formula is re-derived rather than served.

8. 2026-09-04methodology

   Rules v0.4.1 — a bag we could not read is no longer called average

   THE MID-CURVE says "perfectly average", and that is a claim. It may only be made about a bag whose composition was actually scored. Until today it could also be made about a bag that was never scored at all. assignArchetype ends in a catch-all for "no distinctive rule matched", and every rule above that catch-all reads the largest allocation or the category shares — both of which are deliberately nulled when composition could not be scored. So a wallet the engine could NOT read failed every rule for lack of data and fell through to the one archetype that asserts it is unremarkable. It was caught on a real card: one position, that position unpriceable, the card printing "1 token could not be priced (provider), not zero - concentration not scored" and a verdict reading "no verdict on the mix" - directly beside the headline THE MID-CURVE / "perfectly average. somehow." The card contradicted itself, and the half that was wrong was the loud half. Unscored bags now return THE MYSTERY BAG ("the receipts are smudged"), which already existed for exactly this state and was previously reachable only when pricing failed completely. Aura numerics are untouched and MID-CURVE still works for bags that really were scored and really are unremarkable. This has a consequence for the published community reports, and it is not a small one: PONS and Tendies were previously measured at 27 of 28 and 30 of 32 Mid-Curves that were in fact unscored. Reports re-run under v0.4.1 should show Mid-Curve share fall and Mystery Bag rise. The earlier reports were not wrong about the wallets they could read; they were over-confident about the ones they could not, and they carry the rules version they were computed under.

9. 2026-09-03policy

   $BAGGY is live, and the creator economics are now decided: no founder surcharge

   $BAGGY launched on Pons V2 on Robinhood Chain, paired with ETH, contract 0x9f450FEA96aB124a735733C36237c8D7E04f409f. This page previously said creator economics were not decided. They are now, and the decision is zero founder surcharge: traders pay the Pons platform baseline of 1.00% and nothing on top of it. The launchpad offers the creator up to a further 10%, and its own help text reads "Traders pay 1.00% in total, up to 10% of it yours" — which reads as a share of that 1% and is not. Entering 10 changes the label to "Traders pay 11.00% in total": it is additive, not a split. A token whose entire claim is that it never touches your wallet has no business carrying the highest trading cost on the chain, so the field is zero. To be precise rather than flattering: this is not "the founder takes nothing". The deploying wallet still receives the launchpad's baseline creator fees, which are a separate stream from the optional surcharge, and that wallet is 0xBccA...fE6E. Holder fee sharing was left off; routing those fees to holders is permanent once done and was not a decision to make in the same minute as the launch. The founder buy was 0.0993 ETH (about $250) executed inside the launch transaction from that same wallet — one disclosed wallet, no second address, and no snipe-tax exemptions were declared. These economics still cannot be changed with a deploy-time flag; altering them requires a code change and another entry here.

10. 2026-09-03correction

    The published check counts included preview traffic; they have been reset to production-only

    Preview and production share one database, and preview runs with fixtures on, so preview checks had been writing snapshot rows and bumping the counters this page publishes. The counts shown here were therefore not a count of real checks: of the 26 stored snapshots, one was a fixture and eight predated the guard that refuses to score anything that is not a wallet — two of those eight were the zero address and a token contract, i.e. verdicts on things that cannot hold a bag. Fix: the snapshot rows and the v1 counter rows were deleted (2026-09-03, a full export and a restore point taken first), so "addresses checked" and "checks" now count production usage only and start from a real zero. Share links were deliberately left untouched — every /b/ link already posted still resolves, and the result behind it is re-derived from chain data on the next visit. Nothing about the methodology changed; the numbers are smaller because they are now true. Preview will keep contaminating them until it gets its own database, and this reset has to be repeated after any cutover that follows more preview traffic.

11. 2026-09-03methodology

    Rules v0.4.0 — which provider answered is now part of the score

    The same wallet derived 151 positions on one run and 17 on another, and its Bag Aura moved 6,706 to 8,987. Both runs printed MODERATE confidence. The cause: when the explorer stalls, a fallback provider carries the balances behind it under a 16-token metadata budget, and that provider's balance call carries no prices, no 24h volume and no reputation. So the fallback read is smaller AND blinder — and it scored HIGHER, because a sample taken from the head of a token list is disproportionately the real positions: no dust tail to penalise, no illiquid tail to discount, fewer positions to spread concentration across. That bias does not average out; it is upward by construction, every time. Fix: every result now records which provider supplied the holdings, how many tokens were observed against how many the provider said the wallet holds, which limit stopped the read, and what share of positions got a price answer. Depth of read is its own confidence dimension: an explorer read is unaffected, a fallback read of a whole wallet can never be HIGH, and a fallback read cut short by the budget is LIMITED — it withholds rare badges, mints no block tag, does not publish an archetype card, and its composition breakdown is withheld rather than reported as "16 of 16 priced, coverage 100%", which is a true statement about the sample and a false one about the bag. The depth is folded into the proof hash, so a sample can no longer inherit a full read's identity, and a stored result taken from the fallback provider is re-scored rather than re-served, because the explorer recovering is the normal case. AURA_VERSION stays 0.2 — the Aura numerics are untouched. RULES_VERSION moves to 0.4.0; CACHE_VERSION moves to v9, so every result scored under the old rule is re-derived.

12. 2026-09-02correction

    Rules v0.3.1 — a truncated bag was told the wrong reason, naming a budget that was never reached

    A wallet holding more tokens than the explorer will paginate (50 per page, 3 pages, so 150+) came back capped. That set a truncation flag which was folded into pricing quality and reported through a placeholder count, so the wallet was told "1 token beyond pricing coverage (budget 168 per check)" and given the coverage-limited verdict. Both halves were false: the 168-token PRICE budget was never reached — the 150-token page cap was — and "1 token" was a placeholder meaning "at least one more exists", not a count. Meanwhile the composition panel beside it read "coverage 100%, 151 of 151 priced, scored", because everything visible had priced fine. Two surfaces on one screen contradicting each other, and the one that named a cause named the wrong one. Observed live on 2 of 5 real wallets, both at exactly 151 positions. Fix: explorer truncation now sets a balances gap rather than a pricing one, says "token list truncated at the explorer page limit", and gets its own verdict. Concentration is still withheld in both cases — only the stated reason changed. Aura numerics untouched. This entry is written after the fact: 0.3.1 shipped on 2026-09-02 and was not recorded here at the time, which is itself the kind of gap this log exists to close.

13. 2026-09-02methodology

    Composition is scored on what could be read, not on what carried a price

    "WHAT'S ACTUALLY IN THE BAG?" gated itself on priced positions ÷ all positions and refused to score below 80%. On Robinhood Chain that measured the wrong thing: most of what a real wallet holds is airdropped launchpad tokens that DEX Screener and GeckoTerminal were both asked about and both answered "no market" for. A token with no market anywhere is worth about nothing, which is an answer — not an unknown — but it dragged coverage to 6% or 65% on ordinary wallets and printed "composition not scored" on the module the product leads with. Fix: composition is scored unless the price providers failed to ANSWER (timeout, poisoned batch, exhausted budget) for more than 20% of positions, or pricing is unavailable outright; the unscored reason now names the count ("providers did not answer for N of M positions"). Marketless tokens are excluded from the value basis, counted, and printed under the breakdown as "N tokens with no market — excluded". Coverage is unchanged and still published as priced ÷ all positions — it is a transparency number now, not a gate. Community reports inherit this: more sampled wallets now have a scored composition and a scored concentration, and every report publishes the basis (compositionSampled) next to the medians it produced.

14. 2026-09-02policy

    Token policy revised before any official contract existed

    The earlier adoption gates for a token (25,000 wallets/week, 40% re-check, K ≥ 0.6, sewn drops, Genesis freeze, counsel opinion) are retired. They were written before the launch plan existed and were never conditions a chain token has met. BAG CHECK remains useful with no token; holding $BAGGY has zero influence on scores, reactions, reports or corrections. Planned launch: Robinhood Chain → Pons V2 → ETH. Creator economics are not decided.

15. 2026-09-02methodology

    Rules v0.3 — stock tokens classified; Aura v0.2 unchanged

    Rules v0.3 introduces "stock" as a first-class token classification, so official Robinhood Chain stock tokens (e.g. NVDA) stop being silently bucketed into meme and start being classified for what they are. This changes which archetype, badge and verdict rules fire — Wall Street Gremlin and THE SUIT now read stock + rwa instead of rwa alone, and meme-share reads exclude stock tokens — but it does not change how Bag Aura is computed: the composition component still counts stock tokens folded back into the legacy meme category, exactly as it did before v0.3. AURA_VERSION stays 0.2; RULES_VERSION moves to 0.3. A token classifies as stock only when it is on the committed allowlist, or its name ends in "• Robinhood Token" and the explorer marks its reputation ok — a token that merely contains a ticker or brand name does not qualify.

16. 2026-08-26correction

    Community reports were re-run after a pricing-budget gap misfiled Mid-Curve wallets

    The first three community reports (Cash Cat, PONS, TENDIES) were sampled under a 40-token pricing budget. Wallets holding more tokens than that had their concentration left unscored and were filed as Mid-Curve by default, so the PONS and TENDIES "Mid-Curve" headlines were mostly an artifact of coverage, not a reading of the wallets. The Cash Cat report was less affected (8 of 32 Mid-Curves unscored). Fix: Budget raised so every observable token is priced (pricing coverage v2) and activity measured outbound (aura v0.2); the same frozen cohorts were re-run (docs/reports/sensitivity-2026-08-26.md). None of the three narratives survived: Cash Cat was 42% One-Bag Maxi / median 6,131 and is now 75% Dust Lord / median 5,733 with a median largest position of 99% (they picked one bag and kept every receipt); PONS was 47% Mid-Curve / 4,509, now 68% Dust Lord / 5,651; TENDIES was 53% Mid-Curve / 4,714, now 55% Dust Lord / 6,028. Old verdicts, retired: "Cash Cat's biggest holders didn't diversify. They picked." · "PONS's biggest holders don't pick. They collect." · "Tendies holders hold a hundred tokens. Tendies is one of them." The reports were not distribution-ready and were not distributed.

17. 2026-08-26correction

    Backdated ledger roots removed; the ledger no longer computes past days

    Rendering a 7-day ledger-root series on this page asked the ledger for past days it had never computed, and the ledger answered by computing roots from today's records and storing them under the old dates — six backdated roots (Aug 20–25) that were never anchored, and the chain pointer moved to the oldest of them. Caught within the hour by the identical hashes on this page. Fix: The six backdated roots were deleted and the chain pointer restored to today's root. The ledger now refuses to compute a root for any day but today; a past day with no stored root shows as empty, never as fabricated.

18. 2026-08-26correction

    "Keep my Block Tag" disabled until proof of control exists

    "Keep my Block Tag" trusted the card's key as proof of ownership. The key only proves someone ran the check, so a stranger could have kept a tag for a wallet they do not control. The two tags kept so far were written by the operator while testing. Fix: Keep is switched off until a proof-of-control step exists. Until then nothing per-wallet is written by anyone: checking is not claiming.

19. 2026-08-26correction

    Operator-token hook removed from the verdict engine

    The verdict engine carried a hook keyed to holdings of a hypothetical operator token ("holds only BAGCHECK"). It never touched Aura, but a judge whose lines depend on its own coin is a conflict whichever way it points. Fix: Hook and line removed; the engine takes no input about any operator asset, by type.

20. 2026-08-26correction

    Chain age and token age are now stated separately

    The Cash Cat report and our research notes dated the chain from the Jul 1 public mainnet announcement ("chain is 56d old") and called the token "deployed day-of-mainnet." Robinhood Chain's block 1 is dated 2026-04-30 and the CASHCAT contract was deployed 2026-06-18 (block 88,836), 13 days before the announcement. Fix: Two clocks, both stated: the chain has existed since block 1 (2026-04-30) and the product anchors chain age to the public launch (2026-07-01) because nobody outside could use earlier blocks; reports now show token age (CASHCAT: 69d at sampling), which is the real Diamond Duffel constraint — no holder can have held 90 days yet.

21. 2026-08-25correction

    Community report timestamps now state UTC

    Community report timestamps were shown as a bare date; a late-evening US sample read as a future date. Fix: All report timestamps now state UTC.

22. 2026-08-25correction

    Community nomination rule widened past the 90-day chain-age trap

    The community nomination rule (≥90 days of history) disqualified every community on a chain younger than 90 days, including the one already reported. Fix: Rule is now ≥1,000 holders AND (≥90 days OR top-3 by holders on the chain); the exception is stated on the page.

23. 2026-08-24correction

    First-check records limited to explicit "Keep my Block Tag" writes

    First-check records were written for any pasted address, including wallets pasted by someone else. Fix: Only the owner's explicit "Keep my Block Tag" writes a record; an erasure endpoint removes anything written before the fix.