Smart contract: Difference between revisions

From The Jolly Contrarian
Jump to navigation Jump to search
No edit summary
No edit summary
 
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{A|technology|}}Smart contracts cleave to [[Lawrence Lessig]]’s coinage [[Code is Law]] — you code legal rights into the electronic operating parameters between the parties: they physically constrain what you do to each other, rather than being abstract metaphysical considerations that float above your messy interactions which may or may not reflect those abstract terms.
{{A|tech|}}Smart contracts cleave to [[Lawrence Lessig]]’s coinage in his terrific {{br|Code: Version 2.0}}: “[[Code is Law]]— you code legal rights into the operating parameters between the parties: “enforcement” of the contract is a matter of electronic [[affordance]]. If delivery parameters are X, Y, and Z, then that is all you can do, the machine polices that in practice by not letting through anything else. The thus your legal terms are matters of fact, rather than abstract [[metaphysical]] considerations agreed amongst l[[egal eagle]]s, committed to paper at inception and then put away, filed and forgotten, never to be looked at again, ''until it is too late''. For legal terms that float free, high above messy actual interactions with your counterparty, are a fat lot of good: wouldn’t it be great to code them directly into your [[API]], so to speak, so everything was deterministic, automatic and ''certain''?


Notwithstanding breathless [[distributed ledger technology]] chat to the contrary, we’ve had [[smart contract|smart contracts]] for a while: wherever counterparties interact electronically (as in collateral posting arrangements under a [[CSA]] for example: it is the algorithms and thresholds set in the technology, rather than the abstract ones set out in paper, which govern what, when and how much collateral the parties exchange: it is hardly a big leap to ditch the need for abstract textual reflections of operatring parameters in separately executed "legal terms".
But we’ve had [[smart contract|smart contracts]] for a while. ''Whenever'' counterparties interact electronically, as they do when posting collateral under a [[CSA]], for example: the [[algorithm]]s, thresholds and validation sub-routines embedded in the technological infrastructure, rather than abstract ones set out on paper, govern what, when and how much collateral the parties exchange. Everything happens fast, ''deus ex machina'', and there is no articled clerk with a quill monitoring the data flows and cross-checking each transfer against the agreed eligibility criteria written in the [[CSA]]. All of that coded into the machine.  


Where the contract is of a highly operational nature — and much of the machinery of finance is, in fairness — smart contracts aren’t so much a revolutionary idea as an utterly necessary one. But the problem is this: while 80% of your contract delivered by electronic interaction and is suitable for digital governance, the balance typically isn't. These are the [[close out]] rights, [[Termination event|termination triggers]] and [[events of default]]. They concern matters not ascertainable by electronic transmission between the parties, and they require judgment and evaluation, both of their existence (is that [[Material adverse change|adverse change]] truly material?) and in terms of one’s response: Ok, the [[NAV trigger]] has been hit. But do we want to close out? How is our overall position? What do we think of the counterparty's forward prospects? What are the pros and cons?
So all a [[smart contract]] amounts to is the insight that ''that operational handshake'', rather than the bit of paper you first wrote it down on, is what matters. It would be no big leap to ditch the abstract textual articulation of these operating parameters in separate “legal terms” altogether.


No smart contract will be able to measure these things, much less make an executory decision about them.
But, ''[[blockchain]]'', you know?
{{seealso}}
 
And consider this: if, in that CSA, due to a mutual mis-key when you set up the operating parameters in 1998, you allowed a wider range of collateral through than the contract formally mandated, and no-one noticed until your counterparty blew up in 2008 and the ropey [[collateral]] it had been posting for a decade suddenly tanked, ''what good is your sainted piece of paper then''? Not much, in this commentator’s humble opinion.
 
So, where a {{t|contract}} is of a highly operational nature —  much of the machinery of finance is  — [[smart contract]]s aren’t so much a revolutionary idea as an obvious one. We already have them.
 
But while 80% of your {{t|contract}} is electronic and suitably “smart” already, the other 20% — all the things that matter only when things turn growlish — ''isn’t''. The [[close out]] rights, [[Termination event|termination triggers]] and [[events of default]]: matters that can hardly be coded into anything, much less ascertained by electronic transmission between the parties. They require judgment, experience and evaluation, both of their existence (is that [[Material adverse change|adverse change]] really “material”? Hey, [[legal eagles]]! What does “[[material]]” mean?) and in terms of your reaction to them: Ok, a [[NAV trigger]] has been hit. But is this the real thing? Or is this just a drill? Do we want to close out? How is our overall position? What do we think of the counterparty’s forward prospects? What are the pros and cons?  No [[smart contract]] will be able to measure these things, much less make an executory decision about them.
 
Looks like we need those messy humans after all.
 
{{sa}}
*{{br|Code: Version 2.0}}
*{{br|Code: Version 2.0}}
{{C|Technology}}
{{C|Technology}}

Latest revision as of 16:05, 31 January 2021

JC pontificates about technology
An occasional series.
Tell me more
Sign up for our newsletter — or just get in touch: for ½ a weekly 🍺 you get to consult JC. Ask about it here.

Smart contracts cleave to Lawrence Lessig’s coinage in his terrific Code: Version 2.0: “Code is Law” — you code legal rights into the operating parameters between the parties: “enforcement” of the contract is a matter of electronic affordance. If delivery parameters are X, Y, and Z, then that is all you can do, the machine polices that in practice by not letting through anything else. The thus your legal terms are matters of fact, rather than abstract metaphysical considerations agreed amongst legal eagles, committed to paper at inception and then put away, filed and forgotten, never to be looked at again, until it is too late. For legal terms that float free, high above messy actual interactions with your counterparty, are a fat lot of good: wouldn’t it be great to code them directly into your API, so to speak, so everything was deterministic, automatic and certain?

But we’ve had smart contracts for a while. Whenever counterparties interact electronically, as they do when posting collateral under a CSA, for example: the algorithms, thresholds and validation sub-routines embedded in the technological infrastructure, rather than abstract ones set out on paper, govern what, when and how much collateral the parties exchange. Everything happens fast, deus ex machina, and there is no articled clerk with a quill monitoring the data flows and cross-checking each transfer against the agreed eligibility criteria written in the CSA. All of that coded into the machine.

So all a smart contract amounts to is the insight that that operational handshake, rather than the bit of paper you first wrote it down on, is what matters. It would be no big leap to ditch the abstract textual articulation of these operating parameters in separate “legal terms” altogether.

But, blockchain, you know?

And consider this: if, in that CSA, due to a mutual mis-key when you set up the operating parameters in 1998, you allowed a wider range of collateral through than the contract formally mandated, and no-one noticed until your counterparty blew up in 2008 and the ropey collateral it had been posting for a decade suddenly tanked, what good is your sainted piece of paper then? Not much, in this commentator’s humble opinion.

So, where a contract is of a highly operational nature — much of the machinery of finance is — smart contracts aren’t so much a revolutionary idea as an obvious one. We already have them.

But while 80% of your contract is electronic and suitably “smart” already, the other 20% — all the things that matter only when things turn growlish — isn’t. The close out rights, termination triggers and events of default: matters that can hardly be coded into anything, much less ascertained by electronic transmission between the parties. They require judgment, experience and evaluation, both of their existence (is that adverse change really “material”? Hey, legal eagles! What does “material” mean?) and in terms of your reaction to them: Ok, a NAV trigger has been hit. But is this the real thing? Or is this just a drill? Do we want to close out? How is our overall position? What do we think of the counterparty’s forward prospects? What are the pros and cons? No smart contract will be able to measure these things, much less make an executory decision about them.

Looks like we need those messy humans after all.

See also