Subnet 93: Bitcast
Bitcast is Bittensor Subnet 93. Its on-chain description is “The Decentralized Creators Economy,” and the project site is bitcast.network. The subnet connects brands with content creators: brands publish content briefs describing what they want covered, creators make and post videos that satisfy those briefs, and the network rewards them according to how the content actually performs with a real audience. The codebase for the subnet is the bitcast-network/bitcast repository, and the Bitcast README source describes the brief, creator, validator, and reward roles.
What Bitcast Rewards
The work on Bitcast is content creation. A brief sets out a topic or message a brand wants promoted, and miners — the creators — publish YouTube videos that genuinely fulfill that brief. Rewards are tied to real performance rather than to simply posting: a video earns based on the engagement and audience response it draws once it is live, so creators who reach and hold an audience are paid more than those who do not.
Because the rewards follow real engagement, the subnet puts weight on guarding against manipulation. The system is built so that a creator cannot earn by inflating views or faking activity; it leans on verified analytics and safeguards that discount engagement which does not hold up, keeping the reward pointed at authentic audience attention.
Brief Marketplace Context
Bitcast is organized around briefs rather than generic posting. A brief is the campaign object that tells creators what kind of content is eligible, which topic or sponsor message must be addressed, and which work can be considered for reward. This makes the subnet closer to a marketplace for campaign fulfillment than to a simple social-media leaderboard.
That distinction matters for miners. A creator does not earn merely because a video exists or because a channel is large. The content needs to match an active brief, satisfy the brief’s requirements, and then produce measurable audience response. The Bitcast creator portal exposes the brief-facing side of that workflow, while the public repository describes how creator submissions, validators, brands, and the briefs server fit together.
Engagement Verification Context
Bitcast’s reward signal depends on whether the audience response is real and attributable to eligible content. The README describes validators using temporary analytics access to validate performance, which keeps the scoring path tied to platform-side engagement data instead of self-reported creator numbers.
For readers, that makes validation the trust layer between a brand brief and subnet rewards. Validators are not simply checking whether a video URL exists; they are verifying that qualifying content produced authentic engagement under the rules of the active brief. Manipulation resistance is therefore part of the subnet’s core design rather than a side concern.
Brief Eligibility and Engagement Boundary
The Bitcast README separates video eligibility from video performance. A creator first has to publish content that satisfies an active brief. Only then does audience engagement become relevant to rewards. This keeps the subnet from treating every creator upload as eligible work.
The Bitcast creator portal exposes the brief-facing side of that workflow. In article terms, a brief is the campaign object that tells creators what kind of content can count. The brief context comes before reward calculation because it defines the content requirements that a submitted video has to meet.
The README also describes different brief formats, such as dedicated content, ad reads, and integrations. That supports a narrower reading of eligibility: a video should be judged against the format and requirements of the brief it claims to satisfy, not only against a generic “posted a video” standard.
The README then describes rewards as tied to platform-side engagement data rather than to a self-reported creator claim. That makes validation a two-part boundary: first, content must match a brief; second, validators need enough analytics evidence to connect the eligible video to real audience response.
This distinction is useful because a video can fail at either stage. A video may receive views but not satisfy the active brief, or it may satisfy a brief but fail to produce meaningful engagement. Bitcast rewards the intersection: qualifying content that also performs with an audience.
For readers, Subnet 93 is therefore best understood as a brief-driven creator marketplace with engagement verification. Miners create eligible content, validators verify performance evidence, and rewards follow the content that both matches campaign requirements and earns real audience attention.
References: Bitcast README, Bitcast creator portal
Miner and Validator Roles
Miners are the creators. They produce and publish videos that match one or more active briefs and connect the relevant account so the network can measure how each video performs. A registered hotkey on netuid 93 is what ties a miner’s content back to them.
Validators are the verification layer. They obtain temporary, read-only access to the analytics for a creator’s content, confirm the genuine engagement and performance behind each qualifying video, and translate that into rewards by setting weights on the network. That weighting is how reward flows through Yuma Consensus. At the article level the split is straightforward: miners supply the content, while validators check how well it really performed and weight each creator accordingly.
Source and Live Data
The public project site is bitcast.network, and the codebase is maintained in the bitcast-network/bitcast repository. Live SN93 subnet data is available on TaoStats. The mechanism context in this article is tied to the project site, creator portal, and public README rather than to live identity fields alone.
Relationship to Yuma Consensus
Subnet 93 uses Yuma Consensus to convert the engagement-verification weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The Yuma Consensus documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Bitcast’s context, validators obtain temporary analytics access to verify genuine audience engagement behind qualifying creator videos, translating verified engagement performance across active brand briefs into weight vectors for the subnet. The Emission documentation describes how those consensus weights determine each participant’s share of the subnet’s accumulated emission each tempo.
Development Stage Context
The Introduction to Bittensor describes subnet development as moving from localnet to testnet and then mainnet. For Bitcast (SN93), that sequence changes how readers should interpret creator content submission examples and engagement-verification scoring outcomes.
In localnet, Bitcast-compatible miners and validators can be developed and tested in an isolated environment. Localnet content engagement results and emission outcomes do not represent production subnet performance.
On testnet, Bitcast-compatible creator submission workflows can be exercised in a shared, non-production network. Testnet validation results and validator weights are separate from mainnet subnet state.
On mainnet, Bitcast (SN93) is the live production subnet where miners publish YouTube videos fulfilling brand briefs and validators verify real audience engagement to determine real Bittensor emissions. The Bitcast on GitHub describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. An engagement score or emission outcome from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 93 Bitcast should not be read as generic Bittensor subnet documentation, a generic YouTube view-farming scheme, or proof that any posted video earns rewards. The Bitcast README source describes creators publishing content for active brand briefs and validators checking engagement through temporary analytics access.
Brief Format Rules Cap Eligible Videos per Account
The README states that each brief specifies a required format, with per-account video limits such as up to two rewarded videos per dedicated brief and up to five per ad-read brief. Reward eligibility is brief-specific rather than an assumption that every upload from a channel can score.
Rewards Follow Premium-Revenue Metrics, Not Raw Hype
The same README describes rewards based on a seven-day moving average of YouTube Premium revenue, with estimation paths for channels outside YouTube Partner Program metrics. That scoring frame is different from treating raw view counts or self-reported performance as sufficient evidence on their own.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).