Loading
Loading

Neuron registration trends
Sports bettors face a fundamental trust problem: how do you know if an analyst's track record is real? A claimed 65% win rate could be cherry-picked past picks, fake results, or outright fabrication. Even when you find someone with a genuine edge, you have no way to verify they're actually using their claimed strategy rather than adjusting their picks after the fact. Simultaneously, analysts with real expertise have no credible way to monetize their edge—sharing picks publicly destroys their value, and asking people to trust them based on reputation alone doesn't scale.
The status quo forces bettors to either trust opaque services that provide zero verifiable proof of performance, or build their own analysis and take all the risk themselves. There's no infrastructure where an analyst can prove their picks work without revealing them to everyone.
Djinn solves this by inverting the trust model: analysts encrypt their picks on-chain, preventing anyone—including the platform operators—from seeing what was actually picked. When a game concludes, validators running the public ESPN API independently verify the outcome and compute a quality score via cryptographic consensus. The score is recorded on-chain and attributed to the analyst. Buyers see only the track record (favorable outcomes, unfavorable outcomes, ROI) and can verify it came from real game results, not fabricated data. The encryption and the on-chain attestation make it impossible to fake a track record; the only way to build a reputation is to actually make correct picks.
Validators never learn individual picks (they reconstruct only an aggregate quality score via multi-party computation), miners verify real betting lines exist before any settlement occurs, and smart contracts on Base chain handle escrow, collateral lockup, and settlement. The entire system runs as a decentralized subnet on Bittensor, with validators and miners incentivized to participate via TAO emissions.
Use cases were auto-generated from the GitHub repository and may not reflect the latest changes.
Djinn Protocol (Bittensor Subnet 103) is a decentralized platform for encrypted sports betting signal distribution and verification. Geniuses sell encrypted predictions with collateral-backed SLAs, Idiots purchase access to signals based on verifiable track records, Miners verify real-time betting line availability via TLSNotary proofs, and Validators hold Shamir key shares, coordinate MPC for key reconstruction, and attest game outcomes on-chain via Base chain smart contracts. The protocol keeps signals encrypted end-to-end and records quality scores on-chain without revealing individual picks.
Djinn is a multi-layer architecture: (1) On-chain layer (Base chain smart contracts) handles escrow, collateral, signal commitments, audit settlement, and vote recording. (2) Bittensor layer (Subnet 103) coordinates miner tasks (line verification via TLSNotary), validator consensus (outcome attestation via MPC and ESPN API), and weight setting. (3) Web layer (Next.js 14 frontend) provides UI for browsing signals, purchasing, and viewing track records indexed via The Graph subgraph. (4) MPC layer coordinates key reconstruction for signal purchases and quality score computation across validators using Shamir secret sharing and distributed key generation. Validators hold Shamir shares of signal encryption keys and never reconstruct full keys; purchases trigger k-of-n threshold MPC to obtain only the necessary decryption material. The protocol ensures signals stay encrypted throughout and individual picks are never revealed on-chain.
Capability Composition Subnet
This information was auto-extracted from the GitHub repository and may be incomplete or out of date. Always refer to the subnet's GitHub repository for the latest instructions.
Miners are evaluated on: (1) response latency — faster responses score higher; (2) accuracy — correct line availability checks; (3) proof quality — valid TLSNotary proofs when requested; (4) uptime — consistent availability. Validators compute quality scores via MPC (hiding individual outcomes) and vote on-chain; when 2/3+ validators agree, settlement triggers automatically and miners are weighted accordingly. Geniuses receive fees (configurable bps) from signal purchases; their quality score (favorable/unfavorable outcomes) is publicly verifiable on-chain and determines future purchase demand.
The sections above were auto-generated from the GitHub repository and may not reflect the latest changes. View repository
FAQs were auto-generated from the GitHub repository and may not reflect the latest changes.
Holder & total-staked metrics as of 2h ago (hourly snapshot)
Performs HTTP odds checks and TLSNotary proof generation; SSD preferred with 500 IOPS minimum (2000 recommended)
Runs MPC orchestration, outcome attestation, and weight setting; SSD preferred with 1000 IOPS minimum (5000 recommended)
Copy environment template and edit with Bittensor wallet, hotkey, API key configuration
cd miner && cp .env.example .env
Install miner dependencies (or use uv: uv sync)
pip install -e .
Configure UFW firewall rules (port 8422 for API, 7047 for notary sidecar)
bash scripts/miner-firewall.sh
Start the miner process (or docker compose up miner)
djinn-miner
Verify miner is running and healthy(optional)
curl http://localhost:8422/health
Copy environment template and edit with Bittensor wallet, hotkey, Base RPC URL, contract addresses
cd validator && cp .env.example .env
Install validator dependencies using uv package manager
uv sync
Create a separate Base chain keypair for settlement signing
Generate an EVM wallet (cast wallet new or Python) for Base chain transactions
Obtain ~0.01 ETH for transaction gas
Fund wallet with Base Sepolia ETH from faucet (testnet) or mainnet ETH
Start the validator process
uv run python -m djinn_validator.main
Verify validator is running, connected to Bittensor, and holding Shamir shares(optional)
curl http://localhost:8421/health