There is a redeemable field, and the name suggests it tells you whether a position
can be redeemed. Measured, it cannot be used to determine win or loss:
after a board closes, winners and losers are flagged identically.
The sibling trap is worse — query positions, get "empty", assume you are clear, and the money is still there.
The book empties once a board closes. Query positions then and you see something odd:
| You hold | The API says | Reference price | Truth |
|---|---|---|---|
| the winning side | redeemable: true | ≈ 0.5 | worth $1 |
| the losing side | redeemable: true | ≈ 0.5 | worth $0 |
Where does 0.5 come from? With the book empty the best bid is 0 and the best ask is 1,
so the midpoint is (0 + 1) / 2 = 0.5. It is not the market's valuation of the position —
it is the numeric expression of "there is no market".
Workaround one: only redeem positions valued ≥ $0.50. The result is that losing positions pass too — they also show 0.5. You send redemption transactions for a stream of certainly-worthless positions, burning fees.
Workaround two: raise the threshold to ≥ 0.9. Now winning positions are stuck — they show 0.5 as well and never clear the bar. Money sits there until something else rescues it.
Both were tried, both failed. The problem is not the threshold value; it is that judging outcomes from price is the wrong idea entirely — after close, that price carries no information about who won.
| Why it is better | |
|---|---|
| It is the settlement | not inferred from price, volume or any helper field |
| Immune to book state | empty book, no quotes, cold market — all irrelevant |
| Independently verifiable | public on-chain; reproduce it on any settled board |
| No threshold to pick | greater than zero wins, equal to zero loses |
After switching to those two values the misjudgements stopped. Re-checking history with it, agreement with market settlement was total (207:0 across the disputed windows, and 31:0 on a second batch).
This one nearly left money stranded on-chain.
The scenario: shut down a line, and before finishing, query positions to confirm everything is clear. The API returns empty. Looks perfect — so the redemption component gets switched off too.
In fact the last two windows had just been bought and were not yet indexed. The positions were entirely real; the API simply did not know about them yet.
And the redemption component was already off — without a re-check, that money would have stayed stuck. Manual reconciliation afterwards showed one of those windows had won, for a non-trivial amount.
Ruleafter stopping a line, "the positions are clear" cannot rest on a single API snapshot. At minimum one of: wait several minutes past the last board's close, or reconcile against your own order ledger trade by trade.
| The API said | You concluded | Truth | |
|---|---|---|---|
| Trap 1 | redeemable, worth 0.5 | an unresolved position | resolved; the book is simply empty |
| Trap 2 | no positions | everything is closed | positions exist, not yet indexed |
Both are "cannot find it" read as "does not exist" — a class I have paid for repeatedly. The other two instances: reading "no record in the activity feed" as "no loss" (off by eight times), and reading an empty array as "this board has no rewards" (the API traps).
"Has this board settled?" has the same problem: the directory's closed flag lags by five to ten minutes. Waiting on it before redeeming costs you an extra cycle for nothing.
And settlement is already self-evident on-chain — since you are reading the payout result anyway, you do not need to ask a directory whether it closed. Removing that redundant precondition took the redemption cycle from ten-to-twenty minutes down to two to six, which is the mechanism's own floor.
Hand-assembling requests to read chain data rather than using a library? Send a User-Agent header — otherwise you are silently refused: no error, just no data.
Silently is the problem. The failure looks exactly like "there is no such record on-chain", so you go and doubt the data rather than the request. Library users never meet this.
| Do not use | Use instead |
|---|---|
| a "redeemable" field to judge outcomes | the on-chain payout result |
| the post-close price to judge outcomes | as above — that price carries no outcome information |
| a single position snapshot to declare "clear" | wait past close, then reconcile trade by trade |
| a directory closed flag to detect settlement | read the chain; it is self-evident |
| "cannot find it" as "does not exist" | first confirm you are querying correctly |
After close, price carries no information about who won — 0.5 means "no market", not "even odds". There is exactly one place to ask about outcomes: the settlement on-chain. And to ask whether you are clear, never trust a single snapshot.
redeemable true at a reference price of ≈0.5, the empty-book midpoint (0+1)/2.