Thread by @lex_node

1/ It seems like a lot of approaches to blockchain-based smart contracts, recognizing that "code is law" was unworkable, are going to the opposite extreme where smart contracts will be easily stoppable through administrator-type privileges, and claiming that this is necessary

2/ to ensure legal compliance. If that is true, then the benefits of deploying a smart contract to a public blockchain (vs. someone's server) are modest. By far the biggest benefit dreamed of by cypherpunks for blockchain-based smart contracts was always their potential

3/ to reduce both ex ante and ex post transaction costs by establishing an "unstoppable" arrangement on a world computer where (assuming good ex ante due diligence into the code), the parties had close to 100% certainty that the code would execute and the funds would flow.

4/ If the smart contract can be unilaterally halted, then you are essentially back to relying on traditional methods of deal certainty--a legalese agreement + the ability to enforce it through ADR and/or courts. That system is not a "bad thing" but falls far short of the

5/ cypherpunk dream that people thought smart contracts would deliver in the early-ish days of #Ethereum. Personally, I still have hope of working out a legal framework within which an only slightly diluted version of those early dreams can be achieved.

6/ The framework is what I call "Qualified Code Deference" (as contrasted with both the "Absolute Code Deference" of "code is law" and the "No Code Deference, Only Code Delegation" of some more recent approaches).

7/ Certain contractual arrangements are very well suited to being expressed in the kind of code + escrow arrangements which on-chain smart contracts provide. For example, a syndicated loan smart contract could hold collateral in the form of ETH and automatically distribute it

8/ as interest payments to the lenders' ETH addresses on a pro rata basis. For these types of arrangements, it is possible to have a role for smart contracts that is more important than being a means of performing a legalese agreement.

9/ Rather, the legalese agreement can provide for legal deference to the results of operating the code--i.e., that the results of the operation of the smart contract are final, binding and non-appealable by the parties. That's the "code deference" part.

10/ The "qualified" part is that the legalese should state some exceptions to the deference. The exceptions can be seasoned to taste, with fewer/narrower exceptions leading to greater code deference, and broader/more numerous exceptions leading to less code deference.

11/ An example of a super-specific exception would be the situation where the private key of one of the lenders had been stolen and the lender notified the borrower before the next distribution. The legalese would set forth procedures for how to deal with this.

12/ The procedures could involve a multisig-address-update command sent to the smart contract, or could involve the parties agreeing on and deploying a new updated smart contract with a corresponding amendment to the legalese agreement to replace smart contract address references

13/ On the other hand, if the lender failed to notice the key theft or notify the borrower in time, the lender would be out of luck and someone else would end up with the lender's interest payment, with the borrower having no liability.

14/ That's a draconian result, but in some situations the parties may be willing to live with the mere possibility of draconian results in edge cases in order to get the guaranteed actuality of reducing transaction costs as such.

15/ To me that is the big value-add of deploying smart contracts on a public blockchain-based world computer. It would be a shame if we lost all possibility of parties harnessing that benefit, and we lawyers should try to find ways to preserve it for those who might want it.

16/ Of course, there are many issues to be worked out--how does an automatic stay in bankruptcy play out, etc.? But a priori I see no reason to assume that there aren't ways of addressing these issues while also using smart contracts that have no unilateral halting mechanism.

@threadreaderapp unroll

And, BTW, this is not so different from a legalese contract that limits the borrower's payment obligations to sending a check to such-and-such prearranged address. There are a lot of draconian possibilities even in current legalese arrangements. 😀

FN--an additional issue is doing the actual math on transaction costs. Code deference approaches put pressure on parties to do costly code due diligence ex ante. But that may be cheaper for some parties than hiring lawyers. Point is not to be prescriptive but to offer options.