Skip to main content
The Direct Resolution Oracle (DRO) lets an approved wallet for your creator submit the official outcome directly onchain. Resolution Rewards adds a bonded community signal without changing that authority: users may report YES or NO, while your approved proposer still decides the final result from the market rules and source.
Resolution Rewards is an engagement layer, not a vote. A user report cannot resolve a market or override your approved proposer.
The market-creation fee splits between the Kuest RefillVault and Resolution Rewards, bonded reports flow through the approved resolver, and final balances become claimable or move to the Security Reserve

​
Resolution rules

Before resolving, verify the market’s complete criteria, named source, relevant date and timezone, thresholds, and cancellation behavior. The title summarizes the question; the written rules determine the result.
DRO resolution is final. Resolve only after the answer can be verified from the market’s published rules and source.

​
Fee and reward split

With the current global default, Kuest receives 20% of the DRO creation fee and the remaining 80% funds the market’s community reward pool. The Kuest share is transferred immediately to the RefillVault. The reward pool remains in the Resolution Rewards proxy until finalization and claim. Any integer-division remainder also belongs to Kuest. Kuest controls the global defaults for bond, reward percentage, timers, fee recipient, and Security Reserve. A creator-specific override may change only the reward percentage or disable rewards. When disabled, the full fee goes to Kuest and the market is not registered for proposals.
The effective configuration is copied and frozen when each market is created. Later global or creator-level changes affect only new markets.
Resolution Rewards uses an upgradeable proxy with a permanent address. Market records, accounting, and claims remain in proxy storage when Kuest upgrades the implementation.

​
Proposal lifecycle

1

A user reports an outcome

A canonical DepositWallet locks the market’s configured bond—currently 300 USDC—and selects YES or NO. Reports may be submitted at any time before official resolution, but users should wait until the answer is verifiable.
2

The report occupies a side

Each market has one active YES slot and one active NO slot. Each DepositWallet may participate only once during the entire market lifetime and cannot change sides.
3

Your approved proposer resolves

The proposer whitelisted for the creator evaluates the rules and submits the official outcome. It does not receive forfeited bonds and therefore cannot profit by resolving against a user report.
4

Balances become claimable

Users, Kuest, and the Security Reserve withdraw only their own credited balances. Finalization does not loop through reporters or push funds to arbitrary recipients.
The contract accepts a reporter only when both the wallet’s isDepositWallet() marker and the official DepositWallet Factory validation succeed. Passing through the relayer alone does not prove that a caller is an eligible DepositWallet.

​
Why reporting both sides does not pay

The protocol permits one active report on each side so opposing signals remain visible. This does not create a risk-free strategy: after a binary result, one 300 USDC bond is forfeited, while the correct side receives only its 300 USDC bond plus the small reward pool. One DepositWallet cannot submit both reports.

​
Withdrawal from an unresolved market

A report is locked for 48 hours. After that period, only its originating DepositWallet may request withdrawal. The request is irreversible and starts a further 24-hour delay:
  • reward eligibility is waived immediately;
  • the bond remains exposed to the official result and the slot remains occupied;
  • if the report is correct during the delay, only the bond is returned;
  • if it is wrong, the bond is credited to the Security Reserve;
  • if the market remains unresolved, the bond becomes claimable and the slot can be released permissionlessly.
No third party can redirect or claim the reporter’s bond. Releasing an expired slot only makes that bond claimable by its original DepositWallet.

​
Finalization outcomes

If no one reports before a YES or NO resolution, the reward pool returns to Kuest. An unresolved market may keep its pool pending while reporters remain free to complete the withdrawal flow above.

​
Reliability and accounting

  • With rewards active, market creation, fee split, reward funding, and registration are atomic. A registration or funding failure reverts creation.
  • During resolution, the Rewards hook is isolated. A Rewards failure never prevents the DRO from recording the official result.
  • If that hook fails, anyone may call syncFinalization(marketId). The retry reads the outcome and timestamp from the DRO and never trusts caller-supplied result data.
  • Claims are pull-based and have fixed recipients. A reporter can claim only to the originating DepositWallet; institutional credits can go only to their frozen recipient.
  • A pause blocks new registrations and proposals but does not block claims, expired bond release, refunds, or pending finalization sync.

​
Security Reserve

Forfeited bonds and exceptional-result pools are credited to a separate Safe. The Reserve can support security work, exceptional reimbursements, and future improvements to the Resolution Rewards system. It is not the operator’s revenue wallet. SAFE-SECURITY-RESERVE: 0x089517438121eA31BAf3666554d812ca0b36c6c5

​
Kuest fee recipient

Kuest’s fee share is sent to the RefillVault, which replenishes the wallets and contracts used to operate the Kuest system. RefillVault: 0xE2fD3A613f0290705d777af5ef87277C4BD82EEe

​
Contract addresses

The same addresses are used on Polygon mainnet and Amoy. For the final-resolution calls, proposer checks, outcome values, and adapter addresses, see DRO Resolution API.