Default Choice of Law

Especially in permissionless dApp networks, parties might enter into agreements without specifying the substantive law that should control the resolution of their disputes. Someone residing in France might transact with one living in Ukraine, for instance, without specifying the choice of law. If they fell into dispute, it would not be clear whether the laws of France, Ukraine, or some other jurisdiction should apply. Resolving that uncertainty might prove very costly. A network thus might want to specify a default choice of law, so that disputing parties can at least argue on common ground.

For a network to choose the law of a particular country as its default would risk treating some parties better than others, however. It would also tie the network to the preferences (or whims, as the case may be) of a particular sovereign, which might not care about or even like the network borrowing its laws.

And, yet, a network cannot very well create its own body of law from scratch. Users will want a body of law that they can trust because it comes from time-tested precedents and has benefitted by long scrutiny by by judges, lawyers, and scholars.

Check out Ulex, the open source legal system. It combines comprehensive set of rules from the most respected flag-free sources in an organized framework. If parties running Ulex had an contract claim, for instance, the American Law Institute’s “Restatement” of the common law of contracts would by default govern their dispute.

Spent some time last night looking into ULEX, the idea of bootstrapping of an existing body of law and precedents is very compelling. However, as far as a default goes, Im not sure exactly how that would work as I would imagine that parties to an agreement would need to explicitly define the arbitration procedure (and with it have choice of law), so rather than a default there may be an emergent consensus?

The default would apply in the absence of the parties’ having chosen otherwise. Parties to agreements often overlook such boilerplate issues, so a dispute resolution can reduce uncertainty and add value by providing a neutral starting point.

The default would apply in the absence of the parties’ having chosen otherwise

At present we are operating under the assumption that users will have complete control of all of their assets unless they explicitly deposit collateral and pre-select and arbitration provider. This process reduces the need for users to trust the system and provides some significant checks on the power of arbitrators.

In a hypothetical situation, Bob wants to pay Alice to perform a service so they enter into an agreement that defines the responsibilities and liability of both parties. To ensure that the agreement is actually enforceable, we require liability to be deposited/staked and subject to specific restrictions (like locking the funds for the duration of the agreement) in order provide assurance that the funds will be available as restitution in the event that one party breaches the agreement. If the arbitration mechanism is compromised, Alice and Bob have the option to simply amend their agreement to select a different arbitrator.

It is certainly possible to create a system where there is an implicit agreement between all parties simply by holding an asset and use that agreement as the basis or default “law” for participants. However, such an approach puts significantly more power in the hands of the arbitration/legal/jurisidictional authority.

From my perspective, we should think about these things in layers of increasing subjective complexity. At the base layer you try and remain neutral and objective, providing the basic infrastructure (Ethereum), from there you may introduce subjective agreements and opt-in dispute resolution (Aragon), and then perhaps you may have an additional opt-in layer on top of that that provides more broad subjective assurances (transaction rollbacks, implicit agreements, etc). By separating concerns in this way people can opt-in at various levels without splintering the utility and network effect of lower level systems.