Overview
UMA’s Optimistic Oracle allows anyone to dispute incorrect proposals during the liveness period. When a dispute occurs, the adapter automatically handles the reset process and, if necessary, escalates to UMA’s Data Verification Mechanism (DVM) for final resolution.Dispute Flow
The priceDisputed() Callback
Function Signature
UmaCtfAdapter.sol
Automatic Invocation: This function is automatically called by the Optimistic Oracle when a dispute occurs. You never call this directly.
Callback Behavior
When a price is disputed, the adapter’s response depends on the question’s current state:Already Resolved
Already Resolved
If the question was already resolved (e.g., via
resolveManually()), the callback:- Does not modify any storage
- Refunds the reward to the question creator
- Returns early
Source: UmaCtfAdapter.sol:170-173
Already Reset Once
Already Reset Once
If the question was already reset from a previous dispute:
- Sets the
refundflag totrue - Does not reset again (maximum one automatic reset)
- Reward will be refunded on eventual resolution
Source: UmaCtfAdapter.sol:175-178
First Dispute
First Dispute
If this is the first dispute:
- Calls
_reset()to create a new price request - Sets
resetflag totrue - Updates
requestTimestampto current time - Reuses original reward/bond/liveness parameters
Source: UmaCtfAdapter.sol:182
Reset Mechanism
Automatic Reset
When a question is reset (during first dispute), the adapter:- Updates the request timestamp to
block.timestamp - Sets the
resetflag totrue(prevents multiple automatic resets) - Submits a new price request to the Optimistic Oracle with:
- Same ancillary data
- Same reward/bond/liveness parameters
- New timestamp for tracking
Source: UmaCtfAdapter.sol:390-410
Who Pays for Reset?
First Dispute (Automatic)
Payer: The adapter itselfThe reward is reused from the original request that’s now sitting in the adapter contract
Manual Reset (Admin)
Payer: The admin calling
reset()Admin must approve token spending for the reward amountManual Reset (Admin Only)
Admins can manually reset a question using thereset() function:
UmaCtfAdapter.sol
The unique identifier of the question to reset
- Question has been disputed multiple times (second+ dispute)
- The
priceDisputedcallback failed due to an edge case - Admin intervention is needed to unstick a market
- Caller must be an admin
- Question must be initialized
- Question must not be resolved
- Admin must have approved adapter to spend
rewardamount ofrewardToken
Manual Reset Example
Refund Handling: If the
refund flag is set (from a previous dispute), reset() will first refund the reward to the original creator before creating the new price request.DVM Escalation
When a dispute cannot be resolved through the Optimistic Oracle (e.g., after multiple disputes or when proposer/disputer disagree), the question escalates to UMA’s Data Verification Mechanism (DVM).What is the DVM?
Data Verification Mechanism
The DVM is UMA’s decentralized oracle system where UMA token holders vote on disputed outcomes.
- Voting Period: 48-96 hours typically
- Incentive: Voters earn rewards for voting with the majority
- Final Authority: DVM decision is final and binding
DVM Resolution Process
Monitoring DVM Progress
You can check if a question is awaiting DVM resolution:Check DVM Status
DVM Vote Outcomes
The DVM can return any of the standard prices:- 0 = NO
- 0.5 ether = UNKNOWN (50/50 split)
- 1 ether = YES
- type(int256).min = IGNORE (question should be reset)
Dispute Scenarios
Scenario 1: Single Dispute, Quick Resolution
Timeline:- T0: Initial proposal
- T0 + 1 hour: Dispute submitted
- T0 + 1 hour: Question reset automatically
- T0 + 2 hours: New proposal submitted
- T0 + 2 hours + liveness: Market ready to resolve
Scenario 2: Multiple Disputes, DVM Escalation
Timeline:- T0: Initial proposal + first dispute → automatic reset
- T1: Second proposal + dispute → refund flag set, no auto reset
- T2: Admin manually resets
- T3: Third proposal + dispute → DVM escalation
- T3 + 48-96 hours: DVM vote completes
- T3 + 96 hours: Market ready to resolve
Scenario 3: Dispute After Manual Resolution
Once a market is manually resolved, disputes on the underlying OO request have no effect except triggering a refund to the creator.
Admin Intervention Tools
Flagging for Manual Resolution
Admins can flag problematic markets for manual intervention:UmaCtfAdapter.sol
- Pauses the market (prevents resolution)
- Sets
manualResolutionTimestamptoblock.timestamp + 1 hour(safety period) - Emits
QuestionFlaggedevent
- Question is ambiguous or invalid
- Oracle manipulation suspected
- Need time to investigate before resolution
Manual Resolution
After flagging and waiting for the safety period, admins can manually resolve:UmaCtfAdapter.sol
The unique identifier of the question
The payout array to report. Must be a valid payout:
[0,1], [1,0], or [1,1]- Question must be flagged
- Safety period must have passed (
block.timestamp >= manualResolutionTimestamp) - Payouts must be valid
Manual Resolution Example
Pausing Markets
Admins can temporarily pause market resolution:UmaCtfAdapter.sol
- Sets
pausedflag totrue - Prevents
resolve()from being called - Prevents
ready()from returningtrue
- Temporary hold while investigating
- Coordinating with UMA team on resolution
- Waiting for additional information
Error Handling
Dispute-Related Errors
Attempting to reset a question that doesn’t exist
Attempting to reset a question that’s already resolved
priceDisputed() was called by an address other than the Optimistic OracleThis should never happen in normal operationEvents to Monitor
Dispute Events
Best Practices
Monitor Reset Events
Listen for
QuestionReset events to detect disputes and track market lifecyclePlan for Delays
DVM resolution can take 48-96 hours. Build this into your UX
Higher Bonds = Fewer Disputes
Size bonds appropriately to deter frivolous disputes
Document Manual Resolutions
Keep records when using admin powers for transparency
Dispute Economics
Dispute Bond Mechanics
- Proposer
- Disputer
- DVM Voters
Initial Bond:
proposalBond (set in initialize())If Correct:- Keeps bond
- Receives reward
- Receives disputer’s bond
- Loses bond to disputer
Incentive Alignment
The dispute mechanism is designed to economically incentivize honest behavior:- Proposers want to propose correctly to earn rewards and avoid losing bonds
- Disputers want to challenge only incorrect proposals to earn the proposer’s bond
- DVM Voters want to vote honestly to earn rewards
The higher the
proposalBond, the more costly it is to propose incorrectly, and the more lucrative it is to dispute incorrect proposals.Related Functions
getQuestion()
reset and refund flagsisInitialized()
isFlagged()
Summary
The UMA CTF Adapter’s dispute handling provides:- Automatic reset on first dispute
- Manual intervention tools for admins
- DVM escalation for final resolution
- Economic incentives to ensure honest participation
- Flexibility to handle edge cases