Oceans is implemented as Subnet 66 on the Bittensor network, with a custom incentive and governance mechanism built on top of Bittensor’s substrate-based blockchain. The “product” is essentially a liquidity-direction protocol and platform. It consists of on-chain logic run by SN66 validators, off-chain components for voting and data fetching, and a user-facing dashboard for participants. The technical architecture can be broken down into a few key components and processes:

Governance via α-Stake Voting: The core of Oceans is its governance mechanism. Holders of the SN66 Alpha token continuously cast votes to express how important each target subnet is (relative to others)
oceans66.com. Each holder’s voting power is weighted by their stake (amount of SN66 Alpha held or staked), meaning larger stakeholders have proportionally more influence. All votes are aggregated to produce a normalized weight vector W = [W₁, W₂, …, Wₙ] representing the relative priority of each subnet’s pool. For example, if subnet X has weight 0.25 and Y has 0.10, the community is signaling that liquidity for X is more urgently needed than for Y. This weight vector is publicly available and auditable – transparency is crucial, as anyone can verify that votes are counted correctly. (Initially, in the July 2025 launch, this voting happens off-chain via a web app where holders log in and assign weights; the votes are then fetched by the subnet’s validators. By August 2025 (V3), the plan is to migrate all voting on-chain using smart contracts, eliminating any centralized handling of votes and making governance fully trustless.) Notably, the governance will evolve to allow more granular control: in future versions, voters can specify details like Uniswap v3 price ranges for liquidity provision – meaning holders could not only pick which pool to fund but how (e.g. focusing liquidity around certain price points).

Miners Providing Liquidity: In Subnet 66, “miners” are not mining hashes or training AI models – instead, they provide liquidity (typically by supplying token pairs to decentralized exchanges or liquidity pools) for the target subnet tokens. Each miner monitors the current W weight vector (which is periodically updated by the latest votes) and then decides where to allocate their liquidity to maximize rewards. Essentially, miners act as liquidity allocators: if a certain subnet’s pool has a high weight (meaning the community strongly wants that pool filled), a miner will likely dedicate capital there, since rewards from Oceans will be higher for that pool. However, miners also consider the “current market situation” – for example, if many others are already providing liquidity to a very high-weight pool, the marginal benefit might decrease, so a miner might strategically deploy to a slightly less prioritized pool with fewer competitors. This dynamic creates a market-based competition: miners are competing for Oceans’ rewards by providing liquidity effectively. They might use any DeFi platform where Bittensor’s TAO and subnet tokens are traded (the project explicitly mentions Uniswap V3, indicating Ethereum-based liquidity provision is in scope
oceans66.com). In practice, a miner likely registers an external wallet (e.g. Ethereum address) with the Oceans subnet so the validators can track that wallet’s LP positions. Miners can spread liquidity across multiple pools if they want, but only those pools that correspond to Bittensor subnets (the ones in the weight vector) will count for rewards.

Rewards Distribution Mechanism: Oceans incentivizes miners by distributing block rewards (emissions of SN66 Alpha tokens, or potentially TAO, depending on subnet configuration) in each epoch according to the liquidity provided. The reward algorithm is straightforward and proportional to both the community weight and the miner’s contribution. For each target subnet pool k, a portion of the total emission E is allocated equal to its weight Wₖ. That allocation is then split among the miners who provided liquidity to pool k in proportion to how much each contributed. This reward function means a miner gets a slice of the pie for a given pool proportional to their share of that pool’s liquidity, and the size of the pie itself is determined by the community’s weight for that pool. If the community shifts votes over time (say favoring a new subnet), the weight vector updates and miners will reallocate liquidity to chase the higher rewards – thus liquidity follows the collective sentiment in near real-time. All of this occurs on a regular cycle (Bittensor epochs), and Oceans’ validators are the ones who compute these weights and rewards each block/epoch. They pull in the latest voting results (off-chain in V1, on-chain by V3) and query on-chain data for liquidity positions (e.g. reading DEX contracts to see how much liquidity each miner’s address is providing). After computing the rewards, the subnet mints or dispenses the appropriate amount of SN66 Alpha tokens to the miners. The design is fully transparent – since votes and liquidity stats are public, anyone can reproduce the calculations and verify that each miner’s reward was correct.

Beyond the core protocol logic, the product includes a front-end (dashboard) for both holders and miners. Through an intuitive web interface, Alpha holders can easily allocate their votes by adjusting weight sliders for different subnets (e.g. increasing the percentage for a subnet they want to boost). They can also see community sentiment tracking, such as how others are voting (perhaps aggregated or leaderboards), and a global overview of the current weight vector W that has been agreed upon. On the same dashboard, miners and holders alike can see live metrics: which pools are being filled by miners at the moment, how the actual liquidity deployment compares to the voted weights, and performance stats like total TAO liquidity provided network-wide. This real-time monitoring is crucial for the feedback loop – if a certain high-weight pool isn’t getting enough liquidity, that’s visible, and it may attract new miners or prompt holders to adjust votes, etc. Essentially, Oceans’ platform provides visibility and control over liquidity allocation that previously did not exist in Bittensor.

Technically, the architecture of Oceans subnet straddles multiple blockchain environments. Bittensor itself is a Substrate-based chain, and Subnet 66 runs as part of that network (with validators elected, issuing blocks and rewards in SN66 tokens). However, the liquidity provision likely takes place on external chains (for example, Ethereum for Uniswap V3, or perhaps Polkadot parachains if TAO is bridged there). Oceans validators function somewhat like oracles: during each epoch they may call out to an Ethereum node or API to get the state of TAO/<subnet-token> pools and measure liquidity contributions. In V1 this is done in a semi-trusted way (the validators themselves perform the queries), but a goal in the roadmap is to move towards trustless verification – for instance, by migrating voting on-chain and possibly using decentralized oracles for cross-chain liquidity data. The roadmap’s final phase (V5) is full decentralization: eliminating off-chain dependencies so that the entire vote-to-reward pipeline is on-chain and trustless. Achieving this might involve deploying smart contracts on the liquidity-providing chain to log miners’ positions, which Oceans can then trustlessly read, or other innovative cross-chain solutions.

Another important part of the build is the Liquidity Boost (Burn) mechanism, planned as V4 of the subnet. This feature introduces a burn-based “bounty” system: both miners and holders can choose to burn a certain amount of SN66 Alpha to temporarily boost the weight of a specific subnet pool or boost their own liquidity’s influence. The whitepaper describes it as a gamification strategy where burning a small amount of α gives a time-limited liquidity boost for one’s preferred pool. Concretely, this could mean that if a holder/miner feels Subnet X urgently needs liquidity, they could sacrifice some of their SN66 tokens to spike Subnet X’s effective weight (or their own reward multiplier for that subnet) for a short period. Oceans will implement this with decay timers and UI support – meaning the boost gradually decays after activation. The purpose is to add a mechanism to quickly correct imbalances or seize opportunities: for example, if a new subnet launch is creating a lot of excitement but its liquidity is still low, burning some SN66 could instantly increase rewards for that subnet’s pool, luring more miners to fill it right away rather than waiting for the next vote cycle. This feature underscores Oceans’ focus on dynamic, real-time liquidity management.

In summary, the product is a complex of smart-contract logic, off-chain services, and user interfaces that together enable decentralized liquidity provisioning as a service. Oceans isn’t a typical AI model subnet – it’s an infrastructure subnet that coordinates economic incentives. By building on Bittensor’s crypto-economic framework, it introduces novel extensions (governance voting, cross-chain liquidity tracking, burn boosts) to create a self-regulating liquidity engine for the network. The technical build leverages robust blockchain principles (transparency, decentralization, game-theoretic incentives) and marries them with DeFi concepts (liquidity pools, LP rewards) to support Bittensor’s vision of a decentralized AI economy.