DEV Community: Edy Cu

50,000 property tests passed while my app crowned an impostor

Edy Cu — Fri, 25 Sep 2026 02:26:11 +0000

You hear "buy PEPE", type PEPE into your wallet, and get fourteen tokens with the same name and the same frog. Which one do you buy?

I built a tool to answer that. You type a ticker, and it asks Nansen's API for every token with that name across chains. Then it checks who actually holds and trades each one: labelled Smart Money, whales, top-PnL wallets, exchange flow, tagged top holders. Exactly one card turns green, or the tool abstains.

Last week it crowned a token that its own scorer had flagged as an impostor. My property test ran 50,000 generated cases on that exact decision, and they all passed. While writing this post I found out why, and the answer was worse than I expected.

Live: https://whichone.edycu.dev
Code: https://github.com/edycutjong/whichone

Two rules in two files

The engine judges each candidate twice.

The impostor rule lives in score.ts. A candidate is an impostor when nothing labelled has touched it, it has no meaningful exchange flow, and it is either brand new or barely held:

// packages/core/src/score.ts
const impostor = f.labelledWallets === 0 && exchMag < 10_000 && ((f.ageDays != null && f.ageDays < 14) || (f.totalHolders != null && f.totalHolders < 500));
if (impostor) reasons.push("IMPOSTOR: nothing labelled has ever touched it");

The crown rule lives in verdict.ts. It decides whether ranked[0] gets the green card or the tool says "none of these looks real". This is how it read before the fix (abridged: I left out the guards for zero results, unscorable chains and failed lookups, which didn't change):

// packages/core/src/verdict.ts, before commit 3b5f16f (abridged)
export function crown(ranked: Scored[], sameNameCount: number, q: string): { winner: Scored | null; abstainReason?: string } {
  const best = ranked[0];
  /* ... guards: 0 results, unscorable, every lookup failed, holders lookup failed ... */
  if (best.score < ABSTAIN_THRESHOLD || (best.labelledWallets === 0 && (best.recognisedHolders ?? 0) < MIN_RECOGNISED_TO_CROWN))
    return { winner: null, abstainReason: "none of these looks real — nothing labelled has touched any of them" };
  return { winner: best };
}

best.impostor isn't read anywhere in it. The score module had already answered the question, and the crown rule never asked.

A fix for one bug opened the door

Three days earlier, live testing turned up a different failure. SHIB2 was a dead token, about $36K market cap, three years old, with zero labelled wallets, and the tool crowned it REAL. The cause was the holders tiebreak. Nansen's tgm/holders returns an address_label for each top holder, and SHIB2's top holders included a UniswapV2 pool and a SHIB2 Token Deployer. Every token has a pool and a deployer, so those labels prove nothing.

That fix excluded structural tags (pools, deployers, ENS/SNS names, burn addresses, the contract itself). It also raised the bar for a candidate with zero labelled wallets: it can be crowned only if at least 3 of its top 20 holders carry a wealth or activity tag, like "Token Millionaire" or "High Activity". That is MIN_RECOGNISED_TO_CROWN = 3.

I added that clause on purpose as an escape hatch. Nansen's labels are uneven, and some real tokens have no labelled wallets in a 7-day window but plenty of tagged holders.

On 2026-09-19, PEPEGA got through that hatch. It had one candidate:

0 labelled wallets in 7 days
no meaningful exchange flow
283 holders
7 of its top 20 holders wealth-tagged

283 holders is under 500, so score() set impostor: true. The score cleared the abstain threshold and 7 tagged holders beat the bar of 3, so crown() crowned it anyway. The fix commit put it this way: "a green card and an IMPOSTOR badge at once."

The fix takes two lines:

// packages/core/src/verdict.ts, after commit 3b5f16f
  // a card cannot be "this is the one" and IMPOSTOR at once: when the best candidate trips the impostor rule, abstain
  if (best.impostor) return { winner: null, abstainReason: "none of these looks real — the best candidate trips the impostor rule" };

Here is the CLI output now:

PEPEGA — 1 same-name token on Nansen

✖ ethereum   0x9634…c879    PEPEGA   4.68   0 labelled wallets in 7 days · no meaningful exchange flow · 283 holders IMPOSTOR

no winner — none of these looks real — the best candidate trips the impostor rule
7 credits · 4 calls (0 cached) · 2.1s · verdict 47b4ac4fc907

Why 50,000 property cases missed it, part one

Two days before PEPEGA, I had added property-based tests with fast-check. The crown-rule property generates random lists of scored candidates, ranks them, calls crown(), and checks every winner. It runs 10,000 times for each of five properties, which is where the 50,000 comes from. Everything was green.

This is what the property asserted about a winner before the fix:

// packages/core/test/property.test.ts, before commit 3b5f16f (the winner check only)
return (
  winner === ranked[0] &&
  winner.scorable &&
  !winner.unchecked &&
  winner.score >= ABSTAIN_THRESHOLD &&
  !(winner.labelledWallets === 0 && (winner.recognisedHolders ?? 0) < MIN_RECOGNISED_TO_CROWN) &&
  abstainReason === undefined
);

Each line restates one of crown()'s own if statements, so the property only checked that the function did what the function said. The rule I had missed wasn't in crown() at all. It was a rule about what the user sees: a card is never green and IMPOSTOR at once. That rule crosses two modules, and my tests were organized by module.

The fix commit added !winner.impostor && to that list. At the time I thought that closed it.

Part two: the generator never made an impostor

While writing this post I wanted to say how fast the new assertion would have caught the bug. So I copied the test's generator into a scratch script, paired it with the pre-fix crown(), and counted.

The generator draws each wallet class separately, and the labelled count is their sum:

// packages/core/test/property.test.ts (abridged: 4 of the 17 fields)
smartTraderWallets: fc.nat(500),
whaleWallets: fc.nat(500),
topPnlWallets: fc.nat(500),
publicFigureWallets: fc.nat(500),
// ...
.map((r) => facts({ ...r, labelledWallets: r.smartTraderWallets + r.whaleWallets + r.topPnlWallets + r.publicFigureWallets }));

For a candidate to have zero labelled wallets, all four independent draws have to land on 0. Across five seeded runs of 10,000 lists, about 44,000 candidates per run, the generator produced zero candidates with zero labelled wallets. So it produced zero impostors, and zero cases where the pre-fix crown() crowned one. Even with the right assertion, the old code passed.

It is not just the impostor line. Every branch that matters for a zero-labelled token (the SHIB2 bar, the PEPEGA veto, the failed-holders abstain) was sitting in a corner of the input space the generator never visited.

I changed one thing in the scratch copy, not in the repo. Each wallet count became fc.oneof(fc.constant(0), fc.nat(500)), so zero comes up about half the time for each class. Then I ran it against the pre-fix crown() with the !winner.impostor property. fast-check found a counterexample on all five seeds, after 47, 53, 71, 109 and 244 cases.

Two things went wrong, and fixing either one alone would not have caught the bug:

The invariant was the implementation restated. Write properties about what the output must never do, not about which branches the code takes.
The generator had no weight where the bugs were. A uniform draw almost never produces the edge case your domain revolves around. Here that case was "zero". If a value drives a branch, put it in the generator on purpose.

As of this writing, the repo's generator still has that gap. The PEPEGA regression test pins the actual bug, so the crown rule is covered. The property test just doesn't cover as much of it as "50,000 cases" suggests.

The rest of the system

The score is plain arithmetic over four Nansen endpoints:

search/general: 0 credits
tgm/flow-intelligence and tgm/token-information: 1 credit each, for up to 8 candidates
tgm/holders: 5 credits, for the top two finalists only

Market cap, volume and search rank are left out of the score, because those are what an impostor can buy.

The repo includes a benchmark: 12 queries × 2 cold runs against the live API, on 2026-09-16. Cold p50 was 3.6 s, p95 7.2 s, warm p50 3 ms. Verdicts cost 18.6 credits on average and 26 at most. npm run verify replays twelve recorded verdicts offline with the same decision hash. It needs no API access and no network. The web page streams every Nansen call into a side rail as it fires, with the endpoint, credits, latency and a short hash of each response.

Limitations

search/general decides the candidate set. The tool can't warn about an impostor Nansen hasn't indexed.
Label coverage is uneven across chains. A real token on a thinly labelled chain can lose to a bridged copy on a busier one, which is why there's a chain filter.
Flow data covers a 7-day window, so a real but dormant token can look quiet.
The zero-labelled escape hatch is still there. On 2026-09-16, AI16Z and PEPE UNCHAINED were crowned on wealth-tagged holders alone. The card says "0 labelled wallets" so you can see the weakness, but it's a weaker verdict than a green card backed by 90 labelled wallets.
DOGE crowns a Solana meme DOGE, because native DOGE has no contract to compare against.
USDC is the slow outlier, about 15 s cold. Nansen times out on some of its lookups, and the call drawer shows each timeout.

Try it

Live: https://whichone.edycu.dev. Try PEPE, then PEPEGA.
Code: https://github.com/edycutjong/whichone. npm run whichone -- PEPE --explain prints every term of the score (you need your own Nansen key).

If you write property tests, count how often your generator actually produces the values your branches depend on. I hadn't, until this post.

Nansen called Binance 14 a 'Token Billionaire'. The name cost 1 credit

Edy Cu — Fri, 25 Sep 2026 02:26:09 +0000

It's 2am and you just sent 316 USDT to the wrong address. Maybe it was an old deposit address from an email, maybe a look-alike planted in your history, maybe a contract. You Google "can I get it back" and the first three results are recovery scams.

What happens next depends on what that address actually is. A Binance customer deposit address means a support ticket and a real chance of recovery. A burn address means it's gone, and anyone offering to recover it is lying.

I built Sent Wrong to answer that one question. You paste the address you sent to (and your own, if you like). It runs up to ten calls against Nansen's API and gives you one of four routes, the evidence behind it, and a support ticket ready to copy.

Live: https://sentwrong.edycu.dev
Code: https://github.com/edycutjong/sentwrong (MIT)

The whole thing depends on the address's entity label. The obvious place to get that label turned out to be the wrong one.

The field that should have worked

Nansen has cheap profiler endpoints that return a label per address: counterparties (5 credits), first-funder and related-wallets (1 credit each). So the first plan was to profile the address, read its label, and be done.

On day one I pointed them at Binance 14, probably the best-known labelled hot wallet on Ethereum. The label that came back was:

["Token Billionaire"]

Coinbase 10 came back as ["High Activity"]. Those are wealth and activity tags. They tell you the address is rich or busy. They don't tell you it belongs to an exchange, and they say nothing about a customer deposit address, which is the case that actually gets people their money back.

The entity name does exist in profiler/address/labels, which costs 100 credits per call. That's too much to spend by default on every panicked paste.

Where the name actually was

It turned up, unexpectedly, in transaction-with-token-transfer-lookup. It takes a transaction hash and returns its token transfers, each with a label for both sides. For 1 credit, on the hero address, the sending side read:

🏦 Binance: Deposit [0xe46077]

That names the exact customer deposit address, not just the exchange. The receiving side read 🏦 Binance 14 [0x28c6c0]: the sweep into the exchange's own wallet. Nothing in the docs says this endpoint carries entity labels. The repo's decision-table doc says it plainly: the whole engine hangs on that field.

That changed the design. I stopped asking "what is this address?" and started asking "which transactions should I look at to find out what this address is?"

Labels live on transactions, so pick transactions

The engine gathers in stages: a free search/general call (a token contract stops here), then 14 days of transactions plus the cheap identity lookups, full history for quiet addresses, and finally the choice of which hashes to look up. Abridged from packages/core/src/lookups.ts, with the sender-matching branch removed:

// Which transaction hashes to look up: the newest 2 outbound (the sweeps), the newest inbound, the sender's transfer
// if we can see it, and the funding transaction. These carry the entity labels the profiler rows do not.
const wanted: Array<{ hash: string; role: TxLookup["role"] }> = [];
if (transactions.ok) {
  const { outbound, inbound } = splitDirection(transactions.data.data, a);
  for (const r of outbound.slice(0, 2)) wanted.push({ hash: r.transaction_hash, role: "outbound" });
  /* … the sender's own transfer, if --from was given … */
  if (inbound[0]) wanted.push({ hash: inbound[0].transaction_hash, role: "inbound" });
}
if (firstFunder.ok && firstFunder.data.data[0] && lc(firstFunder.data.data[0].chain) === chain)
  wanted.push({ hash: firstFunder.data.data[0].transaction_hash, role: "funding" });

Each hash does its own job:

Outbound transactions show where the address sweeps to, and the address's own label.
The newest inbound transaction carries the address's own label as a recipient, even if it has never sent anything.
The funding transaction shows who paid the address's first gas. Exchanges fund their own deposit addresses, so first-funder → funding tx → 🏦 Binance [0x943080] can name the exchange before the address has swept anything.

That's up to four lookups at 1 credit each. The hero verdict costs 13 credits across 10 calls, against 100 for the labels endpoint, which is still available behind --deep (cost printed first; the card says whether it agrees).

Parsing a label is its own small trap

Labels are free text with emoji and an address stub: 🏦 Binance: Deposit [0xe46077], 🤖 🏦 Coinbase [0xa9d1e0], Token Billionaire, sofaking.eth*. The rule behind the most common good-news verdict is short. From packages/core/src/labels.ts, verbatim:

/** "<Entity>: Deposit" — Nansen's label for a user-level exchange deposit address. */
export function isDepositLabel(p: ParsedLabel | undefined): p is ParsedLabel & { entity: string } {
  return !!p && !!p.entity && /^Deposit$/i.test(p.role ?? "");
}

Getting there took two regression tests:

🏦 doesn't mean "exchange." Nansen puts the same bank emoji on DEX routers: 🤖 🏦 Uniswap: V2 Router 2. A router's outflow looks exactly like a sweep, so any label that names a contract (Router, Pool, Proxy, …) is now kept out of the sweep rule.
Direction matters. A : Deposit label on a destination means a person is depositing into an exchange. That makes the sender an ordinary user wallet, not a deposit address. One of the recorded live runs hit exactly this, and it's now a named regression test: "a user wallet sending to its own ': Deposit' address is NOT a deposit address."

The refusal is the answer

On burn addresses, transactions and counterparties return HTTP 422 Burn address not allowed. It reads like an error. It's actually the most certain answer the API gives, so it's rule 1 in the decision table:

export function isBurnRejection(r: LookupResult<unknown>): boolean {
  return !r.ok && r.status === 422 && /burn address/i.test(r.error);
}

Paste 0x…dEaD and you get a red CONTRACT OR BURN card with the evidence line profiler/address/transactions → HTTP 422 = Burn address not allowed and the sentence "Do not pay anyone who promises recovery." This check runs before any transaction lookups, so a burn verdict costs 2 credits.

The flip side: a 422 is an answer about the input, so it's cached and replayed; a timeout or 5xx is not, so a failed transactions lookup yields a retry, never a verdict. An early build turned a slow minute into "nothing on record", a made-up verdict. A property test now checks, over 10,000 generated response sets, that this can't happen.

What it looks like end to end

Real output from --explain --no-cache, from the repo's DEMO.md (abridged to the verdict and totals):

EXCHANGE-DEPOSIT (high · direct-label)
This is a Binance deposit address. Recoverable through Binance support.
  ✔ Nansen has this exact address labelled as a Binance customer deposit address.
    transaction-with-token-transfer-lookup → token_transfer_array[].from_address_label = 🏦 Binance: Deposit [0xe46077]
  ✔ Everything it receives is swept into Binance's own wallet.
    transaction-with-token-transfer-lookup → token_transfer_array[].to_address_label = 🏦 Binance 14 [0x28c6c0]
  ✔ All outflow ($2,953 at today's prices) goes to one counterparty: the sweep pattern of a deposit address.
    profiler/address/counterparties → volume_out_usd = 100% to 0x28c6…1d60
  ✔ Binance paid this address's first gas — exchanges do that for their deposit addresses.
    profiler/address/first-funder → first_funder_address (looked up) = 🏦 Binance [0x943080]
…
13 credits · 10 calls (0 cached) · 3.9s · verdict 3ea6cfcd752b

The numbers. A benchmark of 13 real addresses × 3 runs with every call live gave a cold p50 of 3,157 ms and p95 of 6,477 ms, a mean of 10.2 credits per verdict (0 to 13), 309 live calls and 0 failures other than the expected 422s. Warm from the 24 h cache it's p50 2 ms at 0 credits, with the same decision hash every run. There are 234 vitest tests. 13 recorded fixtures replay offline with identical hashes (npm run verify, no key, no network).

Honest limits

Latency is Nansen's. Per-call latency varies from 0.3 to 3 s depending on the minute, so a cold verdict takes 4–13 s. On Vercel the cache is in-memory per function instance, so a cold start is fully live.
"Nothing on record" is ambiguous. It can't tell a brand-new address from one Nansen doesn't index. vitalik.eth returns empty profiler pages and comes back as a low-confidence fresh stranger. The card says so instead of promising that waiting will help.
Ethereum is the deeply tested chain. Seven other EVM chains go through the same endpoints, but only Base has been checked live.
Odds on the stranger route are words, not numbers. Nansen can tell whether a wallet moves funds. Nobody can tell whether its owner is honest.
It's triage, not legal advice. Every route's text tells you not to pay recovery services.

The takeaway

If an API returns labels in more than one place, don't assume the cheapest field is a cheaper copy of the expensive one. Here they were different kinds of label: wealth tags on the profiler rows, identity on the transfer rows. Test the field on an address whose answer you already know. Binance 14 took one call to show the problem.

Try it at https://sentwrong.edycu.dev, or clone https://github.com/edycutjong/sentwrong and run npm run verify without a key. The 30-second demo is on X.

If you've been sent here after a 2am mistake: paste the address before you reply to anyone offering help.

I built a sell planner to dodge the pros. They were under 4% of buys

Edy Cu — Fri, 25 Sep 2026 02:26:08 +0000

Somebody hands you a token you never asked for, and now you have to turn it into dollars. Maybe a nonprofit got a $40K memecoin donation, or a freelancer got paid in a project's token. They have never used a DEX, and they don't want to be the seller who knocks the price down, or the one selling into a day when the funds are dumping too.

I built Glidepath for that person. You paste token, chain and amount held. It gives you a dated selling calendar: one tranche per day, each sized to the token's organic demand, with a .ics file so the plan lands in your calendar. It plans. It never trades.

Live: https://glidepath.edycu.dev
Code: https://github.com/edycutjong/glidepath (MIT)

The whole design rested on one assumption. The data knocked it down in the first afternoon. This post covers what I assumed, what Nansen's labels showed, and which part of the product turned out to do the real work.

The assumption

My premise was that a big chunk of a memecoin's DEX buying comes from pros: Smart Money wallets, funds, whales, exchanges, sniper-bot users. If you size your daily sell against headline volume, you are sizing it against money that can leave the same afternoon. So take the pros out, size against what's left, and call that organic demand.

Nansen can do that split, because its wallets carry labels. The list of labels that make a buyer "not organic" lives in one constant:

/**
 * Labels that make a buyer "not organic": Nansen's Smart Money tiers, funds, whales, exchanges and the Telegram
 * sniper-bot user tags. From the OpenAPI `LabelType` enum; Public Figure / LP / miner labels are deliberately kept —
 * those are people, not the cohort a forced seller must avoid competing with.
 */
export const EXCLUDED_LABELS = [
  "Smart Trader",
  "30D Smart Trader",
  "90D Smart Trader",
  "180D Smart Trader",
  "Fund",
  "Whale",
  "Exchange",
  "Maestro Bot User",
  "Top Maestro Bot User",
  "BananaGun Bot User",
  "Top BananaGun Bot User",
] as const;

Surprise 1: you can't see the label you filtered on

My first plan was to pull every buyer from tgm/who-bought-sold and classify the rows myself. That doesn't work. The address_label on a row is a display name, not the label the filter matched. On PEPE, the single wallet that exclude_smart_money_labels removed shows up as nftsindubai.eth. Elsewhere, excluded rows read High Balance or <X> Token Deployer.

So the organic/pro split only exists on Nansen's side, as a filter. On the 8 tokens I probed, include_smart_money_labels and exclude_smart_money_labels with the same list partitioned the buyer set exactly. That became the pager:

// packages/core/src/nansen.ts — abridged: signature and field list trimmed
const filters: Record<string, unknown> = {};
if (filter.exclude) filters.exclude_smart_money_labels = [...filter.exclude];
if (filter.include) filters.include_smart_money_labels = [...filter.include];
const rows: WhoBoughtSoldRow[] = [];
let pages = 0;
for (let page = 1; page <= maxPages; page++) {
  const res = await client.post<WhoBoughtSoldResponse>("tgm/who-bought-sold", {
    chain,
    token_address: token,
    buy_or_sell: "BUY",
    date: { from: iso(from), to: iso(to) },
    pagination: { page, per_page: 1000 },
    filters,
    order_by: [{ field: "bought_volume_usd", direction: "DESC" }],
  } /* , fields, opts */);
  pages++;
  rows.push(...(res.data ?? []));
  if (res.pagination?.is_last_page !== false || (res.data ?? []).length === 0) return { rows, pages, truncated: false };
}
return { rows, pages, truncated: true };

Surprise 2: you can't page the organic side either

The obvious next move was to page the organic buyers and add them up. Then I ran it on 5-to-7-day-old Solana launches. They had more than 20,000 buying addresses in 7 days: 20 pages of 1,000, 110 seconds, 20 credits, and the list was still truncated.

So the math is flipped. Glidepath never adds up the organic side. It takes total DEX buys from tgm/token-information and subtracts the pro rows. Across every token I looked at, the pros were at most 67 wallets, so that list is one page, three at most:

// packages/core/src/plan.ts — computePlan, the organic-demand block (abridged: surrounding code omitted)
if (totalBuy7dUsd != null) {
  if (proBuy7dUsd == null) {
    organicBuy7dUsd = totalBuy7dUsd;
    organicShare = null;
    warnings.push("pro-buyer split unavailable (who-bought-sold failed) — organic = all DEX buys");
  } else {
    organicBuy7dUsd = Math.max(0, totalBuy7dUsd - proBuy7dUsd);
    organicShare = totalBuy7dUsd > 0 ? organicBuy7dUsd / totalBuy7dUsd : null;
  }
}
// from the pager's own flag: a list that ends exactly on page 3 is complete, not truncated
if (facts.proTruncated) warnings.push(`pro-buyer list truncated at ${facts.proPages} pages — organic volume is an upper bound`);
const organicDailyUsd = organicBuy7dUsd == null ? null : organicBuy7dUsd / 7;

That last comment is a bug I fixed later. The warning used to fire on proPages >= 3, so a pro list that happened to end on exactly page 3 was reported as truncated when it was complete.

Surprise 3: the premise was wrong

Once the subtraction worked, I printed the split for real tokens. Here is PEPE, recorded live on 2026-09-16:

organic buys $458,738/day = ($3,236,056 DEX buys 7d − $24,893 by Smart Money/Fund/Whale/Exchange/bot users [1 wallets]) / 7 · organic share 99.2% · 528 organic buyers

One labelled wallet. 99.2% organic. And PEPE wasn't unusual. On all 11 tokens I tried, pros were 0–3.6% of DEX buy volume. Majors came out 98.5–100% organic. Fresh Solana launches came out 96.4–96.7%. The four sniper-bot labels matched zero rows, even on pump.fun launches with 20,000+ buyers. I kept them in the exclusion list, but I don't claim they do anything.

So the label filter I built the product around moves the "organic" number by a few percent. That's worth knowing, but it isn't the headline. I had a choice: make the split look dramatic on screen, or show it at its real size. The app shows it at its real size, and the README lists it as a limitation.

What actually changes the calendar

The part of Nansen's data that visibly changes a plan is cohort flows, not buyer labels. Glidepath marks a day red if Smart Money is net-selling, or if exchanges are receiving more tokens than organic buyers absorb in a day:

/** Red-day test: Smart Money net-selling past θ_sm, or net deposits to exchanges past θ_ex. */
export function redDay(smNetUsd: number | null, exNetUsd: number | null, th: Theta): { red: boolean; reason: string | null } {
  const fmt = (v: number) => `${v < 0 ? "−" : "+"}$${Math.round(Math.abs(v)).toLocaleString("en-US")}`;
  if (smNetUsd != null && smNetUsd < -th.smUsd) return { red: true, reason: `Smart Money net ${fmt(smNetUsd)}` };
  if (exNetUsd != null && exNetUsd > th.exUsd) return { red: true, reason: `Exchange net deposits ${fmt(exNetUsd)}` };
  return { red: false, reason: null };
}

export function theta(organicDailyUsd: number | null): Theta {
  const d = organicDailyUsd ?? 0;
  return { smUsd: Math.max(THETA_FLOOR_USD, THETA_SM_SHARE * d), exUsd: Math.max(THETA_FLOOR_USD, THETA_EX_SHARE * d) };
}

"Today" comes from tgm/flow-intelligence. The 13 complete days before it come from tgm/flows daily cohort history. A red today halves the first tranche, and the red-day rate over the last 13 days stretches the expected finish date. On PEPE's 16 September run, 4 of the 13 days had been red, all from exchange deposits between +$499K and +$1.92M. That turned a 2-tranche plan into "expect ~3 days". When I recorded the demo on the 19th, today itself was red (+$736K net exchange deposits) and the first tranche was halved on camera.

The exchange threshold is a full day of organic buying, and that's on purpose. For CEX-listed tokens, ±$1M of exchange flow is routine shuffling. The threshold is the point where you would really be competing with the pros.

Tranche size is min(k × organic/day, 1% of liquidity_usd), where k slides from 10% down to 3% as Nansen's peer-percentile risk indicators rise. For PEPE that came to 2 tranches, $30,598 then $9,372. Under a constant-product model the estimated cost is $147.90, against $230.36 for dumping the whole bag today.

Testing the planner

computePlan is a pure function of (facts, input, now), so it's cheap to test hard. There are 6 fast-check properties at 10,000 runs each, 60,000 generated cases. They check that tranches plus remainder equal the bag, that every tranche stays under both caps, that a red today halves tranche 1 and only tranche 1, and that the dates are consecutive. On its first run it found a real bug. At a dust price, the liquidity cap underflowed to a tranche of zero tokens, and the planner printed 90 empty rows. The fix is one guard:

// packages/core/src/plan.ts — sizeTranches (abridged: loop omitted)
// a tranche of zero tokens (liquidity cap underflowing at a dust price) would otherwise emit MAX_DAYS empty rows:
// nothing can be sold at this pace, so the calendar is empty and the whole bag is the unsold remainder
if (!(trancheTokens > 0)) return { tranches, days: 0, truncated: true, remainderTokens: amount, remainderPct: 1 };

The suite has 258 vitest tests in total. 13 recorded live plans replay offline byte-for-byte with zero network calls. Cold plans run p50 3.5 s / p95 6.0 s against live Nansen, averaging 13 credits each (12 on EVM chains, 15 on solana/base, where three trade/quote calls replace the cost model with a real route).

Limitations

The cost model is an approximation. It treats liquidity_usd as one pool with the token on one side. That's optimistic for tokens whose depth sits in a single thin pool, and it ignores MEV and gas. Only solana and base get a real routed quote.
Future days can't be known red or green. Each calendar event carries the rule, so you re-check it on the morning.
Two definitions of "Smart Money." Today's test uses flow-intelligence's smart_trader cohort. History uses tgm/flows' smart_money cohort. For PEPE that's 21 wallets vs 18 holders.
A nonexistent-but-valid address still spends 12 credits, because the calls fan out in parallel with no existence check first.
Stablecoins get no history strip. tgm/flows refuses them with a 422, and the plan says so.

This is not financial advice. It is a pacing calculator with its reasoning shown.

Try it

Live: https://glidepath.edycu.dev. Click the PEPE or BONK chip, then open "Every Nansen call" to see what each number came from. Whether today is red depends on that day's flows.
Code: https://github.com/edycutjong/glidepath. npm run verify replays all 13 plans with no key.
Built for the Nansen Meridian Buildathon. The entry post is here on X.

If you've measured the pro share on a token where it's actually large, I'd like to see the number.

My AI trading tool would sign a wallet drain as a login challenge

Edy Cu — Fri, 25 Sep 2026 01:44:23 +0000

BagOS is an MCP server I maintain. It lets an AI agent read token data on Bags, a Solana launchpad,
and, if you configure a wallet, trade and claim creator fees. I built it around one idea: a model
should be able to propose a spend but never complete one on its own. The first call to a write
tool signs nothing. It returns a preview and a single-use token bound to the exact arguments. Every
trade is capped. Every transaction is simulated before it's signed.

This week an outside review showed that none of that mattered. There was a way to drain the wallet
without touching a single write tool.

The attack

It needed two flaws. Either one alone was harmless.

1. The server trusted the folder you had open. MCP clients such as Claude Code start a local
server in the current project folder. BagOS called dotenv.config(), which reads .env from the
working directory. So any repository you opened could supply configuration you never set, including
BAGS_API_URL, the endpoint the login tool talks to.

2. The login tool signed whatever it was given. bags_authenticate proves you own a wallet: it
fetches a challenge from the auth endpoint, signs it, and trades the signature for an API key. It
signed the challenge bytes without checking what they were.

On Solana, a transaction signature is an ed25519 signature over the transaction's serialized
message. So if the "challenge" is a transaction message, the signature the tool sends back is a
valid signature for that transaction. Whoever receives it can broadcast it.

Put them together. A repo ships a .env that points BAGS_API_URL at a server its author
controls. You open the repo, and your agent calls bags_authenticate, maybe because a README told
it to. The fake endpoint returns a transfer of your balance as the challenge. The tool signs it and
sends the signature to that server.

The login tool wasn't a write tool, so none of the guardrails applied: no token gate, no cap, no
preview, no confirmation. My docs even said "Signing a challenge is not signing a transaction."
Before the fix, that wasn't true.

Why 100% coverage didn't catch it

The suite had 100% line, branch and function coverage, enforced in CI. Every line of the auth tool
was tested. The tests checked that it fetched a challenge, signed it and exchanged it, and it did
all of that correctly.

Coverage measures which lines run. It says nothing about which inputs you assumed were safe. My
tests used a well-behaved endpoint and a config I wrote myself, because I had never asked who else
could write that config or what else could arrive as a challenge. The missing check wasn't
untested; it had never been written.

The fix

3.0.0 is a breaking release, because it changes how configuration loads.

The server no longer reads .env from the working directory. You name a file explicitly, and the
path must be absolute:

const explicit = env["BAGS_ENV_FILE"]?.trim();
if (explicit) {
  // A relative path resolves against the working directory, which is the
  // exact thing this function exists not to trust.
  if (!isAbsolute(explicit)) {
    console.error(/* "refusing BAGS_ENV_FILE=...: it must be an absolute path" */);
    return "refused-relative";
  }

If a .env is sitting in the working directory, the server says it's ignoring it, on stderr.

The login tool now signs only Bags' exact sign-in text, with the nonce from the same init response.
It also refuses anything that decodes as a Solana transaction, and anything that isn't printable
text:

export function isTransactionMessage(bytes: Uint8Array): boolean {
  try {
    const message = VersionedMessage.deserialize(bytes);
    return Buffer.from(message.serialize()).equals(Buffer.from(bytes));
  } catch {
    return false;
  }
}

The auth endpoint is pinned to https on bags.fm unless the operator sets
BAGS_ALLOW_CUSTOM_API_URL=true. The model can no longer choose the keypair path either.

Shipping a security release

I drafted a private GitHub security advisory, fixed the bug on a temporary private fork, and merged
it from the advisory page. Then:

Released 3.0.0 through the normal pipeline, with npm provenance.
Deprecated every older version on npm (1.0.0 through 2.6.0), with a message pointing to the advisory.
Published the advisory: GHSA-g679-3wq7-mh3m.
Turned on private vulnerability reporting, so the next person has a private channel.

One trap for anyone doing this with release-please: merging from the advisory page squashes the
private fork into one commit titled "Merge commit from fork." That isn't a conventional commit, so
release-please computed a patch version for a breaking change. I caught it by checking the
release PR before merging, and fixed it by pushing an empty commit that restated the breaking
change.

Then it happened again

Hours later, I had the review check my launch plan against the code, and it turned up a second
gap.

The spend caps checked the amount the agent asked for. But the swap transaction that actually gets
signed is built by the Bags API, and nothing compared the two. The cap bounded the request, not
the signature.

3.0.5 closes that. Before signing, BagOS reads the wallet's SOL balance, asks the simulation for
the balance afterwards, and refuses if the difference is more than the approved amount plus 0.01
SOL for fees and rent. A fee claim approves nothing, so it may cost fees only. If the simulation
doesn't report the balance, the transaction isn't signed. The check is required on every path,
so no transaction can skip it.

What's still open

These are documented in SECURITY.md rather than hidden:

HTTP mode has no auth. --http serves /mcp on 0.0.0.0. Don't run it with a funded wallet. The stdio default is unaffected.
The simulation check reads SOL, not tokens. A transaction from the Bags API that also moved SPL tokens wouldn't trip it. That's trust in the Bags API, whose endpoint is fixed in its SDK.
The confirmation token binds the arguments, not the quoted price. Confirming re-runs the quote, so the price can move inside the five-minute window.
Caps are in SOL. A swap from another token can't be valued, so those swaps are refused unless you opt in.

What I'd tell anyone building an MCP server that holds a key

Treat configuration as input. An MCP server's working directory belongs to whatever project is open. Only the operator should set config, in the client's own settings.
Never sign bytes you didn't construct or check. "It's just a login" is how a signing tool ends up outside every guardrail.
Bound the effect, not the request. Simulate the transaction and check what it actually does to the wallet before you sign it.
Keep an adversarial reviewer in the loop. Both bugs were found by review, not by tests. The tests were written with the same assumptions as the code, so they couldn't find them.

Links: repo ·
advisory ·
SECURITY.md ·
npm

Earlier I wrote about a different BagOS bug, where the write tools reported success without signing anything: I shipped an MCP server that reported success without signing anything.

I build safety layers for AI agents that move money. I'm open to remote work.

I went looking for sandwiches and found a DEX pool trading with itself

Edy Cu — Wed, 23 Sep 2026 04:37:43 +0000

A DEX trader sees a quote and a fill and cannot tell what stood between them. I set out to measure the obvious suspect, the sandwich: a bot that buys just before you and sells straight after, in the same block.

I found almost none. What I found instead was a pool where two thirds of the volume was three wallets trading with themselves. The pool was ranked #1 on the same activity those trades were inflating.

Live: middleman.edycu.dev (the judge page is /judge, every request behind it on /evidence)
Repo: github.com/edycutjong/middleman. MIT, stdlib-only Python, no key.

The row that makes it possible

CoinMarketCap's /v1/dex/tokens/transactions returns a token's recent swaps, keyless, with a cursor. Each row carries the fields a sandwich detector needs: the maker's wallet (ma), the block (h), the log index inside the block (lgid), the side (tp) and both amounts (a0, a1). Here's one real row, trimmed:

{ "h": "26006339", "lgid": "209", "tp": "sell",
  "ma": "0xc9160fdab187f2e55567b760d88a87ae7fe56d95",
  "a0": 842991.8537715519, "a1": 1.0430246602456774,
  "en": "Uniswap v2", "t0s": "MOTO", "t1s": "WETH",
  "tx": "0x1345bed7cd96a35ae5543fdbfde710c1f7b41a3a365fc31b4c3c52e47512028b" }

The maker address lets you count "the same wallet on both sides" instead of guessing. The log index makes "between" exact inside a block. You get no mempool and no MEV labels, and you don't need them: a middleman has to print.

First trap: the block number is a string

Look at h and lgid again. They're quoted. The amounts on the same row are numbers, but the two fields that place a swap in the chain arrive as strings. Sort them as text and "99" comes after "1000". Every "between" in the detector is then wrong, and nothing raises an error.

So the first function in the engine does exactly one thing:

def sort_key(row):
    """(block, log index) as integers, or None when the row cannot be placed."""
    h, lgid = _int(row.get("h")), _int(row.get("lgid"))
    if h is None or lgid is None:
        return None
    return (h, lgid)

Rows that can't be placed are dropped and counted, and every receipt states the count. A regression test pins the trap by name: test_block_and_log_index_are_sorted_as_integers_not_as_the_strings_they_arrive_as.

The join

With prints in chain order and grouped per pool (venue plus the two token contracts, because the rows carry no pool address), the rule is short. For each print by wallet A, find A's next print in the same block. If it's the other side and the size matches within 5 %, A stood on both sides of the block. The prints between the two legs decide the shape:

def _legs_match(a, b, tol):
    """Two rows that could be the two legs of one middleman: same wallet, same block,
    opposite sides, matched size."""
    return (
        a.get("ma") is not None
        and a.get("ma") == b.get("ma")
        and _int(a.get("h")) is not None
        and _int(a.get("h")) == _int(b.get("h"))
        and side(a) in ("buy", "sell")
        and side(b) in ("buy", "sell")
        and side(a) != side(b)
        and size_match(a, b, tol)
    )

Sandwich (A-B-A): every print between the legs is another maker trading in leg 1's direction, there are 1 to 4 of them, and A came out ahead.
Round-trip (A-A): anything else. Usually nothing between, in one transaction: the same wallet buying back what it just sold.
Organic: every print that isn't a leg. Victims stay organic. They're real fills, and what they paid is the question.

What the join actually found

The day-1 spike ran this on 1,200 real prints from the busiest pair and found zero same-block sandwiches. A ten-token census across Ethereum, BSC and Solana found 2 in 8,000 prints: the same wallet, front-running a seller on UNI and on LINK, for $0.95 and $2.19.

That's a sandwich rate of 0.025 %. It's not a headline.

The round-trips were a headline. On MOTO/WETH, CoinMarketCap's #1 Uniswap v2 pair on Ethereum by 24-hour transactions at capture time, the last 800 prints (3.6 hours) held 29 round-trips by 3 wallets, every one inside a single transaction. They made up 66.2 % of the pool's volume: $127,254 of $192,275. The first one, straight from the receipt:

leg 1  lgid 209  0xc9160fdab187f2e55567b760d88a87ae7fe56d95  sell  a1/a0 = 1.0430246602456774 / 842991.8537715519 = 1.237289133434893e-06
leg 2  lgid 218  0xc9160fdab187f2e55567b760d88a87ae7fe56d95  buy   a1/a0 = 1.0325944136432206 / 829640.6520318444 = 1.2446285161103536e-06
same wallet · same block 26006339 · same tx · |Δa0| / a0 = 0.0158 ≤ 0.05 → round-trip

So I changed the headline before building the page, not in a caveat after. The engine didn't change: same feed, same ordering, same maker join. The sandwich became one named case of a middleman, and the page leads with the number the join actually found.

Why it matters to the person placing the order

Round-trip legs aren't trades anyone else can fill against, yet they sit on the tape. If you measure what a fill pays against the print before it across the raw tape, MOTO/WETH says 55.3 bps at the median. Take out the legs and measure only organic prints against the organic print before them, and the median is 15.5 bps (p90 60.9). The legs roughly triple the apparent cost of trading there.

The measurement is deliberately plain. It's the adverse-signed move of each print against the previous one:

if tp == "buy":
    bps = (q / prev - 1.0) * BPS
elif tp == "sell":
    bps = (1.0 - q / prev) * BPS

The price is always a1 / a0. The feed's own q field is rounded to two significant figures, and on Uniswap v4 rows it's sometimes zero. From the organic p90 the tool picks a route and a slippage cap. For MOTO: Uniswap v2 / WETH, cap 0.65 %.

The number moved, and that's the point

I ran the same bare command 24 minutes later and it measured 27.5 %: one wallet, eight round-trips. The next morning the window was clean, zero round-trips, and the tool printed zero on its own headline.

Two days after that, the hero rule (it's a rule, not a hard-coded token) picked a different pair, wildebeest/WETH. This time the join found the other shape: 17 sandwiches, 18 victim prints, 4 wallets in a 4.5-hour window. The first wallet listed was the one the census had caught on UNI and LINK.

So the census number stands as a census number: sandwiches are rare on average, not rare everywhere. All four transcripts are in DEMO.md with their receipts, and python3 scripts/verify_tape.py re-derives every published figure from the committed tapes offline.

I also got the classification wrong once. The first cut of the join called four prints on a BSC pair sandwiches. They were two wallets washing around each other, each buying back for exactly what it received. A sandwich now requires the attacker to come out ahead, and a same-wallet return that extracted nothing is a round-trip. That's the one thing it's safe to call.

Honest limitations

A run measures the last 800 prints, not 24 hours. That was 3.6 h on MOTO and 20 h on SHIB. The span is on every row.
Uniswap v3 fee tiers of one pair merge. The feed carries no pool address, so the number is per pair, not per tier.
Quote-to-fill includes fees and is realised. On a busy 0.30 % pool, consecutive opposite-side prints straddle the fee twice, so the p90 sits near 60 bps. Use it comparatively.
A round-trip is a shape, not a verdict. The tool prints the rows and the definition and never labels a person.
The anonymous tier throttles per IP, with no Retry-After. The CLI backs off and says so.

Run it

git clone https://github.com/edycutjong/middleman.git && cd middleman
python3 scripts/middleman.py

No pip install, no .env, no key. It asks CoinMarketCap which Uniswap v2 pair is busiest right now, pulls 800 prints and prints the table, the route and the raw rows of the first middleman it finds. It takes about ten seconds and uses 0 credits.

The live page is at middleman.edycu.dev, the code is at github.com/edycutjong/middleman, and there's a 3-minute demo at youtu.be/BwikjIf19hQ. If you've ever wondered what your fill actually paid for, the rows are one keyless call away.

Two in three 'liquidity pulled' alerts are the same wallet putting it back

Edy Cu — Wed, 23 Sep 2026 04:37:13 +0000

A treasury bot pings: LP removed, −$21,330,275, UNI/WBTC. Somebody pulls up a chart, somebody asks in the group chat whether the market maker left, and for the next hour the answer is a guess.

The answer was sitting in the same API, one query away. 132 seconds later the same wallet put 99.8% of that money — the same 1,962,475.5391248302 UNI, to the last decimal — into UNI/WETH, one pool over. The alert was true. The panic was not.

So I stopped looking at one removal and followed 335 of them. Two in three "liquidity pulled" alerts were the same wallet putting it back within six hours. This post is about that number, the one API parameter that produces it, and the two kinds of row that almost made it wrong.

Live: forwarding.edycu.dev (the short path is /judge)
Repo: github.com/edycutjong/forwarding — MIT, stdlib-only Python, no API key

The alert everyone fires, and the row nobody reads

CoinMarketCap's DEX API has /v1/dex/liquidity-change/list: every add and remove on a token's pools, with a USD value (tu), a side (tp), a timestamp, and — the part that matters — the wallet that did it, m. Filter it with minVolume=100000, sort by tu, and you have an "LP removed" alert bot. That is the obvious product, and it stops at the first row.

The endpoint also accepts maker= as a server-side filter. One keyless call returns everything one wallet did across every pool of the token. That is the whole trick — the second row was never hidden, it was just never joined:

def follow_maker(
    client, platform, address, maker, *, t0_ms, back_h=W_BACK_H, fwd_h=W_FWD_H, pages=FOLLOW_PAGES
):
    """THE JOIN. Every liquidity event by `maker` on `address`, inside t0 -+ the window."""
    lo = t0_ms - int(back_h * 3600_000)
    rows, meta = walk(
        client,
        {"platform": platform, "address": address, "maker": maker},
        pages,
        until=lambda page: min(ts_ms(r) for r in page) < lo,
    )
    return window_rows(rows, meta, t0_ms=t0_ms, back_h=back_h, fwd_h=fwd_h)

The walk() with a cursor is there because startTime is plan-gated on the keyless tier (HTTP 403, error 1013) while endTime is not, so a ±6 h window has to be paged back to with lastId and cut client-side on ts.

Here are the two rows from the live run, verbatim fields:

remove  ts=1788321551000 tu=-21330274.564875204 m=0x4f0aa5900b8292273b2f9a178d5468f8048bb9a9 en=Ring Exchange (Ethereum) a0=-1962475.5391248302
add     ts=1788321683000 tu=21287254.934237212  m=0x4f0aa5900b8292273b2f9a178d5468f8048bb9a9 en=Ring Exchange (Ethereum) a0=1962475.5391248302
        21,287,254.93 ÷ 21,330,274.56 = 0.9980

Same maker, same token amount, a different pair. That run made 14 calls, all 200, 0 credits, in 50.6 s, and every response body is embedded in the receipt under the sha256 the trace prints.

Turning two rows into a verdict

Once you have the wallet's rows inside the window, the classification is arithmetic on tu — no model produces a number. The adds are split into same pool and other pools, and the shares decide:

if same_share >= FULL and same_share >= other_share:
    kind = "REBALANCE"
elif other_share >= FULL:
    kind = "MIGRATION"
    if dest and dest["pubAt_ms"] and dest["pubAt_ms"] > ts_ms(removal):
        kind = "CONSOLIDATION"
elif total_share >= PARTIAL_MIN:
    kind = "PARTIAL"
elif complete:
    kind = "EXIT"
else:
    kind = "INCOMPLETE"

FULL is 0.70 and PARTIAL_MIN is 0.10. The last two lines carry the rule I care most about: an EXIT is only allowed when every follow completed. If a page was throttled or the walk never reached the start of the window, the answer is INCOMPLETE, never "they left". Calling a rebalance an exit is the exact false alarm this exists to kill, so the tool is not allowed to produce one from missing data.

The same follow runs on the asset's other EVM chains too: /v1/dex/search and /v2/cryptocurrency/info resolve the same CoinMarketCap asset to its contract on each chain (13 for UNI), and a chain is followed only if the asset has a market there. /v4/dex/pairs/quotes/latest then confirms the destination pool actually holds the money now.

The number

Following one removal proves the mechanism. To measure how often the alert is the wrong headline, I ran the same-chain follow over every non-JIT removal ≥ $100k on an 11-token, 3-chain watchlist — 335 removals, 352 keyless calls, 0 credits, about 20 minutes of wall clock:

Outcome of a "≥ $100k removed" alert	Count	Share
Rebalance — ≥ 70% back into the same pool	194	57.9%
Migration — ≥ 70% into a different pool	19	5.7%
Partial — 10–70% came back	10	3.0%
No same-wallet re-add within ±6 h	112	33.4%

223 of 335 — 66.6% — came back. The last row is deliberately not labelled "exits": the base-rate sweep follows the same chain only, so 33.4% is an upper bound on real exits, not a count of them. The receipt is docs/proof/base_rate.json, and every row in it can be re-derived.

Two kinds of row that nearly broke it

The number above only holds because two kinds of row are refused before anything is counted. Both came from running against the live API, not from the docs.

A removal worth 10⁴² dollars. On 2026-09-19, thirteen rows for the real CAKE contract on an unlabeled BSC venue carried tu = -1e+42 — and a0 = -1e+42 CAKE, trillions of times the supply. They pass minVolume, and in an 11-token sweep they out-ranked every real removal. Sort by tu, which is the obvious thing to do, and a scam pool's overflow is the top of every list. The guard is one constant and one function:

# A single liquidity event above this is not a removal, it is a price-feed artefact: live
# 2026-09-19, 13 CAKE rows on an unlabeled BSC venue carried tu = -1e42 (and a0 = -1e42 CAKE,
# trillions of times the supply) and out-ranked every real removal on the watchlist.
SANE_USD = 10_000_000_000.0

def plausible(row):
    """False for a row whose USD value no market could have produced (see SANE_USD)."""
    return usd(row) <= SANE_USD

Removals that are really one swap. Just-in-time liquidity — a searcher adds liquidity for a single swap and pulls it in the same transaction. 85 of 100 PEPE rows were JIT pairs; so were 28 AAVE, 27 DAI and 31 CAKE transactions in 100 rows. Every one of them is a "removal" to a naive consumer. Nothing in the row flags it, but both sides share a txn:

def jit_txns(rows):
    """Transactions that both add and remove — just-in-time liquidity, not an event."""
    sides = {}
    for r in rows:
        sides.setdefault(r.get("txn"), set()).add(r.get("tp"))
    return {t for t, s in sides.items() if {"add", "remove"} <= s}

Neither guard is clever. Both are the kind of thing you only write after the live data surprises you, which is the argument for building against the real API from the first hour instead of against fixtures.

Honest limits

Pool identity is venue + pair, not pool address. Rows never carry the pool contract, so three Uniswap v3 fee tiers of one pair collapse into one identity. The card says so.
The window is ±6 h. A wallet that comes back a day later reads as "no re-add" for that window.
A wallet is not an entity. Liquidity moved through a second wallet is not followed.
A wallet that cycles more than once in the window can show a share over 100%; the adds are attributed to the whole window, and the output discloses the other removals.
The anonymous tier throttles per IP, reported as 429/1022, 429/1011 or 500, with no Retry-After. The client backs off 15/30/60 s and records the retry in the receipt; the hosted page leads with the dated receipt for that reason.

The whole thing is one stdlib Python file on the default path, an unattended watch loop, and a three-tool MCP server (claude mcp add forwarding -- python3 $PWD/scripts/mcp_server.py). 324 offline tests, 100% statement and branch coverage, gated in CI.

Run it yourself — no key, no signup:

git clone https://github.com/edycutjong/forwarding.git && cd forwarding
python3 scripts/forwarding.py investigate --platform ethereum --address 0x1f9840a85d5af5bf1d1762f925bdaddc4201f984

The removal it picks comes from the market, so yours may differ from the one above. The live page is at forwarding.edycu.dev, a 2:54 demo is on YouTube, and the twelve dated things the API did that surprised me are in FEEDBACK.md.

If you run an alert on "liquidity removed", query the same endpoint once more with maker= before you send it.

My fact-checker said CONFIRMED about a group that doesn't exist

Edy Cu — Wed, 23 Sep 2026 00:13:27 +0000

I built a tool that fact-checks crypto claims. You paste a sentence like "Whales are holding $XYZ" and it plans the on-chain calls that claim needs, runs them against Nansen's API, and answers CONFIRMED / OVERSTATED / CONTRADICTED / UNVERIFIABLE with the numbers that decided it.

Last week it answered CONFIRMED about a group of wallets that does not exist.

Not "returned a weak signal." Not "was slightly off." It printed the word that means this claim is true, next to a cohort the data source tags exactly zero members of. Here is how a tool whose entire purpose is refusing to overstate ended up overstating, and why the README had already warned me.

Live: https://rebuttal.edycu.dev
Code: https://github.com/edycutjong/rebuttal

The promise I'd already written down

Three limitations ship in the repo's JUDGE.md. The second one says this, verbatim:

Nansen's Whale label is sparse. A post's "whale" is often a big wallet Nansen does not tag; when no Whale-labelled wallet exists in the token the tool says UNVERIFIABLE rather than pretending a CONTRADICTED.

I wrote that line early, and I wrote it because it is true of the data. My API notes from the build (docs/DX-REPORT.md) record the measurement it came from:

tgm/flow-intelligence 1d on WETH: whale_wallet_count = 0. tgm/holders label_type=whale on the same token: 38 holders.

Zero labelled whales on wrapped Ether. Not an edge case — the label is genuinely sparse, and the flow columns that report it are DEX-only. "No wallets of this class" is an ordinary, frequent answer from this API, not a rare one.

So I knew. I documented it. And then I enforced it in exactly one of the two places it mattered.

The choke point that wasn't

Claims come in three shapes: buying, selling, holding. The first two go down one branch, holding goes down another. Both need the same question answered first — does this class of wallet exist in this token at all? That question has a function:

/** Does the subject class exist in this token at all (any window, any endpoint)? */
export function presence(e: Evidence, cls: "smart_trader" | "whale"): boolean {
  return (
    (e.flow1d?.[cls]?.wallets ?? 0) > 0 ||
    (e.flow7d?.[cls]?.wallets ?? 0) > 0 ||
    (e.holders?.count ?? 0) > 0 ||
    (cls === "smart_trader" && (e.table?.traders ?? 0) > 0) ||
    (e.named ? e.named.buyRows + e.named.sellRows > 0 : false)
  );
}

The flow branch calls it, and does the right thing:

if (!presence(e, cls))
  return R("UNVERIFIABLE", "U-NOCLASS", [
    `Nansen tags no wallet as ${who} in this token (24 h, 7 d, holders) — ` +
    `the wallet in the post is not one Nansen labels`,
  ]);
return R("CONTRADICTED", "C-NOBODY", [ /* ... */ ]);

The holding branch never called it. Not once. Here is what it did instead — read it as a ladder, because that is how it fails:

function decideHolding(claim, e, rules, T7, R) {
  const who = subjectName(claim.subject);   // "Whales" | "Smart Money"
  const cls = subjectClass(claim.subject);  // "whale"  | "smart_trader"
  const h = e.holders;
  const net7 = e.flow7d?.[cls]?.net ?? null;
  if (!h && net7 == null) return R("UNVERIFIABLE", "U-HOLD", [/* no data at all */]);

  // ↓ no presence() check here ↓

  if (h && h.count < rules.minHolders) return R("OVERSTATED", "O-HOLDERS", [/* ... */]);
  if (h && net7 != null && net7 <= -T7 && h.delta7d < 0) return R("CONTRADICTED", "C-EXIT", [/* ... */]);
  if ((h && h.delta7d < 0) || (net7 != null && net7 <= -T7)) return R("OVERSTATED", "O-TRIM", [/* ... */]);
  return R("CONFIRMED", "A-HOLD", [/* "balances are not shrinking" */]);
}

Two ways to be wrong, and the second one is much worse

Zero holders. tgm/holders answers with an empty page, so h.count === 0. The first rung catches it — 0 < 5 — and returns OVERSTATED, whose UI copy means partly true. Partly true about nobody. Bad, but at least it is hedging.

The holders call failed. Now h is null, and the seven-day flow answered with wallets: 0. Look at the ladder again: every remaining rung is guarded by h &&. O-HOLDERS needs h. C-EXIT needs h. O-TRIM needs h or a net flow below the negative threshold — and the net flow is 0, which is not below anything. So the claim falls all the way through and lands on the last line:

{ label: "CONFIRMED", rule: "A-HOLD", presence: false,
  reasons: [ "7 d Whales net flow $0 (threshold $5K)",
             "Whales balances are not shrinking" ] }

"Whales balances are not shrinking." Technically unfalsifiable and completely true, in the way that "all the unicorns in my garage are healthy" is true. There are no whales. Nothing is shrinking because there is nothing. And the tool rendered that as CONFIRMED, the strongest word it owns, on the one screen a reader actually looks at.

The path needs no exotic input. One failed HTTP call to a sparse endpoint, on a token whose class is empty — which, per my own notes, is WETH.

The fix is one line, which is the annoying part

if (!presence(e, cls))
  return R("UNVERIFIABLE", "U-NOCLASS", [/* same message the flow path uses */]);

One line, plus a comment, plus 45 lines of tests. The whole commit is +51.

I found the first case because I ran the source past an outside model, which spotted the zero-holders rung. Verifying its claim is what turned up the second: I wrote a throwaway test with holders: null to see what the other branch did, and got CONFIRMED back. The review found the hedge; checking the review found the lie.

All 13 recorded fixtures still reproduce with byte-identical sha256 evidence hashes after the change, which is the thing that let me ship a one-line edit to the verdict engine four days before a deadline without flinching.

What I actually take from this

A limitation stated in prose is not a constraint. I had the right belief, written in the right file, in public, in the artifact judges read. It did nothing. Prose cannot fail a build.

An invariant enforced in one branch is enforced in zero branches. presence() existed. It was correct. It was even called — just not on every path that needed it. A shared helper that callers must remember to call is a convention, and conventions decay the moment someone adds a fourth claim type.

The dangerous bug was in the fallback, not the happy path. Every test I had written covered tokens with data, because that is what the demo uses and what the fixtures recorded. The failure mode lived where the data was absent — h === null, wallets: 0, a call that didn't answer — and absence is exactly what nobody writes fixtures for. If you have a decision function with a default return at the bottom, the question worth asking is not "is this the right default" but "what is the emptiest input that can reach this line?"

Sparse-by-design data is a first-class input. I treated "no whales" as degenerate. It is not. It is Wednesday.

Honest limits, since that is the whole point of the tool

The fix makes the engine refuse more often, and refusing is the correct answer, but it is still a refusal — a user who pastes a claim about an unlabelled wallet gets UNVERIFIABLE, not an investigation of who that wallet is.
Two Nansen endpoints can report different numbers for the same 24 hours (flow-intelligence vs smart-money/netflow). I surface both rather than reconcile them; docs/DX-REPORT.md has the measurement.
Net flows are priced at current rates and drift. The evidence hash covers the integers that decided the label, so a fixture replay always matches and a live re-run usually does.

For the numbers people ask for: 352 tests, 100% statement/branch/function/line coverage on the engine, 13 fixtures that replay offline with zero network calls, cold p50 4.0 s / p95 5.0 s, ~10 API credits per verdict, 0 of 154 live calls failed in the benchmark. Details in docs/BENCH.md.

The tool is at https://rebuttal.edycu.dev and the code is at https://github.com/edycutjong/rebuttal — the commit in this post is fedb50b, and the test that pins both failure paths is packages/core/test/review4.test.ts.

If you have a verdict function with a return at the bottom of a ladder, go and check what the emptiest possible input does to it. That is the whole article.

has_tokens: true is a boolean. 476 of 791 have no market behind them.

Edy Cu — Tue, 22 Sep 2026 08:00:43 +0000

A desk that sizes a tokenised-equity position on has_tokens: true finds out at the ticket that the one Morgan Stanley wrapper on CoinMarketCap has no price, no volume, and no market CoinMarketCap tracks.

I built a small tool to count how often that happens. The first draft of the headline said the wrappers had never traded. That was wrong, and the way it was wrong is the most useful thing I learned in the build — so this post is about the retraction as much as the number.

Live: shelfware.edycu.dev (the judge page is /judge)
Repo: github.com/edycutjong/shelfware — MIT, stdlib-only Python

Two rows, two endpoint families, one word

CoinMarketCap's RWA API is new. /v5/real-world-assets/map lists every underlying it knows about — 7,811 of them — and flags 791 as has_tokens: true. /v5/real-world-assets/quotes/latest returns, per underlying, a tokens[] array of the wrappers minted against it, with the issuer that minted each one.

Here is Morgan Stanley on that surface, trimmed to the fields that matter:

{ "symbol": "MS", "name": "Morgan Stanley", "asset_type": "stock",
  "rwa_rank": 43, "has_tokens": true,
  "tokens": [ { "crypto_id": 41513, "symbol": "wMSx",
                "issuer_name": "Backed Assets",
                "price": null, "market_cap": null, "volume_24h": null } ] }

price: null. Nothing on the RWA surface says why. The reason lives in a different endpoint family, /v1/cryptocurrency/map, which is keyless and carries a status per listing:

{ "id": 41513, "symbol": "wMSx", "status": "untracked",
  "platform": { "name": "X Layer",
                "token_address": "0x2874A11805783324C54562eDB1A641C5d1d077a5" } }

CoinMarketCap's documentation defines untracked as "registered cryptocurrency projects that are listed but do not yet meet methodology requirements to have tracked markets." So: tokenised, yes; a market CoinMarketCap tracks, no. The boolean and the listing state disagree about what "tokenised" means, and nobody joins them — every price-based RWA tool drops the price: null rows before it starts.

Shelfware is built on exactly those rows.

The join, and the three counting rules

The engine is pure functions over the two ledgers. The rule that produces the headline:

def zero_tracked(wrappers, has_tokens_rows, strict=True):
    """rwa_ids of underlyings with no wrapper that has a CMC-tracked market.

    strict (the headline): the underlying has >= 1 attached wrapper and EVERY one is untracked.
    loose: no wrapper is active — also counts unresolved-only and inactive-only underlyings.
    Strict is always <= loose; the headline never takes the larger number."""
    groups = by_underlying(wrappers)
    out = []
    for r in has_tokens_rows:
        ws = groups.get(r["rwa_id"], [])
        if strict:
            if ws and all(is_shelf(w) for w in ws):
                out.append(r["rwa_id"])
        elif not any(w.get("status") == "active" for w in ws):
            out.append(r["rwa_id"])
    return out

is_shelf is one line — status == "untracked" — and that line is the whole retraction. The first draft tested price is None. It gives the same number today, because on the committed census price == null ⇔ status == "untracked" held with 0 exceptions across 1,431 resolved wrappers. But it is the wrong predicate: a null price is an observation, untracked is CoinMarketCap's stated reason for it. The suite re-checks the equivalence on every run so the day CoinMarketCap prices an untracked wrapper, the join says so instead of quietly drifting.

Live on 2026-09-18, 5 keyed credits, 54 calls, 40.9 seconds:

476 of the 791 underlyings flagged has_tokens: true — 60.2% — have no wrapper with a CMC-tracked market. Stocks alone: 437 of 689 (63%).
673 of the 1,435 wrappers (46.9%) are untracked.
By issuer: Dinari 27 attached, 0 tracked (100% shelf). Backed 772 attached, 140 tracked (82%), $669M live in the rest. Robinhood 8 of 106 on the shelf. Ondo 4 of 214. bStocks 0 of 77.

Re-derive the headline from the committed rows with no code at all:

jq '.wrappers | group_by(.rwa_id) | map(select(all(.[]; .status=="untracked"))) | length' data/census.json   # 476

Why "never traded" had to go

The spike that settled it cost 2 credits and is committed as docs/proof/spike.json. For wMSx: map status untracked, quotes/latest price null, quotes/historical zero points — and, on the same RWA row, a tradfi_markets entry pointing at Binance's tokenised-stock venue for MS. Dinari's dShares trade on Dinari's own permissioned venue. A pool CoinMarketCap does not index is still a pool.

So "never traded" was a claim about the world that the data could not support. untracked is a claim about CoinMarketCap's coverage of what CoinMarketCap calls tokenised — which is exactly why it can be re-derived from CoinMarketCap's own rows. Every surface was re-worded to listed, no CMC-tracked market, and the readiness gate now fails the build if the stronger phrase comes back. The number did not change. What it means did, and the second meaning is the one an allocator can act on.

Answering a ticker with no key

The listing state is on the keyless /public-api surface, so the ticker question runs from a fresh clone with nothing installed:

$ git clone https://github.com/edycutjong/shelfware.git && cd shelfware
$ python3 -m shelfware MS

  MS  Morgan Stanley · stock · rwa_rank 43 · has_tokens: true
      ▒ wMSx  Wrapped Morgan Stanley Tokenized Stock (xStock)
          issuer   Backed Assets
          chain    X Layer  0x2874A11805783324C54562eDB1A641C5d1d077a5
          price    null · market_cap null · volume_24h null
          status   UNTRACKED      ← /public-api/v1/cryptocurrency/map, live, keyless, 0 credits
                   listed 2026-08-11 (date_added) · 38 days on the shelf

  0 of 1 wrapper(s) with a CMC-tracked market

receipt: cmc/map symbol=wMSx → HTTP 200 · keyless · 0 credits to any key · 491 ms · sha256 d7e1ecdef293e6c8

The roster leg (tokens[]) is keyed, so without a key it comes from the committed snapshot and says so on the row; the state leg is live regardless. Every answer ends in a receipt line — endpoint, HTTP status, credits, body hash — because a number with no receipt is an opinion.

Numbers, briefly: the whole keyless question is p50 552 ms, p95 603 ms (n=9); the join over the 1,435 committed wrappers is 1.94 ms. 262 tests, 245 of them offline in about a second, engine coverage gated at 100%. A daily snapshot gives the shelf a time axis; day 5 recorded the first movement — MXL flipped active → untracked — and the page names it.

Where it breaks

untracked is a listing state, not a claim about every venue. See above; it is the whole point.
The RWA family is keyed. Keyless callers get a dated roster and a live state.
CoinMarketCap's map rejects its own dotted symbols (NVDA.D, AI.FRx — 38 wrappers, HTTP 400 for the whole call). Those rows fall back to the coarser /v2/cryptocurrency/info vocabulary, and each row names which source answered.
4 wrapper ids in tokens[] resolve on no public CoinMarketCap surface. Shown in their own bucket, never counted as shelf.
The anonymous tier is per IP; a shared cloud egress can be refused outright. The CLI backs off, answers from the snapshot, and exits 75.
It is a daily series, not a history. Untracked rows carry no dates; date_added is a listing day, not a market day.

Twelve dated findings for the CoinMarketCap API team — the plan gates, the two vocabularies for one coin's state, the symbol filter — are in FEEDBACK.md at the repo root, each with the evidence that produced it.

If you track tokenised assets, type a ticker at shelfware.edycu.dev and open the evidence drawer — it shows you the raw rows, so you don't have to take my word for the count either.

Twice the workers, 14% faster, three broken calls: what a 110-call map taught me about API latency

Edy Cu — Tue, 22 Sep 2026 05:58:21 +0000

A founder asks "so where are our holders — Korea or the US?" and the honest answer takes 40 seconds to compute. Not because the maths is hard. Because the answer is spread across ~110 API calls, and each one takes about two seconds.

I built Holder Atlas to draw that answer as one world map: type a token, and the countries its top holders reach exchanges from fill in bubble by bubble, read from Nansen's exchange entity labels and a curated exchange → country table. Code is at github.com/edycutjong/holderatlas. This post is about the part that didn't work: the afternoon I doubled the concurrency to make it faster, got 14 %, and got three broken calls for it.

Where 110 calls come from

A map is one atlas() function calling five Nansen endpoints. The first two are cheap and fixed — search/general to resolve the contract (0 credits), tgm/holders twice for the top-100 population and the exchange-custody subset (5 credits each). The cost is in the per-wallet part:

per wallet   = tgm/transfers (CEX-only, newest, 1 cr)
             → transaction-with-token-transfer-lookup (1 cr)
             → "🏦 Upbit: Deposit"
country      = exchanges.json[entity]        # Upbit → KR · Coinbase → US · Binance → global (never placed)

Up to 52 wallets get examined (12 exchange-custody + 40 people), two calls each. Here is the tail of a real cold run for PEPE, pasted from the CLI's --explain output:

117 credits · 110 calls (0 cached) · 57.3s · atlas 241f4d6ce145

calls:
  search/general                             1 calls     0 cr  0 cached  580 ms avg live
  tgm/holders                                2 calls    10 cr  0 cached  1025 ms avg live
  tgm/transfers                             78 calls    78 cr  0 cached  1695 ms avg live
  transaction-with-token-transfer-lookup    29 calls    29 cr  0 cached  2007 ms avg live

107 of the 110 calls average 1.7–2.0 s each. Serially that would be three and a half minutes; with the 4-wide pool the client ships with, under a 5-requests-per-second bucket, the benchmark across four tokens came out at cold p50 40.3 s, p95 59.0 s (warm p50 7 ms — every call is cached for 24 h and a warm map costs 0 credits).

Forty seconds is a long time to watch a map fill. So the obvious idea: widen the pool.

The experiment: 8-wide under 10 rps

Same bench script (npm run bench), same four tokens, one cold run each, DEFAULT_CONCURRENCY 4 → 8 and the rate bucket 5 → 10 rps. Nansen's documented cap is 300 requests per minute, so 10 rps is fine for one map in isolation. Results, side by side with the defaults:

	4-wide / 5 rps (2026-09-18)	8-wide / 10 rps (2026-09-22)
cold p50	40.3 s	34.5 s
cold p95	59.0 s	58.1 s
failed calls	0 / 444	3 / 441
warm hash = cold hash	4 / 4 tokens	3 / 4 tokens

p50 improved by 14 %. p95 did not move — DEGEN on Base took 59.0 s and then 58.1 s. And the wider run produced three failed lookups where the narrow one had none, all on DEGEN, which is also why its warm hash no longer matched its cold hash: a failed lookup isn't cached, so the second run made different calls and got a different picture.

I reverted it. The defaults stay 4-wide / 5 rps, and the comment in the client now says why:

// Nansen's cap is 300/min. 5 rps keeps one ~110-call atlas inside it with headroom for a second visitor; the rolling
// 300/min window is the hard stop for a third. Measured 2026-09-22 (docs/BENCH.md): 8-wide under 10 rps only moved
// cold p50 40.3 → 34.5 s and introduced 3 failed calls in 441 — per-call latency, not the pool, is the ceiling.
this.limiter = new RateLimiter(opts.rps ?? 5, opts.rpm ?? 300);

The mental model I had wrong

I was treating the map's latency as a throughput problem: N calls, W workers, finish in N/W × per-call time. Double W, halve the time.

That model has two holes when the per-call time is 2 s and the server is the one doing the work.

First, the long pole isn't average-shaped. A map's wall-clock is dominated by its slowest handful of calls — tgm/transfers with a to_address filter over a year of a high-volume token is the slow one, and it stays slow no matter how many siblings run beside it. Widening the pool compresses the middle of the distribution and leaves the tail exactly where it was. That is what "p50 −14 %, p95 flat" means.

Second, concurrency isn't free on the server side either. The client only reports a call as failed after an 8 s timeout and one retry (which also covers 429 and 5xx), so each of those three failures held a worker for up to ~17 s before giving up — and the same lookups had succeeded at 4-wide four days earlier. The bench doesn't record which of timeout/429/5xx each one was, so I won't claim it. What it does record is that the extra width partly paid for itself in failures.

The honest statement is in the DX report I wrote for Nansen alongside the repo: latency is the product's ceiling, and it lives in the per-call time, not the client. The only thing that would make this a five-second experience is a batch endpoint — N transaction hashes in, N labelled transfers out. Nansen has counterparties/batch; a transfer-lookup/batch would do it. That is a wish, not a workaround.

What did survive the experiment: the rolling 300-per-minute window. The old client only had a per-second bucket, which would happily let two concurrent visitors blow through Nansen's documented per-minute cap. The experiment introduced a second sliding window, and it's kept as a hard stop:

/** Two sliding windows: at most `rps` requests per rolling second AND at most `rpm` per rolling minute. */
class RateLimiter {
  private timestamps: number[] = [];
  constructor(private rps: number, private rpm: number) {}
  async take(): Promise<void> {
    for (;;) {
      const now = Date.now();
      this.timestamps = this.timestamps.filter((t) => now - t < 60_000);
      const lastSecond = this.timestamps.filter((t) => now - t < 1000);
      if (lastSecond.length < this.rps && this.timestamps.length < this.rpm) {
        this.timestamps.push(now);
        return;
      }
      // wait for whichever window is full to open by one slot
      const wait = lastSecond.length >= this.rps ? 1000 - (now - lastSecond[0]) : 60_000 - (now - this.timestamps[0]);
      await new Promise((r) => setTimeout(r, wait + 5));
    }
  }
}

The other thing the same bench run caught: 🏦 is not "exchange"

WLFI's attributable share went from 55.2 % to 3.3 % between the two runs. My first reaction was that the wider pool had broken something. It hadn't. The wallet holding 52 % of the analysed supply — Upbit's internal wallet — had a newer exchange touch by the second run: "🏦 Blockchain.com: Deposit". Blockchain.com wasn't in my table yet, so the biggest wallet on the map fell into "entity not in the table" and the number collapsed. Live data moved; the atlas hash said so (warm hash = cold: yes in both runs, but a different hash on each day).

That was the second time the bank emoji bit me. Nansen puts 🏦 on exchange entities — "🏦 Binance 14", "🏦 Upbit: Deposit", "🤖 🏦 Coinbase" — which is exactly the field this whole product hangs on. But it also puts 🏦 on DEX pools, staking contracts, bridges and aggregators: "🤖 🏦 Uniswap: V3 USD1-WLFI … Liquidity Pool", "🤖 🏦 PancakeSwap: CAKE Staking Pool", "🤖 🏦 OKX: DEX Aggregator". And the label_type: "exchange" filter on tgm/holders returns those too. On CAKE, 5 of the 12 "exchange custody" holders were staking pools.

If you take 🏦 at face value, a swap into a Uniswap pool reads as "this person used an exchange whose country I don't know" — grey, but the wrong kind of grey — and a staking contract gets counted as exchange custody in the denominator. The fix is to read the name, and to let a real exchange always win:

/**
 * Nansen puts 🏦 on DEX pools, staking contracts and bridges too ("🤖 🏦 Uniswap: PoolManager V4", "🤖 🏦 PancakeSwap: CAKE
 * Staking Pool"). A 🏦 label that names no exchange in the table AND reads as a pool/contract is not
 * an exchange trace at all; the caller treats such a transfer as "no exchange trace" instead of "entity not in the table".
 * A table exchange always wins ("🏦 Binance: Bridge" is still Binance).
 */
export function isDexOrContractEntity(label: string | null | undefined): boolean {
  if (!label || !label.includes(EXCHANGE_MARK)) return false;
  if (exchangeOf(entityKey(label))) return false;
  return STRUCTURAL_TAG.test(label);
}

And in the engine, a "custody" holder that turns out to be a pool leaves the denominator entirely rather than being placed as global:

if (contractLabel) {
  // the "exchange" holder is a pool / staking / bridge contract wearing Nansen's 🏦: structural, out of the denominator
  row.kind = "structural";
  row.share = 0;
  row.bucket = "untraced";
  emit({ type: "reclass", row, reason: `lookup: ${contractLabel} is a pool/contract, not exchange custody` });
} else if (!label && onlyDexParties(transfers)) {
  // the exchange-filtered transfer was a swap or a stake (Nansen marks DEX pools 🏦 too): no exchange trace, not a table gap
  row.bucket = "untraced";
}

Every label spelling seen live — "Upbit", "Upbit : Link Wallet", "Upbit: Internal Wallet", "Coinbase Prime: Custody Wallet", the ones with invisible U+200B prefixes — is pinned in labels.test.ts. 220 tests, 100 % coverage on the core package, plus 24,000 generated property cases that check things like "global is never attributed" and "structural never enters the denominator".

What it still doesn't do

Solana can't be named. The transfer lookup has no Solana support, so Solana tokens show 0 % placed with a banner saying which field is missing.
Supply-weighted means whales decide. 86 % of LINK's analysed supply is one 2017 team wallet with no exchange trace, so LINK reads 4 % placed; the by-wallet share (44 %) prints beside it for exactly this reason.
Countries are exchange jurisdictions, not people. Coinbase → US, Revolut → GB by licence. Binance, OKX, Bybit are global and stay grey on purpose — 47 % of PEPE's analysed supply is that grey bar.
It's still 40 seconds cold. That is the point of this post.

Try it on a token you care about — holderatlas.edycu.dev — and open the provenance drawer to see every one of the ~110 calls with its latency. The repo is github.com/edycutjong/holderatlas; the benchmark that produced every number above is docs/BENCH.md, and the DX report with all nine frictions is docs/DX-REPORT.md. Built for Nansen's Meridian buildathon.

I claimed my gas refunds were exact. An audit found the 21,000 I was crediting twice.

Edy Cu — Mon, 21 Sep 2026 09:36:29 +0000

My README said the gas refund was exact. An audit round the next day showed it wasn't: a contract that batched K orders in one transaction was over-refunded 21,000 × (K − 1) gas. Nobody had exploited it, it was bounded by each order's reserve, and it was still not "exact". This post is the mechanism, the mistake, the fix, and the receipts that stayed in the repo.

Live: https://legwork.edycu.dev/ (reviewer path: /#/judge)
Repo (MIT): https://github.com/edycutjong/legwork
2:17 video of a real create → execute on Arc mainnet: https://youtu.be/YPUbDlJc1lY

Why recurring payments need a keeper network (everywhere else)

A standing order on-chain needs someone to call it when it's due. Whoever does pays gas. To make that worth their while you have to repay them — and on any chain where gas is ETH and the app's money is an ERC-20, repaying gas in the payment asset needs a price oracle, and finding executors needs a keeper network. That is the whole reason automation protocols exist.

On Arc, gas is USDC, with 18-decimal msg.value. The payment and the fee are the same dollar. So the contract can meter the gas it used, multiply by tx.gasprice (already USDC), and pay it back from the order's own deposit — in the same transaction, with no oracle and no keeper network. Anyone can run a due order and nets exactly the tip.

Legwork is that contract, live on Arc mainnet at 0x8E2F8AFC29e9dc127103CD6AD5BCfBe661141ccb.

How the meter works

execute(id) reads gasleft() on its first statement, does the work, and reads it again at a fixed measurement point after which nothing of variable cost runs. Everything outside that window — intrinsic gas, calldata, the payout call, the event, one tstore — is a constant, OVERHEAD, calibrated on mainnet and baked in as an immutable:

function execute(uint256 id) external {
    uint256 g0 = gasleft();                                                     // 1  first statement
    if (_lock != 0) revert Reentrant();                                         // 2  guard (transient)
    _lock = 1;
    Order storage o = orders[id];                                               // 3  load + checks
    if (o.payer == address(0)) revert NoOrder();
    if (o.paused) revert IsPaused();
    uint48 nextDue = o.nextDue;
    if (block.timestamp < nextDue) revert NotDue(nextDue);
    if (_txSeen == 0) { _txSeen = 1; g0 += INTRINSIC_GAS; }                     //    intrinsic credited to the first execute of a transaction only
    uint256 price = tx.gasprice;                                                // 4  price = min(gasprice, 2·basefee, maxGasPrice)
    if (price > block.basefee << 1) price = block.basefee << 1;
    if (price > o.maxGasPrice) price = o.maxGasPrice;
    // … pre-check, effects, pay the payee (a refused payment pauses the order instead of reverting) …
    uint256 metered = g0 - gasleft() + (OVERHEAD - INTRINSIC_GAS);              // 9  measurement point
    if (metered > REFUND_CEIL_GAS) metered = REFUND_CEIL_GAS;
    uint256 refund = metered * price;                                           // 10 bounded by the deposit
    if (refund > deposit) refund = deposit;
    o.deposit = uint128(deposit - refund);                                      // 11
    (bool ok,) = msg.sender.call{value: refund + tip, gas: EXECUTOR_GAS}("");   // 12 repay + tip, one call
    if (!ok) revert PayoutFailed();
    emit Executed(id, msg.sender, metered, price, refund, tip, nextDue, paid); // 13 fixed width on both branches
    _lock = 0;                                                                  // 14
}

The price is capped at min(tx.gasprice, 2 × basefee, maxGasPrice) so an executor cannot drain a deposit by choosing an absurd gas price, and the refund is capped at REFUND_CEIL_GAS and at the deposit itself.

Then you check it against reality. The transaction receipt has gasUsed and effectiveGasPrice, neither of which the contract can see. If metered == gasUsed and price == effectiveGasPrice, the refund equals the real fee to the wei. That difference — gasUsed − metered — is what I call drift.

The line if (_txSeen == 0) { … } is the fix. It wasn't there in v1.

What v1 got wrong

The transaction's intrinsic 21,000 gas is paid once per transaction. v1 credited it once per call. For a wallet calling execute directly that's the same thing, and every test and every mainnet run said drift 0. But a contract that batches several orders in one transaction pays the intrinsic once and would have been refunded it K times.

Bounded? Yes — a refund can never exceed the order's reserve. Exploited? No — the only executors were my own two wallets. Exact? No. And "exact" was the word in the README's first paragraph.

v2 tracks it in transient storage: the first execute in a transaction claims the intrinsic, later ones in the same transaction don't. The regression test runs two orders through a batching contract and checks the second call's metered figure is the first's minus 21,000 (plus the one tstore the first call paid):

function test_execute_batchedExecutorIsChargedTheIntrinsicOnce() public {
    // two orders to two existing, cold payees; a batcher runs both in one transaction
    address p1 = makeAddr("p1"); address p2 = makeAddr("p2");
    vm.deal(p1, 1); vm.deal(p2, 1);
    uint256 a = _create(p1, 0.01 ether, 60, 0.01 ether, 100 gwei, 0.05 ether);
    uint256 b = _create(p2, 0.01 ether, 60, 0.01 ether, 100 gwei, 0.05 ether);
    Batcher bt = new Batcher(lw);
    uint256[] memory ids = new uint256[](2); ids[0] = a; ids[1] = b;
    vm.recordLogs();
    bt.go(ids);
    Vm.Log[] memory logs = vm.getRecordedLogs();
    (uint256 m1,,,,,) = abi.decode(logs[0].data, (uint256, uint256, uint256, uint256, uint48, bool));
    (uint256 m2,,,,,) = abi.decode(logs[1].data, (uint256, uint256, uint256, uint256, uint48, bool));
    // the second call's metered figure is the first's minus the 21,000 intrinsic (and minus the one tstore the first paid)
    assertGe(m1 - m2, 21_000 + 100, "intrinsic credited once per transaction (plus the one tstore the first call paid)");
    assertLe(m1 - m2, 21_000 + 300, "nothing else differs between the two calls");
}

The change is inside the measured window, so OVERHEAD didn't move. v1 (0x68a92aF2Be2e6A640a19508a0fe44cbc8B2C62E2) had its demo orders cancelled and holds nothing — but its 36 execute receipts stay in proof/receipts/ and are still re-checked by npm run recheck, next to the 36 from v2. Deleting them would have made the repo look cleaner and the claim weaker.

It was not the only correction that day. OVERHEAD was estimated at 31,400 before the first deploy; three calibration runs on mainnet measured 32,503 — under by exactly 1,103 on all three, spread 0. The wrong number stays visible in the deploy record. And the paused branch (payee refuses the payment) meters 6 gas over, so on that path the executor is over-refunded by 6 × 20 Gwei — about a hundred-millionth of a dollar, and it's documented rather than hidden.

The numbers, after the fix

30 consecutive mainnet executes on the production contract (25 by the payer's wallet, 5 by the payee collecting its own payment):

refund ÷ real fee = 1.000000 on all 30 rows (the pre-stated invariant was 1.00 ± 0.02)
drift = 0 gas on every row
gasUsed p50 = p95 = 58,415 (the payee-as-executor rows are 55,915 — the payee is tx.origin and already warm, and the meter caught that too: drift 0)
tx.gasprice == effectiveGasPrice on every row, 20 Gwei

There is no randomness to seed and no warm-up to discard: each run is its own transaction. The 107 committed receipts are recomputed from raw chain data by npm run recheck, which exits non-zero on any drift outside the documented −6…0 window.

Why the retraction is the point

The engineering interest here is small: one transient flag. The reason I'm writing it up is that "exact" is a claim you can only make after you've gone looking for the case where it isn't — and the case was a contract executor I hadn't built, running a batch I hadn't imagined, against a README I had already written. If your refund logic has never been called from a contract, it hasn't been tested for the intrinsic.

Honest limitations

Executors so far are my own two wallets. Nobody else has run an order yet.
Every bench row sits at Arc's 20 Gwei base fee; the 2× cap is exercised by tests and one capped receipt, not by the bench.
Explorer source verification wasn't possible (the API is behind a challenge page); the on-chain runtime bytecode is checked byte-for-byte against forge build instead.
This is a modifier for one contract's payouts, not an automation network. It doesn't schedule anything for you; it makes it worth someone's while to call you.

Proof

Contract on Arc mainnet (chain 5042): 0x8E2F8AFC29e9dc127103CD6AD5BCfBe661141ccb · OVERHEAD() = 32503
The run in the video: https://explorer.arc.io/tx/0x2b33e38f8404b12be1c07706c196991a05da1824ab08ea1b95f833c6cd6ad255 — 58,415 gas × 20 Gwei refunded, drift 0
42 Foundry tests (34 unit · 2 fuzz × 512 · 6 invariants), 36 vitest incl. 20,000 fast-check property cases, Playwright end-to-end with live mainnet reads

Live page: https://legwork.edycu.dev/ · repo: https://github.com/edycutjong/legwork

If you've shipped gas-refund logic on any EVM and metered it differently, I'd like to compare notes.

A USDC deposit address with no private key — and the 9,999-block RPC cap that almost froze it

Edy Cu — Mon, 21 Sep 2026 09:34:41 +0000

Every deposit address an exchange hands out is a private key someone has to generate, store, guard and eventually sign a sweep with. I built a deposit address that has no key at all — and then, the evening before submitting it, found out the live page would have frozen at "UNPAID" a few hours after deploy.

This is the mechanism, the bug, and what pinned it.

Live: https://pigeonhole.edycu.dev/ (reviewer path: /#/judge)
Repo (MIT): https://github.com/edycutjong/pigeonhole
2:30 video of a real cycle on Arc mainnet: https://youtu.be/BGuzotTXQEA

A deposit address with no private key

Pigeonhole runs on Arc, Circle's L1 where USDC is the native balance — it pays for gas, and a plain value transfer moves it. That one fact makes an old Ethereum trick work for a stablecoin.

The factory holds an immutable treasury. For any invoice, salt = keccak256(invoiceId), and the deposit address is the CREATE2 address of a 22-byte throwaway whose entire code is PUSH20 treasury; SELFDESTRUCT:

/// @notice The sweeper init-code, derived from the immutable treasury.
function initCode() public view returns (bytes memory) {
    return abi.encodePacked(hex"73", treasury, hex"ff");
}

/// @notice The deterministic deposit address for `salt` (offline-reproducible).
function predict(bytes32 salt) public view returns (address) {
    return address(
        uint160(uint256(keccak256(abi.encodePacked(hex"ff", address(this), salt, keccak256(initCode())))))
    );
}

That address is handed out before anything is deployed. It has no code, no nonce and no key. Because USDC is Arc's native balance, sending to it just works — EXTCODESIZE == 0 is fine for a native send, and Arc's system emitter (0xffff…fffE) logs the movement as a Transfer.

When anyone calls sweep(salt), the factory CREATE2-deploys the throwaway. Its constructor is the SELFDESTRUCT, so the whole balance moves to the treasury inside the deploy transaction, and EIP-6780 deletes the account again because it was created in the same transaction:

/// @notice Sweep the pigeonhole for `salt` to the treasury. Permissionless; funds can only reach `treasury`.
function sweep(bytes32 salt) public returns (address deployed) {
    address expected = predict(salt);
    uint256 bal = expected.balance;
    bytes memory code = initCode();
    assembly {
        deployed := create2(0, add(code, 0x20), mload(code), salt)
    }
    if (deployed != expected) revert Create2Mismatch(expected, deployed);
    emit Swept(salt, expected, bal);
}

The address is empty and reusable afterwards. A balance-moving sweep on the production factory is 64,162 gas at p50 over 25 bench rows, about $0.0013 at Arc's 20 Gwei floor.

On every other EVM chain, USDC is an ERC-20. SELFDESTRUCT cannot move an ERC-20 balance, and a native send to a codeless address leaves no log. So the pattern is either impossible or blind everywhere else. On Arc it is both possible and observable.

No backend: PAID and SWEPT are one log filter

There is no database. PAID is "the system emitter has a Transfer with to == pigeonhole", SWEPT is "…and a Transfer with from == pigeonhole that took the balance to zero". The invoice is its URL.

Which means the entire product stands on eth_getLogs. That is where it nearly fell over.

The wall: 9,999 blocks

Day-2 code walked the full history in one call. It worked in every test and in every manual run, because the factory was hours old.

The pre-submission audit asked a boring question: what does the public RPC actually allow? The answer, measured on 2026-09-17: a span of 9,999 blocks is fine; 10,000 is rejected with -32012 requested range too large. Arc produces roughly two blocks a second. 9,999 blocks is about 85 minutes of chain.

So the page would have kept working for the rest of the afternoon, and then, for every invoice older than ~85 minutes, every refresh would have thrown, and the UI would have sat on "UNPAID" forever — for a paid invoice. The demo I had planned to record the next morning would have been the first thing to break.

The fix is unglamorous: chunk every scan, poll incrementally, and carry the invoice's creation block in its URL (?from=) so a scan never starts at the factory's genesis when it doesn't have to.

// Chunked, incremental eth_getLogs over the EIP-7708 system emitter.
// The public Arc RPC rejects any eth_getLogs span of 10,000+ blocks with -32012 "requested range too large"
// (measured 2026-09-17: 9,999 ok, 10,000 rejected). At ~2 blocks/s that is ~85 minutes of chain, so every
// scan must be chunked and every poll must be incremental — a fresh full-history scan per refresh is not viable.

/** Largest span the RPC accepts, with headroom (9,000 < 10,000). Exported so the test can pin it. */
export const MAX_LOG_SPAN = 9_000n;

/** Yields [from, to] inclusive spans, each ≤ MAX_LOG_SPAN blocks wide, covering from..to. */
export function* spans(from: bigint, to: bigint, max: bigint = MAX_LOG_SPAN): Generator<[bigint, bigint]> {
  for (let start = from; start <= to; start += max) {
    const end = start + max - 1n > to ? to : start + max - 1n;
    yield [start, end];
  }
}

The walk itself is sequential and paced, because the same RPC also rate-limits bursts, and it reports every completed chunk so the caller can checkpoint:

export async function fetchMovements(client: LogClient, pigeonhole: Address, fromBlock: bigint, toBlock: bigint,
  onChunk?: (moves: Movement[], chunkEnd: bigint, progress: Progress) => void): Promise<Movement[]> {
  const out: any[] = [];
  const all = [...spans(fromBlock, toBlock)];
  for (let i = 0; i < all.length; i++) {
    const [a, b] = all[i];
    if (i > 0) await paced(client);
    const ins = await withRetry(() => client.getLogs({ address: ARC.systemEmitter, event: transferEvent, args: { to: pigeonhole }, fromBlock: a, toBlock: b }));
    await paced(client);
    const outs = await withRetry(() => client.getLogs({ address: ARC.systemEmitter, event: transferEvent, args: { from: pigeonhole }, fromBlock: a, toBlock: b }));
    out.push(...ins, ...outs);
    onChunk?.(toMovements([...ins, ...outs]), b, { done: i + 1, total: all.length, toBlock: b });
  }
  return toMovements(out);
}

Checkpoints go to localStorage, so a returning visitor never re-walks what they already read. The two seeded demo invoices ship a committed, receipt-verified checkpoint in the repo so they open in seconds.

And it is pinned, because "fixed the same evening" is worth nothing without a test that fails if someone bumps the constant:

it("no span ever reaches 10,000 blocks, and the spans tile the range exactly", () => {
  const out = [...spans(21_337_182n, 21_337_182n + 250_000n)];
  expect(out.every(([a, b]) => b - a + 1n <= MAX_LOG_SPAN && b - a + 1n < 10_000n)).toBe(true);
  expect(out[0][0]).toBe(21_337_182n);
  expect(out.at(-1)![1]).toBe(21_337_182n + 250_000n);
  for (let i = 1; i < out.length; i++) expect(out[i][0]).toBe(out[i - 1][1] + 1n);
});

Two more tests cover a 250k-block history fetching without -32012, and overlapping polls never double-counting a log (keyed by tx:logIndex — the RPC is load-balanced, and two backends can disagree about the head).

What I took from it

The mental model that was wrong: "a view call is free, so ask for everything." Log queries are not views. Every public RPC has a span cap and a rate, they are rarely in the docs, and they only bite once the chain has moved on without you — which is exactly the window between "demo recorded" and "reviewer opens the link".

The audit question that found it was not clever. It was "what are the limits of the one external thing this depends on, measured, not assumed." I now ask it on day one.

Honest limitations

The page needs an anonymous Arc RPC and reads history at the rate that RPC sustains (measured ≈ 0.5 eth_getLogs/s). An invoice URL without ?from= scans from the factory's deploy block — about 38 calls per day of chain — so the first read of an old invoice takes minutes. Progress is shown and never repeated, but it is minutes.
PAID latency is not benchmarked.
The treasury is immutable: a single point of failure, by design. There is no beneficiary rotation; the remedy is a new factory.
The factory's source is not verified on the explorer (its API sits behind a challenge page). The on-chain runtime code is byte-identical to forge build output — keccak 0x8806de8d… — and that check is in the repo.

Proof, if you want to check

Factory on Arc mainnet (chain 5042): 0x942b8c102e73aeea1a652ebC8F2d319fD08D9A40
The pay in the video: https://explorer.arc.io/tx/0x25658c68c396ff1c89ea8cb1f0d84e5263ab3694f39e11baf596db203614448a
The sweep in the video (64,162 gas): https://explorer.arc.io/tx/0x423e71bb29e183f4875ad145db121ae1658bcf9205dc6c99548b90233ab941e6
12 Foundry tests, 25 vitest incl. 20,000 fast-check property cases, 34 Playwright checks read-only against mainnet; npm run verify checks the offline CREATE2 arithmetic against the on-chain predict() for 50 random ids.

Live page: https://pigeonhole.edycu.dev/ · repo: https://github.com/edycutjong/pigeonhole

If you run deposit infrastructure and this pattern would or wouldn't work for you, I'd genuinely like to hear why.

Four numbers, five labels: how far can you read a crypto wallet without a model?

Edy Cu — Sun, 20 Sep 2026 12:47:16 +0000

You have read "Smart Money is buying" in forty tweets this month. Could you point at a Smart Money wallet if one were on your screen — no label, just the numbers?

I couldn't. So I built a card game to find out how much of a wallet's label is actually visible in its numbers, and then I wrote the dumbest possible reader — one page of thresholds, no model, no LLM — to see how far "reading a wallet" goes before it stops being a skill and starts being a lookup.

Play it: labelme.edycu.dev · code: github.com/edycutjong/labelme

The game, in one card

Ten real ethereum wallets. Each card shows four things Nansen computes for the address over the last 30 days — PnL, top trades, balance profile, counterparty mix — and five chips: Smart Money · Exchange · Whale · Contract / Pool · Regular. You pick one. The reveal is Nansen's own label group for that wallet, plus a one-line tell written from the card's numbers.

Here is card 1 of the round I recorded, straight from the CLI (npm run labelme -- play --seed meridian1933 --answers):

Wallet 1 of 10 · ethereum
PnL 30d    realised +$12K · win rate 67% · 472 trades · 6 tokens · top: GIVE 4%, GULD 3%, ETH 3%, WIN -10%, ELMT -13%
Trades     GIVE +$6.6K (113b/44s) · GULD +$5.4K (67b/113s) · ETH +$2 (2b/5s) · WIN −$68 (48b/9s) · ELMT −$87 (22b/48s)
Balance    10 tokens · $14K · top GULD 86% · stables 0%
Counterp.  9 in 30 d · 472 interactions · top outflow 51% · DEX 97% · wealth-tagged 0% · contracts 0% · unlabelled 3%
→ Smart Money
tell: 472 trades in 30 d · win rate 67% · realised $12K across 6 tokens · 97% of flow through DEX pools and routers — a trader Nansen tracks as Smart Money

The important design decision is that the answer key is not my opinion. A card is Smart Money because the address came back from tgm/holders with label_type: "smart_money", or from smart-money/dex-trades. It is an exchange because it came back from the exchange filter. It is Regular because it came back from tgm/who-bought-sold with all seventeen of Nansen's label groups excluded — an honest negative, "none of the groups", not a positive identification. Every clue on the face is a field from one of four profiler calls. If Nansen is wrong, the card is wrong, and the reveal says exactly which call decided it.

The house rule: one page of thresholds

Once the deck existed, the obvious question was: how much of this can a rule read? Not a classifier — a rule a player can read, argue with, and beat. This is the whole thing, from packages/core/src/reader.ts:

export const READER = {
  /** a pool: traffic without a trader, and few tokens (a two-sided pool holds two) — exchange hot wallets have traffic AND 20–100 tokens */
  contract: { minInteractions: 2000, interactionsPerCounterparty: 20, maxTokens: 20 },
  /** an exchange: big, many tokens, no DEX trades; either its counterparties are wealth-tagged/exchange wallets or it simply holds 50+ tokens */
  exchange: { minUsd: 10_000_000, maxTrades: 5, minTokens: 15, minWealthMix: 0.5, manyTokens: 50 },
  /** a whale: one position is most of a $1M+ balance and it barely trades */
  whale: { minUsd: 1_000_000, minTopShare: 0.8, maxTrades: 10 },
  /** Smart Money (active): many trades across many tokens in 30 days — win rate and sign of PnL do NOT separate it from a regular buyer on this deck */
  smartMoney: { minTrades: 25, minTokensTraded: 6 },
} as const;

The reader runs those in order — contract, exchange, whale, Smart Money, else Regular — and returns a guess with a sentence:

const traffic = k.interactions >= R.contract.minInteractions || (k.countCapped && perCp >= R.contract.interactionsPerCounterparty);
if (traffic && b.tokens < R.contract.maxTokens)
  return {
    guess: "contract",
    because: `${k.interactions} interactions from ${k.count}${k.countCapped ? "+" : ""} counterparties and only ${b.tokens} tokens — traffic, not trading`,
  };

On the 62-card deck it reads 50/62 — 81%. On ten fresh draws it had never seen (the benchmark, docs/BENCH.md), it read 7/10. After every round the score screen shows the house rule's score next to yours. That's the bar.

What the thresholds taught me

Two things I believed going in were wrong, and the deck said so.

Win rate does not identify Smart Money. I assumed the tell would be "wins more". It isn't. On this deck, a Smart Money wallet's win rate and the sign of its PnL do not separate it from a regular buyer who got lucky on one token. What separates it is breadth and tempo: 25+ trades across 6+ tokens in 30 days. Smart Money, as Nansen labels it, looks like a job, not a streak.

Exchanges are not "big wallets". Whales are big wallets. An exchange hot wallet is big and holds 15–100 tokens and barely trades on DEXes and — the clue that surprised me — its counterparties are themselves wealth-tagged or exchange-labelled wallets. Money moves in and out; nobody is trading. Card 2 of the recorded round is a $9.4B Binance wallet whose 30-day PnL is exactly $0.

Where the rule fails — and why that's the game

The confusion matrix on the deck, rows are truth:

truth \ guess	smart-money	exchange	whale	contract	regular
smart-money	10	0	0	0	2
exchange	0	14	1	0	1
whale	0	0	11	1	0
contract	1	0	0	3	6
regular	0	0	0	0	12

The rule is nearly perfect on Regular and good on Smart Money, exchanges and whales. It is bad at contracts: 6 of 10 read as Regular. A dormant proxy or multisig — zero counterparties in 30 days, a handful of tokens, no trades — has no numbers, and "no numbers" is what Regular looks like too. A Bybit wallet holding eight tokens reads as a whale. A "Token Millionaire" with 5,019 trades reads as a contract, because that much traffic from few counterparties is what a pool looks like.

Those twelve cards are the hard ones, and a human can beat the rule on them — that's what makes it a game rather than a demo. The rule doesn't know that a $165K balance in one MOG position with zero activity is more likely a proxy than a person, because the rule has no priors. You do.

Building it so it can't break on camera

The deck was recorded once, live, by scripts/seed.ts: 163 candidate addresses from the sourcing calls, 101 dropped with a reason (100 of them for being in Nansen's Public Figure group — a person label is not a wallet behaviour, and the class turned out unreadable from clues), 62 dealt. Every raw response is committed. Each card carries a sha256 of {address, chain, class, nansenLabel, entity, clues, tell}, so npm run verify replays all 62 offline and fails if a clue, a tell or an answer drifts. The default round makes zero network calls and costs zero credits. Only "Draw fresh" is live — one sourcing page and four clue calls, about 12 credits, cold p50 2.1 s, streamed to the page as each call lands.

134 tests, 100% statement/branch/function/line coverage on the engine, 12,000 property-based cases on the reader (it must be total over any clues, the tell must be one line, the hash must ignore time).

Honest limits

Free-tier labels are wealth and structural tags (Token Millionaire, MultiSig), not entity names. An entity name (🏦 Binance) appears only where a 1-credit transfer lookup found one — 23 of 62 cards.
"Regular" is a negative. It means Nansen filed the wallet in none of its groups, not that it's a retail trader.
A dormant Smart Money wallet is unreadable from cheap clues; the deck keeps only active ones. A live draw can still deal one, and says so.
Ethereum only. The 30-day window is a snapshot from 2026-09-18.
The house rule's thresholds were set by looking at this deck. The 7/10 out-of-sample number is the honest one; the 81% is not.

The round in this post is shareable: labelme.edycu.dev/r/meridian1933 — same ten cards for everyone. I got 7/10, which is exactly what the rule got. If you beat it, I'd genuinely like to know which of the hard cards you read right.