We develop Azuro-style prediction protocols — decentralized sports betting systems where liquidity pools act as the counterparty and smart contracts replace the bookmaker. This approach leverages on-chain betting and sports betting smart contracts for trustless operations. You get an on-chain solution with transparent math and manipulation resistance. The protocol combines DeFi prediction market mechanics with a pool-based counterparty. Our experience: 5+ years in Web3 and 10+ implemented protocols. We guarantee an audit-ready codebase and provide a 6-month post-launch warranty. Contact us to assess your turnkey project.
How the Azuro Model Works
Liquidity Pool as Counterparty — Prediction Protocol Development
Unlike peer-to-peer betting protocols (e.g., Augur), Azuro uses a pool-based model. Liquidity providers deposit assets into the pool, which automatically acts as the counterparty for all bets. LPs receive a share of fees proportional to their contribution.
The key LP risk: if one side of an event is overloaded with bets, the pool faces one-sided exposure. Azuro balances this via reinforcement — dynamic odds adjustment on imbalance. The more bets on one outcome, the lower its odds and the higher the opposite outcome's odds. The math:
newOdds = initialOdds * (1 - k * imbalanceFactor)
where imbalanceFactor is the ratio of bets on each side. Proper calibration of k is critical — too aggressive makes odds uninteresting; too soft accumulates one-sided risk. Typically, k is set between 0.01 and 0.05.
Core/Express: Bet Structures
Azuro distinguishes Core (single bets) and Express (accumulators). In Express, the product of odds creates a large potential payout, but payment occurs only if all outcomes are correct. Contract logic: check each event sequentially; if one loses, the entire Express loses and all locked funds return to the pool.
LP lockup is a complex part. When a bet is accepted, the pool reserves the potential payout (maxPayout = betAmount * odds). These funds are unavailable for new bets until the event is resolved. With many concurrent events, the locked/available ratio can drop to 0.2 — the pool cannot accept new bets. Mechanisms like maxExposure per event and global maxLockFraction are needed.
Oracle and Resolve: Where Protocols Break
Result resolution is the most vulnerable point. A reliable sports oracle is essential. A centralized oracle is a single point of failure and manipulation. Azuro uses Data Providers (DP) — authorized addresses that confirm results. Multiple DPs and a consensus mechanism handle disputes.
Typical problems:
- Delayed resolve: DP does not confirm the result on time. Bets are locked, LPs cannot exit. Need a timeout: if no result within N hours after scheduled event time — bets are automatically refunded.
- Wrong result: DP confirmed an incorrect outcome. Need a dispute period (24–48 hours) + governance overrule via DAO or multisig. After the dispute period, the result is finalized.
- Cancelled event: match canceled (rain, VAR, disqualification). The protocol must support a
CANCELEDstatus → full refund of all bets.
Contract Architecture
Key Components
- LP Contract — manages liquidity. ERC-20 LP tokens,
addLiquidity,removeLiquiditywith lock period (standard 7 days — protection against flash liquidity attacks). Tracks locked/available funds. - Core Contract — accepts bets.
bet(uint256 conditionId, uint256 outcomeId, uint256 amount, uint256 minOdds, uint256 deadline). ParameterminOddsprotects against odds slippage (like slippage protection in DEX).deadline— bet is rejected if block > deadline. - Condition — a single event. Structure:
conditionId, gameId, outcomes[], reinforcement, margin, state, ipfsHash.ipfsHashcontains event metadata (teams, time, type). Storing strings on-chain is expensive. - PrematchCore / LiveCore — separate contracts for prematch and live bets. Live bets require more frequent odds updates (every minute) and different oracle logic.
| Component | Responsibility |
|---|---|
| LiquidityTree | Store LP positions, calculate withdrawable |
| OddsLib | Odds math, reinforcement |
| AzuroBet (ERC-721) | Bet NFT token |
| BettingEngine | Main bet and payout logic |
| DataProvider | Oracle for results |
| ProxyFront | Entry point with permit2 support |
Bet as NFT
Each bet is an ERC-721 token, representing ERC-721 bets. This enables: transfer of bets between addresses, secondary market (sell pending bet), aggregation in wallet. tokenURI is generated on-chain or stored on IPFS with event metadata.
Margin Math
Azuro embeds margin into odds — not an explicit fee, but a built-in spread. For a binary outcome with true probability 50%/50%, odds would be not 2.0/2.0 but e.g., 1.9/1.9 at 5% margin. Margin typically ranges from 5-10% for binary outcomes and 10-15% for multi-outcome events. Math:
margin = 1 - (1/odds1 + 1/odds2 + ...)
trueOdds = publishedOdds * (1 - margin)
Properly calibrated margin covers: DP operational costs, reserve for bad results, protocol treasury profit.
Why Azuro Model is Better than Peer-to-Peer?
In P2P protocols (Augur, PolyMarket), liquidity is distributed across outcomes, leading to large spreads and insufficient depth for large bets. Azuro's pool-based model concentrates liquidity: one pool serves all events, and reinforcement dynamically redistributes it. Comparison:
| Parameter | P2P (Augur) | Pool-based (Azuro) |
|---|---|---|
| Market depth | Depends on number of traders | Single pool |
| Spread | High at low activity | Low, regulated by reinforcement |
| Execution time | Can be slow | Instant |
| LP risk | No direct LP | Requires risk management |
Azuro protocol documentation
How to Protect the Liquidity Pool from One-Sided Risk?
The key task is to prevent the pool from covering all bets on one outcome. Azuro uses reinforcement, but that alone is insufficient. LP risk management involves several measures.
- Max exposure per event — limit on bet amount per event. Bets exceeding it are rejected.
- Global lock fraction — maximum percentage of locked funds from total pool (usually 80–90%). Exceeding blocks new bets.
- LP lock period — 7 days to prevent pump-and-dump liquidity.
- Dispute period — protection against incorrect results.
Typical Development Mistakes
- Missing
minOdds— bets go through with unfavorable odds after changes. - Incorrect
kcalibration — reinforcement too aggressive or too weak. - Ignoring cancelled events — funds get stuck forever.
- Centralized oracle without protection — one vulnerability breaks the whole protocol.
Process
- Analysis (1 week). Define: 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. Solidity development with Foundry and Hardhat.
- Testing (2 weeks). Simulate extreme scenarios: 90% bets on one outcome, delayed resolve, simultaneous 1000 bet redeem.
- Audit. Smart contract audit is mandatory — the protocol holds real user funds. Audit focus: oracle manipulation, LP drain via exotic event scenarios, reentrancy in payout.
What's Included
- Architecture documentation and flow diagrams
- Smart contract source code (Solidity) with unit tests
- Oracle integration (Data Provider or Chainlink)
- Subgraph for bet history (The Graph)
- Deploy scripts and deployment documentation
- Team training (2–3 days)
- Post-launch support (1 month)
- Over 5 years of experience in blockchain development, 10+ successful protocol launches
Timeline Estimates
Basic protocol with prematch bets and centralized DP — 2–3 months. Full protocol with live betting, dispute resolution, and DAO governance — 4–6 months. Average cost starts from $50,000, with savings of up to 40% vs traditional bookmaker software. A full protocol with all features costs between $100,000 and $200,000.
Cost is calculated after detailed requirements assessment. Request a consultation — we'll evaluate your project.