Events and disputes
Every act is an event of one contract, read back with one getLogs from the deployment block and folded into state.
Events
| Act | Event |
|---|---|
| create (keeper) | MarketCreated(id, specHash, deadline) |
| stake (yours) | Staked(id, staker, yes, amount, yesPool, noPool) |
| forecast (anyone) | Forecast(id, forecaster, hash) |
| bond (forecaster) | Bonded(id, forecaster, amount) |
| settle (keeper) | Settled(id, verdict, sourceHash, closesAt) |
| dispute (anyone) | Disputed(id, challenger, url, bond, inToken) |
| decide (keeper) | Decided(id, verdict, sourceHash, challengerWins, disputes) |
| finalize (anyone) | Finalized(id, verdict, refund, fee, toDistributor, toForecasters, toChallengers) |
| claim (yours) | Claimed(id, account, amount) |
| forecasters (keeper) | ForecastersPaid(id, forecasters, weights, amounts) |
| bonds (keeper) | BondsReleased(id, forecasters, outcomes, returned, burned) |
Verdicts are 1 for YES, 2 for NO (the placebo wins) and 3 for VOID.
Reading them
Anyone can rebuild the state from one address. Call eth_getLogs on the contract from its deployment block, decode with the ABI and apply the events in block order. The contract's own views (markets(id), claimable(id, account), bonds(id, account)) give the same numbers directly. The site, the SDK and the keeper run the same fold.
The dispute window
Between the settlement and finalization, anyone can call dispute naming a different primary document, from the Dispute tab of the market page or through the API, with the bond. The keeper hashes every document named and publishes the hashes with its decision. A disputed market cannot be finalized until the decision. Step by step.