Summary: Azuro is worth cataloging not as just another sportsbook frontend or prediction-market brand, but as a reusable liquidity-and-control-plane design for onchain betting. Its primary materials split the system into Factory-deployed pools, owner-pluggable betting engines, data-provider-managed conditions, a singleton liquidity pool, and a custom LiquidityTree accounting layer that lets many live markets share one capital base while still supporting deposits and withdrawals. That makes Azuro a useful comparison point for prediction markets, market-making systems, and intent-style routing stacks because the real control surfaces are not just event resolution or odds display, but who can launch pools, who can create and price conditions, how reinforcement and virtual-fund limits allocate LP risk, and how much frontends, affiliates, relayers, and DAO-controlled deployment gates shape access to orderflow.
What it does:
Lets pool owners deploy unified betting platforms on EVM chains through a Factory contract, then plug in one or more betting engines that create conditions, accept bets, compute payouts, and route app rewards
Uses a singleton LP shared across many active conditions so one liquidity base can underwrite thousands of concurrent markets instead of siloing liquidity per market
Has data providers create and manage conditions with chosen reinforcement, margin, and oracle-resolution parameters, which in turn determine initial odds, max-loss caps, and live pricing behavior
Tracks LP balances and condition-driven liquidity booking through LiquidityTree, a segment-tree-based accounting system designed to defer most per-user updates until withdrawal time
Supports customizable oracle and pool settings per chain, including public or private pool choices and different plugged-in contract modules
Adds a distribution and execution layer above core market logic through affiliates, relayers, freebet / paymaster flows, and sponsored transaction handling
Key claims:
Azuro clears the bar because it makes prediction-market infrastructure legible as several layers that consumer betting apps usually flatten together: pool deployment, risk allocation, odds control, market resolution, and frontend / affiliate distribution.
The singleton-LP plus LiquidityTree design is the most reusable mechanism insight. Azuro is not just pooling capital; it is trying to solve the specific accounting problem of how one liquidity base can fund many concurrent conditions, attribute profit and loss fairly, and still allow live deposits and withdrawals without updating every LP position on every block.
Reinforcement and virtual fund are analytically important because they separate two usually hidden questions: how much initial liquidity and pricing support a condition gets, and how much additional LP capacity it books as betting flows change. That makes Azuro a useful comparison point for prediction markets that hide their capital-allocation logic behind one generic AMM or orderbook label.
The docs make clear that data providers are real control surfaces. They create conditions, set reinforcement and margin, push odds, and resolve outcomes, while AzuroDAO is presented as the arbiter of last resort when needed.
The architecture docs also show a meaningful governance tension: the knowledge-hub TL;DR says pool requests go through a Factory owned by AzuroDAO and are approved before deployment in the reference flow, while other docs frame pool deployment as open through the Factory. That is exactly the sort of practical-versus-nominal openness distinction worth retaining in the corpus.
Azuro’s broader stack matters because the protocol is not only contracts for betting logic. Relayer, PayMaster, affiliate, and freebet flows create a distinct access-and-distribution layer where sponsored execution and frontend control can shape who actually captures users and orderflow.
Azuro belongs in the active corpus because it gives the library a strong prediction-market base-layer entry where shared liquidity, risk booking, and data-provider authority are explicit instead of hidden inside one app brand.
Whitepaper: No canonical standalone Azuro whitepaper surfaced in this pass. The strongest primary materials were the official docs and open-source repositories collected in ../whitepapers/azuro-primary-sources-2026-05-13.md.