From subnets to services: How Gravity turns SN13 into products
Building products from subnets is hard. Here are our key lessons learned from building Gravity's data-collection tool on SN13.
When you think of Bittensor, you think of subnets. The two are inseparable, with the protocol’s value largely coming from the individual projects it houses.
However, subnets are just one layer of Bittensor. As the the protocol matures, another is emerging from it: products. User-facing apps, services, and solutions - the front-end - are being built on subnets, which serve as the back-end.
Yet a subnet’s success is no guarantee that products built upon it will succeed too. In fact, the inherent competitiveness, flexibility, and innovation of subnet competitions can impede the design of reliable front-end services.
Gravity and Nebula, our data-scraping, sentiment analysis and visualization tools built on SN13, were among the first products on Bittensor. The process of building, iterating, and improving them - all while continuing to maintain and update the subnet itself - have yielded important insights as to the relationship between backend and frontend, protocol and product, miner and user.
Subnets vs products: what’s the difference?
It’s easy to think of subnets as products in their own right - they have users, create income, and in many cases offer solutions. However, at its core a subnet at is simply a network designed and running within Bittensor, with its own rules, guidelines, incentives, rewards, and community.
This can make fertile ground for a product, but the two are not identical. You can have a subnet that has no product features whatsoever (this was especially common before dTAO launched). These can be research outfits, experiments in decentralization, or pure backends for other subnets or services. They serve the ecosystem, and prove Bittensor’s versatility, but they don’t actually provide user-facing services or solutions.
Yet products can exist on Bittensor, and have done so for a long time. If miners and validators are put towards work people want to pay for, then you can build a product on top of it. For many subnets, this is their north star. But how do you get there?
Gravity: Building a product on a subnet
Subnet 13, Data-Universe, provides a case study for how to build products on Bittensor. The subnet focuses on data scraping - miners collect data based on certain parameters, and upload it via the subnet. Within SN13’s first year, the miners had already amassed the world’s largest open-source social media dataset repository on Hugging Gace.
It was a significant achievement - but without a frontend, its utility was limited. In order to explore the value of those datasets, we needed to provide an accessible user interface allowing people to collect data for themselves.
That’s why we launched Gravity, SN13’s data scraping product. Customers outline the type of data they want, miners receive the request, and when the dataset is ready, customers pay for access. Miners are rewarded for collecting data, but now that reward is backed by genuine customers actively using their results. Not only does this populate dynamic tasks for the job pool, but it also shows us the types of data collection task that are most in demand from real-world users.
Find a product-market fit
Building a front-end is complex. Without genuine demand from the market, even the most well-designed product might fail to attract users. Product-market fit is the iterative, ongoing dynamic between the product and its intended audience.
The design and launch of products is risky, unless it’s informed with regular feedback from potential customers and users. You could waste months tweaking features that customers don’t care about, and completely ignore a low-effort solution that would’ve been far more valuable to them instead.
For us, this process meant matching Data Universe’s core strengths - the sheer scale of its datasets, its directability, and so on - with specific users, markets, and industry niches in need of them.
Communications Lead Chris Zacharia discussing Gravity on the Ventura Labs Podcast
It’s a dual-process: subnet owners need to be in continuous dialogue with prospective customers, but they also need to report this feedback so that it informs the ongoing development of both the front- and backend architecture. In turn, this helps maintain focus on revenue-driving solutions.
Gathering feedback from outside the Bittensor ecosystem doesn’t necessarily reveal where improvements are needed, but by consolidating the feedback with engineers and Bittensor users, it can clarity how best to ensure that your incentive design genuinely serves product and user needs.
Create consistent results
Customers expect a consistent, reliable service. That’s what they’re paying for. If users struggle to get what they’re promised, they’ll give up and go elsewhere. On Bittensor, this is especially daunting: output fluctuations, protocol updates, and changes to both miners and validators are everyday occurrences that can potentially destabilize a working product overnight.
However, subnet owners can reduce these risks: tightened incentives, clear demands and limitations on miners, transparent protocols for updates and releases, and ongoing monitoring to flag and report issues as they arise.
Embedding versatility into your subnet design can enable user-led features downstream. For example, SN13 had to support dynamic desirability before it could uphold a product. Individuals can choose specific queries to be scraped, rather than a random range of data. This created the space for users to show us what they needed most, rather than us trying to guess.
Make product-first decisions
Decisions should be driven by product, not the subnet alone. The customer-base is the real arbiter of your work - not the miners, validators, or even the subnet owners. The upside is that, despite the frustrations, user-friendly services will tend to scale faster outside of Bittensor’s niche audience, which can then be translated into revenue beyond emissions.
SN13’s product layer allows us to attract customers with no knowledge of the protocol, but who simply want affordable and fast real-time unstructured data. This demographic is far larger than Bittensor’s user-base - so designing products that don’t need to refer to subnets, miners, or validators can help ease onboarding.
Consider external solutions
A product layer like SN13’s Gravity gives you opportunities to build additional tools which can be packaged into your product. For instance, we provide sentiment analysis via our 3D visualization service, Nebula. This isn’t handled by miners or validators - it’s an extra feature we built to supplement their work.
It also provides room for cross-pollination with other subnets - Gravity uses SN1, Apex, as an agentic assistant to help users choose the right data-collection topics for their task. These synergies can increase the product’s efficiency, while also strengthening Bittensor’s infrastructure.
Bittensor’s product era
Since dTAO launched, subnet owners have been questioning how they can stay financially secure, whilst weathering alpha token market dynamics. Products provide the solution: by generating revenue from customers, you create an additional income stream, prove your initial hypothesis, and expand your audience.
Together, these insulate subnets from the volatility of token prices, giving them real-world feedback that can help them succeed beyond the protocol. Ultimately, that’s what will ensure lasting success.
To learn more about subnet 13 and Gravity, come and chat in our Discord and Telegram.