Development of Prediction Protocol (Azuro-style)
Centralized bookmakers are a black box. Bet limits, account freezes, opaque coefficient changes. Azuro solves this via on-chain protocol: liquidity pools as counterparty, smart contracts as bookmaker, oracles as result source. Building a similar protocol is not just contracts, it's a risk management system for LPs, precise margin mathematics, and resistance to oracle manipulation.
Core Protocol: How Azuro Model Works
Liquidity Pool as Counterparty
Unlike peer-to-peer betting (Augur-style protocols), Azuro uses pool-based model. Liquidity providers deposit assets into pool, which automatically acts as counterparty for all bets. LPs get share of fees proportional to their deposit.
Key LP risk: if one side of event is overloaded with bets, pool bears one-sided exposure. Azuro balances through reinforcement — dynamic coefficient change on imbalance. The more bets on one outcome, the lower the coefficient on it, higher on opposite. Mathematics:
newOdds = initialOdds * (1 - k * imbalanceFactor)
where imbalanceFactor is ratio of bets on each side. Correct calibration of k is critical. Too aggressive — coefficients drop to uninteresting. Too soft — pool accumulates one-sided risk.
Core/Express: Bet Structure
Azuro distinguishes Core (single bets) and Express (accumulators). In Express, product of coefficients creates large potential win, but payout only happens if all outcomes are correct. Express contract logic: check each event sequentially, if one lost — entire Express lost, all locked funds return to pool.
LP lockup — complex part. Upon bet acceptance, pool reserves potential payout (maxPayout = betAmount * odds). These funds unavailable for new bets while event unresolved. With many simultaneous events, locked/available ratio may drop to 0.2 — pool physically can't accept new bets. Need maxExposure per event and global maxLockFraction.
Oracle and Resolve: Where Protocols Break
Result resolution is most vulnerable spot. Centralized oracle is single point of failure and manipulation. Azuro uses Data Providers (DP) — authorized addresses able to confirm results. Multiple DPs, consensus mechanism for disputed cases.
Typical problems:
Delayed resolve. DP doesn't confirm result on time. Bets locked, LPs can't exit. Need timeout: if result doesn't arrive N hours after scheduled event time — bets auto-refund.
Wrong result. DP confirmed wrong outcome. Need dispute period (24-48 hours) + governance overrule via DAO or multisig. After dispute period result finalizes.
Cancelled event. Match cancelled (rain, VAR, disqualification). Protocol must support CANCELED status → full refund of all bets.
Contract Architecture
Key Components
LP Contract — liquidity management. ERC-20 LP tokens, addLiquidity, removeLiquidity with lock period (standard 7 days — protection from flash liquidity attacks). Tracks locked/available funds.
Core Contract — accepts bets. bet(uint256 conditionId, uint256 outcomeId, uint256 amount, uint256 minOdds, uint256 deadline). Parameter minOdds protects from odds slippage (like DEX slippage protection). deadline — bet rejected if block > deadline.
Condition — single event. Structure: conditionId, gameId, outcomes[], reinforcement, margin, state, ipfsHash. ipfsHash contains event metadata (teams, time, type). Storing strings on-chain is expensive.
PrematchCore / LiveCore — separate contracts for prematch and live bets. Live bets need more frequent coefficient updates (every minute) and different oracle logic.
| Component | Responsibility |
|---|---|
| LiquidityTree | LP position storage, withdrawable calculation |
| OddsLib | Coefficient math, reinforcement |
| AzuroBet (ERC-721) | NFT bet token |
| BettingEngine | Main bet and payout logic |
| DataProvider | Oracle for results |
| ProxyFront | Entry point with permit2 support |
Bet as NFT
Each bet is ERC-721 token. This allows: transfer bets between addresses, secondary market (sell pending bet), wallet aggregation. tokenURI generated on-chain or stored on IPFS with event metadata.
Margin Mathematics
Azuro bakes margin into coefficients — not explicit fee, but built-in spread. For binary outcome with true probability 50%/50%, coefficients won't be 2.0/2.0, but e.g. 1.9/1.9 at 5% margin. Mathematics:
margin = 1 - (1/odds1 + 1/odds2 + ...)
trueOdds = publishedOdds * (1 - margin)
With correct calibration, margin covers: DP operational costs, reserve for bad results, protocol treasury profit.
Development Process
Analytics (1 week). Determine: which sports/events, prematch only or + live, oracle model (centralized DP or Chainlink Functions), LP tokenomics.
Design (1-2 weeks). Contract architecture, LP lockup scheme, dispute resolution flow, governance.
Development (6-10 weeks). Smart contracts + oracle integration + Data Provider backend + subgraph for bet history + frontend. Parallel tracks.
Testing (2 weeks). Simulate extreme scenarios: 90% bets on one outcome, delayed resolve, simultaneous 1000 bet redeem.
Audit. Mandatory — protocol holds real user funds. Audit focus: oracle manipulation, LP drain through exotic event scenarios, reentrancy in payout.
Timeline Reference
Basic protocol with prematch bets and centralized DP — 2-3 months. Full protocol with live betting, dispute resolution and DAO governance — 4-6 months.
Cost calculated after detailed requirements assessment.