TensorCash Interview: “Don’t Trust, Verify” with Imosuke Takakuni
“Hype borrows credibility from the future, and this project’s entire thesis is verifiability.”
Project: TensorCash | Interviewed by: Rowenta01 | crypto-lowcap.com
Tags: #ProofOfWork #AI #PoUW #Lowcap #TSC
| ⚠️ BEFORE WE START — NOT FINANCIAL ADVICE. This article does not constitute investment advice. These are purely personal observations from a fundamental analyst who has been covering the privacy crypto space since 2016. Micro-cap and low-cap projects carry significant risk. The positions and opinions expressed here are my own. Do your own research. |
TensorCash is a five-week-old chain built on a simple bet: the same GPU pass that answers a real prompt can also secure a block. I first came across the project through its mining pools, where miners were quietly running Qwen3-8B forward passes instead of hashing, and I wanted to hear the reasoning behind it directly from the person who designed it.
The team behind TensorCash operates under a single pseudonym, Imosuke Takakuni, a name the project treats as a deliberate design choice rather than a marketing device: verify the code, not the biography. What struck me across this exchange is how often Imosuke corrected my own premises before answering them, on the retarget speed, on the GPU requirement, on what “premine” actually means here. That kind of precision is rare in this space, and it is the reason I wanted this interview on the record.
We cover the origin of the proof-of-inference design and how it differs from Bittensor, Gensyn and Gonka, the team’s account of its zero-premine launch and the early-mining concentration that followed, the statistical replay mechanism that has already caught a quantized miner on mainnet, the model registry’s admission and challenge process, and where the roadmap goes from here.
The network and market figures below (price, supply, market cap, volume, holders) come straight from TensorCash’s own block explorer and its SafeTrade price feed, snapshotted on September 15, 2026. They move with the network, so treat them as a point-in-time read rather than a fixed number.
Source: TensorCash block explorer and SafeTrade price feed, September 15, 2026.
1. Origins
To start, tell us about the person behind Imosuke Takakuni — what’s your background, and what pulled you toward building a proof-of-work chain around AI inference specifically?
Imosuke Takakuni: I am going to disappoint you slightly on the first half, and I hope you will see why. The name is a pseudonym and it stays one. Not for theatre but because a project whose entire claim is “verify the work, not the reputation of the person who did it” cannot then ask you to trust a CV. If the code is sound it is sound whoever wrote it, and if it is not, my biography would not save it. It is the same instinct that kept the most famous ancestor of every PoW chain a name and a public key — I cannot claim to know their reasons, but the example stands: the code carried it, not the person.
What pulled me here I can answer plainly. Proof-of-work has always burned real resources for an artificial result — a hash that means nothing outside the game of finding it. Meanwhile the most valuable compute on earth is running inference, and paying for it in trust: you send a prompt to a black box and hope the model that answered is the one you paid for. Two problems that happen to be each other’s solution. If the work that secures the chain is the same forward pass that answers a real prompt, then useful inference can also carry the security budget, and its result becomes something an operator can independently check rather than take on trust. So this was never about launching another coin for its own sake. The blockchain is the means, not the end: what it buys us is a decentralised verification protocol that anyone can run and check — one that could be adopted across the whole inference industry and become its gold standard. The coin is what makes that protocol run; it was never the reason for it.
TensorCash’s pitch is that the same GPU pass which answers a prompt also secures the chain. What’s the one thing about that idea that existing projects — Bittensor, Gensyn, Gonka — get wrong in your view?
Imosuke Takakuni: I would not say wrong so much as they answer a different question. Bittensor delegates scoring to subnet-defined validator mechanisms — those can be objective or subjective depending on the subnet, but the general shape is that validators score miners under an incentive scheme someone designed, one that can be both complex and subjective. Gensyn is a compute marketplace aimed mostly at training, not inference, and it verifies that work trustlessly through proof-of-learning. Gonka runs a periodic, time-boxed proof-of-compute sprint that is separate from useful serving. Our bet sits in a different place from all three: we bind actual inference to block production and check it non-interactively, every block, straight from the serving pass — a model-bound receipt screened by cheap deterministic prefilters and confirmed by a statistical replay. No separate contest to run, no dispute round, no committee forming an opinion of worth, just a property of the computation that a cheaper run tends to give itself away on. And that is the crucial part: a miner produces real inference — for their own use or to sell commercially — from the very same energy that mints the block.
2. Team & vision
How did the team form around the project, and how many people are actually building this day to day?
Imosuke Takakuni: Small, and deliberately so. I will not put a specific headcount on it, but I will say that the core that touches consensus is a handful of people, and it has to be: consensus code is where excess complexity kills you, so a small number of implementers and a lot of review per line is the combination we want — fewer hands writing it, as many eyes as possible checking it. The wider circle is not us at all — it is the pools who built images, the people who read the code and filed sharp questions, the builders on Bob Labs and AskTilly. Decentralisation Day was partly about saying that out loud: past a certain point the project is not something a team ships to users, it is something a network runs, and the team becomes one more participant that happens to know the codebase well.
The mission page talks about decentralization working “for everyone or not at all.” As the network grows past its first few thousand miners, what concretely keeps that from drifting toward a small set of well-capitalized operators?
Imosuke Takakuni: Let me start from the opposite instinct: we want more participation, not less. Every new miner validates the thesis that this work is worth doing, adds security and stability to the network, and makes the protocol more relevant to everyone on it, the smaller participants included. So the task is not to police concentration so much as to keep the playing field level, and two design choices do most of that. The work is inference on a consumer-reachable card, not an ASIC — a used 3090 can mine, so the capital floor stays where enthusiasts live, and the model registry that defines the eligible lanes requires block-producer support after the audit and operator gate. And there is no protocol-level advantage to size — no bonus for large operators, no staking tier that pays big holders more per unit of work. I want to be honest that real-world scale effects still exist, as they do in any mining: cheaper power, better utilisation, hardware efficiency, pool fees. What the protocol does is refuse to add its own thumb to that scale, so at the consensus layer a small miner earns the same per unit of honest work as a large one.
Where concentration does show up today, I will be plain about it: beyond the dev team, the largest hashrate sits with a handful of big mining pools — that concentrates things to a degree, similar to early Bitcoin. But at least on the pool side it is softer than it looks, because that power is not fully delegated to the operators. Individual miners point their hardware where they choose and can switch pools at low friction, and we have already seen exactly that in practice: hashrate moving between pools when miners had reason to move it. A pool that acts against its miners’ interest gives them every reason to leave, and they can, so pool concentration is not locked in the way a snapshot suggests. That is a mitigation, not a guarantee — a determined, well-capitalised operator is a harder problem, and I would not claim otherwise.
3. Tokenomics & timing
TensorCash launched with zero premine and no team allocation. Walk us through that decision — and how does the team fund ongoing development without it?
Imosuke Takakuni: Let me put it more precisely than “zero premine,” because that phrase gets abused and I would rather be exact. There was no protocol allocation, no token sale, and no investor unlock schedule — every coin in existence was created as a proof-of-work block reward, with none allocated outside mining. The early mining is all on-chain; anyone can see it and watch whether those coins move. A premine — coins allocated to insiders outside the mining process — is what we avoided. That is genuinely different from early mining, but I am not going to hide behind the distinction.
The initial development was self-funded by the team, without external investors, and ongoing work is funded by the same mining the rest of the network does. A growing community of capable teams and developers has also joined independently and contributes to the project — Bob Labs, AskTilly, and others among them. As mentioned in the Decentralisation Day communications, the community will play an increasingly important role in the ongoing maintenance and development of TensorCash.
Blocks arrived 4 to 7x faster than target before the retarget at block 20,160. How much of the early supply did that concentrate among the very first miners, and is that a distribution outcome you’re comfortable with?
Imosuke Takakuni: One correction to the premise: over the full epoch immediately before the retarget at block 20,160, blocks arrived roughly 3.7 times faster than target, rather than 4 to 7 times. The early mining period was shared between the dev team and early adopters who had read the code and believed in the project before there was much external validation. That concentrated a meaningful share among a small group, and a large portion of what was mined then still sits unspent today.
Am I comfortable with it? Comfortable is the wrong word — I am accountable for it, which is different and more useful. Every PoW chain that ever launched had a period when few people knew and blocks were easy, ours included. What you can do is be transparent about it — the wallets are public and anyone can watch whether they move. On Decentralisation Day the statement was signed with the genesis key and four early coinbase addresses, drawn at random from the first 2,000 blocks by the hash of block 24,000, and its hash was committed on-chain. I want to be exact about what that proves: it is a receipt, not a covenant. It links the statement to those keys; it does not prove control of every early address or, by itself, bind our future behaviour. What it does buy you is that the wallets are named and on-chain, so you never have to take restraint on our word — you can watch for it directly. A distribution outcome I would be uncomfortable with is one you had to trust. This one you can audit to the satoshi.
Rowenta’s note: TensorCash’s own explorer puts a number on that concentration. As of September 15, 2026, the top 100 addresses hold 38.39% of the circulating supply, across 20,778 funded addresses. That is an address-level view, not proof of how many distinct people or entities sit behind those addresses, so it confirms the shape of what Imosuke describes above rather than settling it.
4. Deep technical dive
Statistical replay instead of bit-exact verification or ZK — walk us through what actually happens when a verifier catches a quantized or substituted model, in plain terms.
Imosuke Takakuni: “Replay” makes it sound heavier than it is. The proof is a bounded window — a couple of hundred tokens, not the whole inference — and checking it is cheap by design. Verification is a ladder: the first rungs are just hashes and table look-ups that throw out malformed proofs for free, and only a proof that clears them reaches the Full check. Every validating node runs that Full check before it will extend its chain, but Full does not repeat the miner’s search — it reruns the model computation once as a single teacher-forced pass over that short window, all positions at once, not the token-by-token search the miner ran. Mining is search; verifying is reading one candidate. Expensive to produce, cheap to check — the same asymmetry that makes any proof-of-work function, except ours is a forward pass where Bitcoin’s is a hash.
As for what it catches: the sampling is not free choice. Given the miner’s committed distribution and a public draw fixed by the header, the next token is determined. Feed a cheaper or substituted model the same draw and its curve is shifted, so it can select a different token; once it does, the subsequent context and final proof hash diverge. Even where the token stays the same, Full can detect the altered logit distribution statistically. This is not just theory — it has already happened on the live network, and we wrote it up. A miner ran the committed model at fp8 on a smaller GPU and submitted the proof as though it were full-precision bf16; the format check passed, and the proof even replayed perfectly against its own submitted numbers. Full verification reran the model at bf16, the statistics collapsed, and both blocks were assigned zero work — the chain never extended them. The whole story, with the p-values, is on our blog: “Trust in action: how verification caught an fp8 miner”. That is the honest version of the claim — strong results against the attacks we have actually seen, not a proof that nothing could ever slip through, which is exactly why the verifier is open for anyone to attack.
Theorem B.2 bounds a grinding adversary’s advantage. For a reader who isn’t a cryptographer, what does that guarantee actually rule out?
Imosuke Takakuni: Grinding is the cache-and-hope attack. Instead of running the real model per block, you spend a lot of compute once, offline, building a library of pre-generated legal outputs. Then for each new block you cheaply reach into that library and submit a candidate, hoping the block’s required draw happens to point at one you already have. Theorem B.2 ties your odds to how many outputs you cached: if you hold at most L legal outputs, your per-trial chance of acceptance is bounded by q times L times two-to-the-minus-Bmin, where Bmin is an entropy floor the protocol enforces — a legal output can’t be too probable, so each cached one covers only a tiny slice of the space. That bound holds under a soundness assumption on the entropy certificate, which the paper is careful to state. A separate economic corollary then turns it into money and, elegantly, the break-even is independent of the mining difficulty.
To be clear, it is not an impossibility proof: for any fixed entropy floor, a large enough cache is eventually profitable. What the theorem bounds is a region — an attacker holding some bounded number of cached leaves stays below profitability, and the paper works out the safe range of L for the deployed setting under stated cost assumptions. It does not prove that no well-funded adversary could ever reach that range, and the paper is explicit that adaptive attacks and cross-architecture false-rejects are still open validation work. So the honest claim is bounded and quantified, not absolute. And it only bounds the game it describes — attacks outside the model are why the verifier is external, open, and better broken on testnet for a bounty than trusted blindly.
The model registry uses hashrate-weighted voting to approve new models. What does a contested or malicious registration attempt actually look like in practice, and who resolves it?
Imosuke Takakuni: To clarify how the process works in practice, it is not a weighted vote where hashrate is tallied as ballots — support is implicit: a registrant posts a deposit, and over a hundred-block window block producers either include commit transactions for the model or they don’t, fifty of the hundred slots being the bar. But that only decides admission. What decides whether a registration can do harm is pricing. A validation service measures the model’s real compute — FLOPs per token — and prescribes its difficulty from that. I should be precise about how binding that is: at inception the audit is advisory and operator-gated, so it is not the case that every miner independently recomputes the same number and agrees — the check produces a review, not automatic consensus. The current tooling flags any deviation beyond ±5% from the audited value and presents that for operator review — so it is a flag plus a human gate, and a deliberately conservative first version. The whitepaper describes the inception audit as advisory and operator-reviewed and explicitly leaves room for more sophisticated rules later — we would welcome proposals from the community to tighten it. The intended defence is that a model that is cheap to run should not be quietly priced as if it were expensive. If it were, its proof-of-work target would be set too easy — the block subsidy itself does not change, but the puzzle guarding it gets weaker, so its blocks could be won too cheaply. The real attack is fooling the measurement, not winning a vote.
So a malicious attempt is a measurement-forgery problem, not a persuasion one, and it resolves in two places. Up front, a model that cannot attract the commits lapses and its deposit burns. After the fact, if a bad one slips through, anyone posts a challenge deposit against a block it mined; a fresh window opens, and — after an operator-reviewed check clears — miners include challenge commits, and if it reaches the bar the model is banned, its deposit burned, and that block’s chain-work stripped so the network reorganises away from it. I would not call it fully committee-free, because an operator does sit in the loop on both the audit and the challenge review. But the discretion is about whether a measurement holds up, not about a model’s merit — and admission is cheap to contest, pricing is measured rather than asserted, and fraud is reversible after the fact.
Mining requires a 24GB Ampere-or-newer GPU. Isn’t that a meaningfully higher barrier to entry than a typical retail-GPU coin, and does that worry you long-term?
Imosuke Takakuni: Let me correct the premise slightly first: a 24GB Ampere card is the recommended configuration on NVIDIA today, not a hard protocol requirement. The software also runs on Apple Silicon, on newer NVIDIA generations, and there is even a slow CPU path for testing — so the floor is a practical recommendation for the current model, not a rule carved into consensus. That said, it is higher than a typical retail coin and I will not pretend otherwise. But look at what the barrier buys and what it costs. It buys work that is real inference on real models rather than an arbitrary puzzle. And the entry point is a used 3090 — a consumer card at a consumer price, not an ASIC that does one thing and becomes scrap when the network moves. Worst case as a miner, you are left holding a GPU that runs LLMs, which is the most liquid second-hand compute there is. Long term, and this matters: multiple models coexist and compete on the chain at once, so the floor is the smallest model the registry keeps eligible, not the largest. Registering a heavier model does not raise the floor for everyone — it opens a lane for bigger rigs while the smaller model stays minable right alongside it. The floor only rises if the smaller models become ineligible, are banned or removed, or cease to be practically usable — not merely because miners add a heavier model.
COMPUTE options settle straight from the block header with no oracle. What’s the failure mode nobody’s thought about yet with that design?
Imosuke Takakuni: If nobody has thought of it, I cannot hand it to you, but I can tell you the one that keeps my attention. Credit the design first: it does not read the block that confirms settlement, it reads difficulty at a committed, already-buried ancestor height, which kills the obvious attack — the in-the-money party timing their settlement around a retarget boundary. What that relocates rather than removes is that the underlying is difficulty, and difficulty is not an external fact: miners produce it, through timestamps and work. So the residual worry is a miner who also holds a big derivatives position nudging the index itself near the fixing — shading timestamps, withholding briefly around a retarget — and the buried-ancestor rule doesn’t touch that, because the manipulation happens before the value is buried, not after.
None of which is a new problem: fixing manipulation is something financial markets have wrestled with for a long time, and there are solutions there we can draw on in future if needed — averaging a fix over a window instead of reading a single instant, for example. As of today the real discipline is the boring kind — keep sizes and tenors small while the network’s hashrate is young enough that one participant could matter — and solutions such as the averaging window are mitigations we would reach for if manipulation ever showed up in practice. Derivatives turn every consensus quirk into money, which is a reason to start small, not a reason to pretend the risk is zero.
In five weeks you’ve shipped RWA issuance, ZK-KYC, post-quantum addresses, and a sharded DEX paper on top of the core PoW thesis. Isn’t that a lot of attack surface for a network this young?
Imosuke Takakuni: I would push back on the premise, because a feature count and an attack surface are not the same thing. Surface is not how many things a chain can do; it is how much untrusted input can reach how much unconstrained code. One of the biggest ways to blow the surface open — behind a large share of the headline DeFi losses — is a general-purpose programmable layer: a virtual machine, arbitrary contract code, loops, unbounded state. We have none of that, by design. What we shipped instead are narrow, fixed-format consensus primitives on a Bitcoin Core base: the asset protocol, delegated and zero-knowledge KYC, and post-quantum ML-DSA signatures. And to be exact, these are consensus features, active from genesis — every node parses asset records, verifies the Groth16 proofs and checks ML-DSA signatures in ordinary validation, and a bug in any of them could reject valid transactions or split nodes. I am not going to pretend they sit outside the core. They are the core. That is precisely why they were built the way they were.
Because adding capability and adding risk are only the same act if you do it carelessly. Each of these is deliberately small — fixed record formats, no VM, no loops, no contract storage, no oracle calls — which is a surface you can actually read, test and audit, not a Turing-complete layer nobody can fully reason about. They extend a Bitcoin Core base with a decade-plus of hardening behind it — the new validation paths are of course new code and do not inherit that history, but they sit on battle-tested UTXO machinery rather than replacing it — and they were activated from genesis rather than hot-patched into a live chain, and are exercised conservatively while they prove themselves. The one item that genuinely is just a paper is the DEX — and a paper is the cheapest possible place to attack an idea. We view this as the disciplined way to add real capability and utility to a chain, precisely because we avoid creating the sprawling programmable surface the question is concerned with.
Cexius shows TSC at $1.40 with negligible volume while SafeTrade prints a real order book. How do you want the market to read that discrepancy?
Imosuke Takakuni: Honestly, early price action is not something we comment on — it is not the point of this project, and I am not going to referee between two young venues. What I will offer is the general principle, because it holds regardless of the number: a price with little or no volume behind it is not really a price. A quoted figure that almost nobody has traded into tells you very little; a book with real two-sided depth and actual fills gives slightly more information. So I would not put weight on any single quote without checking whether volume and a functioning book stand behind it — and by that test a thin, one-sided quote is worth far less than it looks, wherever it appears. We do not endorse venues and will not tell anyone what TSC is worth. Same rule as the chain: don’t trust, verify — and with a price, volume is the thing to verify.
5. Ecosystem & roadmap
Bob Labs and AskTilly are already building on top of the network. What do independent builders need from you that they don’t have yet?
Imosuke Takakuni: Let me start by turning the question around, because the framing matters: the protocol keeps improving to the credit of the independent builders, not the dev team. That is by design — decentralisation means the network is improved by whoever shows up to improve it, which is why teams as good as Bob Labs and AskTilly are the point, not a bonus. We stand ready to help however we can, but we are one participant, not the engine.
What we owe those builders is boring, and I mean that as self-criticism, because they succeeded despite our documentation rather than because of it. Stable, versioned RPC interfaces with a real deprecation policy, so nothing they ship breaks on a minor release. The delegated-verification client and the benchmark harnesses already exist — what they need is hardening, documentation and versioning, so a builder can depend on them instead of reverse-engineering them. There is no foundation and no war chest here, so what we offer is not grants, it is predictability — a small team’s most valuable export is interfaces that stay put, and builders should hold us to that in public when we slip.
What’s the next model you’re aiming to get registered, and what does the path to frontier-scale models actually look like technically?
Imosuke Takakuni: The next model being discussed is Qwen3.5-27B, the FP8 multimodal build — it is being talked through openly on Discord and elsewhere, so I am not getting ahead of anything by naming it. It is a real step up from the 8B model the chain runs today: roughly triple the parameters and multimodal rather than text-only, exactly the kind of jump the registry exists to absorb. It is not registered yet, and the mechanics are worth stating plainly, because it does not just “happen”: someone posts the deposit, then a hundred-block window opens and the model needs fifty commit slots to clear it. That is the miners’ call, not mine. Worth being precise about one thing, since it is easy to get wrong — a 27B model in FP8 asks more of the hardware than the 8B does, so miners who choose it will need bigger rigs. But because models coexist and compete, that does not raise the floor for everyone: the 8B stays minable alongside it. The heavier model opens a lane for larger hardware rather than shutting the door on smaller.
On frontier scale, the constraint is not ambition, it is physics plus verification. Efficient frontier-scale serving generally needs model parallelism across accelerators — bigger-memory cards and CPU/RAM offload push the ceiling up, but past a point a model is split across several workers — and then the statistical verifier has to attribute an output to the right shards, which is a harder problem than scoring one machine. As I see it the direction runs through mid-size models like this one, then mixture-of-experts designs where the active per-token compute stays modest while total capability grows, and eventually sharded inference with per-shard attestation — but I should be clear those later stages are directions we are considering, not a shipped roadmap. Each step only happens when verification keeps up.
6. Marketing & the current moment
TSC roughly doubled in the days after SafeTrade opened the pair. Your public communication has been unusually sober and anti-hype throughout — how are you thinking about that move internally?
Imosuke Takakuni: Internally, mostly by not reading much into it — early price action is not the point, and a move on a young, thinly-traded pair is low-information whichever way it goes. It can unwind as fast as it arrived, and neither direction would tell you whether the verification design is sound, which is the only question we can actually influence. The sober communication is deliberate: every claim we publish is one we have to still stand behind in a drawdown. Hype borrows credibility from the future, and this project’s entire thesis is verifiability, so we are the last people who can afford that loan. Whatever the price does next, the blog will stay boring.
7. Closing
Are there other projects in this space right now — PoUW, privacy, or otherwise — whose work you genuinely respect?
Imosuke Takakuni: There are a few that stand out to us. Chia’s VDF work is the reason our proof of time exists at all; we build on chiavdf and say so. Bittensor took the idea of useful work seriously before it was fashionable, and even where our approach differs from theirs, they mapped terrain everyone in this space now walks on, and the arguments in their ecosystem made our design sharper. Kaspa we admire for its engineering discipline; its patience with hard problems is worth copying. On privacy, Monero has defended an unpopular, necessary idea for a decade with no premine and no block-reward development tax, sustained by voluntary community funding rather than a protocol cut — roughly the temperament this whole space should aspire to. Respecting rivals is cheap. Reading their code is the sincere version.
Anything you want to say directly to the people mining or holding TSC today that hasn’t been said yet?
Imosuke Takakuni: Mostly thank you, and I do not mean that as a formality. This network has run remarkably smoothly — no known prolonged halt or consensus split, through some genuinely hard problems — and that is due in no small part to the early adopters: the pools who built images, the miners who kept the chain busy, the people who read the code and came back with sharp questions. The trust they put in the project before there was much reason to is what carried it here, and we are grateful for it.
What we would ask for going forward is more of the same, and one thing on top: stay adversarial. The most useful thing this community can do while the network is still small is keep trying to break it in the open — run the verifier against your own blocks, read the registry commits before you follow them, and when we publish a theorem, look for the assumption it leans on. That is what signing the Decentralisation Day statement with the genesis key is meant to stand for — symbolically, the burden of proof moving to the open record rather than resting on us. From here the network is only as honest as the people checking it, and that is you. Keep checking, keep challenging us in public, and don’t trust — verify.
— Imosuke Takakuni
Related reading: our exclusive interview with Midstate’s ciphernom on building a post-quantum, CPU-mined proof-of-work chain, and our analysis of why proof-of-useful-work could finally matter.
