In some cases, it might be preferable to have a question that doesn’t resolve until after the event happens, whenever that might be. Rather than on a specific date. In which case we would need open ended questions.
This could effectively be accomplished with early resolution and an expiry date that is effectively infinite (1,000 years or something).
The usecase I see this being good for is markets like “which will happen first, A or B?”
It may also be useful for insurance-style markets.
Yeah, I think it would be great. This could work at a latest resolution date.
We probably don’t want to make resolution date really long (> 10 - 100 years) as it could lead to a high capital cost in case of invalid or result to be known very late (see Time value of money), but allow early resolution and if the result is still not known by the resolution date rule as invalid.
Early reveal would make prediction market more capital efficient.
From a technical perspective, we could only ask the reality.eth question when someone makes a report. If the result is not known, the correct answer would be invalid and the question could be asked again in the future when there is a new report. If invalid is reported after the latest resolution date, the market would resolve as invalid.
Preciously I was thinking about 3 possible answers.
a) resolve
b) invalid
c) not yet clear
But I like your solution much better to just have one “don’t resolve” question.
And the semantic of that would be that before the resolution date system nothing would happen and after it could trigger the “invalid”/“all outcomes equal” payout.
@edmundedgar - what do you think about this chance to reality.eth?
I feel like “invalid” has a different meaning to “not yet clear” and something may be worth settling as invalid before the thing timed out, so I’d be inclined to add “not yet clear” as an additional option as per Martin’s previous thinking, but I don’t have a strong opinion about it, and we can handle either or both.
Assuming we want a “not yet clear” option rather than just having “invalid”, it would work if you just added an extra option to the list of answers, but it’s probably cleaner if we explicitly support “not yet clear” as an answer and assign it a special answer code (I guess bytes32(-2), like we did bytes32(-1) as invalid) with a new attribute in the question template (something like “has_unresolved”) to tell our UI to provide an “unresolved” option.
If you prefer to just have the one option I’ll just rename “Invalid” to “Invalid or not yet clear” in the UI, which works as a question that can’t be answered yet is already generally considered invalid.
the reason I would tend towards only having one option is that schelling point games IMO work best if the schelling point is clear. See the upcoming question around the presidency. If it should be resolved now “invalid” and “not resolvable” yet would be in conflict with each other and thus make the schelling point less clear.
Unfortunately it is not just a UI update.
I think the main thing that needs to change is that if a question is resolved to “later” - it needs to be possible to start the process of submitting an answer later again. Today - once resolved to invalid no second submission is possible.
Alternatively - if we want to push the change to Omen/ conditional token framework we can do it like this:
I’d envisaged doing it in the way described in your “alternatively”. Don’t create the reality.eth question until somebody wants to resolve it, and if a question reports as “not resolved yet” (or “invalid”), with at least a minimum bond posted, the querying contract (Omen etc) ignores it and waits for somebody to create a version of the question that reports as resolved.
If we wanted to do this at the reality.eth end I have some (unaudited) code somewhere that wraps this into what I called a meta-question that handles that and looks to the querying contract like any other reality.eth question, except that it won’t return an answer until there is one. In theory I could ressurrect that and build a UI around it in reality.eth. But I suspect it’ll make more sense to build this into the querying contract.