@djinn_gg positions itself as an “intelligence × execution” protocol that separates sports-analysis (“information”) from bet placement (“execution”). #Analysts (“Geniuses”) sell encrypted predictions; buyers (“Idiots”) purchase access and decrypt locally. The platform claims signals stay secret forever and track records remain verifiable forever via cryptographic commitments and zero-knowledge #ZK proofs. How it uses #Bittensor $TAO: + Miners verify real-time sportsbook line availability and later back it with TLSNotary proofs. + Validators hold #Shamir key shares, coordinate #MPC, and attest outcomes. + Base chain smart contracts handle escrow/collateral/audits and ZK verification (per docs). 1) What Djinn is building 1.1 Core idea: unbundle information from execution The whitepaper frames the core problem as “information and execution are bundled together,” while they’re fundamentally different capabilities. Djinn aims to let analysts scale edge to many buyers without moving markets, while buyers can decide whether/how to act on the information. 1.2 Two guarantees + Signals stay secret forever (including from #Djinn itself). + Track records are verifiable forever without revealing individual picks, using ZK proofs. 1.3 Accountability mechanisms Djinn combines: + On-chain commitments/timestamps (commit before the game, immutable). + Collateral-backed SLAs: after 10 signals with a buyer, an audit triggers; underperformance pays damages from collateral. + “True blindness”: client-side encryption + Shamir secret sharing (validators) + decoy-line masking. + ZK audit proofs: contracts verify correct Quality Score / ROI computation without learning individual signals. 2) Technical architecture deep dive 2.1 “Decoy lines” + secret index A Genius commits 10 lines (1 real + 9 decoys). Observers can’t tell which line is real. This is a key differentiator: it attempts to preserve “alpha” by preventing signal leakage even on-chain. 2.2 Purchase flow and executability (3–5s target) The purchase flow is designed to be fast: pre-funded escrow avoids wallet confirmation delays, and the target end-to-end time is 3–5 seconds. 2.3 Two-phase miner verification using #TLSNotary + Phase 1: miner checks availability quickly (gates the purchase). + Phase 2: miner generates a TLSNotary proof of that session; validators verify it after the purchase; miners are penalized if proofs contradict reports. TLSNotary itself is designed to allow proving what a server sent over TLS without revealing everything publicly (privacy-preserving attestations). 2.4 Validator responsibilities + hold Shamir key shares and coordinate MPC, + attest outcomes (2/3+ consensus), + and validators submit weights that are processed by #Yuma #Consensus to compute emissions. 2.5 Codebase maturity signals The repo shows 485 commits and substantial test coverage counts cited in the README area (e.g., validator and miner test suites). It does suggest meaningful engineering effort and an intent to harden the system. 3) Economics & token value accrual 3.1 Unit economics inside the protocol (sports marketplace) Key parameters from the whitepaper: + Genius pricing (MP%) commonly 5–15% of notional (examples given). + Audit occurs after 10 signals between a Genius-Idiot pair. + Protocol fee: 0.5% of total notional paid by the Genius at each audit (in @USDC), intended to cover costs; the paper says a portion may be used to buy #SN103 alpha, supporting token price (“revenue-backed” framing). 3.2 SLA damages + “credits” design (why it matters) If a Genius fails an audit, the buyer receives: + USDC refund up to fees paid, plus + credits that can be spent on future signals but cannot be withdrawn, which the whitepaper argues reduces adversarial incentives and improves “information services” regulatory posture. This is a deliberate attempt to keep the product in “paid information / accountability” territory rather than “casino payouts,” though regulatory interpretation remains a risk. 3.3 Network equilibrium and buybacks Djinn’s “network equilibrium” section claims: +the protocol charges fees, + funds operations, and + may allocate a portion to purchasing the subnet alpha token, creating a support mechanism (especially if usage scales). This is one of the clearer “real revenue → token” narratives among subnets, but it is still execution-dependent and subject to governance/owner discretion. 3.4 Governance centralization Whitepaper governance: key parameters (scoring weights, audit window, fees, emission allocations) are controlled by the subnet owner (Djinn Inc.), which is described as “standard for Bittensor subnets.” For institutions, this is a material governance + key-person risk and should be priced accordingly. 4) Differentiation vs competitors (why Djinn could matter) 4.1 Versus traditional “picks” businesses Djinn’s strongest differentiator is cryptographic accountability with permanent secrecy: + timestamps prevent backfilling, + ZK proofs prevent cherry-picked track records, and decoy lines + Shamir shares reduce leakage risk. + If this works end-to-end, it’s more defensible than “Discord + screenshots.” 4.2 Versus prediction markets (Polymarket-style) Prediction markets are about price discovery and settlement. Djinn is about selling private analysis with verifiable performance and no public reveal of the underlying picks. These can coexist; they’re not direct substitutes. 4.3 “Web attestation” as a second wedge Djinn’s repo describes a public web attestation service where users burn a small amount of SN103 alpha (priced in TAO terms) to request TLSNotary proofs that a website served specific content at a time. The whitepaper also describes a web attestation architecture using Base contracts + Arweave storage, and then expands to “Beyond Sports” use cases. If web attestation becomes a meaningful product line, it diversifies away from sports-specific regulatory exposure and could create a more “enterprise palatable” revenue path. 5) Key risks 5.1 Regulatory and compliance risk (highest) Even with “information services” framing, sports-related monetization has jurisdictional complexity (marketing, consumer protection, gambling-adjacent rules, KYC/AML expectations depending on structure). The whitepaper explicitly leans on “information services have clearer regulatory standing than gambling,” but this is not a guarantee. Diligence action: require a clear legal memo by jurisdiction + product UX review (what exactly users are doing, where funds move, what claims are made). 5.2 Dependency risk: sportsbooks, APIs, blocking The protocol depends on miners verifying real-time line availability and producing proofs. Sportsbooks can rate-limit, geo-fence, or change APIs/ToS, creating operational fragility. 5.3 Crypto-systems complexity risk (TLSNotary + MPC + ZK + contracts) Djinn stacks multiple high-assurance components: + TLSNotary proofs, + MPC coordination, + ZK circuits (Groth16/snarkjs), + and escrow/collateral/audit contracts. Each component is defensible alone; the composition raises tail risk. For institutions: demand audits, threat models, and staged rollouts with measurable failure rates. 5.4 Governance / admin-key risk Subnet owner controls key parameters (fees, scoring weights, allocations). That is a centralization vector and an institutional governance concern. 6) KPI framework (for the team to deliver) A) Marketplace traction + of active Geniuses (weekly) + of paying buyers (weekly/monthly) + Signals posted/day, purchases/day + Audit pass rate distribution (is performance believable or too “perfect”?) + Repeat purchase rate / buyer cohort retention B) Protocol revenue + token support + USDC protocol fees collected (from audits + web attestation) + Buyback amounts/frequency (if implemented) — tied to whitepaper equilibrium claim + Burn volumes (attestation burn gate) C) Network health + Active validators/miners trend vs max UIDs + Validator uptime and dispute rates + Miner proof failure rate (Phase 2 proof contradicting Phase 1 report) D) Risk / compliance + Jurisdiction coverage + restrictions + Consumer complaint rate / refund rate + Smart contract audits completed + remediation SLA 7) Bottom line: Strengths: clear product narrative; strong crypto-mechanics for accountability + secrecy; credible use of Bittensor roles; plausible revenue model; meaningful current liquidity/holder count for a subnet token. Primary risks: regulatory exposure; governance centralization; complex system integration risk; unknown real traction (private beta).