With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
With the amount of new subnets being added it can be hard to get up to date information across all subnets, so data may be slightly out of date from time to time
Djinn is a cryptographically accountable “intelligence marketplace” implemented as Bittensor Subnet 103, with user-facing activity settled in USDC on Base. Its core premise is to “unbundle” information from execution: sellers (called “Geniuses” in the whitepaper) publish encrypted sports predictions and buyers (“Idiots”) purchase access—while the protocol claims no party (including Djinn) ever sees the plaintext signal and yet track records remain verifiable forever via cryptographic commitments and zero-knowledge proofs.
Subnet 103’s distinctive contribution is that it uses Bittensor’s miner/validator roles for verifiable executability and privacy-preserving key custody:
Economically, the protocol is designed to generate real USDC revenue by charging a 0.5% protocol fee on total notional at each audit, with an explicit emission split (miners 41%, validators 41%, subnet owner 18%) and a stated intention that some protocol revenue may be used for alpha-token buybacks. Users, however, are not required to hold TAO or the subnet’s alpha token—USDC is “the only token users touch.”
Primary-source accessibility note: the official website pages (including djinn.gg/about) and the official X/Twitter profile were not readable through the current research tooling at the time of writing (responses returned empty/blocked). As a result, this report prioritises the public GitHub repository and its whitepaper/specs as the authoritative basis; any facts not verifiable there are marked unspecified.
Djinn is a cryptographically accountable “intelligence marketplace” implemented as Bittensor Subnet 103, with user-facing activity settled in USDC on Base. Its core premise is to “unbundle” information from execution: sellers (called “Geniuses” in the whitepaper) publish encrypted sports predictions and buyers (“Idiots”) purchase access—while the protocol claims no party (including Djinn) ever sees the plaintext signal and yet track records remain verifiable forever via cryptographic commitments and zero-knowledge proofs.
Subnet 103’s distinctive contribution is that it uses Bittensor’s miner/validator roles for verifiable executability and privacy-preserving key custody:
Economically, the protocol is designed to generate real USDC revenue by charging a 0.5% protocol fee on total notional at each audit, with an explicit emission split (miners 41%, validators 41%, subnet owner 18%) and a stated intention that some protocol revenue may be used for alpha-token buybacks. Users, however, are not required to hold TAO or the subnet’s alpha token—USDC is “the only token users touch.”
Primary-source accessibility note: the official website pages (including djinn.gg/about) and the official X/Twitter profile were not readable through the current research tooling at the time of writing (responses returned empty/blocked). As a result, this report prioritises the public GitHub repository and its whitepaper/specs as the authoritative basis; any facts not verifiable there are marked unspecified.
Djinn’s stated purpose is to create a market where skilled analysts can sell predictions at scale without having to (a) bet personally, (b) risk sportsbook limits, or (c) rely on trust-based marketing claims. The whitepaper frames the “problem” as a structural mismatch: information (identifying value) and execution (placing the bet) are distinct capabilities, but traditional models force them to be bundled—leading to limited scalability for real skill and weak accountability for buyers.
The data product being sold: encrypted sports “signals” with provable timestamps
A “signal” is a specific sports betting prediction (for example, a spread/total/moneyline at given odds). In Djinn, signals are encrypted client-side and committed on-chain before outcomes are known; the commitment acts as a cryptographic timestamp that cannot be retroactively altered. Observers can see that something was committed at a specific time, but cannot see the plaintext pick.
To reduce the information leakage that would occur if a single encrypted signal were posted (and later decrypted), the protocol uses a decoy system: the Genius publishes 10 candidate lines (9 decoys + 1 real), with only the Genius knowing which index is real. This “masking” aims to prevent outsiders (and even infrastructure participants) from trivially inferring what the real pick was. The SignalCommitment contract explicitly enforces a fixed decoy list length of 10 as an on-chain invariant.
How the subnet makes signals “buyable” without revealing them to the network
The purchase flow described in the whitepaper is built around the idea that buyers are paying for methodology, not necessarily for any single disclosed pick. Before purchase, the buyer can see public metadata (sport category, expiry time, pricing parameters) and cryptographically verified aggregate track record stats (ROI, favourable/unfavourable/void rates, proof coverage, purchase success rate), but not the underlying game/teams/line/odds embedded in the encrypted blob.
When a buyer purchases, the protocol must answer a crucial question quickly: is the real line actually executable at the buyer’s chosen sportsbook at the stated odds (or better)? Djinn’s design pushes that question to Subnet 103:
Miners do the fast “Phase 1” check by querying sportsbook/odds data sources and reporting whether specific candidate lines are available.
Validators do not learn which of the 10 lines is real. Instead, they run a specialised MPC set-membership calculation: “is the secret index ∈ available indices?” The MPC is intentionally narrow (single integer membership) to stay within a targeted 3–5 second purchase window.
If the MPC result is “not executable,” the purchase is voided for that buyer (and the whitepaper describes “no charge”), while the signal may remain available for other buyers at other sportsbooks. If executable, then (i) the Escrow contract charges the fee from the buyer’s pre-funded balance and (ii) validators release enough Shamir shares for the buyer to reconstruct the decryption key locally.
Accountability mechanism: collateral-backed audits settled by ZK proofs
Djinn’s “accountability” is enforced via a repeated-interaction audit cycle: after 10 signals between a given Genius and a given buyer, an audit occurs. The whitepaper argues that 10 signals balances statistical separation with speed of accountability, and it defines a Quality Score driven by notional amounts, odds returns on favourable outcomes, and SLA penalties on unfavourable outcomes.
Critically, Djinn claims audits can settle without revealing individual picks to the blockchain: the client generates a zero-knowledge proof that it knows the preimages of the commitments and that the Quality Score was computed correctly against public outcomes, while revealing only aggregate results. The smart contracts verify the proof and, if the Quality Score is negative, trigger a compensation structure split into:
Tranche A (USDC): the buyer is refunded up to 100% of fees paid in actual USDC
Tranche B (Credits): additional damages become non-transferable, non-cashable “Djinn Credits” used only as discounts on future purchases. The whitepaper emphasises that a buyer cannot extract more USDC than they put in (credits cannot be cashed out).
On-chain, the Audit contract hard-codes the protocol fee rate as 50 bps (0.5%) and positions itself as the settlement layer after the “10 signals” threshold per pair.
Secondary use case: Web attestation (TLSNotary) as an additional subnet workload
The whitepaper also describes a “Web Attestation Service” that reuses the same miner/validator TLSNotary infrastructure to generate cryptographic proofs of what a website returned at a point in time, with proof hashes stored on-chain and full proofs stored on Arweave. It describes this as an additive revenue stream and workload that may fill low-volume sports periods, potentially via Bittensor’s “multiple incentive mechanism” allocation.
Implementation status of the WebAttestation contract is unspecified in this report: the whitepaper specifies it and the repository contains TLSNotary tooling, but a definitive deployed-contract reference and an identified contract source file named as such were not verifiable from the accessible sources during this research session.
Djinn’s stated purpose is to create a market where skilled analysts can sell predictions at scale without having to (a) bet personally, (b) risk sportsbook limits, or (c) rely on trust-based marketing claims. The whitepaper frames the “problem” as a structural mismatch: information (identifying value) and execution (placing the bet) are distinct capabilities, but traditional models force them to be bundled—leading to limited scalability for real skill and weak accountability for buyers.
The data product being sold: encrypted sports “signals” with provable timestamps
A “signal” is a specific sports betting prediction (for example, a spread/total/moneyline at given odds). In Djinn, signals are encrypted client-side and committed on-chain before outcomes are known; the commitment acts as a cryptographic timestamp that cannot be retroactively altered. Observers can see that something was committed at a specific time, but cannot see the plaintext pick.
To reduce the information leakage that would occur if a single encrypted signal were posted (and later decrypted), the protocol uses a decoy system: the Genius publishes 10 candidate lines (9 decoys + 1 real), with only the Genius knowing which index is real. This “masking” aims to prevent outsiders (and even infrastructure participants) from trivially inferring what the real pick was. The SignalCommitment contract explicitly enforces a fixed decoy list length of 10 as an on-chain invariant.
How the subnet makes signals “buyable” without revealing them to the network
The purchase flow described in the whitepaper is built around the idea that buyers are paying for methodology, not necessarily for any single disclosed pick. Before purchase, the buyer can see public metadata (sport category, expiry time, pricing parameters) and cryptographically verified aggregate track record stats (ROI, favourable/unfavourable/void rates, proof coverage, purchase success rate), but not the underlying game/teams/line/odds embedded in the encrypted blob.
When a buyer purchases, the protocol must answer a crucial question quickly: is the real line actually executable at the buyer’s chosen sportsbook at the stated odds (or better)? Djinn’s design pushes that question to Subnet 103:
Miners do the fast “Phase 1” check by querying sportsbook/odds data sources and reporting whether specific candidate lines are available.
Validators do not learn which of the 10 lines is real. Instead, they run a specialised MPC set-membership calculation: “is the secret index ∈ available indices?” The MPC is intentionally narrow (single integer membership) to stay within a targeted 3–5 second purchase window.
If the MPC result is “not executable,” the purchase is voided for that buyer (and the whitepaper describes “no charge”), while the signal may remain available for other buyers at other sportsbooks. If executable, then (i) the Escrow contract charges the fee from the buyer’s pre-funded balance and (ii) validators release enough Shamir shares for the buyer to reconstruct the decryption key locally.
Accountability mechanism: collateral-backed audits settled by ZK proofs
Djinn’s “accountability” is enforced via a repeated-interaction audit cycle: after 10 signals between a given Genius and a given buyer, an audit occurs. The whitepaper argues that 10 signals balances statistical separation with speed of accountability, and it defines a Quality Score driven by notional amounts, odds returns on favourable outcomes, and SLA penalties on unfavourable outcomes.
Critically, Djinn claims audits can settle without revealing individual picks to the blockchain: the client generates a zero-knowledge proof that it knows the preimages of the commitments and that the Quality Score was computed correctly against public outcomes, while revealing only aggregate results. The smart contracts verify the proof and, if the Quality Score is negative, trigger a compensation structure split into:
Tranche A (USDC): the buyer is refunded up to 100% of fees paid in actual USDC
Tranche B (Credits): additional damages become non-transferable, non-cashable “Djinn Credits” used only as discounts on future purchases. The whitepaper emphasises that a buyer cannot extract more USDC than they put in (credits cannot be cashed out).
On-chain, the Audit contract hard-codes the protocol fee rate as 50 bps (0.5%) and positions itself as the settlement layer after the “10 signals” threshold per pair.
Secondary use case: Web attestation (TLSNotary) as an additional subnet workload
The whitepaper also describes a “Web Attestation Service” that reuses the same miner/validator TLSNotary infrastructure to generate cryptographic proofs of what a website returned at a point in time, with proof hashes stored on-chain and full proofs stored on Arweave. It describes this as an additive revenue stream and workload that may fill low-volume sports periods, potentially via Bittensor’s “multiple incentive mechanism” allocation.
Implementation status of the WebAttestation contract is unspecified in this report: the whitepaper specifies it and the repository contains TLSNotary tooling, but a definitive deployed-contract reference and an identified contract source file named as such were not verifiable from the accessible sources during this research session.
The whitepaper states that subnet parameters are controlled by the “subnet owner (Djinn Inc.)”, consistent with a typical Bittensor subnet-owner model, and that governance decentralisation is expected to be progressive rather than immediate.
Djinn Inc. – Subnet owner / parameter controller Official org presence: GitHub org page Whitepaper explicitly states subnet owner controls parameters; emissions allocate 18% to subnet owner
Philip Maymin – Unspecified (code contributor) GitHub profile Appears as a commit author in repository history; no role statement in accessible official docs
claude (GitHub user) – Unspecified (code contributor) GitHub profile Appears as a commit author in repository history; no role statement in accessible official docs
The whitepaper states that subnet parameters are controlled by the “subnet owner (Djinn Inc.)”, consistent with a typical Bittensor subnet-owner model, and that governance decentralisation is expected to be progressive rather than immediate.
Djinn Inc. – Subnet owner / parameter controller Official org presence: GitHub org page Whitepaper explicitly states subnet owner controls parameters; emissions allocate 18% to subnet owner
Philip Maymin – Unspecified (code contributor) GitHub profile Appears as a commit author in repository history; no role statement in accessible official docs
claude (GitHub user) – Unspecified (code contributor) GitHub profile Appears as a commit author in repository history; no role statement in accessible official docs
Djinn’s development roadmap outlines a sophisticated progression of cryptographic infrastructure and decentralized coordination mechanisms. Many of the foundational components have already been implemented within Subnet 103, while others remain conceptual or partially developed, according to publicly available repositories and documentation.
The core identity of Djinn as Bittensor Subnet 103 is already established and fully operational. The subnet is recognized on-chain, and all public-facing repositories and documentation—including its GitHub and whitepaper—consistently reference its status as SN103. Djinn is visible in Bittensor’s ecosystem analytics via platforms such as TaoStats, confirming it is deployed and active.
A major milestone in Djinn’s technical implementation is its sports protocol core, which includes encrypted signal commitments, escrow-based purchase logic, collateral locking mechanisms, and a ten-signal audit cycle. These components have been implemented directly in smart contracts available in the codebase. The contracts—SignalCommitment, Escrow, Collateral, Account, and Audit—encode the invariant rules of the Djinn prediction system, ensuring traceable, auditable forecasts bound by cryptographic and economic guarantees.
Djinn has also implemented a zero-knowledge verification layer to secure its auditing and reputation processes. Specifically, the protocol leverages Groth16 zk-SNARKs and Verifier Delegation to allow validators to check correctness of miner-submitted proofs without learning the prediction contents themselves. This system is handled through ZKVerifier and TrackRecord smart contracts, which manage the lifecycle of zero-knowledge attestations for performance history.
In terms of wallet-level safety, Djinn supports key recovery through encrypted blobs. A dedicated KeyRecovery contract allows users to store encrypted metadata blobs that can be used for reconstructing private keys or authentication metadata, adding redundancy and resilience to the system.
On the subnet infrastructure side, Djinn has well-defined operational support for miner and validator services, complete with environment-based configuration, port management, and clear API roles. These are described in the technical documentation and implemented across the repo’s Docker, env, and Python orchestration layers. Validators monitor the zk-proof pipeline and maintain scoring integrity, while miners submit encrypted signal commitments with escrow logic.
Djinn’s roadmap also includes efforts at advanced security hardening, particularly in evolving its multiparty computation (MPC) design. Security improvements include OT-based (oblivious transfer) triple generation, SPDZ MAC (message authentication code) verification, and improved invariant enforcement. The progress and trade-offs of these implementations are logged in the public DEVIATIONS.md file, which enumerates security corner cases, resolved issues, and current limitations under adversarial models.
A future-facing component is the Web Attestation Service, envisioned as a second incentive mechanism that can attest to TLS-originated predictions. This is partially specified in the whitepaper and codebase, where TLSNotary components and associated tooling exist. However, implementation completeness and real-world deployment details are not yet publicly confirmed, indicating this is a work in progress.
Djinn’s long-term vision includes expansion beyond sports prediction markets into broader domains of “accountable remote intelligence.” These could include financial forecasting, decentralized research contribution, or even on-chain governance participation. The whitepaper’s section “Beyond Sports” articulates this as a theoretical expansion path, but no specific milestones or dates are assigned to this phase yet.
Finally, Djinn proposes a path toward progressive governance decentralization, wherein control over protocol rules, economic parameters, and verification rules will eventually shift to the network community. The whitepaper emphasizes that this timeline is intentionally non-predetermined and dependent on the protocol’s maturity and demonstrated resilience.
Djinn’s development roadmap outlines a sophisticated progression of cryptographic infrastructure and decentralized coordination mechanisms. Many of the foundational components have already been implemented within Subnet 103, while others remain conceptual or partially developed, according to publicly available repositories and documentation.
The core identity of Djinn as Bittensor Subnet 103 is already established and fully operational. The subnet is recognized on-chain, and all public-facing repositories and documentation—including its GitHub and whitepaper—consistently reference its status as SN103. Djinn is visible in Bittensor’s ecosystem analytics via platforms such as TaoStats, confirming it is deployed and active.
A major milestone in Djinn’s technical implementation is its sports protocol core, which includes encrypted signal commitments, escrow-based purchase logic, collateral locking mechanisms, and a ten-signal audit cycle. These components have been implemented directly in smart contracts available in the codebase. The contracts—SignalCommitment, Escrow, Collateral, Account, and Audit—encode the invariant rules of the Djinn prediction system, ensuring traceable, auditable forecasts bound by cryptographic and economic guarantees.
Djinn has also implemented a zero-knowledge verification layer to secure its auditing and reputation processes. Specifically, the protocol leverages Groth16 zk-SNARKs and Verifier Delegation to allow validators to check correctness of miner-submitted proofs without learning the prediction contents themselves. This system is handled through ZKVerifier and TrackRecord smart contracts, which manage the lifecycle of zero-knowledge attestations for performance history.
In terms of wallet-level safety, Djinn supports key recovery through encrypted blobs. A dedicated KeyRecovery contract allows users to store encrypted metadata blobs that can be used for reconstructing private keys or authentication metadata, adding redundancy and resilience to the system.
On the subnet infrastructure side, Djinn has well-defined operational support for miner and validator services, complete with environment-based configuration, port management, and clear API roles. These are described in the technical documentation and implemented across the repo’s Docker, env, and Python orchestration layers. Validators monitor the zk-proof pipeline and maintain scoring integrity, while miners submit encrypted signal commitments with escrow logic.
Djinn’s roadmap also includes efforts at advanced security hardening, particularly in evolving its multiparty computation (MPC) design. Security improvements include OT-based (oblivious transfer) triple generation, SPDZ MAC (message authentication code) verification, and improved invariant enforcement. The progress and trade-offs of these implementations are logged in the public DEVIATIONS.md file, which enumerates security corner cases, resolved issues, and current limitations under adversarial models.
A future-facing component is the Web Attestation Service, envisioned as a second incentive mechanism that can attest to TLS-originated predictions. This is partially specified in the whitepaper and codebase, where TLSNotary components and associated tooling exist. However, implementation completeness and real-world deployment details are not yet publicly confirmed, indicating this is a work in progress.
Djinn’s long-term vision includes expansion beyond sports prediction markets into broader domains of “accountable remote intelligence.” These could include financial forecasting, decentralized research contribution, or even on-chain governance participation. The whitepaper’s section “Beyond Sports” articulates this as a theoretical expansion path, but no specific milestones or dates are assigned to this phase yet.
Finally, Djinn proposes a path toward progressive governance decentralization, wherein control over protocol rules, economic parameters, and verification rules will eventually shift to the network community. The whitepaper emphasizes that this timeline is intentionally non-predetermined and dependent on the protocol’s maturity and demonstrated resilience.