Azuro liquidity: New Deposit Losses and Withdrawal Timing

Shared capital for markets and LP returns

A pool supplies capital across its supported prediction markets and allocates their financial results among participants. A liquidity provider (LP) contributes the token the pool accepts. The deposit creates exposure to betting activity across those markets, while LiquidityTree tracks how that activity affects individual deposits.

A market within this system is a condition, which groups its possible outcomes. Betting apps give users access to conditions, and data providers manage their pricing and resolution. Supplying liquidity funds the pool behind this activity. An LP position therefore needs assessment against the pool's results and its entry rules, even when the depositor follows only particular events.

LiquidityTree and individual deposit accounting

LiquidityTree connects a pool's aggregate balance with separate records for individual deposits, using a structure called a segment tree.

Deposit entries and allocation history

A leaf is an individual deposit record within the tree. Parent nodes combine ranges of leaves, and the root holds their up-to-date total. When the pool assigns reinforcement, the capital allocated to a condition, its accounting remembers the relevant deposit range. Returning funds can then affect the appropriate entries without treating later deposits as earlier participants.

Deferred balance updates

Market activity changes balances without requiring a rewrite of every deposit record on every block. LiquidityTree records changes in parent nodes and applies them to the individual leaf during withdrawal. A stored leaf value alone may therefore omit changes recorded higher in the tree. The accounting must include those changes to establish the position's withdrawal balance.

Why can a new liquidity deposit show an early loss?

A new deposit faces losses on already open markets, while profit eligibility begins with markets created after entry. Profits from markets created before a deposit do not accrue to that new position. Existing market exposure can therefore reduce its balance before later markets produce eligible gains.

Market creation time sets this boundary. An event can finish after a deposit yet belong to a condition created earlier. The finishing time alone does not make that condition eligible to contribute profits to the newer position.

The initial skew discourages attempts to game LiquidityTree's accounting. Its size cannot be calculated from the deposit amount alone. The relevant market results and the position's exposure determine the effect, so an early shortfall does not identify a fixed deposit charge.

Later eligible profits can offset early losses, while further bettor outperformance can deepen them. Elapsed time allows more markets to resolve; it does not determine their results.

Market pricing and the pool's earning spread

Reinforcement allocates pool capacity to a condition and its outcomes, giving its virtual automated market maker (vAMM) the inputs for pricing. The data provider chooses the initial allocation and margin, the spread embedded in sell-side odds. Betting flows then adjust the odds within the condition. Each vAMM maintains virtual funds, accounting balances used in that market's pricing mechanism. These balances fluctuate with betting activity.

The vAMM handles the condition's pricing, while LiquidityTree tracks the effects across liquidity deposits. A spread gives the pool a potential earning source. The outcome of the betting activity still determines whether the pool gains or loses tokens when conditions resolve.

Resolved conditions and the LP reward balance

LP returns come from a share of the pool's financial result on resolved conditions, under the applicable reward distribution rules. The pool gains when a condition returns more tokens than the pool allocated to it. Returning fewer tokens produces a loss. This comparison concerns the pool's capital and returns, rather than one bettor's stake and winnings.

Reward accounting applies the applicable LP reward rate to each condition's pool profit or loss. Positive amounts add to the contributor balance, and negative amounts reduce it. The rate measures a share of that result, not an annual percentage of the original deposit. AzuroDAO can change reward splits, so the distribution rate cannot establish a fixed future return.

Data providers, apps, and AzuroDAO also participate in revenue distribution. Their rules differ: an app's positive-or-zero reward rule does not protect LP capital from a negative pool result.

Historical yield and the return since entry

A pool's displayed annualized yield describes past pool performance, while a new deposit starts with its own exposure history. The annual percentage rate (APR) calculation starts with daily rewards from resolved events divided by pool liquidity at the day's end. It then annualizes the daily return. A change in the liquidity denominator can alter the rate even when the reward amount stays the same. The pool's earlier returns may also include conditions a later deposit cannot share profits from. Neither a positive rate nor a profitable older position establishes the return earned by new capital.

A position-specific return compares its starting amount with its attributed balance in the same token. Its holding period begins at deposit, regardless of how long the pool has operated.

Pool compatibility across tokens and chains

Pool selection depends on the accepted token and blockchain, with separate contracts for different deployments. Azuro Portal organizes pools by token and chain. Protocol V2 and V3 also have distinct deployment records. A deposit's accounting belongs to the particular pool holding it, so a balance from another environment cannot explain that deposit's performance.

Production V3.0.13 deployments include Polygon, Gnosis, Base, and Chiliz. Those contract environments do not establish which pools every interface displays or accepts deposits into. Development deployments also have their own records. The chain, token contract, and pool deployment must describe the same position before its balances can support a return calculation.

What changes when the initial lock ends?

Azuro's LP terms allow withdrawals after an initial seven-day lock. The end of that lock changes access to the position, while its balance continues to reflect the applicable pool results.

Access to the attributed balance

The withdrawal amount depends on the position's accounted balance. A negative position does not recover its original principal merely because the lock expires. Keeping funds in the pool leaves them exposed to later eligible results.

The end of unresolved-market exposure

A completed withdrawal ends the withdrawn capital's exposure to unresolved prediction markets. That capital no longer participates in their later pool results. A completed bet cashout closes a bettor's wager, which is a different operation from removing an LP position. A cashout offer therefore cannot establish the value available for a liquidity withdrawal.

Network costs alongside pool performance

Deposits and withdrawals require onchain accounting work, including creating deposit entries and updating balances affected by earlier market activity. LiquidityTree reduces repeated balance updates through deferred bookkeeping. Those savings concern how the contracts maintain records; transaction costs still depend on the network and the work an operation performs. A fixed gas amount cannot describe every deposit or withdrawal.

Pool performance and network spending affect a depositor's overall result through different mechanisms. A position can lose tokens through betting outcomes before counting gas. Gas paid in another token requires a consistent valuation before combining it with the position's return. Subtracting unlike token amounts would produce a misleading total.

A shortfall calculated within the same pool

Suppose a deposit record shows 1,246 units of a pool's accepted token, while a later position view shows 1,216 units. Both amounts and this position state are hypothetical. The depositor wants to understand the apparent shortfall before considering another transaction.

View image file

The comparison first requires the original pool, token, blockchain, and deployment, plus a balance including deferred LiquidityTree adjustments. A balance from another environment cannot diagnose this deposit. With matching records, 1,216 minus 1,246 gives a loss of 30 token units. Dividing the signed change of -30 by 1,246 and multiplying by 100 gives a return of about -2.41%, before network costs.

This calculation measures the decline without identifying which conditions caused it. The initial exposure rules can explain an early loss, but the balance difference alone does not establish a deposit fee. Gas remains a separate cost unless its value has been expressed in the same token units.

If the 1,216-unit reading belongs to a different token, chain, pool, or deployment, the calculation no longer describes the deposit's return. Returning to the original pool's records resolves that comparison problem. It does not recover tokens lost through the position's actual betting exposure.

Continuing exposure and a recovery date

Exposure across a pool's markets spreads activity among events while leaving the pool as the counterparty to bettors. A broader set of markets can still produce an aggregate loss, and the position's entry history determines how its accounting reflects those results.

Extended bettor outperformance can leave a position negative well beyond its initial lock. Recovery requires enough later eligible gains to offset the accumulated loss. Withdrawing capital ends its participation in that possible recovery, as well as its exposure to further pool losses.