This market will resolve if any of the following are true:
- If the current time is past 2022-10-31 11:59:59
It will resolve based on the following decision tree:
- If the human operator agrees:
- Resolves to round(MKT).
- Otherwise, a manually provided value
Note that the bot operator reserves the right to resolve contrary to the purely automated rules to preserve the spirit of the market. All resolutions are first verified by the human operator.
The operator also reserves the right to trade on this market unless otherwise specified. Even if otherwise specified, the operator reserves the right to buy shares for subsidy or to trade for the purposes of cashing out liquidity.
Related questions
🏅 Top traders
| # | Name | Total profit |
|---|---|---|
| 1 | Ṁ81 | |
| 2 | Ṁ60 | |
| 3 | Ṁ49 | |
| 4 | Ṁ26 | |
| 5 | Ṁ11 |
@Yev I'm actually not sure? Even if the bot submitted in UTC instead of ET, that still leaves a few hours unexplained
@BenjaminCosman in the absence of some API that I can reach out to, I set things to resolve by defaults to Market consensus. It does reach out to me to make sure that this is correct before resolution, so if there are shenanigans I can resolve it manually. The vast majority of the time, I just hit the button that says resolve default, because the default is correct
I initially interpreted "round(MKT)" as round to the nearest percentage point; I take it you instead mean round all the way to 0 or to 100?
The wording still seems confusing/misleading. If you are in the loop on every single resolution, and when you disagree with the bot your decision takes precedence, then there is no user-facing sense in which there is actually a default value at all. Sure the bot might provide one to you on the backend, but why should market participants care about that detail? So instead it would be simpler to just state that it always resolves to a manually provided value. (cf "My coin always predicts whether the sun will rise tomorrow: Heads means yes, and Tails means no but then I manually override it to Yes instead"; there is a simpler and more honest way to describe how this prediction is actually being made)
@BenjaminCosman fair enough. The original intent behind my explainer method was to have it comment on resolution time with what the decision process was. At the time that wasn't possible, so I put it in the description
Now that it is, I plan to stop putting that in the description and only comment when it is resolved. Probably I will leave the "do I resolve" criteria in the description, though.
As for the round thing, yes, internally a lot of stuff works with probability rather than percentage, and I forgot that would have different meanings