Azuro
Azuro cashout offers reflect changing live odds
Azuro cashouts let bettors close eligible bets in full before an event ends, using offers influenced by live odds and the current event state. A completed cashout fixes the payment for that bet. Availability applies to particular markets and bets, so an open wager does not automatically qualify.
The short version: A completed full cashout ends the wager's exposure, so later event results cannot change its cashout payment.
An eligible bet before a cashout request
A cashout request starts with the selected bet's eligibility and an offer calculated for its owner and blockchain environment. The bettor authorizes the calculated terms before the app submits the request. An unavailable response stops that path before an early settlement can occur. A later availability check may reveal an offer, but repeating a request cannot create eligibility for an unavailable wager.
An app can display a live market without offering early settlement for every wager on it. Apps choose which protocol markets to present, while cashout availability concerns eligible bets. A missing control and an unavailable offer therefore describe different limits.
Full settlement closes the whole wager
A full cashout exchanges the bet's remaining exposure for the offered amount. A completed full cashout closes the entire bet. Later changes in the event cannot increase or reduce its cashout payment. The prematch and live feature supports full settlement; partial cashouts are unavailable. That limitation matters when the intention is to recover only part of a stake while leaving the rest exposed to the result.
The price behind the live offer
A cashout amount reflects the event's current state and the odds of the bet winning or losing. The accepted odds describe the terms when the bet was placed. Available odds describe the market now. A later offer can therefore move even though the stake and chosen outcome remain unchanged. The software development kit (SDK) returns precalculated cashout values as estimates. The dedicated calculation provides an amount for a specific bet, account, and environment. An earlier number in a betting history may differ from the calculated offer available when a cashout request begins.
For an ordinary bet, precalculation combines the wager amount, its accepted odds, the available outcome odds, and a returned margin multiplier. The odds comparison alone does not determine the estimate.
Changed odds
When the accepted and available odds differ, the estimate equals the wager amount multiplied by their ratio, then by the returned margin. The accepted odds form the numerator; the available odds form the denominator.
Unchanged odds
When those odds are equal, precalculation uses
marginMin
in place of the regular margin. Equal odds therefore do not automatically make the estimated cashout equal to the original stake.
A request sent to an incompatible environment
In this hypothetical example, an app displays an unresolved bet funded from the bettor's wallet. The bet belongs to a supported production environment, but the app requests its cashout calculation in an environment the service does not support. The service returns an environment-unavailable error. The missing quote concerns incompatible request settings; it says nothing about which event outcome will win.
The app corrects the request to match the bet's actual environment and owner, preserving the original bet identifier. Assume the renewed availability check permits cashout and a fresh calculation returns an offer. The bettor reviews the terms, supplies the required authorization, and submits the request. Its created order initially reports
PROCESSING
, leaving completion unresolved.
The order later returns a transaction hash. Its receipt confirms a successful cashout, and the bet record shows the early settlement completed. The bettor now has a closed wager, even though the event remains unresolved. Correcting the request's environment selected the existing bet's context; it did not transfer the wager to another network.
Expiry limits and wallet authorization
A calculated cashout carries expiry information because an offer must remain valid through the request and its onchain execution. The wallet's signed authorization also binds the intended bet and network. A quoted amount alone does not grant permission to close the wager.
The request and execution windows
Sending the request
The
approveExpiredAt
deadline limits when the request to create a cashout must be sent. Reviewing an offer consumes part of that window.
Executing the cashout
The
expiredAt
deadline includes contract execution. An earlier submission cannot make an execution after that deadline valid.
Cashout signing uses EIP-712 typed data, which gives the wallet structured terms to authorize. These identify the bet, chain, cashout odds, and expiry. The signed terms accompany a calculation identifier when the app submits the order. A signature records authorization; it does not establish successful settlement.
Order records and payment onchain
A cashout order identifies a request the service has received, while a successful transaction receipt establishes execution on the network. Order details can include a state, transaction hash, and error message. The listed states are
OPEN
,
PROCESSING
,
ACCEPTED
, and
REJECTED
. An order identifier or status label alone does not establish that a payment reached the bettor. The SDK's
useCashout
hook exposes pending and processing indicators alongside a cashout receipt. Its approval indicators are separate from its cashout indicators. A successful approval concerns permission for the action. The cashout receipt concerns settlement itself, so an app must distinguish those results when it reports completion.
Bet cashouts and pool withdrawals
A bettor's cashout closes an individual wager, while a liquidity provider's withdrawal removes capital from a pool. Withdrawing liquidity ends the withdrawn capital's exposure to unresolved prediction markets. Pool capital supports betting, but these actions affect different holdings. A liquidity withdrawal does not close a bettor's wager, and a cashout offer does not describe the withdrawable value of a liquidity position.
Early settlement versus waiting for resolution
Ordinary redemption concerns a winning bet after its market has resolved; cashout closes an eligible wager early for an offered amount. Data providers resolve market conditions, and an event ending does not itself establish that resolution has finished.
The offer values an available exit under the event's current conditions. The potential payout depends on the wager finishing as a winner. Accepting a cashout can realize a loss relative to the stake. Holding the bet preserves the possibility of its winning payout, alongside the risk of losing the wager.
Azuro questions, answered
Can a combo bet qualify for cashout if one condition is unavailable?
A combo's cashout availability check requires every relevant condition to be available. The availability response covers the bet's conditions and outcomes, so an offer for one selection does not establish an offer for the whole combo. If a required condition is unavailable, the combined bet does not pass that check. Full cashout also closes the wager as a whole; it does not remove an unavailable leg.
Can I cash out a bet from a wallet that does not own it?
A cashout request needs a valid signature from the bet owner. The calculation identifies the account, and the signed data identifies the relevant bet and chain. Owner-signature verification can reject a request when authorization fails. Connecting another wallet to the same app does not give that wallet authority over the original owner's wager.
Do I need a new approval for every cashout?
The integration's permission state determines whether approval is required. The SDK exposes isApproveRequired for this decision, and its submit action can trigger approval when needed. Approval remains separate from the signed cashout terms and the settlement transaction, so one successful wallet interaction does not establish that every part has finished.
What does a cashout order already exists error mean?
The service has already recorded a cashout order for the bet. The existing order may still be processing, so the duplicate-order error alone does not establish successful settlement. Its order record remains relevant to tracking the request; repeating submission does not provide evidence that the wager closed or that another payment occurred.
Which bet ID does the cashout calculation need?
A Toolkit cashout calculation requires graphBetId from the indexed bet record. The getCalculatedCashout function uses that identifier to request the calculation. The getCashoutTypedData signing helper uses tokenId, the bet-token identifier, in the authorization. These fields identify the same wager for different operations; an event name or display label does not replace either required identifier.