By Justin Goro
Ulex is primarily composed of 2 parts, a dispute resolution mechanism and a restatement of legal best practice taken from a vast array of sources. The dispute resolution mechanism can be restated in terms of Ethereum primitives in such a way that a blockchain version is more than achievable. Kleros has already demonstrated an Ethereum court system is possible.
What is not obviously achievable or easy is to bring the rest of Ulex onchain. The goal of this paper is to show that once we have the Ulex dispute resolution onchain, combined with IPFS, we have enough technology to use the core dispute resolution system to bootstrap the rest of Ulex onto Ethereum. For clarity, I will use Ulex Core to refer to the dispute resolution system at the heart of Ulex and Ulex Proper to refer to the entirety of Ulex (as expressed here).
While the purpose of this paper isn’t to detail how to bring Ulex Core onchain, a brief word to satisfy the reader might be necessary. The first step is to outline the Ulex Core primitives. In this fictional rendition, we have:
In Ethereum, obligations cannot be created. Instead we require participants to stake deposits subject to cooperation. This means that Ulex Core can’t be invoked against parties who never agreed to be prosecuted under its rules. Instead some pre-existing community exists which would require members to place deposits upfront. These deposits would then be forwarded to the court in the event of dispute.
The court would be responsible for managing deposits and for carrying out a verdict. A plaintiff would open a case by staking a deposit and identifying a valid defendant. The defendant (who’s deposit is already staked) would be notified that non participation within a given window will result in forfeiting their deposit.
Each party selects a judge and those 2 judges select a third. Then, once the judge selection has occurred, judges would stake their deposits and begin adjudication. After a verdict has been rendered, there would be a period of time for appeals to be lodged.
Appeals can be either lodged by the losing party or by external parties who suspect judicial misconduct. In the event of the latter, a new case would be opened against the offending judge and the original case would be suspended pending the outcome of this new case.
While I haven’t outlined the finer details mostly because they are subject to Tom’s approval, the missing parts are not game stoppers but implementation details.
The Ulex Core smart contracts would have one more feature, a concept of community forum. This is the area where plain english rules are outlined for a given community which are then used by the Ulex Core judges to render verdicts on subjective or other rules which are not possible to codify in smart contracts.
For illustration, I’ll use a fictional example of an online cycling enthusiast chat forum that has the following rules:
Instead of centralized moderation, the community wishes the site to be governed by Ulex Core. Each comment left by a user is given a unique number on the blockchain. Users must submit a deposit to leave a comment. Anyone on the internet can challenge a comment when it is first posted. If Ulex Core rules that the post is in violation of community rules, the verdict is to set a flag on the number of the post on the chain. The chat site then only displays comments that aren’t flagged on the blockchain.
So how do we bring the rules outlined above onchain? Here we take each rule and put it in its own text file. So we’ll have 3 files something like the following: “foulLanguage.txt”, “adhominem.txt” and “onlybicycles.txt”. Each of the rules outlined above will be in its own file. We’ll then upload each file individually to IPFS and receive 3 unique hashes.
In Ulex Core we list a community called “Bicyles-R-Love” and we’re given a smart contract that allows us to list the rules of the community. We submit the 3 hashes and the smart contract creates a list of 3 hashes.
When court is in session, the judges will inspect Bicycles-R-Love community and discover the list of 3 hashes. They will then use IPFS to retrieve the rules. When they issue a verdict, they’ll call a guilty() function on the verdict contract and supply the function with 2 values, the ID of the Bicycles-R-Love community and the hash of the rule that was violated.
In this way, we have a direct blockchain based, immutable record of verdicts and the rules invoked. This will provide objective evidence of judicial performance which can be used to assess the quality of judges and can also be used to raise appeals later.
The previous subsection outlined how plain english rules can be encoded into the blockchain via IPFS so that judges can rule on non blockchain events. This allows communities to register their own rules and then use Ulex Core as the supreme court. Suppose, however, we want to use all of Ulex as the rules of our society.
Perhaps, we’re planning a startup society in the real world or a seastead and we want it to be governed by Ulex but with blockchain teeth. In this case, we’d create a Ulex Proper community. Following the approach above, we’d take the Ulex document at github and break it into many text files. For instance, the following lines would get their own text file:
ALI, Restatement of Torts, Third, Liability for Physical and Emotional Harm (2009–12).
These text files would then be encoded to IPFS and the hashes of them would be saved into the Ulex Proper community on Ulex Core. Now when we want to apply Ulex Proper to the adjudication of real world events, we can require users stake deposits with the Ulex Proper community on Ulex Core. Any disputes that arise would then be subject to the full authority of Ulex.
By bringing the very core of Ulex dispute resolution onto the blockchain and by utilizing IPFS to codify more complex legalese, we can bring all of Ulex onto the Ethereum blockchain.