Pricing Mechanism: Azuro vAMMs

In the context of prediction markets, conventional AMMs used by first-generation protocols require sophisticated entities to hold inventory over its constituent “YES” and “NO” tokens as a byproduct of its initial liquidity bootstrapping process, as well as the active management of said liquidity when the prediction market is live. The Azuro vAMM do not require separate bootstrapping instances: they immediately inherit liquidity from the singleton LP on market creation.

Counterintuitively, Azuro data providers do not stream odds via decimal points (or percentages) — they do it by specifying the liquidity bands for each outcome within a Condition.

Suppose a Condition ”FullTimeResult” has three outcomes “1X2”:

• The Data Provider will first ‘book’ a certain amount of Reinforcement (i.e., $100k) from the singleton LP, then split it across the three outcomes (i.e.; $30k on 1; $50k on X; $20k on 2).
• This Reinforcement split is what sets the market’s initial (sell-side) odds: 30%, 50%, and 20%.

Each Condition is represented as a vAMM. Depending on the number of outcomes in a Condition, the vAMM could be a 2-pool, 3-pool, 4-pool, you name it!

When bettors place a bet, they trade one side of the pool, which lowers the odds for the said outcome while increasing the odds of the other outcomes. This self-adjusting price mechanism is similar to conventional AMMs: assuming a 2-pool AMM consisting of $A and $B, if a trader buys $A with $B, it will push the price of $A while simultaneously lowering the price of $B.

Each vAMM maintains its own Virtual Fund, in which its balance fluctuates according to the real-time betting flows of its underlying prediction market.