Lately I’ve been spending less time on price charts, emission schedules, and whale wallet movements. I’ve wanted to spend more time looking at what matters: Bittensor subnets as businesses to be analyzed.
The subnets that survive don’t always start with the right product, they start with the instinct to change it. In the startup world, we call this a pivot. Eric Ries wrote the book on it (The Lean Startup). Marty Cagan built a career teaching product teams how to evaluate whether they’re building the right thing before they run out of runway.
Bittensor subnets are now facing the same pressure. The V440 Emission Gate, which shipped in August, made holding a low-demand slot financially painful. Subnets below the demand bar saw their emissions collapse. The 94 subnets sitting under the bar went from collecting 38.4% of total emission to 12.5%. The top 8 went from 32.8% to 52.7%.
This is an emphatic forcing function. And forcing functions produce pivots.
In this vein, three subnets caught my attention recently, so I’m going to read each one through a Product lens. Two frameworks doing the heavy lifting: Ries’s pivot taxonomy and Cagan’s four risks of product discovery. Plus my own VITALS diagnostic, which I built specifically for subnet evaluation.
How do these stand up as viable businesses? Let’s start with the one that got it right.
Score (SN44): The Textbook Evolution
Score launched as a computer vision subnet for European football clubs. Max Sebti’s team built vision models that could analyze football games for smaller clubs at a fraction of what expensive proprietary systems charged.
Then they expanded. Football became manufacturing. Manufacturing became agriculture. Then, agriculture became gas station security cameras across Europe as they landed contracts with one of the continent’s largest gas station conglomerates.
But they kept going. In August, they launched Score Studio, a platform where developers can build vision apps through “vision vibe coding,” using distilled models shrunk from 3.4GB to roughly 19MB that run on CPUs, not GPUs. They also announced Native Vision AI plugins for vibe coding tools, starting with Cursor AI.
And then, on September 1st, Score posted an announcement: “We Will Build Worlds.”
Score is taking Subnet 44 from computer vision into world models. Asking customers to describe a problem and have miners build a production vision system for it.
The evolution chain moves from computer vision into Score Studio and now world models. Each one a broader application of the same core capability: making cameras understand what they see, on cheap hardware, at the edge.
In Ries’s framework, Score executed a zoom-out pivot. The original product (football analytics) became one application of a broader capability (computer vision on edge devices). That capability became a platform (Score Studio). And now the platform is becoming infrastructure for world models: systems that don’t just detect what’s in a frame, but predict what happens next.
This is the clearest signal of a pivot: each expansion was validated by revenue before the team moved to the next one. Football proved the tech worked, manufacturing proved it generalized, the gas station contracts proved enterprises would pay. Then the platform play came after all of that, not before.
Strong product teams tackle four risks before building: value (will customers buy it), usability (can they figure it out), feasibility (can we build it), and business viability (does the economics work). Score has answered all four with evidence, not theory:
Value: Enterprise clients are paying. Real contracts, real revenue.
Usability: Vision vibe coding, downloadable codecs and Cursor AI plugins. They’ve systematically removed friction for developers.
Feasibility: Models running on CPUs at 50MB is a genuine technical moat, and they shipped it.
Business viability: Multiple revenue streams. Yuma backing. CPU inference means better unit economics than GPU-dependent competitors.
Yuma’s Evan Malanga said it plainly: the growth Score’s team accomplished in 12 months is “insane,” going from “something for football clubs in the UK” to manufacturing, fuel, and agriculture.
Running Score through my VITALS diagnostic, they score 6 out of 6. This is the benchmark.
Score never panicked because they never needed to. They kept finding new cameras to make intelligent. The pivot was gradual, revenue-validated at each step, and the core capability never changed.
Zipcode → Instant (SN46): The Forced Pivot
Subnet 46 started life as RESI, a real estate data lake. Founder Seby Rubino forked Subnet 13 to build a residential property database, scraping Zillow-style data. The team evolved into Zipcode, expanding to real estate price prediction and credit tooling.
Seby had a philosophy: subnets are not one-trick ponies. He framed subnets as processes. “Think about it like a prompt,” he said. “I would like to know the price of this house. Here is an inspection report.”
In early August 2026, the team pivoted the entire subnet to Instant: lightning-fast private inference. The first customer signed was DittoBench (Ditto AI, Subnet 118). The pivot coincided directly with the V440 Emission Gate upgrade.
In Ries’s taxonomy, this is a customer need pivot combined with a technology pivot. The team still serves developers who need AI compute, but the specific problem shifted from “price this house” to “run my model fast and privately.”
Is the pivot too drastic? On the surface, yes. Real estate to generic inference is a 180-degree turn. The accumulated learning from building a property data layer doesn’t obviously transfer to fast inference.
But the structural pressure made it rational. Real estate price prediction is a niche market with a small TAM and long sales cycles. Under V440’s emission rules, the combination of niche and slow revenue means starvation. The team looked at the math and made a call: the slot is worth more as inference infrastructure, which has a massive TAM and immediate demand.
The validated learning that carries forward here is execution capability. Seby’s team proved they could fork a subnet, build infrastructure fast, iterate through three versions, and manage validator relationships. That matters in a competitive inference market.
But here’s my concern, and it’s a huge value risk: inference is a crowded space. And here, the team can no longer rely on the domain expertise they had with property.
Chutes, Engy and Targon subnets already exist, providing inference at scale. Instant’s wedge must be speed and privacy, but fast inference alone doesn’t answer the question: faster than what? At what cost? Why can’t I use another subnet or a centralized provider?
Running Instant through VITALS at day 30 post-pivot, I get 3 out of 6. One signed customer is a proof point, not a business. Distribution beyond that partner isn’t visible yet. The inference market is competitive, and without a sharper differentiation, Instant risks entering a crowded space with no moat.
Vocence → UMI (SN78): The Ambitious One
Vocence (Subnet 78) was built by Koyuki Nakamori, who also builds Perturb (Subnet 26). Vocence was a voice-intelligence subnet: text-to-speech, voice cloning, custom voice design, music generation. The website pitched it as “Decentralized Voice AI.” A partnership with BabelBit (Subnet 59, real-time speech translation) was a natural fit.
Then Vocence pivoted to UMI (Universal Motion Intelligence), expanding from voice into vision, motion, expression, and language. The first commercial product in development is bitsign: real-time sign language translation between deaf and hearing people. The SN78 alpha token rallied sharply in the days after the announcement.
In Ries’s framework, this is a zoom-out pivot combined with a platform pivot. Voice synthesis was the product. Now voice is one feature inside a multimodal intelligence platform. And Vocence went from being an application (generate speech) to positioning as a platform (orchestrate specialized subnets into a unified product).
This is the most intellectually interesting pivot of the three. Here’s why.
Voice AI to Universal Motion Intelligence sounds like a massive leap. But look closer. The underlying customer problem stayed the same: real-time human communication translation. BabelBit translates speech-to-speech in real time. bitsign translates sign-to-speech in real time. This is the same product category (communication translation), but a different modality (motion instead of audio).
But feasibility risk is the existential threat here. Orchestrating multiple subnets (vision for sign capture, voice for speech output, language for translation) into a single real-time product is genuinely hard engineering. bitsign needs to actually work, not just sound good in a pitch.
Running UMI through VITALS at this early stage, I get 3 out of 6. The value signal is muddied: “Universal Motion Intelligence” is vague. “Real-time sign language translation” is concrete. They need to lead with bitsign, not UMI, as the platform story comes after the product works.
On the risk assessment:
Value: Strong if they lead with bitsign. Real-time sign language translation is a genuine unmet need. Weak if they lead with UMI as a concept.
Usability: Two-way translation between signing and speech is a hard UX problem. A camera capturing signs and a speaker outputting speech needs to feel seamless.
Feasibility: High risk. Multi-subnet orchestration in real-time is the hardest engineering challenge of the three pivots.
Business viability: Unclear. Accessibility markets can be enterprise-grade (government, healthcare, education compliance) but sales cycles are long.
The lesson: the best pivots keep the customer problem constant and change the solution. Vocence’s pivot works on paper because the user need (communication translation) didn’t change. But a coherent thesis isn’t a working product. Ship a working bitsign demo in 90 days and this could be the most promising pivot on the network. Don’t ship it, and UMI is a vision statement with nothing inside.
What This Tells Us About Bittensor Subnets as Products
Gradual evolution beats dramatic pivots when the core capability is strong. Score never needed a 180 because its core capability (distilled vision models on cheap hardware) kept finding new markets. Each expansion was backed by revenue. This is the Lean Startup Build-Measure-Learn loop executed properly.
Pivots forced by structural pressure are rational but inherit new market risk. Zipcode’s pivot to Instant was the right call given V440. But entering a crowded inference market without a sharp differentiation is the classic zoom-out trap: bigger market, no advantage.
The customer problem should stay constant when the solution changes. Vocence’s pivot from voice to multimodal communication works because the user need (real-time translation between humans) didn’t change. Compare this to Zipcode, where the customer problem changed entirely (property valuation to inference compute). That’s harder to pull off because you’re starting from zero on customer relationships.
The three case studies here are early examples. But they reveal a pattern that will accelerate:
Subnets with proven revenue and expanding markets (Score) don’t need to pivot. They just keep growing.
Subnets with niche markets that can’t clear the gate (Zipcode/real estate) are forced to pivot or die. The pivot direction matters more than the pivot speed.
Subnets with strong technical capability but unclear product-market fit (Vocence) have the option to zoom out into a broader platform play, but the execution risk goes up exponentially with the scope of the ambition.
From Runway to Revenue
The V440 gate is essentially Bittensor’s version of a startup running out of runway. When the money runs out, you either find product-market fit or you pivot. The gate just made the runway visible.
But emissions buy time, not a business.
Canonical Labs published research in May showing that Bittensor’s inference subnets run at 22:1 to 40:1 emissions-to-revenue ratios. For every dollar of real revenue, the network subsidizes $22 to $40 in token emissions. That’s an accelerator model that will end at some point. The goal is to graduate from subsidy to self-sustaining revenue.
All three subnets here are responding to the right pressure. But responding to pressure isn’t the same as building a business.
We need to start evaluating Bittensor subnets the way we’d evaluate any startup:
Product-market fit.
Unit economics.
Revenue that covers costs.
A moat that compounds over time.
The incentive layer is the most powerful thing Bittensor built. It pulls talent and compute into the network that no centralized company can match. But an incentive layer that subsidizes work nobody pays for is just a cost center.
For Bittensor to prosper long-term, the incentive layer needs to become productive. Emissions should fund the transition from experiment to revenue. When they’re funding experiments indefinitely, the ecosystem becomes a perpetual incubator.
Score demonstrates what the path looks like when you get it right. Most subnets are still early in that journey. V440 made the economics urgent, but ultimately, the question every subnet has to answer is the same one every startup faces: can you build something customers will pay for before you run out of runway?
Until next time.
Cheers,
Brian
Disclaimer: This is not financial advice. I am a writer documenting the Bittensor ecosystem. Always do your own research.