Blockchain Betting Liquidity Pools Development
Centralized betting platforms work simply: house takes all risk and sets odds with margin in its favor. In decentralized betting, risk is distributed among liquidity providers — they take the house role and get margin income, accepting possible losses on unusual outcomes.
Protocols like Azuro build this infrastructure. Provider deposits USDC in pool, bets go against it, odds adjust dynamically based on bet volume and current exposure.
Key problem: managing exposure
Bet imbalance
If 90% of bets go one direction (e.g., on Real's win in derby), pool bears huge directional risk. One result — LP providers lose, other result — earn.
Dynamic odds as solution: when exposure exceeds threshold on one side, odds on that side automatically lower (less attractive), opposite side odds rise. This balancing mechanism works without centralized market maker.
function calculateOdds(
uint256 eventId,
uint8 outcomeId
) public view returns (uint256 odds) {
ExposureData memory data = exposures[eventId];
uint256 totalPool = data.lpLiquidity;
uint256 sideExposure = data.outcomeExposure[outcomeId];
// Higher exposure on side = lower odds
uint256 adjustedPool = totalPool - sideExposure * MARGIN_FACTOR / 1e18;
odds = (adjustedPool * 1e18) / (adjustedPool - sideExposure);
}
Simplified formula. Real systems use complex models accounting for correlated events (multiple matches in tournament), liquidity depth and market maker oracle for initial odds.
Result oracle and manipulation
Most vulnerable point of any betting protocol. Who determines match result? Centralized oracle — both failure point and trust anchor. Oracle compromise = drain all liquidity.
Several approaches:
Chainlink Functions / Any API — Chainlink requests data from multiple sports APIs (Sportradar, API-Football), aggregates result via threshold consensus. Need simultaneous attack on multiple sources.
UMA Optimistic Oracle — result published by provider, dispute period follows. If no challenge — considered valid. If challenged — UMA stakers vote. Slower but more decentralized.
Kleros — decentralized arbitration for disputes, not every match.
For production — combination: auto-resolve via Chainlink for clear results, Kleros for edge cases (match halted, technical incidents).
Contract architecture
Liquidity pool structure
Like Uniswap LP but with differences:
- LP token represents pool share (like AMM LP token)
- Liquidity locked during active event periods (can't withdraw while open bets exist)
- Withdrawal queue on mass exit
struct LiquidityPool {
uint256 totalLiquidity; // USDC in pool
uint256 lockedLiquidity; // locked for open bet coverage
uint256 totalShares; // LP tokens
mapping(address => uint256) shares;
}
function addLiquidity(uint256 amount) external {
// shares calculated proportional to current pool value
uint256 newShares = totalShares == 0
? amount
: amount * totalShares / totalLiquidity;
// ...
}
lockedLiquidity — maximum possible payout on all open bets. LP can't withdraw below this. Safety invariant: pool always capable to settle current bets.
Bets as NFT or fungible?
Two approaches: bet as ERC-721 NFT (unique, tradeable on secondary market) or as contract mapping record.
ERC-721 enables betting marketplace — user can sell winning bet before event concludes. Additional liquidity for users and revenue for protocol (secondary fee). Azuro uses this via betting ERC-721.
Tradeoffs: slightly higher creation gas (~50k vs ~30k for mapping), harder audit.
LP economics
LP yield = betting platform margin - winning bet payouts. At 5% margin and balanced bets — LP earns ~5% annually plus additional yield from unused liquidity (stake USDC in Aave while events closed).
Risk: series of upset results (underdogs win) — LP loses. Insurance fund from part of fees partially buffers.
Timeline estimates
Basic betting pool with fixed odds and centralized oracle — 1-2 weeks. Full protocol with dynamic odds, Chainlink oracle, LP tokenomics and secondary bet market — 6-10 weeks.
Cost calculated after discussing architecture and result data sources.