Hm, one point of the vision of realitytoken is that it is the system/currency with the best arbitrators. They can be arbitrators for facts(realitycheck), but also for juridical decision(s.th. like kleos.) and maybe internal government decision( tokendistribution). So in fact the decision will be stored in many dapps anyway(realitycheck, kleos, etc.) I do not see this distributed storage of facts as a disadvantage.
Also I feel like the linking between the decision quality(facts) and the arbitrator list needs to be strong, in order to make the system work smoothly.
(Additionally, in your example, when arbitrator Y and X are both in the realitytoken arbitrators list, the dapps need to handle additional complexity on how to resolve these cases. I do not think that only the first realitytoken claimer should get funds. This additional complexity does not feels to be right)
My current implementation is not storing the data twice. If there is no escalation about the facts and no arbitrator is being paid, the facts are stored solely in realitycheck. Once a arbitrator is paid, the data is only stored in arbitratorData contract and read it int realitycheck by:
https://github.com/josojo/realitycheck/blob/master/truffle/contracts/RealityCheck.sol#L465
(The answer is received by looking up the arbitrator responsible for the current branch, and then get the answer from this particular arbitrator out of his arbitratorData contract. Everything is secured by a timestamp, so that if a arbitrator publishes anything after he is no longer an arbitrator on the arbitrator list of the branch, these data will not be recognized as given answeres)
Yes, I agree the linking is not a problem in neither of the designs. But since the linking always exists, we can, but we do not have to, separate it from a technical perspective.
If one does not use a wrapper for the arbitrator, this has one additional significant disadvantage:
Let's look at your example again:
- Weather insurance contract wants to know the weather as of day 10
- You make your insurance agreement on branch A of reality token on day 1
- Somebody makes a Reality Check question backstopped by arbitrator X, maybe someone else makes a different question backstopped by arbitrator Y
- On day 10, the answer is reported by the Reality Check Arb X question and the Reality Check Arb Y question. For these purposes it doesn't matter whether it was reported by somebody posting the highest bond, or whether someone asked the selected arbitrator to settle it
- On day 10, there is a branch A-A with arbitrator X, and a different branch A-B with arbitrator Y
- You can claim the funds from the weather contract on branch A-A, and also on branch A-B. If arbitrators X and Y gave different responses, maybe different parties will be claiming the funds on those different branches
If the arbitrator X was a good arbitrator over many years, but suddenly turns malicious between day 1 and 10, then the all the people bet on his correct answer in realitycheck will loose their money. RealityToken would only ensure, that the people bet on the weather contract get the right answer. But people betting in realitycheck on arbitrator X would loose their money, right? (They transfer money on branch A, and not matter whether branch A-A or branch A-B is valid, they will not regain access to these transfered realityTokens )
In my wrapper approach, even the bets on realitycheck will be secured by the realitytoken approach.
Over night I prepared a first look/draft of tokenized-events for the realitytoken eco system. It's super basic, but still I put some thought into it.
https://preview.webflow.com/preview/alexander-herrmanns-first-project?preview=a3fa69b7a21677865395fe37a2eff727
Contracts are also nearly finished.
I hope that this enables everyone to quickly create long and short bets on any event. The long and short tokens could then be traded on exchanges like instex (it's like idex, but for arbitrary tokens.) This would have a much much better performance than any trading experience augur is offering their clients.
no idea why the link changed
tx
[
-> input
-> current_window
-> arbitrator
-> amount
]
[
-> output
-> amount
]
Ah, this solves the replication system within forward looking systems.
In general I do not like utxo models, as you can not easily build smart contracts on them. Referring to some number stored in the realitytoken contract is so much easier than referencing to many utxos and splitting them.
But the idea is good. Currently we are storing balance_changes(address=>amount), maybe we can store them differently balacne_changes(address=> arbitrator=>amount)
... hm just thinking out loud