Smart contract outsourcing

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.

Price finder

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.

5 thoughts on “Smart contract outsourcing

  1. Bart Cant

    Interesting Read.

    One particular thought that comes to my mind about this process is the public nature of any action taken by actors on the Ethereum or Thelonious blockchain.
    Although transparency overall is a positive feature and helps with auditing and reconciling the current state, in certain cases actors may benefit from privacy (execution of certain steps, prices, etc) while acting in their own self interest. Finding the right balance between transparency and privacy is going to be a critical component of the new blockchain re-design in financial services

    1. Ayoub Naciri Post author

      Thanks for your comment Bart. Right, there is a need to provide different levels of transparency. This is not different in today’s banks trading books where different traders have limited level of visibility e.g they can see their desk positions but not external desks whereas compliance departments may have global read access. This is a problem that is technically solvable and something that
      platforms providers would need to offer.

  2. Casey Kuhlman

    Ayoub and Bart, I’m interested in your opinions as to the usefulness of building capacity for EVM style contracts to be able to run in something like “detached” mode wherein their state (which is what the privacy // transparency line hinges on) over the course of the execution is not widely visible within the smart contract network?

    This idea would likely require transaction inputs to be sent out-of-band from the blockchain’s perspective (over http, zmq, whatever). The advantage is that the same language could be used no matter whether the contract was executed in “attached” or “detached” mode. To add additional functionality perhaps a “shutdown” function could be added to reset and/or update the “saved” state of the contract (signed and verifiable on the blockchain). This new “saved” state could then be used on subsequent “detached” operations.

    Is this something that would be useful, or do you think that the core aspects of what these virtual actors can do would be compromised to the point where the question, “why not just use a node script” cannot be sufficiently answered?

    1. Ayoub Naciri Post author

      Casey, providing the the ability to hide state is a critical feature to offer as Bart has pointed out. The ‘detach-mode’ approach would achieve the state hiding. Personally, I would favor more some sort of a permission layer that would restrict state read access but keep state onchain. This approach would seem to fit better on a ‘consortium’ based setup where only interested parties and maybe regulators would have visibility. It would also disqualify a “node script” as an alternative solution.

      1. Casey Kuhlman

        Interesting. The challenge there, of course, would be to bring authentication with respect to the “read” access into the blockchain client.

        We haven’t done this yet for two reasons:

        1. Restricting access to the state would impinge on full node’s capabilities to verify state — thus it takes away one of the primary selling points of chain tech. (That said, folks thought we already take away the primary selling point when we first added an access control layer at all).
        2. In talking with MFI’s, we usually say that this type of control would best be handled behind a VPN rather than within the chain client itself because this is what VPNs have been optimized to do and basically we’d have to just rebuild most of a VPN’s functionality into the chain client itself in order to support this idea.

        Wondering your thoughts…


Leave a Reply

Your email address will not be published. Required fields are marked *