Subnet 77: Liquidity
Liquidity is Bittensor Subnet 77, a subnet for directing incentives toward decentralized-exchange liquidity. Its public codebase describes a liquidity mining system for the Bittensor ecosystem in which token holders vote on pools and validators use those votes to help set miner weights.
The practical idea is simple: projects and communities often need deeper liquidity so their tokens can be traded with less friction. Subnet 77 turns that need into a Bittensor reward market by letting liquidity providers compete for subnet incentives while token-holder voting helps decide which pools matter most.
What Liquidity Rewards
Subnet 77 rewards supplied liquidity rather than model output, generated content, or compute benchmarks. Miners participate by providing liquidity to the pools favored by the subnet’s voting process. The more useful a miner’s liquidity is to the selected pools, the stronger the basis for rewarding that miner.
This makes Liquidity a DeFi-oriented subnet. It is concerned with market depth and liquidity allocation, not with training an AI model directly. The subnet still uses the Bittensor incentive layer, but the work being measured happens in external liquidity pools.
Voting and Weighting
The subnet introduces a voting layer so token holders can express which pools should receive attention. Those votes guide the system toward pools that the community wants to support, instead of leaving liquidity incentives fixed by a single static list.
Validators translate the voting and liquidity information into subnet weights. At a high level, they look at which pools have been selected, how liquidity is distributed across those pools, and which miners are responsible for that liquidity. Those weights then flow through Yuma Consensus to determine how rewards are allocated on the subnet.
Vote and Liquidity Mapping Context
The Subnet 77 README source describes three separate pieces that have to line up before miner rewards make sense: token-holder votes, liquidity positions, and Bittensor miner identities. Token holders vote on which pools should receive weight, miners provide liquidity to those pools, and validators fetch calculated weights that connect the two.
That mapping is important because the useful work happens outside the Bittensor chain. A miner’s liquidity position is associated with an EVM address, while subnet rewards are assigned to a Bittensor hotkey. The README describes a registration step that links those identities, giving the weighting system a way to credit the miner responsible for a liquidity position.
The same source also describes pool voting as weighted rather than purely one-person-one-vote. Votes express which liquidity pools token holders want to support, while miner positions determine who is actually supplying liquidity inside those selected pools. For readers, the subnet is therefore not rewarding liquidity in isolation and not rewarding votes alone; it is combining both signals into a liquidity-incentive market.
That combination also keeps the article’s DeFi framing precise. Pool demand can change as token holders update preferences, while miner credit depends on whether capital is actually present in the relevant pools. The reward target is useful, attributable liquidity for pools the mechanism has selected.
This helps explain why validators are described as a measurement layer. Their role is not to invent the preferred pools manually. They follow the calculated weight result from the vote and liquidity system, then submit subnet weights so emissions track the pools and miner positions the mechanism is meant to incentivize.
References: Subnet 77 README source, Subnet 77 repository
Miner and Validator Roles
Miners are liquidity providers. Their job is to place capital where the subnet is directing liquidity demand, then keep enough useful liquidity in those pools to remain competitive.
Validators are the measurement and weighting layer. They follow the subnet’s voting result, observe the liquidity supplied by miners, and set weights so rewards track the pools and positions the subnet is meant to incentivize. Operators should treat the Subnet 77 repository as the source of truth for current implementation details.
On-Chain Identity
Live SN77 subnet data is available on TaoStats, which identifies Subnet 77 as Liquidity. The live Finney identity for netuid 77 registers the subnet name as Liquidity, with the description “Supply liquidity on external chains via uniswap, incentivize any project.” The registered project website is sn77.xyz and the GitHub repository is creativebuilds/sn77, whose README describes the voting, liquidity, and validator-weighting model used by the subnet.
Relationship to Yuma Consensus
Subnet 77 uses Yuma Consensus to convert the vote-and-liquidity 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 Liquidity’s context, validators follow the subnet’s voting result, observe the liquidity supplied by miners across token-holder-selected pools, and set weights so emissions track the pools and miner positions the mechanism is meant to incentivize. A miner’s liquidity is linked to its Bittensor hotkey via a registration step that connects EVM liquidity positions to on-chain miner identity. 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 Subnet 77, that sequence applies to the standard Bittensor lifecycle: localnet for isolated development, testnet for shared non-production testing, and mainnet for live operation with real emissions.
On mainnet, Subnet 77 is registered as the live production subnet at netuid 77. The Bittensor Networks reference separates mainnet, testnet, and localnet. Participation examples or emission outcomes from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 77 Liquidity should not be read as generic Bittensor subnet documentation, a yield-farming product, or investment advice. It names one subnet’s liquidity-incentive market — token-holder votes steer incentives and miners compete by supplying liquidity to selected decentralized-exchange pools — on netuid 77 (Understanding Subnets, Glossary: Netuid).
A miner’s reward reflects how useful its supplied liquidity is to the pools favored by the subnet’s voting process, not any return, fee, or price outcome from providing that liquidity (Subnet 77 on TaoStats).