Adding a large loan to a balance sheet is not an enticing proposition in terms of risk/rewards for a bank. Syndicated loans makes this decision more palatable as is shared among other lenders and can serve as entry point into more lucrative from the issuer. Given that the loan is not the main profit-making target or even used as a lead-loss, arranging banks would seek to minimize the cost to originate and maintain. The ledger replication feature of DLP was discussed in previous post, here we investigate the contributions of another feature of DLP smart contracts.
Smart contracts are simply an extension to the concept of a shared ledger. The central idea of a shared ledger is a system that maintains in sync copies of ledgers, so a change entered by one participant will automagically appear in the copy of the ledger of each participant. If instead of static entries a participant enters a set of instructions that can be executed by a ‘machine’, we have a smart contract that each participant sees and can observe being run. The underlying mechanism to make this happen varies between platforms but the general implementation is for each member of this shared network to have a ‘virtual machine’, so a program executed by an authorized member will run near-simultaneously on each virtual machine thus yielding the exact same output.
The guarantee that an input or event triggering a smart contract execution will yield exactly the same result for each participant removes the need of redundant implementation of a binding agreement, collapsing agreement and implementation into a single step. If the term-sheet of a syndicated loan dictates that LIBOR resets must be taken at 4 PM GMT, cashflows scheduled after a reset will automatically be computed with the agreed mark and seen on each ledger copy with no need of reconciliation.
A clear candidate task to delegate to a smart contract is the pricing process. Syndicated loan process is essentially an optimization problem, attempting to minimize spreads taken by junior syndicated lenders while maximizing subscription level, the goal is for most or all of the loan to be syndicated at the minimum spread possible. In practice, the loan will be under or oversubscribed. The arranger will iteratively increase or decrease the target spread until some ‘optimum’ level of subscription is reached. Below the business logic we need to encode into a smart contract:
Smart contract platform menu
The details of creating the contract will depend on the distributed ledger platform used. In Bitcoin smart contracts can be implemented using Script, a rudimentary language that allows to stack instructions that must successfully execute for some action to take place. Bitcoin Script is domain-specific and closely tied to the cryptocurrency, in fact transactions in Bitcoin are actually scripts, manipulating input and output addresses. In technical terms Bitcoin Script is considered a ‘non Turing-complete language with the glaring absence of loops, a key construct in programming languages. Ethereum, another cryptocurrency system, in contrast, offers a general purpose, Turing-complete language and a rich contract level language, Solidity. Ethereum smart contracts sit on the public Ethereum blockchain and its execution is triggered when a message in the form of a transaction is sent to the contract address.
The fly in the ointment for Ethereum is the requirement of Ether, the native token, for this machinery to work. Ethereum contracts have assigned a quantity of ‘gas’, an amount of ether, that depends on the storage requirements and the machine level instructions required by the Ethereum Virtual Machine to execute. This dependency introduces various problems for the syndicated loan use case. Market price fluctuation of Ether makes the cost to operate non-deterministic, and theoretically unbounded. A more critical source of uncertainty is the lack of finality, i.e there is a non-zero probability of reversibility of the change of a program state and its output. Ethereum underlying consensus algorithm makes re-writing of history increasingly difficult as time goes by (technically as more blocks are added into its blockchain) but the zero probability of reversibility is never reached.
Eris, a distributed ledger platform, seems to be addressing these wrinkles making it more suitable for this use case. While retaining the Turing-complete features of Ethereum, supporting Solidity and other Ethereum contract languages, it introduces thelonious one of the three core component of their stack offering which provides a way to create private blockchain with only known validators, removing support for anonymous validators (not needed in this use case) but also removing the need to use an external crypto-token to fuel the contract. The private blockchain can be created with a custom consensus logic that ensures finality.
More than a program…
It’s easy to trivialized smart contracts as simple ‘smart programs’ that happen to run in sync in multiple ledgers. Maybe a better term is needed to capture the range of capabilities of these artifacts. The ability for contracts to hold funds and to programatically encode agreements elevates smart contracts from inert components to virtual actors and open the door for more refined and exotic customizations in syndicated deals. A smart contract could for example give lenders option to increase a line of credit (LOC) drawing funds only from non-objecting lenders, it could also take votes from all lenders on waiving a covenant condition and act accordingly.
Moving contracts from the rigid paper domain to the flexible programmable domain not only deliver automation, but introduces a dutiful actor, transparent, auditable and exempt from human unintended or deliberate errors.