A token promised up to 4x leverage on SOL and delivered a realized beta of 2.91. It worked exactly as advertised, every day, for 309 days.
$1,000 in it became $56.68.
Six measurements, six windows I did not choose. https://t.co/gX8GLLQnfJ
Twelve providers answer to Claude Sonnet 5.5 today. Two days ago I wrote that names sitting one version above the current one do not resolve. This one resolves.
That post checked five model names going round as a leak. None of them was in the registry, and each sat exactly one step above something that was. The shape looked like a rule.
It is not a rule. It is a test, and Sonnet 5.5 passes it.
Read the same registry now and the provider counts line up in a way worth knowing:
Sonnet 4.5, forty-two providers. Sonnet 4.6, fifty-one. Sonnet 5, thirty-nine. Sonnet 5.5, twelve.
Twelve is the number that matters. A name nobody shipped sits at zero, and it stays at zero however many screenshots go round. A model that shipped this week sits in the low dozens and climbs as the rest of the catalogue picks it up. An established one sits in the forties.
The twelve are not obscure either. Anthropic itself, Amazon Bedrock, Google Vertex, Azure, OpenRouter, Vercel.
So the thing to carry forward is not that current plus one is fake. It is that current plus one is checkable, and the check takes one request. Zero means somebody made it up. Twelve means you are early.
The file is https://t.co/OdH3gnyl9Y slash api.json. It is public, it is one fetch, and it answered both of these questions in the time it takes to read this post.
faster-whisper for the ears, Kokoro for the mouth, Obsidian for the memory. Everybody stops counting there. The fourth part is Claude, and Claude is not on your machine.
That is the wiring diagram of a self-hosted AI assistant, and it is worth saying plainly, because the parts list reads so much better than the sum.
The first three are genuinely yours. faster-whisper turns the microphone into text without opening a socket. Kokoro turns text back into speech the same way. A folder of Obsidian markdown holds everything the thing knows, linked as a graph, no database, sitting on your disk. Skills are folders too, each with a file describing what it does, loaded only when needed.
Then the request leaves the building. The router can match a regex or wake a small local model, and past a certain difficulty it calls an API. The component that reads your notes and decides what to do about them is rented by the token.
What you have built is an excellent local interface to a remote brain. That is worth having. Transcription that works on a plane, notes nobody can revoke, a voice that answers with the network down.
The word local is doing two jobs in that sentence. It describes where the files live, and it gets heard as describing where the thinking happens. Only the first one is true.
There is a one-line test. Pull the network and ask it something hard. Whatever still answers is the part you own.
126,537 stars. A Chinese developer's tool passed 100,000 while people were still writing posts that said 100,000.
It is called MoneyPrinterTurbo, and it builds a short video from one line of input.
You give it a topic. It runs the whole chain:
1. Writes the script.
2. Generates the voice.
3. Cuts the subtitles.
4. Finds the footage.
5. Assembles the finished file.
You supply the idea. It supplies everything downstream of the idea.
The repo is harry0703/MoneyPrinterTurbo, MIT licensed, and it was pushed today. Both numbers above came from the GitHub API rather than from the screenshot, and you can pull them the same way in one request.
Someone posted a $246,578 profit claim this weekend and did the rare thing: named the account. That makes it checkable, so I checked it.
It holds.
The profit curve for pspspsps5 runs 299 days. It starts on 4 December at minus three dollars, passes $102,703 on 1 June, reads $243,939 on the day the post went out and $249,038 today. The claimed figure sits between those last two, which is what an intraday screenshot looks like.
170,191 trades. For scale, the account at the top of Polymarket's all-time profit board has made fourteen.
The strategy description survives too. Every trade I can see is a buy on a five-minute Solana up-or-down market, a couple of dollars at a time, both outcomes, never closing.
Now the part I cannot check, and why it matters.
The activity endpoint stops at 5,000 rows. That is 3.2% of this account's history, all of it from the last two days. In that window the average trade is about five dollars, not the $23.59 in the post.
That sounds like a contradiction. Do the arithmetic and it is the opposite.
At $23.59 across 170,191 trades, lifetime volume is $4.0m and the profit is 6.2% of it. At five dollars, volume is $0.85m and the profit is 29% of it. Nobody market-makes five-minute contracts at a 29% take. The larger number is the one that makes the result possible, so the honest reading is that the account has scaled down recently and the post's figure comes from a window I am not allowed to see.
One thing nobody mentioned. The profit is $249,038 and the account currently holds $1,269. Whatever this thing earned, it is not sitting there.
What I could not reach: the 90% both-sides rate, the 94.5c median pair cost, the 40% imbalance. All three need the full trade history, and the API gives you 3.2% of it.
This guy built an HFT algorithm on Polymarket with an average trade size of $23.59
Result: +$246,578
The bot trades short-term crypto Up/Down markets using dynamic hedging and a directional residual:
1. First buys the outcome its model considers underpriced
It continuously estimates the fair probabilities of Up and Down and compares them with prices on Polymarket
The bot builds a position whenever it detects a mispricing
2. Buys the opposite side when the signal changes
If the underlying asset reverses, it does not close its initial position. Instead, it starts accumulating the opposite outcome
It bought both sides in 90% of markets
3. Turns part of the position into complete sets below $1
In two-sided markets, the median combined cost of Up and Down is 94.5c
But this is not pure arbitrage
The median inventory imbalance is 40%, so after pairing both sides, the algorithm is left with a directional residual
Its Polymarket account: pspspsps5
You can build your own trading bot here:
https://t.co/JVofcJa07i
(A trial is available after signing up)
The main edge of this HFT algorithm comes from continuously shifting directional exposure as its fair probability estimates change, while purchases of the opposite outcome function either as a hedge or as part of a complete set
Five models are going round this week as a leak. Every one of them is exactly one version number above the highest model that actually exists.
I pulled the public model registry — 223 providers, the same one that carries OpenCode's own listing — and searched for each name.
Kimi K4: nothing. The real top is K3, on 74 providers.
GLM 5.4 and 5.5 Flash: nothing. Real top is 5.3, on 68.
DeepSeek V4.1 Pro: nothing. What exists is V4.1 Flash, on 43.
Muse Spark 1.4: nothing. Real top is 1.3, on 13.
Four unrelated companies. Four version numbers, each incremented by exactly one step.
Now the part that keeps this honest, because it matters. A model that has not shipped is not supposed to be in a registry of models you can call. Absence proves nothing by itself, and if Moonshot ships K4 next week none of the above will have been wrong about K4 existing.
What absence does not explain is the shape. A real leak from four separate labs would not land on current-plus-one for all four. A list generated by reading today's model names and adding a decimal point would.
One of these posts falsifies itself without any of that. It went out on 25 September and says an August launch is reportedly in the plans. It also quotes another post as its source, and that post is about Codex usage limits and does not mention Kimi.
Since the name that got me here was Kimi 2, the registry has the actual line, with dates:
K2 0711 — 11 July 2025
K2 Thinking — 6 November 2025
K2.5 — 27 January 2026
K2.6 — 21 April 2026
K2.7 Code — 12 June 2026
K3 — 16 July 2026
K3 has been out for over two months and sits on 69 providers. The K2 family stopped in June. Anyone still quoting K2 benchmarks is two generations behind, and anyone quoting K4 is one ahead of anything you can call.
I do not know, and that is the honest answer — the video published one total and nothing else.
But I think the two collapse into each other on the invoice. A retry that reached the model is billed like any other call, so from outside a retried call and a genuinely large one are the same input tokens. The field that separates them is the one you already keep: last error. A retry leaves a trace, an expensive call does not.
Your per-comment run is the closest thing to confirmation this has. I priced the shape from published rates; you got the same shape by running it.
A video going round this week says Opus 5 took 34 minutes and $23 to sort 1,400 YouTube comments into five buckets, and that a new model did the same class of job for a cent.
I priced both halves against the published rate cards. The cheap half is honest. The $23 is about 43 times too high.
Opus 5 is $5 per million input tokens. $23 buys 4.6 million of them. Spread over 1,400 comments that is 3,286 tokens per comment. A YouTube comment is 20 to 60 tokens.
Read it the other way and it is worse: at $25 per million output, $23 is 657 output tokens per comment, for a job whose output is one word out of five.
Same job, same model, priced at the card:
1,400 comments -> 50 per call -> 28 calls -> 64,400 input + 8,400 output -> $0.53
Through the Batch API, $0.27.
So the honest version of that slide is not Jev versus Opus. It is Jev versus one particular way of driving Opus: an agent loop that re-reads its own context, one comment at a time, while also writing a CSV and building a dashboard. That is a real cost and he really paid it. It is just not what Opus costs to classify 1,400 comments.
Now the part that goes the other way, because I checked it too.
Every Jev figure in the video holds up. TypeSafe publishes $0.042 per million input tokens, output free. Work backwards from each claim:
250 leads for 1 cent -> 952 tokens per lead
203 members for 1 cent -> 1,173 per member
1,300 posts for 4 cents -> 733 per post
227 call transcripts for 7 cents -> 7,342 per transcript
443 browser screens for 1 cent -> 537 per screen
Those are the right sizes for what each of those things is. A call transcript really is ten times a forum post. Nothing there is rounded in his favour.
So the model is as cheap as he says. The comparison is the thing that is broken, and it is broken in the direction that makes the video's case.
Two assumptions in my arithmetic, stated so you can attack them. I assumed a comment is 20 to 60 tokens, and I priced classification only, while his $23 run also produced a spreadsheet and a dashboard. Halve my estimate or double it and the gap is still two orders of magnitude.
The rule this leaves you with: when a post compares a new tool against an old one, check whether the old one was being used properly. Most of the difference in these threads is not the tool. It is the batching.
Agreed, and that is the harder half. I can only price what somebody already published, and a single total is not falsifiable — $23 reads the same whether it was retries, context regrowth, or the dashboard at the end.
Which is the rule worth taking from it: if you post a cost comparison, post the receipt rather than the total. The four fields you keep are the ones that would settle it before anyone has to do arithmetic from outside.
Your receipt would have caught it. 97.7% of that $23 is not the comments.
The corpus is 28,000 to 84,000 tokens at 20 to 60 a comment. The spend covers 4.5 million input tokens. That is the whole thing read 54 to 160 times over.
What I could price was the job. What I could not price was the run — retries, context regrowth, or the dashboard it built at the end, and the bill looks identical from outside. Per-call spend with the route attached is the only thing that separates them.
Every number in this thread is exactly right. I cloned the repo and counted: 18 skills, 72 commands, 6 subagents, 28 tools, 26 plugins, 15 repos, 12 skills, 10 sections, 5 tracks. Not one is rounded up.
The line worth checking is the one without a number in it.
"6 subagents — 4 of them read only, so nothing rewrites your vault behind your back."
Four is correct. Four of the six carry no Write and no Edit. But three of those four hold only Read, Glob and Grep, and the fourth holds Bash.
Bash writes files. The agent is called graph-analyst, its description says "Read-only", and its prompt says "You analyse the graph and never modify the vault." That is an instruction, not a permission. Three of those four cannot touch your notes. The fourth is asked not to.
That distinction is the whole reason the sentence exists. If you are pointing six agents at years of your own writing, "cannot" and "has been told not to" are not the same guarantee, and only one of them survives a bad prompt.
Two smaller things, both in the repo rather than the thread.
The thread lists five scripts and says plain Python, zero dependencies. All five are standard library — that checks out. But the repo's own README inside that folder calls the whole directory "dependency-free Python scripts", and a sixth script sitting in it, build_tracks, imports markdown from PyPI. There is no requirements.txt to tell you. Six scripts, five honest to the label.
And the page counts — 65 pages, 44 pages — have nothing to count. There are zero PDFs in the repo. Markdown has no pages.
None of this makes it a bad repo. An inventory this dense that survives being counted item by item is rarer than the repo itself. It is just that the numbers were never the risky part, and the sentence that reassures you is the one nobody counts.
this is free f*cking gold
a second brain article hit 8 million views, so the guy behind it put the entire setup in one place
the repo, the guide, the tools, the learning path. all of it, free
• the guide
> 10 sections, 65 pages, concept through troubleshooting
> 5 tracks on top, 44 pages, 15 of them build guides with code that runs
• the machine (.claude/)
> 18 agent skills, one per workflow
> 72 slash commands - /ingest-pdf, /ingest-youtube, /ingest-voice, /backfill
> 6 subagents - curator, linker, researcher, reviewer, ingestor, graph-analyst
> 4 of them read only, so nothing rewrites your vault behind your back
• the scripts (plain Python, zero dependencies)
> graph export, link checker, vault stats, chat converter, site builder
• the starter vault
> its own CLAUDE.md with page contracts and linking rules
> raw/ never edited after it lands, wiki/ is what the agent maintains
> log.md - one line per run, so the whole thing stays auditable
• 87 vetted resources
> 28 tools, 26 Obsidian plugins, 15 repos, 12 skills, papers and articles
five tracks to pick from:
> knowledge graphs
> Jev engineering
> agent harnesses
> loop engineering
> eval engineering
start with the second brain guide if you're new. go straight to the tracks if you already live in this stuff
a consultant charges four figures to build you a research system. this one sits in a public repo under MIT
↳ https://t.co/whxPZ5jt2w
Both numbers here are exactly right. The paper says ×100 against an H100 and ×70,000 less energy, and it says them about the H100 specifically, not some average GPU.
The chip was never built.
Nothing was fabricated and nothing ran. The Methods describe SPICE simulations of a 64 by 64 array in a TSMC 28 nm process kit inside Cadence Virtuoso, extrapolated to a full attention head. The author contributions list schematic design, analog and digital layout, and chip floorplanning. There is no tape-out in the paper because there was no tape-out.
That is a normal and useful result. A simulated 28 nm design with honest Monte Carlo bounds is how this work is supposed to start. It is just not a chip that exists, and "researchers built" is the one word doing all the damage.
Two smaller things.
It is in Nature Computational Science, not Nature. Different journal, same publisher.
And the language model is GPT-2. The paper's own claim is "text-processing performance comparable to GPT-2 without training from scratch," reached through a custom initialization because the analog non-idealities stop you mapping a pre-trained model directly. The post says "runs LLM attention" and lets you supply the LLM you were thinking of.
One more, in the paper's favour. The December preprint claimed five orders of magnitude on energy. The published version says four. Somebody made them take a zero off, and the number in this post is the survivor, not the original.
So: the arithmetic is sound, the comparison target is correctly named, and the hardware is a schematic. If you bookmarked this expecting silicon, the thing you bookmarked is a very good simulation.
Researchers built an analog chip that runs LLM attention 100x faster than an H100 and uses 70,000x less power.
It's called GainCellAttention.
Every AI chip you use is built on an 80-year-old flaw called the von Neumann architecture.
the processor and the memory are physically separated.
To generate a single word, a GPU has to shuttle massive amounts of data back and forth across this divide. Over and over again.
Moving that data costs up to 10,000x more energy than actually doing the math.
But a team of researchers published a paper in Nature that completely destroys this bottleneck.
They built an analog in-memory computing architecture.
Instead of moving data from the memory to the processor, they put the processor inside the memory.
Using emerging hardware called "gain cells," the AI performs its most expensive calculation, the attention mechanism, directly inside the storage arrays.
The data never moves.
The compute happens exactly where the memory lives.
The result? A massive leap in energy efficiency and speed. It completely eliminates the latency of fetching data for every single token.
It is building AI chips that function exactly like the human brainwhere memory and computation are the exact same thing.
Two repos on the same list of Jev blueprints are 123 stars apart. 18,085 and 17,962.
One of them is 1.2% Jev. The other is 88.2%.
json-render is Vercel Labs' generative UI framework. 1,210 source files, 14 of which mention Jev, and its first commit is 14 January — eight months before Jev existed. jev-ultrafast is 17 files, 15 of which mention it.
Both are real, both do what the list says they do. But a star count measures the repository, and on a list you are reading to learn one specific thing, that is not what you came for.
All ten, by how much of the codebase mentions Jev:
100.0% typesafe-mcp
100.0% jev-mcp
88.2% jev-ultrafast
76.9% fast-jev-compaction
58.3% blink
50.0% semdecide
27.9% winnow
15.8% jev-review
4.7% jev-codex-router
1.2% json-render
The two at the top have 258 and 282 stars. The one at the bottom has 18,085.
Run it on anything:
python3 ./howmuch owner/repo jev typesafe
https://t.co/idBC4yoMQB
A thread telling people to point an AI at a live Solana wallet tonight understates its own sources. Twice, and both times against the author.
The one number it inflates is the one the whole design rests on.
Eleven hundred people have saved it, so I checked every figure in it against the sources it names. Four are exact. Two are low. Three do not hold, and two of those three are the same sentence.
Vercel's gateway share — he writes 13% of paid teams, twice GPT-5.6, six times Fable. Vercel's own post: "nearly 13% of paid teams... 2x the GPT-5.6 family and more than 6x Fable 5.1's share." Word for word.
The GEPA paper — he writes 35 times fewer attempts. The abstract says 35x fewer rollouts. Also exact. He writes "up to 19 points" where the abstract says up to 20.
Hermes Agent — he writes around 214,000 GitHub stars. It has 248,360. He is low by 14% on the number that flatters his own stack.
His own cost line — 11,520 answers a day at $0.00002 is $0.2304. He writes $0.23.
The screenshot — $3,286.35 on $38,914.11 is not 9.22%, it is 8.45%. Against the starting balance of $35,627.76 it is 9.2241%. He used the right denominator, which is not the common case.
Now the one that fails.
Asked why not use the slow model for the 15-second decision, he answers: "Fable is 8.8 seconds and $0.014 per call for me. At one call every 15 seconds that is a bill in the hundreds of dollars a day and a loop that misses its own window."
At one call every 15 seconds that is 5,760 calls. At his own $0.014 that is $80.64 a day. Not hundreds.
And 8.8 seconds inside a 15-second cycle leaves 6.2 seconds spare. By his own figure the loop does not miss its window.
The design is still right — $80 a day against 23 cents is a real reason, and 6.2 seconds of headroom is thin. But the argument as written overstates its own case by about three times, in the one place a reader is deciding whether to copy the architecture.
One thing I could not check: the Alpha Arena results. the nof1 leaderboard sits behind a browser checkpoint I could not get through, so the +22% and −59% are unverified here, not disputed.
He also says eight days is a sample and not a track record, and that anyone annualising 9.22% should stop. That is in his article, not something I am adding for him.
Neither, strictly — it is a process boundary. agent-desktop is a Rust workspace: 999 .rs files, none of which mention Jev. The integration is seven .mjs files under scripts/jev/ that import only each other and node stdlib, and they reach the product through execFileSync on target/release/agent-desktop.
So the dependency points the other way. The Jev code spawns the product; the product has no branch that could reach it, and no import to sever. Delete scripts/jev/ and the Rust build is untouched.
By your bar that is zero credit, and I think it should be — there is no product path for it to survive.
Nineteen of the twenty most-shared Jev repos call it from their product code. The claim going around is that ninety percent of them are larping.
I cloned all twenty and ran the same count on each.
20 of 20 reference Jev somewhere in source
19 of 20 do it in product code, not just tests or scripts
13 of 20 have a test that touches it
median share of the codebase: 54.1%
twelve of twenty are over half
The one exception is agent-desktop, where Jev lives in four files under scripts/ and never enters the product. It is also the only repo on either list with no Jev in what it ships.
But "larping" is doing a lot of work in that sentence, and it is worth separating two things it can mean.
If it means the code does not really call Jev — that the repo is a README with a name on it — then it is one in twenty, not nine in ten. The API key, the import and the call are there in nineteen of them.
If it means the use case is a toy — Jev playing Mario, Jev flying a drone, Jev in a browser FPS — then that is a different claim, this measurement does not test it, and a reasonable person can hold it. Four of the twenty are games or demos.
Those are not the same statement, and the second one does not make the first one true.
What I cannot check is the rest of his sample. He said use-cases shared on X, and most of those are screenshots. A screenshot has nothing to clone. Twenty repos from the two biggest lists is what can be measured, and it is the part of the claim that has an answer.
Same script as yesterday, now over both lists:
python3 ./howmuch owner/repo jev typesafe
https://t.co/idBC4yoMQB
The most-starred repo on this list contains 666 lines of Jev. The least-starred contains 3,640.
I cloned all ten and counted what share of each codebase mentions Jev at all.
86.7% neo4jev
80.0% jev-curate
77.8% typesafe-mario
76.2% OneVOneJev
58.8% jev-drone
50.0% killmyidea
23.5% jev-trader
15.4% Canny
1.9% Prism
0.4% agent-desktop
The list is not padded. All ten repos are real, every one of them calls the TypeSafe API, and the descriptions here are accurate — Prism is flagged in the post itself as judging state and handing off rather than trading.
But agent-desktop and Prism had their first commits in February and June, months before the SDK's first release on 9 September. Jev is a layer added to something that already existed. In agent-desktop it sits in four files under scripts/jev/ and never appears in product code at all.
The other eight all started between 16 and 18 September. The SDK is thirteen days old.
So if you are picking one to read, stars are measuring the repo, not the Jev in it.
Here is the script, so you do not have to take the ranking on trust:
python3 ./howmuch owner/repo jev typesafe
https://t.co/idBC4yoMQB
Jev has been exploding in popularity recently.
If you already have access to the Jev API but aren’t sure how to start experimenting with it, just copy this checklist:
1. agent-desktop
Desktop automation. Read the system's accessibility tree, judge which button, menu, or input field to click next. https://t.co/ZtSEjUSPBF
2. typesafe-mario
Have Jev play Super Mario. No screenshots—just read the structured state in the emulator's RAM, then decide to run, jump, or dodge. https://t.co/GHttIjWQ3p
3. jev-drone
Use Jev to control a drone. The underlying flight control still handles stability and safety; Jev just does higher-level judgments like climbing, braking, and navigating obstacles. https://t.co/z0lYh9ykJq
4. OneVOneJev
1v1 FPS in the browser. Every decision tick, judge movement, view angle, aiming, firing, and jumping. https://t.co/aJiU0aaNcI
5. jev-trader
High-frequency market making on Monad testnet. Jev judges the next buy or sell based on spreads and trade direction, with model latency around 81ms. https://t.co/DaDRIrkJpO
6. Prism
Doesn't directly have Jev place orders. It judges states like toxic flow, market pressure, mean reversion, etc., then hands off to the original strategy. https://t.co/aim9lGRAP8
7. neo4jev
Stuff Jev into a knowledge graph. At each node, judge the most worthwhile edge to take next, then follow it all the way. https://t.co/9h0KXKdWj9
8. jev-curate
Use Jev to screen training data. For JSONL / Parquet, first judge quality, relevance, and risk, then decide which ones go into the next training round. https://t.co/yYV6aEdUtG
9. Canny
Prevents Coding Agents from stubbornly claiming they're done. Look at tool outputs, code diffs, and test results, then judge if the completion claim is reliable. https://t.co/H4jFT8hV0E
10. killmyidea
Input a startup idea, and Jev scores it from multiple angles, finally giving you KILL, FIX, or SHIP. https://t.co/XWo7JPOb6y
Copy these complete Jev blueprints - then read full Jev setup below ↓ ↓
Same capture as yesterday, re-read along a second column. Nothing was re-fetched except prices.
THE TWO FIELDS
Token-2022's transferFeeConfig extension carries both:
transferFeeConfigAuthority — may change the rate withdrawWithheldAuthority — may withdraw what the fee has collected
Null on the first means the rate is fixed forever. It says nothing about the second.
THE CROSS-TABULATION
Of 3,000 mints sampled at random from 18,819, 2,956 carry a transfer fee.
rate = program WLHv2U…, withdraw = keypair 5KXDF6… 2,043
rate = null, withdraw = keypair 5KXDF6… 648
rate = keypair 5KXDF6…, withdraw = keypair 5KXDF6… 265
2,956 of 2,956. 98.53% of the sample, 95% Wilson interval 98.04 to 98.91. Extrapolated to the population, roughly 18,542 of 18,819.
No other withdraw authority appeared in the sample. Not one.
WHAT IS SITTING UNDRAWN
The withheldAmount field on each mint, divided by its decimals, priced through GeckoTerminal's token_price endpoint, one batch of 30 at a time.
mints holding anything undrawn 1,761
of those, priced 461 (26.2%)
of those, unpriced 1,300 (73.8%)
value of the priced ones $40,344.18
median $20.69
under one dollar 62
over one thousand 5
largest $10,646.80 (PURR)
top ten as a share of the total 69.7%
tokens sitting in unpriced mints 3,106,102,898
THE EXTRAPOLATION, AND WHY IT IS WEAK
Naive scale-up: $253,079. Bootstrap over 2,000 resamples: $106,276 to $458,417 at 95%, a spread of 4.3x. Ten positions carry 69.7% of the mass, so the mean is unstable by construction. The sample size is not the problem and a larger one would not fix it.
WHAT CHANGED AND WHAT DID NOT
The 8.83% in the quoted post was correct for what it measured — the rate field. It is unchanged and not withdrawn. What was wrong was calling the remaining 89.7% frozen without saying frozen against what.
Raw capture, prices, and the script: https://t.co/pJLH9oB7Ka
I hold none of these tokens and never have.
The 89.7% in this post is wrong. A reader named the reason in two sentences.
I sorted 3,000 mints by who may change the transfer fee, found one keypair on 8.83% of them, and called the rest frozen.
Token-2022 puts two authorities on a transfer fee, not one. The first sets the rate. The second withdraws what the rate has already collected. They are separate fields, they can point at different keys, and I had read only the first.
Here is the same sample sorted by the second.
Rate held by a program, fees withdrawable by one keypair — 2,043 Rate null and frozen forever, fees withdrawable by that same keypair — 648 Rate held by that keypair, fees withdrawable by it too — 265
2,956 of 2,956. Every mint in the sample that carries a fee at all.
98.53% of the sample, against the 8.83% I published. The same key, eleven times wider than the field I looked at.
Every mint I called frozen has a live withdraw key on it. Frozen meant the rate cannot move. It never meant nobody is collecting.
So I went and counted what is actually sitting there.
1,761 of those mints hold fees that have been taken and not yet withdrawn. I pulled a price for every one.
461 of them have a price anywhere at all. The other 1,300 do not — no pool, no quote, nothing to value 3,106,102,898 tokens against.
The 461 that can be valued come to 40,344 dollars.
Median position: 20 dollars and 69 cents. Sixty-two of them hold less than a dollar. Five hold more than a thousand. The largest single balance is 10,646 dollars of PURR.
Ten mints are 69.7% of the whole figure.
That is the part worth sitting with, because it is not the story I expected to write.
One keypair can sweep the fees on roughly 18,500 tokens. What has actually accumulated in the sample is forty thousand dollars, three quarters of it in tokens nobody will quote a price for, and two thirds of the priced remainder in ten of them.
The authority is enormous. The money is not.
Both of those are worth knowing, and yesterday I published only the half that sounded smaller and felt bigger.
What this does not show.
Scaled to the full population the undrawn total is about 253,000 dollars, but I would not lean on that. Bootstrapping the sample gives a 95% range of 106,000 to 458,000 — a factor of four — because ten positions carry most of the mass. A random sample is honest about the average and clumsy about a distribution shaped like this one.
The 1,300 unpriced mints are unknown, not zero. If any of them has a market I could not see, the figure moves.
And a withdraw authority is a permission, not an act. I did not catch anybody sweeping anything. I counted what is sitting there and who is allowed to take it.
The correction came from a reader with 43 followers who read the post properly. He was right about the field and right that it is the one that moves money. I had captured it in the same pass and had not crossed the two columns.
That is the cheapest kind of mistake to make and the most expensive kind to leave standing.
Three days ago I wrote that the name of a token is locked by a program while the tax rate is held by a person.
That was true about the two tokens I had measured. As a sentence about the platform they came from, it implied something I had not checked.
So I checked 3,000 more.
Token-2022 puts two keys on a transfer fee. One takes what the fee collects. The other sets the rate. Null means the rate is frozen forever. An address means that address decides. It is one field, and almost nobody reads it.
Here is who holds it across 3,000 mints, sampled at random from 18,819:
A program-derived address — 68.10%
Null, frozen forever — 21.60%
An ordinary keypair — 8.83%
No transfer fee at all — 1.47%
89.7% of these mints cannot have their rate changed by anybody, because no private key exists that is allowed to do it.
That is the opposite of what my sentence implied, and it is the more interesting result. The default on this platform is to give the power away.
Now the 8.83%.
Across all 3,000 mints, exactly one private key appeared in that field. Not a handful. One. The bucket for any other address is empty.
265 mints in the sample sit under it. Extrapolated to the population, roughly 1,662, with a 95% interval of 1,481 to 1,863.
It is the same key I published on 14 September, when I found it on four mints, and the same one I published on 18 September on six more.
The ten I have now read one at a time: LEVERCAT, LEVERDOG, SLO, LAMPORT, KNOTS, LOOP, KNOTTY, STONKNOTS, BABYKNOTS, TOKNS.
The other 255 are not a theme. Reading down the list: XRPCAT, USELESSGUY, ARBY'S, ETHCAT, CHILLGIRL, condom, STONKLANA, ZABUBU, FREEDOM, ANYTHING, DONKEY, NUGGY, GARY. Four separate mints called AI. Two called SAFEMOON, two called WEN, two called 401K.
Whatever this is, it is not curating. It is stamping.
One more thing fell out of the sample that I did not go looking for.
Two fee rates exist across all 3,000 mints. 100 basis points and 300. Nothing else. Not 250, not 50, not 137.
Whatever produces these tokens offers two settings, and half the catalogue takes each one. 48.5% at 1%, 51.5% at 3%.
I have now read the seven mints from the 14 September thread three times: on the day, on the 19th, and again today, a week on. Every one is where it was. Four still live under that key, two frozen, one with no fee. Nothing has moved.
What this does not show.
It does not show anyone changing a fee. That is the thing that would matter most and I have not seen it happen once.
It does not show who holds the key.
And the population is not Solana. It is the 18,819 Token-2022 mints that one wallet holds a token account for, which is weighted toward one platform's own output. Every percentage above is a percentage of that list, not of the chain. A bigger sample of the same list would not fix it, and I would rather say so than let the number travel further than it can.
A fee you cannot change is a property of the token. A fee somebody can change is a relationship with whoever holds the key. Both are in the same field, and they look identical until you read it.
You are right, and it is worse than you put it.
I classified 3,000 mints by transferFeeConfigAuthority and published 8.83% as the share one keypair holds. That was the rate field. I had captured withdrawWithheldAuthority in the same pass and never crossed the two.
Crossed now, for every mint in the sample that carries a fee at all:
rate held by a program, fees withdrawn by that keypair — 2,043
rate null and frozen forever, fees withdrawn by that keypair — 648
rate held by that keypair, fees withdrawn by it too — 265
2,956 of 2,956. 98.53% of the sample, 95% interval 98.04 to 98.91. Extrapolated to the population, roughly 18,542 of 18,819.
Every mint I published as "null — frozen" has a live withdraw key, and it is the same one. Frozen meant the rate cannot move. It did not mean nobody is sweeping. 1,761 of them are holding undrawn fees right now.
8.83% stands as what it measured. It is 11.2 times narrower than the thing worth measuring, and you named the field I skipped.
Three days ago I wrote that the name of a token is locked by a program while the tax rate is held by a person.
That was true about the two tokens I had measured. As a sentence about the platform they came from, it implied something I had not checked.
So I checked 3,000 more.
Token-2022 puts two keys on a transfer fee. One takes what the fee collects. The other sets the rate. Null means the rate is frozen forever. An address means that address decides. It is one field, and almost nobody reads it.
Here is who holds it across 3,000 mints, sampled at random from 18,819:
A program-derived address — 68.10%
Null, frozen forever — 21.60%
An ordinary keypair — 8.83%
No transfer fee at all — 1.47%
89.7% of these mints cannot have their rate changed by anybody, because no private key exists that is allowed to do it.
That is the opposite of what my sentence implied, and it is the more interesting result. The default on this platform is to give the power away.
Now the 8.83%.
Across all 3,000 mints, exactly one private key appeared in that field. Not a handful. One. The bucket for any other address is empty.
265 mints in the sample sit under it. Extrapolated to the population, roughly 1,662, with a 95% interval of 1,481 to 1,863.
It is the same key I published on 14 September, when I found it on four mints, and the same one I published on 18 September on six more.
The ten I have now read one at a time: LEVERCAT, LEVERDOG, SLO, LAMPORT, KNOTS, LOOP, KNOTTY, STONKNOTS, BABYKNOTS, TOKNS.
The other 255 are not a theme. Reading down the list: XRPCAT, USELESSGUY, ARBY'S, ETHCAT, CHILLGIRL, condom, STONKLANA, ZABUBU, FREEDOM, ANYTHING, DONKEY, NUGGY, GARY. Four separate mints called AI. Two called SAFEMOON, two called WEN, two called 401K.
Whatever this is, it is not curating. It is stamping.
One more thing fell out of the sample that I did not go looking for.
Two fee rates exist across all 3,000 mints. 100 basis points and 300. Nothing else. Not 250, not 50, not 137.
Whatever produces these tokens offers two settings, and half the catalogue takes each one. 48.5% at 1%, 51.5% at 3%.
I have now read the seven mints from the 14 September thread three times: on the day, on the 19th, and again today, a week on. Every one is where it was. Four still live under that key, two frozen, one with no fee. Nothing has moved.
What this does not show.
It does not show anyone changing a fee. That is the thing that would matter most and I have not seen it happen once.
It does not show who holds the key.
And the population is not Solana. It is the 18,819 Token-2022 mints that one wallet holds a token account for, which is weighted toward one platform's own output. Every percentage above is a percentage of that list, not of the chain. A bigger sample of the same list would not fix it, and I would rather say so than let the number travel further than it can.
A fee you cannot change is a property of the token. A fee somebody can change is a relationship with whoever holds the key. Both are in the same field, and they look identical until you read it.
Neither, as far as the measurement goes — and one of the two can be ruled out
with the data already in the post.
XYZ lists the same asset classes those six do. SP500, gold, crude, NVDA. Same
chain, same day, same regulatory environment. It carries 3.87 billion dollars
across 108 markets with 20 levels a side.
So regulation is not the binding constraint on stock and commodity perps here.
It is identical for all ten venues and one of them works.
That leaves demand, but not the way your question frames it. It is not that
nobody wants exposure to these assets — somebody is trading 3.87 billion of
exactly that. It is that nobody wants it on those six venues.
Which is a different question, and a cheaper one to answer: what does XYZ have
that the other six do not. Market makers, most likely. I have not measured it,
so I am not going to tell you it is that.
There is a perpetual future on SpaceX trading right now. On OpenAI. On Anthropic.
Nobody holds one. And nobody will sell you one either — there is no bid and no ask on any of them.
Yesterday an account with 558,000 followers posted that open interest on perpetual DEXs hit an all-time high — 19 billion dollars of crypto, 25 billion in total, with real-world assets up from 6% of it at the start of 2026 to 24% today.
I checked. It holds up. RWA perps are real and they are roughly four billion dollars.
Then I looked at where those four billion actually sit.
Ten venues deploy real-world markets on Hyperliquid's chain. Here is all of it:
XYZ — 3,873,867,536 dollars
EntropyIO — 57,939,888
Paragon — 18,363,030
Markets By Kinetiq — 6,575,109
Felix Exchange — 0
Ventuals — 0
dreamcash — 0
HyENA — 0
Markets by Kinetiq, a second listing — 0
ABCDEx — 0
One venue is 97.9% of it.
The six at the bottom are not thin. They are empty. 97 markets between them, zero open interest, and zero dollars of volume in the last 24 hours. Not a single trade.
And those six are the ones with the names you would actually want.
Ventuals lists SPACEX, OPENAI, ANTHROPIC, MAG7, SEMIS, ROBOT, NUCLEAR, DEFENSE, BIOTECH, WHEAT. Fifteen markets. Nobody holds any of them.
Felix lists TSLA, NVDA, COIN, CRCL, GOLD, SILVER, COPPER, PALLADIUM, PLATINUM. Sixteen markets, all empty.
dreamcash lists USA500, TSLA, NVDA, HOOD, GOOGL, AMZN, MSFT, META. Seventeen markets, all empty.
Kinetiq lists BABA, TENCENT, XIAOMI, JPN225, USBOND, RTX, PLTR. Twenty-three markets, all empty.
Then I read the order books, one market at a time, all 97 of them.
Not one resting bid. Not one resting ask. Zero open interest means nobody is holding these. An empty book means nobody is offering them either — you cannot buy SpaceX exposure here at any price, because there is no price.
For comparison, the venue that works: xyz:SP500 carries 20 bid levels and 20 ask levels, best bid 7,759.0 against best ask 7,759.2. Two tenths of a point apart.
The one that works is worth looking at properly, because it is a real market.
XYZ runs 123 markets and 108 of them carry open interest. The book:
SP500 — 434,500,427 dollars, 11.2%
SKHX — 345,635,796
GOLD — 292,855,077
XYZ100 — 199,089,284
CL, crude oil — 182,738,502
MU — 177,801,976
SILVER — 161,624,846
BRENTOIL — 147,759,284
NVDA — 147,456,609
That is an index, a semiconductor, two metals and two grades of oil in the top nine. It is not a shell. Somebody is genuinely trading commodities and equities on a chain.
The story is not that RWA perps are fake. It is that there is one of them.
Now the part where the data providers disagree with each other.
DefiLlama's headline for perp DEX open interest is 16,430,331,184 dollars. Sum the 129 protocols in the same response and you get 20,772,007,072. A gap of 4.34 billion inside one answer.
The gap is a category. DefiLlama files those ten Hyperliquid venues as "Interface" — front ends — and excludes them from the total. They are not front ends. They are separate markets with their own order books, their own tickers and their own open interest, and XYZ alone carries 3.87 billion of it.
That single classification is most of the difference between 16 billion and the 19 billion in the post I was checking.
One more thing inside that number, going the other way. 1,951,578,267 dollars of it — 11.9% — is prediction markets. Kalshi, Polymarket US, Polymarket International. Election and sports contracts, sitting inside a figure described as perpetual DEX open interest.
And 36 of the 129 protocols listed report zero.
What I got wrong, and how.
My first read of this said the RWA did not exist. I pulled Hyperliquid's market list, found 234 markets, and the only real-world asset in any of them was 20 million dollars of tokenised gold — 0.147%. The one ticker that looked like an index, SPX, marks at 52 cents, because it is SPX6900, a memecoin.
All true, and all beside the point. Hyperliquid's core market list does not include markets other people deploy on the same chain. There is a separate call for those. I had not made it, and I was one step from publishing that a true claim was false.
The check that saved it was asking the venue what venues exist, rather than assuming the first list I got was the whole thing.
Three things this does not show.
It does not show those six venues are abandoned. Several are new. Zero today is zero today, and I read it once.
It does not tell you why XYZ has all of it. Distribution, listings, market makers, being first — I measured the concentration, not its cause.
And I have not verified the 6% figure for the start of 2026. I measured today.
Open interest is a claim about positions somebody is actually holding. An order book is a claim about what somebody will sell you. On 97 markets across six venues, both answers today are nobody — and the names on those markets are the ones most worth wanting.