Azuro is best understood as shared-liquidity prediction-market infrastructure, not just as a sportsbook app. The docs repeatedly separate pools, betting engines, conditions, LP accounting, and execution / affiliate layers.
The most important mechanism is the singleton LP plus LiquidityTree. Azuro is trying to let many live conditions share one capital base while deferring most LP-specific updates until withdrawal time.
Reinforcement and virtual-fund accounting are the key risk-allocation surfaces. Reinforcement seeds pricing and caps condition-level worst-case loss, while virtual fund tracks extra LP capacity booked as betting flows change.
Data providers are not a cosmetic role. They create conditions, set reinforcement and margin, push odds, and resolve outcomes, which means pricing and market-admission power sit with them more than with an abstract neutral pool alone.
The docs expose a useful governance tension: one page says anyone can deploy pools via the Factory, while the TL;DR flow says pool requests are approved through a Factory owned by AzuroDAO before deployment. That practical gatekeeping question is more important than generic permissionless rhetoric.
The architecture pages make clear that relayers, paymasters, affiliates, and freebet flows form a separate access-and-distribution layer above raw betting logic.
Specific source signals worth retaining
knowledge-hub/how-azuro-works/tl-dr: best concise explanation of condition creation, reinforcement, virtual funds, singleton LP capacity, and outcome resolution.
knowledge-hub/how-azuro-works/liquidity-tree: most important source for the novel accounting mechanism and for why Azuro treats shared LP infrastructure as a custom data-structure problem.
knowledge-hub/how-azuro-works/components/conditions: useful because it shows the actual condition-level state variables, including reinforcement, virtual funds, margin, oracle, and condition flags.
hub/blockchains/architecture: best architecture overview for factory / LP / vault / access / relayer / paymaster decomposition.
protocol-actors/liquidity-providers: useful because it explains the unusual exposure timing of LP deposits and why new LP positions can begin in the red before later markets generate offsetting gains.
Why this entry belongs in the corpus
It gives the library a missing prediction-market infrastructure baseline where shared liquidity, odds control, capital booking, and market resolution are all explicit.
It is a good comparison point for AMM-coupled leverage, sportsbook-style market making, and any system that claims one pool can underwrite many concurrent markets without making the accounting layer legible.
The durable insight is that onchain prediction markets are not just market creation + oracle resolution; the reusable mechanism often sits in how capital, pricing authority, and condition-level risk are partitioned across pools, operators, and data providers.