I Built Prediction Markets That Need Nothing But Bitcoin
Get the project:
- Decentralized Predictive Market Bitcoin — Bitcoin-native prediction markets using OP_RETURN
- All my tools — Full collection of agents, skills, and plugins
The last few weeks have been a blur of building. Portable AI memory in single files. Government APIs wrapped into one interface. Security tools orchestrated across ephemeral VMs. Proxmox clusters rescued by AI agents.
Each project taught me something about self-contained systems. About eliminating external dependencies. About building things that can travel with their context.
And somewhere in the middle of all that, I kept thinking about Bitcoin. I've been building on Bitcoin since 2013, and these patterns keep proving themselves.
The Pattern I Keep Seeing
Every project I've built recently shares a common theme: taking distributed, messy infrastructure and consolidating it into something portable and self-sufficient.
Memvid stores vector embeddings, full-text indices, and metadata in a single
.mv2The civic data MCP wraps seven different government APIs into one interface. No more hunting through old projects for that Census query or NOAA authentication pattern.
The Kali orchestration system spins up isolated VMs, executes security tasks, and destroys the evidence. Self-contained operations that leave no residue.
The pattern is always the same: reduce external dependencies, make the system portable, let it carry its own context.
What would that look like for prediction markets?
Why Prediction Markets on Bitcoin
Prediction markets are one of the most interesting applications of cryptographic systems. They aggregate information in ways that polls and expert opinions can't match. Markets have incentives built in. People put money where their beliefs are.
But existing prediction markets have a problem: they all depend on something external.
Polymarket needs Polygon. Kalshi needs traditional banking rails. Augur needed Ethereum. Every platform introduces dependencies: other blockchains, oracles, custodians, regulatory chokepoints.
What if we built prediction markets that needed nothing but Bitcoin?
Not Bitcoin as a settlement layer for something built elsewhere. Bitcoin as the entire stack. OP_RETURN for commitments. Taproot for conditional payouts. The Bitcoin ledger itself as the source of truth.
Revisiting OP_RETURN
I wrote recently about getting Colored Coins working on modern Bitcoin Core, and I've explored Lightning for encrypted messaging. Those projects reminded me how much you can do with OP_RETURN, the opcode that lets you embed small data payloads directly into Bitcoin transactions.
OP_RETURN historically gave you 80 bytes per output. That's not much. But it's enough to store a commitment hash. A timestamped anchor. A cryptographic fingerprint of something larger. (And as of Bitcoin Core v30, that limit jumped to 100KB, which changes the design space dramatically. More on that below.)
The key insight is that you don't need to store data on Bitcoin. You need to commit to data on Bitcoin. The actual information lives elsewhere. The blockchain provides the immutable timestamp, the proof that something existed at a specific moment.
For prediction markets, this means you can:
- Create a market by committing its parameters to the blockchain
- Register predictions by anchoring participant commitments
- Resolve outcomes by recording attestations from decentralized witnesses
- Settle payouts through Taproot spending conditions
All of it verifiable. All of it timestamped. All of it without external dependencies.
Cryptographic Capsules
The core innovation in this protocol is what I'm calling capsules. These are cryptographic containers that hold verifiable key origin information.
A capsule exposes a public key while keeping the corresponding private key encrypted. This creates an interesting property: you can verify that a capsule exists and audit its state without knowing what's inside.
Markets reference capsule states. "Will this capsule be opened before block 900000?" "Will the key inside this capsule sign a specific message?" "Will two capsules reveal the same underlying secret?"
The outcomes are deterministic. Machine-checkable. No oracle needs to attest to external world events. The Bitcoin ledger itself provides all the facts needed for resolution.
The Architecture
The system layers like this:
Bitcoin Blockchain ├── OP_RETURN anchors (commitments, timestamps) ├── Taproot escrows (conditional payouts) └── Witness bonds (accountability stakes) ↓ Protocol Layer ├── Capsules (verifiable key containers) ├── Markets (YES/NO bets on predicates) ├── Predicates (deterministic resolution conditions) └── Witnesses (threshold attestation network)
When you create a market, you commit its parameters via OP_RETURN. The commitment includes the capsule reference, the predicate for resolution, and the payout structure.
Participants lock funds into Taproot addresses with spending conditions that depend on witness attestations. When witnesses reach threshold agreement on the outcome, the winning path becomes spendable.
No smart contracts. No virtual machines. Just Bitcoin script and cryptographic primitives.
What Makes This Different
Most prediction market designs treat the blockchain as a settlement layer. The interesting logic happens elsewhere: in smart contracts, in oracle networks, in off-chain computation.
This design inverts that. The Bitcoin ledger isn't just where money moves. It's where truth is established.
Capsules create verifiable facts without external data feeds. OP_RETURN commitments create immutable history. Taproot conditions create programmable payouts. Threshold witnesses create decentralized attestation.
The entire system is auditable by anyone running a Bitcoin node. No additional infrastructure required.
Open Questions
This is still research-phase work. There are hard problems I haven't solved:
Witness Economics: What incentivizes witnesses to participate honestly? Bond slashing helps, but the positive incentives need work.
Winner Identification: Tracking which participants bet on which outcomes without revealing positions prematurely. This is the critical MVP blocker.
Information Asymmetry: If someone controls a capsule, they might know the outcome before the market resolves. How do you prevent manipulation?
ZK Genesis Proofs: How do you verify that a capsule was created in a constrained environment? Trusting the proof origin is non-trivial.
These aren't insurmountable. But they need careful design.
Why Now
The timing feels right for a few reasons. And one of them just happened.
Bitcoin Core v30 changed everything. In October 2025, the default OP_RETURN data limit was raised from 80 bytes to 100,000 bytes. That's not a typo. From 80 bytes to 100KB. The update also allows multiple OP_RETURN outputs per transaction.
This was controversial. Critics like Luke Dashjr and Nick Szabo argued it encourages "blockchain bloat," increases node costs, and raises transaction fees for regular users. Some node operators switched to Bitcoin Knots, which maintains the stricter 80-byte limit.
Proponents argue the change aligns default policy with actual consensus limits and enables more sophisticated on-chain applications. Data storage was happening anyway through inscription hacks and UTXO bloat. OP_RETURN is cleaner.
I'm not here to relitigate that debate. But for what I'm building, the implications are significant.
With 80 bytes, you could store a commitment hash. With 100KB, you can store entire market specifications, witness attestations, resolution proofs. The protocol design I outlined above assumed 80-byte constraints. Those constraints are now optional.
Taproot adoption is growing. The tooling for working with Bitcoin script has matured. And prediction markets are having a moment. The 2024 election showed how powerful these markets can be for aggregating information. People are paying attention.
But the platforms that got attention are all centralized in ways that create risk. Regulatory risk. Counterparty risk. Platform risk.
A protocol that runs on Bitcoin alone doesn't have those risks. It has different risks, but they're cryptographic rather than institutional.
The Connection
Looking back at the projects I've built recently, they all share this quality: systems that carry their own context, that don't depend on external infrastructure, that can operate independently.
Memvid doesn't need a vector database server. The civic data MCP doesn't need me to remember which repo had that API integration. The Kali orchestration doesn't leave artifacts on my main machine.
A Bitcoin-native prediction market doesn't need Ethereum, doesn't need oracles, doesn't need custodians. It needs Bitcoin. That's it.
The pattern keeps repeating because it keeps working. Self-sufficient systems are more robust than dependent ones. Portable systems are more useful than anchored ones.
OP_RETURN isn't just a way to store data on Bitcoin. It's a way to anchor systems that carry their own context. And that's exactly what a prediction market needs.
What's Next
The protocol specification is public. The design documents outline what I'm trying to build and the problems that remain unsolved.
If you're interested in Bitcoin protocol development, prediction market mechanism design, or threshold cryptography, take a look. The hard problems are genuinely hard, and I could use help thinking through them.
This might not work. Some of the open questions might not have good answers. But the pattern is too compelling to ignore.
Self-contained systems. Portable context. No external dependencies.
It works for AI memory. It works for API wrappers. It works for security orchestration.
Maybe it works for prediction markets too.