Feature Prioritization (MoSCoW)
Feature Prioritization (MoSCoW Framework)
Must Have
These features are non-negotiable for the protocol to function. Without any one of them, the product doesn't work.
Smart Contract Escrow
The entire value proposition. USDC deposits held in an immutable contract with coded settlement rules. Neither party can access funds outside the defined lifecycle. This is what makes BetBit trustless.
Status: Implemented. WagerEscrow.sol deployed on Fuji with full lifecycle support.
Wager State Machine (Full Lifecycle)
The 11-state progression from creation through settlement/refund. Each state has defined transitions, and the contract enforces them. You can't withdraw from an ACTIVE wager. You can't submit outcomes before both parties deposit.
Status: Implemented. All state transitions tested end-to-end.
USDC Deposits and Withdrawals
Both parties must be able to deposit USDC into escrow and withdraw after settlement. The contract uses SafeERC20 and pull-pattern withdrawals for security.
Status: Implemented. Approve + deposit batched into single UserOperation.
Outcome Submission with Truth Table
Independent (blind) outcome submission by both parties, with an automated truth table that determines the result. Matching outcomes auto-settle; conflicts escalate to dispute.
Status: Implemented. All 9 truth table combinations handled in the contract.
User Authentication
Users need accounts to create and track wagers. Email/password authentication with JWT tokens for API access.
Status: Implemented. Signup, login, and session management working.
ERC-4337 Smart Wallets
Account abstraction so users authenticate with passkeys (biometrics) instead of managing seed phrases. This is what makes the app accessible to non-crypto-native users.
Status: Implemented. ZeroDev Kernel v0.3.1 with WebAuthn P-256 passkeys.
Gas Sponsorship
Users should never need to hold AVAX or understand gas. Every UserOperation is sponsored by the Pimlico paymaster.
Status: Implemented. All transactions gas-free for users.
Shareable Invite Links
The second party needs a way to find and accept a wager. HMAC-signed invite URLs shared via messaging apps (WhatsApp, Telegram, etc.) serve as the primary distribution mechanism.
Status: Implemented. Invite pages with on-chain reads and account creation flow.
Should Have
Important features that significantly improve the experience but aren't strictly required for the core flow to work.
Blind Outcome Submission UI
Hiding the first party's outcome choice from the second party until both have submitted. Without this, the second party could game their response based on what the first party chose.
Status: Implemented. The frontend masks outcomes until both are recorded on-chain.
On-Chain Direct Reads (Subgraph Bypass)
Reading deposit status and wager state directly from the contract via eth_call instead of waiting for the subgraph to index. Eliminates the 5-30 second lag that caused stale UI states.
Status: Implemented. readWagerOnChain() used for all real-time state checks.
Dashboard with State Badges
A central view showing all of a user's wagers with color-coded state badges (Pending, Active, Settled, etc.) so they can see what needs attention at a glance.
Status: Implemented. Dashboard queries both creator and taker wagers.
Rate Limiting and Security Hardening
API rate limiting on all endpoints (stricter on auth), security headers, CORS restrictions, and server-level protections including firewall rules, brute force protection, and reverse proxy rate limiting.
Status: Implemented at both application and infrastructure level.
Transaction History
A profile page showing past transactions (deposits, withdrawals, settlements) with amounts and timestamps.
Status: Implemented on the settings/profile page.
Protocol Fee Collection
5% protocol fee deducted from winning payouts. Accumulated in the contract for operator withdrawal. Fee rate snapshotted at wager creation so changes don't affect existing wagers.
Status: Implemented in the contract with hardcoded 10% cap.
Could Have
Nice-to-have features that would enhance the product but can be deferred without impacting the core experience.
Mediator Dispute Resolution (Full Flow)
The smart contract supports a complete dispute resolution system: mediator ruling, 48-hour appeal window, mediator replacement voting, and operator escalation. The frontend has partial UI for this, but the full mediator management flow (approving mediators, submitting rulings through the app) isn't fully polished.
Status: Contract logic complete. Frontend has mediator approval page but the full dispute flow is not end-to-end tested in production.
Email Notifications
Email notifications for wager events (opponent deposited, outcome submitted, dispute raised). The notification infrastructure and logging are in place, but the triggers aren't fully wired up.
Status: Infrastructure in place, triggers partially implemented.
Telegram Notifications
Bot-based notifications for wager events via Telegram.
Status: Infrastructure in place, not fully implemented.
Admin Panel
Management dashboard for protocol operators: view all wagers, manage disputes, adjust fees, monitor platform health. Frontend has admin routes and UI scaffolded.
Status: UI scaffolded, not fully functional.
Wager Cancellation
Creator can cancel a wager before the taker deposits, getting their creation deposit back (creation fee is non-refundable). The contract supports this, but the frontend cancel button may not be fully wired up.
Status: Contract logic complete, frontend partially implemented.
Expiration Handling
Automatic state transitions when funding or outcome deadlines pass. The contract handles this, but it requires someone to call handleOutcomeExpiration(). There's no automated keeper bot triggering these calls.
Status: Contract logic complete, no automated triggering.
Won't Have (for this competition)
Features that are out of scope for the current build but would be part of a production roadmap.
Mainnet Deployment
The current build runs on Avalanche Fuji testnet with MockUSDC. A mainnet deployment would require audited contracts, real USDC integration, and production-grade key management.
Fiat On-Ramp / Off-Ramp
Letting users buy USDC with credit cards or bank transfers, and convert winnings back to fiat. Would require integration with services like MoonPay, Transak, or Circle.
Automated Outcome Feeds (Oracle Integration)
Connecting to Chainlink or another oracle to automatically resolve wager outcomes based on real-world sports scores. This would eliminate the need for manual outcome submission and the truth table entirely.
KYC / Compliance
Know Your Customer verification for regulatory compliance in jurisdictions that require it. Would need integration with identity verification providers.
Multi-Currency Support
Supporting wagers in tokens other than USDC (ETH, AVAX, etc.). Would require price feeds and more complex settlement math.
Note: Several features previously in this "Won't Have" category, including variable odds, multi-party pools, operator API integration, and an AI agent MCP, have moved into active V2 development. See the Product Roadmap for details on what's coming next.
Last updated