Product Roadmap
Product Roadmap
V1: Current Build (Competition Release)
The current version of BetBit delivers a fully functional 1v1 peer-to-peer wager escrow protocol on Avalanche. Two users create a wager at even odds, both deposit USDC into a smart contract, report outcomes independently, and the winner withdraws. The entire flow runs through passkey-authenticated smart wallets with gas sponsorship. No seed phrases. No AVAX. No crypto complexity.
V1 proves the core thesis: trustless P2P wagering works on-chain with a user experience that feels like a normal web app.
V2: In Development
1. Operator Integration API
The goal: Make BetBit's escrow infrastructure available to any sportsbook, betting operator, or platform through a clean REST API. BetBit becomes the settlement layer that other products plug into.
What this looks like in practice:
An existing sportsbook, say a Brazilian operator running a traditional centralized book, could integrate BetBit's escrow API to offer their users provably fair P2P markets alongside their house-book products. The operator's frontend handles the user experience and market creation. BetBit's API handles the on-chain escrow, deposit verification, settlement, and withdrawal.
The integration flow:
Operator's Platform BetBit API
───────────────── ──────────
User places wager on operator site
│
├──→ POST /api/v2/wagers/create
│ (amount, odds, deadline, metadata)
│ ←── wagerId, deposit instructions
│
├──→ POST /api/v2/deposits/initiate
│ (wagerId, party, USDC approval)
│ ←── UserOp hash, deposit confirmation
│
├──→ POST /api/v2/outcomes/submit
│ (wagerId, party, result)
│ ←── settlement status
│
└──→ POST /api/v2/withdrawals/initiate
(wagerId, party)
←── tx hash, amount transferredOperators get webhook notifications for state changes (deposit confirmed, outcome submitted, wager settled) so they can update their UI in real time. They never custody user funds. BetBit's smart contract handles that. This reduces the operator's regulatory and security burden.
This also opens the door for white-label deployments where an operator runs their own branded frontend but uses BetBit's contracts and API under the hood. The operator sets their own fee split through the API, and BetBit's protocol fee is taken at the contract level.
Revenue model: Per-transaction API fees plus a basis point share on settlement volume flowing through the API.
2. Variable Odds
The problem with V1: Every wager is even money (1:1). If you bet $100, you either win $100 profit or lose your $100. This works for "pick 'em" scenarios where both sides are equally likely, but it doesn't reflect how most real bets work. If the Lakers are heavy favorites, nobody wants to risk $100 to win $100 on them. The risk/reward is lopsided.
Variable odds let the creator set a payout ratio when creating the wager, which determines how much each side puts up.
How it works:
At 3:1 odds (decimal 4.0), the underdog backer risks less but stands to win more. The favorite backer risks more but is betting on the more likely outcome.
Example at 3:1 odds:
Person A (backing the underdog) puts up $50
Person B (backing the favorite) puts up $150
Total escrow pool: $200
If the underdog wins: Person A gets $200 ($50 stake + $150 profit, a 3:1 return)
If the favorite wins: Person B gets $200 ($150 stake + $50 profit)
Both sides deposit their respective amounts into the same escrow contract. The smart contract knows the odds ratio set at creation and calculates the correct payout amounts at settlement. The protocol fee is still taken as a percentage of the total pool.
The contract changes are straightforward: instead of a single amount field, the wager stores amountA (creator's stake) and amountB (taker's stake), with an oddsNumerator and oddsDenominator that define the ratio. The existing truth table and settlement logic stay the same. Only the payout math changes.
On the invite link, the taker sees exactly how much they need to deposit and what their potential payout is before accepting, so there's no confusion about the terms.
3. Multi-Party Pools (Team Play)
The concept: Instead of strictly 1v1, allow groups of people to pool together on each side of a wager. Think of it as a private prediction market between two teams of friends.
How Team Play works:
A pool creator defines the wager (event, odds, deadline) and creates two sides. Participants join a side and contribute whatever amount they want, up to the pool's balance limit. The pool stays open for deposits until the funding deadline.
In this pool, Side A has $350 and Side B has $450. The total escrow holds $800.
Settlement with proportional payouts:
If the Chiefs win (Side A), the $800 pool is distributed proportionally among Side A contributors after protocol fees:
Total pool (after 5% fee): $760
Alex contributed 57% of Side A ($200/$350) → receives $434
Maria contributed 29% ($100/$350) → receives $217
Tom contributed 14% ($50/$350) → receives $109
Each winner gets back more than double their stake because Side B's total was larger than Side A's. The payout ratio for each individual depends on how much was on each side. It's a true market-driven price.
Contract architecture:
The pool contract extends the existing escrow pattern but replaces the two-party model with a contribution mapping:
Deposits are additive. A user can deposit multiple times to increase their position. Withdrawals before the funding deadline let users reduce or remove their stake. Once the deadline passes and both sides have non-zero totals, the pool locks and moves to ACTIVE.
Outcome submission uses the same blind mechanism, but with a designated pool creator (or elected captain per side) submitting on behalf of their team. Alternatively, the pool can use a majority vote among contributors.
Social dynamics: Team Play turns wagering into a group activity. A friend group creates a private pool for the playoffs, everyone picks a side, and the stakes make watching the games together more engaging. The invite link model from V1 extends naturally. The pool creator shares a link, and friends join whichever side they want.
4. API Documentation & AI Agent MCP
Full API documentation published as an OpenAPI/Swagger spec, making it trivial for developers to integrate BetBit into their applications. Interactive docs let developers test endpoints directly from the browser.
Model Context Protocol (MCP) server for AI agents. This is where things get interesting.
An MCP server wraps BetBit's API so that AI agents (Claude, GPT, custom agents) can interact with the wager protocol through natural language. An AI agent could:
Create wagers on behalf of a user: "Set up a $50 wager on the Lakers game with 3:1 odds, funding deadline in 3 days"
Check wager status: "What's the current state of my wager with Sam?"
Submit outcomes: "The Lakers won, submit my outcome as WON for wager #abc123"
Monitor a portfolio: "Show me all my active wagers and their current states"
Facilitate operator integration: An AI assistant for a sportsbook operator could manage their BetBit API integration, handle dispute escalation, and monitor settlement flows
The MCP server exposes BetBit's core operations as tools that any MCP-compatible AI client can call. This means users don't need to open the app at all. They can manage their wagers through whatever AI assistant they already use.
MCP tool definitions:
Each tool handles authentication, parameter validation, and transaction submission. The AI agent signs transactions through the user's existing passkey wallet, so there's no new trust model. The user still approves every fund-moving action with their biometric.
This positions BetBit as infrastructure that meets users wherever they are: in the web app, through an operator's platform, or via their AI assistant.
Future Considerations
These features are on the radar but not yet in active development:
Mainnet deployment with audited contracts and real USDC
Fiat on-ramp/off-ramp (MoonPay, Transak, or Circle integration)
Oracle integration (Chainlink) for automated outcome resolution on major sports events
Multi-chain deployment (Ethereum, Polygon, Arbitrum)
Native mobile apps with push notifications
KYC/compliance for regulated jurisdictions
Last updated