Subnet 103: Djinn
Djinn is Bittensor Subnet 103, a marketplace that separates information from acting on it. The Djinn README source describes the protocol as “Intelligence × Execution”: analysts sell encrypted predictions, buyers purchase access, and track records remain publicly verifiable without revealing the private signals.
What Djinn Offers
A prediction a buyer pays for stays secret, so an analyst can sell insight without giving away the edge that makes it valuable. At the same time, each analyst carries a track record that anyone can verify, so buyers decide who to trust based on a proven history rather than on marketing claims. The result is a market where reputation is earned through results that cannot be faked, and where good analysis can be sold without being leaked.
The subnet is what makes both guarantees credible. It plays the part of an independent referee: it keeps predictions sealed so they cannot be read early, and it checks the real-world outcomes needed to judge whether a prediction was right. Because that work is shared across many participants rather than trusted to one company, neither the secrecy nor the scorekeeping depends on taking any single party’s word for it.
Privacy and Record Context
The README names two core properties: signals stay encrypted, and track records are publicly verifiable. In the README’s architecture summary, signal commitments live on Base, key shares sit with Bittensor validators, and outcome attestation is performed by validators. That source framing is useful because the market is not only about publishing a prediction; it is about preserving the private edge while still leaving an auditable record.
The implementation deviation log also matters for current context. It says the original design document is preserved for design intent, but current audit settlement no longer uses the older zero-knowledge-proof path. The log states that settlement moved to MPC batch computation attested on-chain by a validator supermajority, and that track records are read from public on-chain audit settlements.
For readers, that means Djinn should be read as a privacy-and-accountability protocol rather than as a simple prediction feed. The buyer does not need the whole market to see the pick, while the market still needs enough public settlement evidence to make analyst records meaningful.
Attestation Context
Djinn’s README also describes a public web attestation service. In that flow, a user requests proof that a website served particular content at a particular time, a validator dispatches the request, and a miner generates a TLSNotary proof. This is adjacent to the prediction market because it uses the same broad pattern of verifiable external information: miners and validators help turn off-chain web evidence into a cryptographic artifact that a user can inspect.
Miner and Validator Roles
Miners are the fact-checkers. The README describes miners as verifying real-time betting-line availability with TLSNotary proofs, and it also places miners in the web-attestation flow where they generate TLSNotary evidence for requested web content.
Validators safeguard the market and settle the results. The README describes validators as holding Shamir key shares, coordinating MPC, and attesting game outcomes. The deviation log narrows the current settlement framing further: public track records come from audit settlements attested on-chain by a validator supermajority rather than from the older proof design.
Source and Live Data
Live SN103 subnet data is available on TaoStats. The mechanism details in this article are tied to the Djinn README and the implementation deviation log rather than to live identity fields.
Relationship to Yuma Consensus
Subnet 103 uses Yuma Consensus to convert the prediction-market verification weight vectors that validators submit into the emission shares distributed to miners and validators within the subnet each tempo. The linked documentation describes how validator weight submissions are aggregated into consensus weights for each miner registered on the subnet.
In Djinn’s context, validators hold Shamir key shares, coordinate MPC batch computation, and attest game outcomes on-chain by supermajority to settle audit records, then translate those verification outcomes 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 Djinn (SN103), that sequence changes how readers should interpret private prediction market examples and verifiable attestation outcomes.
In localnet, Djinn-compatible miners and validators can be developed and tested in an isolated environment. Localnet prediction settlement results and emission outcomes do not represent production subnet performance.
On testnet, Djinn-compatible prediction and attestation workflows can be exercised in a shared, non-production network. Testnet audit settlement results and validator weights are separate from mainnet subnet state.
On mainnet, Djinn (SN103) is the live production subnet where miners and validators operate the encrypted prediction market and verifiable attestation protocol to determine real Bittensor emissions. The Djinn repository describes the mechanism that applies on the production network.
The Bittensor Networks reference separates mainnet, testnet, and localnet. A prediction or attestation result from one environment should not be read as representing production subnet performance in another environment.
Reader Boundary
Subnet 103 Djinn should not be read as generic Bittensor subnet documentation, a public tip sheet, or proof that buying a prediction reveals it to the whole market. The Djinn README source describes encrypted analyst signals with publicly verifiable track records rather than open prediction feeds.
Analyst Edge Can Stay Private While Records Stay Public
The README frames signals as staying encrypted while buyers purchase access, with reputation built from outcomes that can be checked without exposing every private pick to competitors. Sealed prediction content should be separated from the public accountability layer the protocol uses to score analysts over time.
Settlement Evidence Follows the Current Implementation Path
The implementation deviation log notes that current audit settlement uses MPC batch computation attested on-chain by a validator supermajority rather than the older zero-knowledge-proof path described in the original design document. Track-record claims should follow that published settlement path, not assumptions from superseded design wording.
Validator weights still flow through Yuma Consensus to determine emissions each tempo (Yuma Consensus, Emission).