One of the largest areas for innovation in 21st century organizations has been in contracting processes, specifically in the areas of smart contracts and end-to-end process development.
Smart contracts, or persistent scripts that automate payments and data exchange, are often built on layers in blockchain backbones such as Solidity on Ethereum or Cardano, though it is possible to build a smart contract on other platforms and other languages besides Solidity. A smart contract can be built and designed by a user and sent out and agreed to by another user without ever passing by a lawyer’s hands (which is one of the proposed attractions to the concept).
In a new book entitled Smart Legal Contracts: Computable Law in Theory and Practice, a compendium of writings details how smart contracts and organizational contracts can be designed both within and without conventional legal structures. In this case, writer Jason Allen analyzes organizational smart contracts as an end-to-end process, based on a layered framework similar to the TCP/IP or OSI stack, with different layers corresponding to different levels of governance and oversight.
In TCP/IP internet models, the bottom layer is the Link or Physical domain, where actual bits and fiber connect; the next layer is the Internet protocol or IP layer, which enables interoperable connections; next is the Transport layer, which exchanges data; and the top layer, which most of us are the best familiar with, is the Application layer. The Application layer is where our services reside, such as Facebook or Twitter or LinkedIn. It is also the layer where innovation and new platforms can be designed.
In her book Internet Architecture and Innovation, Barbara van Schewick details concepts and models of various forms of the end-to-end principle. The main versions are:
1. End-to-end means atomicity of layer transactions. This means a protocol or function should be defined entirely within the same layer without relying on augmenting or changing layers beneath it or needing to perform upcalls to layers above it. Layered atomicity preserves independent protocols for each layer of the stack without needing to rely on other layers needlessly, which complicates design and development.
2. Another form of end-to-end is David Isenberg’s notion that a well-designed internet should be a stupid pipe: What goes in one end should come out the same on the other end without being changed or diluted by the processes between the layers. When you send something over the Internet to a friend, they should receive what you’ve sent without other layers of the protocol stack changing the packet or data. In this same vein, innovation and design choices should happen at the application layers instead of relying on augmenting core processes further down.
At their core, these ideas reflect the same value: Don’t mess too much with core processes enabling linkage and data sharing. A service reliant on changing internal “pipe” structure and evolving to meet its own design specifications with no regard for wider interoperability goes against the broad and narrow interpretations of the end-to-end principles. These principles have also enabled abundant user control in the application layers, and we’ve seen massive digital economies spring up because of this freedom.
Similarly, there are often layers of governance stacking in medium and large organizations. As an example, let’s say Firm A is an M-form corporation with a centralized hierarchy at a homebase and numerous divisions that are fairly autonomous underneath the centralized hierarchy. These autonomous divisions are allowed to set their own procurement and spending contracts within budgets dictated annually by the centralized leadership.
Within Firm A’s contracting structure is a well-developed centralized legal set of protocols governing all outside contracts. Core notions of spending and legal analysis, along with budgeting and financing rules, constrain Division A’s outside independent contracting abilities but do not necessarily limit its autonomy in fielding its own contracts. Firm A’s budget is set by the centralized leadership and monitored by both legal and accounting, which share many of the core business process specifications for all of Firm A. Division A, along with Divisions B and C, are aware of and take direct information from these core business process units.
A protocol stack for contracting and independent financial decisions is beginning to take shape, and it’s one that closely mimics the TCP/IP layered approach. In Jason Allen’s model, core legal processes are in place while the application layer of the stack can be augmented and changed with a degree of innovative autonomy by users.
Let’s say Division A is a communications division, controlling social media for the entire organization. Other divisions, including B and C, might want to use Division A’s networks to highlight their own messages and initiatives online. All three divisions have their own budgets allocated from the core legal and accounting sectors of Firm A, set by the senior leadership. Divisions B and C need a lot of messaging work; this includes graphic design, posting on social media networks, data analysis, and spending on Facebook or Google Ads to get the word out. This is more work than the in-house creative team in Division A can reasonably do on their own, so they look to outside contractors for help.
Division A, in this scenario, has a relationship with Agency X from a prior campaign. To save on contracting or search costs, Division A chooses Agency X for B and C’s messaging campaign work. Division A uses the budget allocated to B and C to pay Agency X for the work. Agency X completes the work and either returns it to Division A for posting or posts it themselves through enabled platform access. B and C’s messaging goes out, and the transactions are completed when the contract is completed.
The above scenario occurred within the confines of the conventional contracting scenario. Now let’s say the organization uses smart contracts. Smart contracts are, first and foremost, applications for business processes. In a perfect theoretical design, they enable highly secure, stable transactions without needing human input. They certainly have their drawbacks: a Turing-complete language like Solidity can get stuck in infinite loop functions; that’s why Bitcoin’s language, called Script, is not Turing-complete—it prevents infinite loop functions that swallow processing speed and network time.
Part of the attraction for smart contract maximalists is the possibility of abolishing lawyers and conventional legal structures. Search costs and contracting costs, along with fees and payments, make hiring and using lawyers an expensive process. Maximalists see lawyers as an unnecessary intermediary in a world of user-defined smart contracts. Much like Bitcoin cuts out banks, smart contracts cut out lawyers and law firms.
While there are many smart contracts (and regular contracts, for that matter) that can be entirely enacted without lawyer involvement at all, there is the risk of opportunism and hold-up in any contracting. The attraction of smart contracts and blockchain transactions is to solve or reduce the hold-up and opportunism costs. This simply means a smart contract (which Ethereum co-founder Vitalik Buterin refers to more accurately as a persistent script) can automatically and securely enforce the terms of a contract without needing to rely on humans and their uncertain bargaining intentions. Oracles fed directly to the blockchain contract operate without human interference or attempted theft; money is transferred autonomously with no ability to stop it from meddlers. Publishing smart contracts on blockchains also enables the entire network to see and govern the validity of transactions through distributed consensus, meaning hold-up or opportunism attempts run into community moderation and are thus discouraged.
Smart contracts built as applications, in an end-to-end principle reading, are best augmented and designed in the user-governed application layer at the highest level of the protocol stack. In Smart Legal Contracts, the authors take the view that while smart contracts can certainly speed up contracting processes and enable independence and innovation for many users, there is still a place for lawyers and core protocols defined outside of a smart contract, for both legal and security reasons. While smart contracts are legally enforced in many jurisdictions, their full legality is still very much debated and uncertain as of this writing. There is also currently little legal remedy for their misuse.
For an organization like Firm A, relying entirely on smart contracts for all business processes is a potential recipe for madness and oblivion if used improperly or lacking sufficient governance and oversight. Smart Legal Contracts takes the view that, like the TCP/IP protocol stack, smart contracts should only be defined and innovated with at the application layer rather than throughout core business processes composing the lower levels of the stack.
This would mean that Division A in Firm A, for instance, can automate its transactions with Agency X via smart contracts that are drafted and defined by Divisions A, B, and C without direct involvement from the core. Division A has a set budget (again, set by the core legal and accounting teams in accordance with dictates from central management), as do B and C, and payments are exchanged between all of them and Agency X for hired services. But Division A can draft its own smart contracts and its own terms and be responsible for their operation and success (or failure).
This smart contracting can decrease transaction costs and oversight costs for Division A. It can lower agency costs for Agency X, speeding up their contracting and payment period—this can mean the difference between life and death for an independent marketing agency. It might also be that asset and payment exchange is facilitated through permissioned blockchains, so everyone with access can see and directly sign off on processes as they occur, in this case graphic design, copywriting, and payment transfer. Divisions B and C can see the progress of their work and payments facilitated as it all happens.
While this automation has many potential benefits, there are also important design considerations. Smart Legal Contracts suggests certain checkpoints in the smart contract where a human must sign-off on what has thus far occurred. This is like a persistent script escape hatch to prevent infinite looping or opportunistic programming errors in smart contract design. At a mutually agreed step in the smart contract process, the script reaches Checkpoint A and both parties must reach consensus for the script to continue. If both sign the transaction (perhaps with their public-private key pairs) then the smart contract continues until reaching Checkpoint B, in which case the signing is again prompted and both parties must sign for the script to continue.
Checkpoints are much like the legal concept of vetogates, i.e. they are places where contracts, legislation, or other documents can be vetoed or ended both through action or inaction. Corporate vetogates can be a headache to navigate, as there are many places where a contract can be held-up or simply die due to inaction or passive veto. Certain people in Division A might benefit from conveniently “forgetting” about Agency X, for instance, and “forget” to sign the smart contract at Checkpoint A. As the messages to be published on social media from Division B are time-sensitive, holding up the process from Agency A and Agency X can create a ticking clock that hastens negotiations. User 1 in Division A, who controls the application-level contracting, might want to give the contract to their friend’s company, Agency Y, and creating hold-up enables Division A to switch from Agency X to Agency Y based on Agency Y’s increased speed and perceived lack of closure from Agency X.
The key benefit of end-to-end design principles is enabling interoperability throughout the entirety of Firm A. A smart contract that is designed by Division A should also be able to communicate with Division D in another unit due to a shared protocol layer of core legal and accounting practices as defined by the centralized leadership. It is up to each firm to decide their level of interlayer operability, however; while a smart contract drafted in Division A might rely on the same lower layers as Division D, A and D might design and write their smart contracts much differently.
For example, in full divisional autonomy (weak end-to-end), Division A might write their smart contract in Solidity and Division D might build theirs on the natural language Lexon framework; languages may or may not translate, divisions may or may not use them for interoperation. In limited divisional autonomy (strong end-to-end constraints), the core legal team might define the language to be used in the application layer for all divisions, so Division A and Division D could write any smart contracts they wish, provided they write them in the same language and obey the end-to-end design of lower stacks protocols.
Smart contracts, being applications and innovated in a shared layer, can be done by different divisions or sectors for their own purposes. As long as innovation is allowed to happen at the application layers, and the smart contracts created by any division for any purpose rely on the core protocols of Firm A and are entirely interoperable, the organization’s contracting and legal agreements can resemble the TCP/IP protocol stack both in design and success. Autonomous divisions can retain much of their autonomy while also speeding up their processes through smart contracts that follow end-to-end principles.