Radius: Hyperlocal ZK Prediction Markets Radius is a decentralized prediction market protocol on Solana that gates participation based on physical location. By utilizing Zero-Knowledge Proofs (ZKPs), we allow users to prove they are within a specific region-like a university campus or a neighborhood-without ever revealing their exact GPS coordinates.
Inspiration The current landscape of prediction markets (Polymarket, etc.) is dominated by macro-events: US elections, federal interest rates, and celebrity news. While fascinating, these markets feel disconnected from our daily reality. We realized that the most valuable "insider information" people possess is often hyper-localized-the foot traffic at a local business, the outcome of a campus event, or the progress of city construction.
We wanted to shift the paradigm from global speculation to local observation. We built Radius to democratize signal for the events that actually impact our communities, creating a system where "being there" is the ultimate edge.
How We Built It Radius is architected as a privacy-preserving dApp that bridges off-chain sensor data with on-chain verification.
The ZK Location Layer (Circom & SnarkJS) The core of Radius is a Circom circuit that acts as a digital geofence. Instead of sending coordinates to a server, the user's browser acts as the prover. It mathematically proves that the user is within the allowed distance using the Euclidean distance formula constraint: We utilize Groth16 over the BN254 pairing-friendly curve, as Solana supports these specific syscalls for efficient on-chain verification.
The Blockchain Layer (Solana & Anchor) We built two custom Anchor programs:
The Verifier: Accepts the Groth16 proof (proof_a, proof_b, proof_c) and public signals. It utilizes Solana's alt_bn128 syscalls to cryptographically verify the location claim.
The Market Engine: A prediction market stub that checks for a valid "Location PDA" (Program Derived Address) before allowing a user to trade. Settlements are handled in USDC (SPL Token) to ensure stable value transfer.
- The Frontend (Next.js) The UI is built with Next.js and Tailwind CSS. We integrated snarkjs directly into the client, allowing users to generate proofs in-browser. This ensures that raw GPS data never leaves the user's device, preserving total privacy.
Challenges We Faced Geospatial Math in Arithmetic Circuits: Converting spherical GPS coordinates (Haversine formula) into a format compatible with zk-SNARK finite fields was difficult. We had to approximate earth-surface distances onto a 2D plane to keep the constraint count low enough for client-side proving.
Solana Compute Limits: Verifying Groth16 proofs on-chain is computationally expensive. We had to optimize our Anchor program to ensure the verification instruction stayed within Solana's compute unit (CU) budget.
The "Cold Start" Problem: Defining what constitutes a "region" and seeding the initial markets was a UX hurdle. We had to balance flexible region creation with the strictness required by the ZK circuit.
What We Learned Building Radius taught us that Proof of Physical Presence is a powerful, unexplored primitive in crypto. We learned that privacy and verification don't have to be trade-offs; with ZKPs, we can have both.
On a technical level, we gained a deep appreciation for the Solana 1.18+ updates that enabled BN254 precompiles. Without these, verifying location proofs on-chain would have been cost-prohibitive. Most importantly, we learned that for crypto to feel "normal," the complexity must be abstract. Users don't care about elliptic curves; they care about betting on their local basketball game. Radius bridges that gap.
Log in or sign up for Devpost to join the conversation.