• © Goverland Inc. 2026
  • v1.0.8
  • Privacy Policy
  • Terms of Use
Overtime GovernanceOvertime Governanceby0x11219d61e95fC5930762b16868dDB2C9c6fc83fApadzank.eth

OIP-258: Introduce Chainlink-Verified Ticket Cashout

Voting ended 17 days agoSucceeded
id Title Status Author Description Discussions to Created
OIP-258 Introduce Chainlink-Verified Ticket Cashout Vote Pending Danijel Introduce early ticket cashout allowing users to exit prematch and live parlays using Chainlink-verified pricing https://discord.com/invite/overtime-io 2026-02-27

OIP-258: Introduce Chainlink-Verified Ticket Cashout

Simple Summary

This OIP proposes introducing Cashout functionality for Overtime tickets, allowing users to exit active bets before final settlement using dynamically calculated market pricing.

Cashout enables users to lock profits or reduce exposure while maintaining fully verifiable onchain settlement and protocol safety.

Unlike traditional sportsbooks, cashout pricing is verified through a Chainlink adapter, ensuring exits are based on real available odds for remaining ticket legs.


Abstract

Overtime tickets currently settle only once all markets resolve (unless they lose early on one of the legs).

This proposal introduces a secure early-exit mechanism allowing tickets to be cashed out whenever valid odds exist for remaining unresolved legs.

Process overview:

  • User requests cashout
  • Protocol validates ownership and eligibility
  • User supplies expected per-leg odds + slippage tolerance
  • Chainlink adapter evaluates remaining-leg odds
  • Approved per-leg implied probabilities return onchain
  • Per-leg slippage and staleness protections are enforced
  • SportsAMM executes payout and resolves the ticket

Cashout works for:

  • prematch bets
  • live bets
  • mixed prematch + live parlays

Motivation

Completing the sportsbook experience

Cashout is one of the most widely used sportsbook features. Without early exits, users must wait for final settlement even when probabilities change significantly.

Cashout allows active risk management while preserving deterministic onchain settlement.

Unified prematch and live model

The Chainlink adapter enables identical pricing logic across both prematch and live betting.

Cashout remains available whenever active odds exist for unresolved legs.

Prediction-market inspiration

Prediction markets such as Polymarket and Kalshi gained adoption largely due to fair early exits.

However, they support only single positions.

Overtime extends early exits to:

  • multi-leg parlays
  • partially resolved tickets
  • live betting combinations

This creates a uniquely capable onchain sportsbook experience.

Capital efficiency

Cashout allows users to:

  • lock profits
  • reduce downside risk
  • redeploy capital faster

It also reduces protocol exposure duration.


Specification

Cashout mechanism

Cashout execution involves three components.

CashoutProcessor

  • validates ticket eligibility and ownership
  • accepts user-provided expected per-leg odds and slippage tolerance
  • requests oracle pricing
  • prevents replay attacks
  • enforces request staleness limits
  • enforces per-leg slippage during fulfillment
  • executes approved cashouts via SportsAMMV2

Ticket Contract

  • validates leg states (resolved/voided/winning/losing)
  • computes cashout quote and payout from approved per-leg implied probabilities
  • applies protocol cashout fee (vig)
  • resolves ticket when cashed out

SportsAMMV2

  • performs payout
  • distributes fees
  • releases liquidity

Only the cashoutProcessor contract may execute cashouts.


Cashout Execution Flow

The following sequence illustrates the cashout execution process.

User
 |
 | requestCashout(ticket, expectedOddsPerLeg[], isLegResolved[], additionalSlippage)
 v
CashoutProcessor
 |
 | validates eligibility + ownership
 | verifies user did not lie about resolved legs / settled odds
 | submits Chainlink request
 v
Chainlink Adapter
 |
 | returns (allow, approvedOddsPerLeg[])
 v
CashoutProcessor.fulfillCashout()
 |
 | rejects if stale (maxAllowedExecutionDelay)
 | re-checks leg status / settled odds
 | enforces per-leg slippage for pending legs
 v
SportsAMMV2.cashoutTicketWithLegOdds(ticket, approvedOddsPerLeg[], isLegResolved[], requester)
 |
 v
Ticket.getCashoutQuoteAndPayout(...)
 |
 v
Ticket.cashout() -> User receives payout

Cashout Pricing Model

Cashout pricing follows a probability-ratio model.

Definitions:

  • P_orig = product of original implied probabilities of all ticket legs
  • P_live = product of live implied probabilities of unresolved legs
  • n = number of unresolved legs

Resolved winning or voided legs contribute probability = 1.

Step 1 — Original probability

P_orig = product(original_leg_probability)

Step 2 — Remaining live probability

P_live = product(live_leg_probability)

Step 3 — Fair value ratio

R = P_live / P_orig

This represents how ticket value changed relative to entry price.


Cashout Fee Model

The cashout fee is derived from the existing SafeBox fee parameter.

Initial configuration proposal

Per-leg cashout fee:

v = 4 × SafeBoxFee

At current parameters:

  • SafeBoxFee ≈ 1%
  • v ≈ 4%

This multiplier approximates the average protocol margin per leg, compensating liquidity providers for assuming the remaining market risk when purchasing a ticket early.

Compounded Fee Application

Because the protocol assumes the remaining ticket risk when executing a cashout, the fee compounds across unresolved legs.

KeepMultiplier = (1 − v)^(n + 1)

Where:

  • v = per-leg cashout fee
  • n = number of unresolved legs

The additional +1 term reflects the protocol taking over the ticket exposure during the cashout transaction.

With v ≈ 4%, this produces a minimum effective fee close to ~8% even when only one leg remains.

Effective Fee Examples

Remaining Legs Effective Fee
1 ~7.8%
2 ~11.5%
3 ~15.1%
4 ~18.5%

Final Cashout Calculation

CashoutQuote = (P_live / P_orig) × (1 − v)^(n + 1)

CashoutPayout = BuyInAmount × CashoutQuote

If any remaining leg is already losing:

CashoutPayout = 0


Per-Leg Slippage Protection

Cashout execution includes slippage protection based on per-leg implied probabilities, not on a minimum final payout.

When requesting a cashout, the user supplies:

  • expectedOddsPerLeg[]: expected implied probability per leg (18 decimals)
  • isLegResolved[]: user-asserted resolved flags per leg (must match onchain)
  • additionalSlippage: maximum allowed increase vs expected odds for pending legs (18-decimal percentage)

During fulfillment, for each pending (unresolved) leg the contract enforces:

approvedOdd <= expectedOdd × (1 + additionalSlippage)

Resolved legs are not subject to slippage; instead, they must match the settled onchain odd:

  • if voided: odd must be 1 (ONE)
  • otherwise: odd must equal the ticket’s stored market odd

This mechanism protects users against:

  • odds movement between request submission and fulfillment
  • sudden repricing for pending legs
  • stale oracle responses (combined with the execution delay rule below)

Oracle Staleness Protection

To reduce stale-quote risk, fulfillments are rejected if too much time has elapsed.

A fulfillment must execute within:

timestampPerRequest + maxAllowedExecutionDelay > block.timestamp

The initial configuration proposes:

  • maxAllowedExecutionDelay = 60 seconds

This parameter is governance/owner configurable and can be adjusted as the system matures.


Ticket Eligibility

A ticket may be considered cashoutable only if all of the following conditions are satisfied:

  • ticket is active
  • ticket is not resolved
  • ticket has not already lost
  • ticket is not an SGP
  • ticket is not a System bet
  • ticket was created after the cashout deployment gating (manager-level)
  • ticket is marked as potentially cashoutable by the manager
  • ticket is not a free bet ticket
  • ticket totalQuote is above the maxSupportedOdds threshold used for cashout eligibility checks

Conceptually (high-level view):

isPotentiallyCashoutable = !ticket.resolved() && !ticket.isTicketLost() && !isSGP && !isSystem && createdAfterCashoutDeploy && !(ticket.totalQuote() <= riskManager.maxSupportedOdds()) && ticketOwner != address(sportsAMM.freeBetsHolder())

Unsupported Ticket Types

Cashout is not supported for:

  • System bets
  • Same Game Parlays (SGPs)
  • Free bet tickets

System bets and SGPs introduce complex payout dependencies and correlation structures that require additional pricing and risk modeling.

Free bet tickets are excluded to prevent exploitation of promotional incentives via early exit.

These limitations may be revisited in future proposals.


Scope

  • applies only to eligible active tickets
  • requires available odds for pending legs
  • executes only after oracle validation
  • does not affect existing tickets

Expected Outcomes

  • major sportsbook feature introduction
  • increased live engagement
  • improved capital efficiency
  • reduced protocol exposure duration
  • competitive differentiation versus sportsbooks and prediction markets

Implementation

  • deploy CashoutProcessor
  • configure Chainlink adapter + job spec id
  • register processor in SportsAMMV2
  • enable frontend cashout UI (including per-leg expected odds + slippage inputs)
  • monitor usage and fee behavior

Governance Flexibility

Cashout parameters can be changed by governance (pDAO) over time as the protocol gains confidence and practical knowledge of cashout usage.

Governance may adjust:

  • SafeBox multiplier used for cashout
  • maxAllowedExecutionDelay (oracle staleness window)
  • eligibility constraints (including free bet restrictions and manager gating)
  • operational and risk parameters around cashout

Copyright

Copyright and related rights waived via CC0.

Are you in favor of this proposal?

Off-Chain Vote

Yes
5 TC-NFT100%
No
0 TC-NFT0%
Quorum:500%
Download mobile app to vote

Discussion

Overtime GovernanceOIP-258: Introduce Chainlink-Verified Ticket Cashout

Timeline

Mar 05, 2026Proposal created
Mar 05, 2026Proposal vote started
Mar 08, 2026Proposal vote ended
Mar 08, 2026Proposal updated