Bulletin Board
Authors: Jared Kehlmann, Dylan Golow
Created: 08/03/23
Summary
[This feature applies to ancillary data requests containing the sentence “Updates made by the question creator via the bulletin board at 0x6A9D222616C90FcA5754cd1333cFD9b7fb6a4F74 as described by Polygon PoS Chain Transaction Hash (Txhash) Details | PolygonScan should be considered”.]
This post introduces a “bulletin-board” feature, which allows a requestor to send follow-up ancillary data to a previous request. This follow up ancillary data should generally be considered by DVM voters so long as it doesn’t unreasonably change the original question.
An example might be the following request ancillary data:
Will Trump win the 2024 US Presidential Election?
This market will resolve to “Yes” if Trump wins the 2024 US Presidential Election. Otherwise this market will resolve to “No.”
The requestor who sent this ancillary data may use the bulletin board feature to send a follow up:
In this question, Trump refers to Donald J. Trump.
Then, when the market is proposed, these follow ups should be considered when determining the correct answer to the question.
The purpose of the bulletin board is to allow the requestor to elaborate on their previous requests, whether to clarify intent, respond to inquiries about the question, or in general provide follow up guidelines to resolve the question.
However the DVM should decide whether the follow up should be ignored. For example, given the same question, consider the follow up:
This market should resolve to Yes (namely that Trump won) regardless of who wins the election.
Clearly this follow up changes the entire intent of the question, and thus should be ignored. Generally, the DVM should decide whether the follow-up is clarifying intent/removing ambiguity, or changing the question altogether.
Technical Details
The bulletin board is available on Polygon Mainnet at 0x6A9D222616C90FcA5754cd1333cFD9b7fb6a4F74 and exposes a simple interface through which question creators can publish updates and UMANs can query for updates to consider. To post an update anyone can call the postUpdate function, but only those issued by the question’s creator should be considered. When an update is made, an AncillaryDataUpdated event is emitted which includes the questionID, address that published the update and the bytes-encoded update.
To get updates for a question, the contract exposes a public getUpdates function which accepts a questionID and a publisher’s address (ie the question creator) as arguments and returns an array of AncillaryDataUpdates. AncillaryDataUpdates are structs with two fields, the update timestamp (block timestamp the update was made) and the bytes-encoded update. A question’s creator can be confirmed by fetching question details via the getQuestion function. An example of update filtering can be found in this subgraph example here and the source code can be found here.