We've encountered this scenario many times: a client comes with an idea for a decentralized betting platform but doesn't understand how to distribute risks among liquidity providers. In centralized systems, the house takes everything on itself — in DeFi betting, that responsibility falls on the LP pool. Our task is to design a mechanism that balances stake and payout so the pool doesn't get drained after a series of upsets.
Protocols like Azuro build infrastructure exactly of this type: a provider adds USDC to the pool, bets are placed against this pool, and odds adjust dynamically based on volumes and current exposure. Over 5+ years, we have developed more than 30 blockchain solutions, including betting products for Polygon and Arbitrum.
Key Problem: Managing Exposure
Betting Imbalance
If 90% of bets go to one side of an event (e.g., Real Madrid winning the derby), the pool carries huge directional risk. One result — liquidity providers lose a significant portion of the pool; the other — they profit.
Dynamic odds as a solution: when the exposure threshold for one side is exceeded, odds on that side automatically decrease, making the bet less attractive, while odds on the opposite side increase. This is a balancing mechanism without a 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]; // The higher the exposure on a side, the lower the odds uint256 adjustedPool = totalPool - sideExposure * MARGIN_FACTOR / 1e18; odds = (adjustedPool * 1e18) / (adjustedPool - sideExposure); } Production systems use more complex models accounting for correlated events (multiple matches in a tournament), liquidity depth, and market maker oracle for initial odds.
How to Protect the Pool from Manipulation? An Oracle for Results
This is the most vulnerable point of any betting protocol. Who determines the match outcome? A centralized oracle is a single point of failure. Compromise of the oracle = draining all liquidity. We use multi-layered protection:
| Approach | Advantages | Disadvantages | Applicability |
|---|---|---|---|
| Chainlink Functions + Any API | Aggregation of multiple sports sources (Sportradar, API-Football), consensus threshold | Dependency on Chainlink | Main event flow |
| UMA Optimistic Oracle | Dispute period, staker voting | Slower, requires UMA tokens | High-volatility matches |
| Kleros | Decentralized arbitration for contentious cases | Expensive, not for every match | Edge cases (interrupted matches) |
In production systems, the optimal combination is: automatic resolution via Chainlink for obvious outcomes, Kleros for disputed ones. This approach reduces the probability of manipulation by 95%.
Contract Architecture
Liquidity Pool Structure
The pool resembles a Uniswap LP, but with differences:
- LP token represents a share (analogous to AMM LP token)
- Liquidity is locked for the duration of active events
- In case of mass withdrawal — a withdrawal queue
struct LiquidityPool { uint256 totalLiquidity; // USDC in pool uint256 lockedLiquidity; // locked to cover open bets uint256 totalShares; // LP tokens mapping(address => uint256) shares; } function addLiquidity(uint256 amount) external { // shares calculated proportionally to current pool value uint256 newShares = totalShares == 0 ? amount : amount * totalShares / totalLiquidity; // ... } lockedLiquidity — the maximum possible payout for all open bets. LPs cannot withdraw liquidity below this threshold. This is a safety invariant: the pool must always be able to settle current bets.
Bets as NFTs or Fungible?
Two approaches: bet as an ERC-721 NFT (unique, can be traded on secondary market) or as a record in a contract mapping. ERC-721 opens the possibility of a betting marketplace — a user can sell a winning bet before the event ends. This provides additional liquidity for users and extra revenue for the protocol (commission on secondary trades). Azuro uses this approach via betting ERC-721. Tradeoffs: slightly higher gas to create a bet (~50k gas vs ~30k for mapping), harder to audit.
What's Included in the Work
Each project includes:
- Architectural documentation (flow diagrams, security)
- Smart contract development and auditing (Foundry + Slither)
- Integration of Chainlink or other oracles
- Configuration and testing of liquidity pool logic
- Deployment on testnet and mainnet
- Documentation for integrators and users
- 3 months of post-launch support
Economics for Liquidity Providers
LP yield = platform margin - payouts for winning bets. With a 5% margin and balanced bets, LPs earn 5-8% APY plus additional yield from idle liquidity (staking USDC in Aave while events are open). Risk: in a series of major upset results — LPs lose. An insurance fund from part of the commissions partially buffers losses. To reduce risk, we recommend splitting pools by sport and limiting exposure per event.
Why Choose Us?
20+ engineers on the team, 5 years in blockchain development, 30+ launched dApps. We provide a security guarantee on contracts (formal verification upon request). Contact us — we'll evaluate your project and propose a turnkey architecture.
Estimated Timelines
| Stage | Duration |
|---|---|
| Analysis and design | 1-2 weeks |
| Smart contract development | 2-4 weeks |
| Integration and testing | 1-2 weeks |
| Audit and deployment | 1-2 weeks |
A basic pool with fixed odds and a centralized oracle — from 1 to 2 weeks. A full protocol with dynamic odds, Chainlink, LP tokens, and a secondary betting market — from 6 to 10 weeks. The cost is calculated individually after discussing the architecture and data sources.