Capital Market Transactions on the Distributed Ledger
A white paper providing technical details on extending blockchain and distributed ledger technologies to support the tokenization of private debt issuance.
By Patrick O’Meara, Chuck Shotton, and Evin Grano
Copyright ©2018 Inveniam Capital Partners, Inc. All rights reserved.
EXECUTIVE SUMMARY
Blockchain and distributed ledger technologies (DLT) possess the potential to transform financial industries. However, the technology is still in its infancy. As with any new platform, blockchain and DLT will undergo multiple iterations before achieving the stability that will support the vast majority of use cases. In their initial implementation, blockchains and cryptocurrencies addressed the need for anonymous, bilateral transactions in a trustless environment. These innovations now include distributed ledger operations that use smart contracts and distributed applications to automate these bilateral transactions.
However, blockchain platforms do not yet implement the range of functionality necessary to represent complex, multi-party, long-term financial transactions that produce numerous artifacts by the host of individuals and entities who participate in the life of these transaction.
The concepts presented in this white paper illustrate Inveniam’s solution to the current limitations of the basic “Blockchain 2.0.” Inveniam deploys functions that support any complex, multi-party financial transaction for its entire lifecycle. While we are focused primarily on the structure, issuance, sale, distribution, tokenization, and trading of private debt offerings, the methods discussed here are relevant to any type of financial transaction that can be better supported using blockchain and DLT platforms.
BACKGROUND
Since its inception, Inveniam’s goal has been to make private debt transactions, focused on the middle market, more efficient and able to attract far more capital and participants by tokenizing these debt instruments and ultimately listing them on global exchanges. Inveniam has developed a methodical, iterative process of originating, structuring, and distributing private debt issuance that makes it possible for our solution to model any complex financial transaction as data. Our automated, interactive workflows execute transaction steps which create deal artifacts (subscription agreements, offer documents, legal opinions, etc.); perform transactions using regulated contracts; and produce regulated tokens that reflect the entirety of the underlying debt instrument, including the terms and conditions of its issue.
Inveniam has already deployed its new solution to originate, structure, and issue debt and equity on the Ethereum blockchain. In December 2017, Inveniam issued enhanced ERC20 smart tokens to support its own equity issue under the newly created Delaware rules governing C corporations’ use of DLT functionality. By the end of July 2018, we will have executed six private debt transactions with a face amount of $43 million using Iveniam.io, Inveniam’s smart contract/smart token WISE™ (Workflows for Investment Services Engine) platform. We expect to have executed just under $150 million in face amount transactions by the end of the third quarter 2018. These private debt deals will soon be listed on multiple exchanges.
An earlier white paper, “Introducing the Tokenization of the Global Debt Markets,” describes Inveniam’s approach and provides the general background for this discussion. It is available online here: https://inveniam.capital/2018/03/08/introducing-the-tokenization-of-the-global-debt-markets/
THE CHALLENGE OF COMPLEX FINANCIAL TRANSACTIONS
The vast majority of debt transactions are a poor fit for existing blockchain solutions. The constraints of smart contract environments such as Ethereum’s Solidity or DLT-only solutions cannot capture and execute bespoke, multi-party, long-duration financial transactions that typify private debt instruments. Simply put, there isn’t a “one size fits all” smart contract, or collection of contracts, that can model the contractual complexities and regulatory constraints of private debt transactions.
These complicated transactions have components and behaviors that do not have analogs in the blockchain technology stack. For example, these transactions may require approval from multiple parties. Regulatory issues (ensuring compliance with a 144A resale of a security issued under a 506 c exemption, for example) such as nationality, investor status as a QIB, or AML checks, may disallow components of the transactions or covenants in the deal paperwork itself. Components of the transactions may be subject to performance conditions that depend on financial reporting or payment performance. Some terms may be subject to external factors such as fluctuations in interest rates. These components and behaviors cannot be adequately captured using current blockchain technology. In addition, diligence processes for secondary sales may depend on information artifacts created as part of the primary issuance or in adjudication when there is a default of the underlying instrument. Smart contracts do not provide a context in which these artifacts can be made available for meaningful review.
Further, DLT software stacks have yet to mature. They lack automated testing and debugging tools and experience runtime performance issues. The engineering base is, as yet, inexperienced. It would be unreasonable to expect participating nodes in a DLT system to provide pricing information, approvals, and permissions, which depend on services external to the system. Likewise, it would be unreasonable to expect participating nodes to represent imprecise, human-readable contracts in machine executable form. Modeling a debt deal using traditional DLT tools becomes exponentially more difficult as the complexity of the deal terms, number of participants, and regulatory requirements increase.
DLT solutions that can only capture transaction details in a rigid, programmatic solution would force businesses to adopt their needs to the constraints of smart contracts, something businesses are highly unlikely to do. They will simply find other methods for executing debt deals that conform to their preferred business processes, leaving large portions of the market for debt transactions unaddressed by DLT solutions that cannot model their complexity.
To address this, Inveniam has created a blockchain-driven token that goes beyond previously conceived token models. Thanks to our technological advances, the token is no longer merely a representation of value — it is also the key that unlocks information related to the origination, structuring, distribution, and performance of debt instruments. This information is hashed and deployed to the blockchain in the form of a regulated contract. The regulated contract represents a series of contracts, events, and activities reflecting the contributions of a variety of market participants throughout the entire lifecycle of a complex financial transaction. Participants’ identities, actions, and work product are cryptographically preserved, and only the owners of the token control access to this secure information.
Our technology therefore facilitates the construction of financial instruments in an environment that is both decentralized and regulated. Our token serves as a mechanism through which token holders and regulators can monitor the instrument, its value, its construction, its contributors, and the provenance of all deal artifacts. Without this robust notion of a token, we are restricted to very simple transactions that can operate using a limited number of templates. Examples of these simple transactions include simple auto loans, or the final piece of home mortgages with meaningful off-chain provenance regarding the underlying home(s) and the origination disconnected from the token. In order to address more complex transactions — such as those related to energy trading, commercial banking, private equity, and municipal bonds — what is needed is a blockchain solution that conveys the provenance of data as well as perfected interest and value. Our regulated contracts convert complex data about clearing, settlement, bank accounts, regulations, and contractual obligations, and model that as data that can be easily deployed to the blockchain. As a result, Inveniam is shaping the future of the global debt markets by facilitating the integration of blockchain technology, via a robust high functioning token, with legacy systems.
SMART CONTRACTS AND THEIR LIMITATIONS
The ERC20 token standard was developed to establish a uniform way to transfer bespoke tokens on the Ethereum network. Token exchanges and wallet management software developers use the ERC20 convention. There are two main types of transfers that take place in the token environment: Direct Transfer and Exchange/3rd Party Transfer. While the developers of the ERC20 standard anticipated it would be used to facilitate token exchange, the ERC20 is not suited for the regulatory and compliance risks associated with private debt. We explain the process for the Direct Transfer and Exchange/3rd Party Transfer below:
For an ERC20 Direct Transfer on an ERC20-Compliant Smart Contract, the originating wallet (Wallet A) creates an Ethereum transaction with the specified amount and the receiving wallet’s (Wallet B) address and calls the function “transfer.” The transaction, if successful, transfers the specified amount from Wallet A to Wallet B and fires an Ethereum Event called “Transfer.” This “Transfer” event triggers the relevant wallet management software and web applications to update their internal references to reflect the effect of the transfer from Wallet A to Wallet B.
For an ERC20 Exchange/3rd Party Transfer on an ERC20-Compliant Smart Contract, Wallet A creates an Ethereum transaction with the specified amount and the transfer/exchange wallet address (Wallet C) and calls the function “approve.” This transaction, if successful, gives permission to Wallet C to transfer tokens at a later time to another wallet of their choosing (Wallet B). This “approve” function triggers an Ethereum event called “Approval” which tells the exchange software it has permission to transfer the tokens at a later time. Once the exchange has identified a suitable sale/transfer of tokens and the Wallet associated with the sale/transfer, which becomes Wallet B, Wallet C creates an Ethereum transaction on the existing ERC20-Compliant Smart Contract. It calls the function “transferFrom.” The transaction, when successful, transfers the amount from Wallet A to Wallet B and fires the Ethereum Event called “Transfer.” Again, this “Transfer” event triggers the relevant wallets and exchange software to update their internal balances.
ERC20 protocols are too limited for transferring regulated tokens from one entity to the other. Inveniam builds on the ERC20 protocol by adding an approval and compliance step controlled by the debt originator or one of its designees, such as a sponsor for a regulated exchange. The Inveniam protocol uses standard ERC20 processes to initiate and complete each transfer, so that the Inveniam protocol is compatible with existing software and exchange processes. However, Inveniam has built into its protocol additional steps that permit off chain regulatory, legal and operational events that have been rendered as structured data to be included in the on-chain transaction.
REGULATED TOKENS AS A SOLUTION
To initiate an Inveniam Regulated Token Direct Transfer, Wallet A creates an Ethereum transaction on a Regulated Token Smart Contract that specifies the amount to be transferred, and the address of the receiving wallet, Wallet B. This function is named “transfer.” The “transfer” function, if successful, withdraws the specified amount from Wallet A and allocates it to Wallet B. At the same time, the “transfer” function moves the specified amount to an internal escrow ledger linked to Wallets A and B and fires an Ethereum Event called “ApprovalRequested.” The “ApprovalRequested” event notifies Wallet A, or one of Wallet A’s delegates (Wallet C), to review the request to transfer. Wallet A or Wallet C can then fulfill any required regulatory or compliance actions within their respective areas of responsibility, after which they create an Ethereum transaction function, “transferApproved.” The “tranferApproved” function contains the specified transfer amount as well as Wallet A and Wallet B’s addresses. The “transferApproved” function transfers the specified amount from the internal escrow account to Wallet B and fires the Ethereum Event “Transfer” in a manner similar to a standard ERC20-Compliant Smart Contract. If Wallet C disapproves the transaction, Wallet C creates a transaction function called “transferRejected” which returns the balance of the escrow account to Wallet A.
For a Regulated Token Exchange/3rd Party Transfer, Wallet A creates an Ethereum transaction on a Regulated Smart Contract with the specified amount and the transfer/exchange wallet address (Wallet C) and calls the function “approve.” This transaction, if successful, gives permission to Wallet C to transfer tokens at a later time to another wallet of their choosing (Wallet B). This “approve” function triggers an Ethereum event called “Approval,” which informs the exchange software that Wallet C has permission to transfer the tokens. Once the exchange has identified a suitable sale/transfer of tokens, Wallet C creates an Ethereum transaction on the existing Regulated Token Smart Contract and calls the function “transferFrom.” The transaction, if successful, withdraws the specified amount from Wallet A, allocates it to Wallet B, transfers it to an internal escrow account linked to Wallets A and B, and fires an Ethereum Event called “ApprovalRequested.” The “ApprovalRequested” event notifies Wallet A or one of Wallet A’s delegates (Wallet D) to review the request to transfer. Wallet A and/or Wallet D can then fulfill any necessary regulatory or compliance actions. If compliance is completed and recorded, Wallet A and/or Wallet D creates an Ethereum transaction called “transferApproved” with the approved amount, and both Wallet A and Wallet B’s addresses. The action transfers the amount from the internal escrow account to increase Wallet B’s balance and fires the Ethereum Event “Transfer” under the standard ERC20-Compliant Smart Contract protocol. If Wallet A and/or Wallet D disapproves of the transaction, a transaction, called “transferRejected”, is created, and this transaction returns the balance of the escrow account to Wallet A. Wallet C retains the ability to transfer to another wallet at a later time unless Wallet A revokes that privilege per the ERC20 protocol.
Adding these steps has allowed Inveniam to extend the ERC20 protocol to work within a regulated environment with minimal impact and is recognizable within the Capital Markets as the ability to DK (Don’t Know) a trade that is in error.
REGULATED CONTRACTS ARE THE LINK TO EXISTING CAPITAL MARKETS SYSTEMS
Inveniam’s enhanced ERC20 Contract implements a regulated token that integrates data supplied from multiple parties throughout the lifecycle of the transaction. It is one of the three components necessary to successfully model and execute bespoke financial transactions in a regulated environment.
The second component is Inveniam’s method of capturing and storing all on-chain and off-chain transaction details into an “event series.” The event series, which might include artifacts such as financial modeling, an auditor’s valuation opinion, or the recording of payout details, is cryptographically hashed and then deployed to the blockchain securing it from unauthorized tampering.
Our third component is Inveniam.io, an interactive digital platform that provides intuitive tools, including a transaction workflow builder and a deal marketplace, making it easy for all parties involved in complex transactions to execute contracts or perform their regulatory responsibilities.
By capturing the actors, actions, and artifacts that constitute a complex financial transaction, contract participants can make decisions programmatically. The event series facilitates audit and compliance, as well as the due diligence necessary for secondary transactions. Inveniam regularly archives segments of the event series and records a reference to their locations with a cryptographic signature. Inveniam extends the trust and transparency provided by the DLT to the off-chain activities necessary for complex, regulated transactions.
CONCLUSIONS
Complex financial transactions need more than the current, bilateral blockchain environment provides. Complex transactions involve multiple participants, lengthy lifecycles, and sophisticated dependencies that require higher-level modeling to structure and execute. Inveniam provides this missing functionality with a single, regulated contract that incorporates all the on and off-chain elements necessary to administer these complex transactions in a regulated environment.
Regulated contracts extend the trust, previously achievable only with bilateral on-chain contracts, to the off-chain contract steps that are an integral part of complex transactions.
In a forthcoming white paper, we will describe the results of contracts completed using the Inveniam solution. The Inveniam solution is a practical and operational application for a variety of complex transactions in a regulated environment.
CONTACT INFORMATION:
INVENIAM CAPITAL PARTNERS
New York:
One World Trade Center
Suite 8500
New York, NY 10007
212–220–6681
Virginia:
202 Church Street SE
Suite 301
Leesburg, VA 20175
Michigan:
114 Main Street
Suite 300
Northville, MI 48167
INVENIAM GIBRALTAR
World Trade Center
6 Bayside Road
1st Floor — Unit 1.02
Gibraltar, GX11 1AA
+350 2000 8095
