Given that the FCA and Fed are moving painfully slowly on the topic of smart contracts in particular and decentralised finance in general I referred back to Ian Hunt's paper on Digital Issuance to remind myself what needs to be done and why. On re-reading it I was disappointed to find very little to argue with. It still all sounded eminently sensible. In retrospect I realised that even though there is a summary on his site my own notes might be helpful for people that prefer bulletpoints to narrative, so I've posted them below.
Notes on “Digital Issuance – An Optimal Model for Digital Assets and Transactions”
- Written by Ian Hunt ( https://www.linkedin.com/in/dr-ian-hunt-228880/ ) and located at https://www.digital-issuance.com/papers where there are 3 versions:
- An exec summary (8 pages of text)
- White paper (28 pages of text)
- Full report (81 pages of text)
- The report covers:
- Current view of transactions - what the problems are
- An explanation - Digital assets 101
- What a good target operating model looks like
- What the benefits are
- What we’re up against (The Objectors' View)
- Practically, what is needed to make it happen by each party
The top 4 key takeaway sections – what digital assets are; why we currently have a problem; what the rules for transaction management should be; and what the rules for digital issuance should be.
- Digital assets
- Are issued only as tokens onto a shared digital network ("ledger" or "digital ledger - DL")
- Do not exist in the current registry/custody/depository world
- Are traded, managed and settled on DL by token transfer not physical movement of assets/cash
- Can replace paper contracts which are rationalised and automated; terms are embedded
- Are processed/lifecycled automatically on-ledger
- Why there's a problem:
- Current regs were drawn up for a different context (allegory - physical exchange of goods for gold) - digital assets don't behave the same way as conventional ones.
- Current operational processes are complex involving lots of intermediaries and additional processes for:
- reconciliations
- Confirmations
- Messaging
- Payments
- Settlements
- Docs+records - ISDA/CSA, Central Securities Depository (CSD),etc.
- All additional processes/intermediaries require regulation - big cost/effort
- Rules for transaction management:
-
- Single transaction record
- No off-ledger assets/cash
- Capture, execution and settlement are instantaneous
- Recording of transaction+settlement become same thing
- Establish direct trust between parties
- Rules for optimal digital issuance:
-
- Issue tokens at flow level not asset level. Represent digital assets as clusters of Smart Tokens (STs) pledging future flows
- Transfer intelligence from conventional business systems and data structures onto tokens.
- Make STs self-actuating, self-executing, self-controlling so that their triggers, capabilities and contstraints are coded onto them.
- Make tokens individually tradeable and fractionalisable so trading can be at fractional flow level.
- Measure value and risk at token level, and therefore pledged flows not assets.
-------------------------------------------------------------------------
More detail – what STs are; how we should deploy the tech; how we value them; how we measure risk; what’s left to do if STs contain the functionality; an enumeration of benefits; a list of debunked objections; and what all parties need to do to make it happen.
- Distributed Ledger Technology (DLT)
- Is not necessary to satisfy the rules... but is a good way
- Examples:
- Corda
- Ethereum
- Quorum
- Change of view needed:
- Don't hold assets, hold pledges of future flows of value
- Assets are just a container for those pledges
- Don't store intelligence in the business systems, store it in the message
- Settlements and transfers are not initiated by parties, they are self-initiated
- Assets are no longer indivisible, they can be fractionalised without limit
- Value and risks apply to pledged flows of value not assets, most usefully aggregated to entity level
- Don't hold assets, hold pledges of future flows of value
- Tokenisation
- Is a way of representing and trading assets
- Is cheaper than conventional trading
- Can be applied to
- conventional financial assets like cash, funds and bonds
- Assets that are illiquid like fine art
- Things which are not investable at all, like community projects/footballers
- Can represent assets that have value
- Can lead to tokens that have value themselves - like cryptocurrencies
- Token location
- The location (holding node) of the token indicates ownership
- Changing node means changing ownership
- Movement of token represents trade execution and settlement
- Smart tokens (STs)
- Contain a
- Pledge which is the core of a
- Smart contract
- Pledge which is the core of a
- Can initiate their own actions and self-execute
- Move tokens between nodes
- Are both settlement and record of pledge
- Are shared by both parties
- Can be bundled together as a cluster and labelled (eg to mimic a conventional asset's behaviour)
- N.B. Perp bonds can't be represented with a finite number of STs because they're unbounded
- One ST represents the repeating coupon payments
- Splits itself before each coupon date into a
- ST representing the next payment
- ST representing the remaining payments
- Splits itself before each coupon date into a
- One ST represents the repeating coupon payments
- Derivatives can reference an Oracle for rate setting which is
- An agreed source of external data in a DL
- Collateralised loans = combination of pledges plus a terminal pledge triggered by full redemption to transfer back title to collateral
- N.B. Perp bonds can't be represented with a finite number of STs because they're unbounded
- Get transferred back to the issuer once the pledged flow has been delivered to the recipient
- Pledges held on an issuer node is inactive but could be used as an Indication of Interest (IoI) to trade
- Matching nodes could anonymously search nodes showing IoIs
- Matched IoIs can lead to orders which are pledges to exchange
- Contain a
- Smart contract constituents:
- Pledge from <Node> : the secret signature of the issuer of the pledge
- To Deliver <Tokens> : what is to be delivered
- Calculated as <Terms>: how the delivery is computed
- <On Receipt of <Tokens>>: if the pledge is for an exchange what is to be exchanged
- <On Event(s)/Condition(s)>: if the pledge is conditional what he trigger is
- <Within Rule(s)>: what compliance rules apply to the pledge
- ST lifecycle (note no intermediaries):
-
- Issuer defines pledged flow and creates ST
- Issuer transfers ST to recipient of pledge
- Issuer ensures pledged tokens are available at its node pre-settlement
- ST self-actuates when trigger date and/or conditions are met
- ST self-executes, evaluates terms and initiates flow from issuer
- Recipient holds pledged tokens
- ST sends itself back to issuer
- Issuer burns ST
-
- If part of a larger transaction there may be multiple instances of this lifecycle with
- aligned trigger conditions
- Bidirectional flows
- If part of a larger transaction there may be multiple instances of this lifecycle with
- 4 kinds of token on ledger:
- Cash title token - giving title to fiat currency off-ledger (eg forms of stablecoin)
- Asset title token - giving access to a tangible, non-digital, off-ledger asset (e.g. a painting)
- Digital cash token - with inherent value but only on-ledger (e.g. a CBDC)
- Smart token - containing a pledge to a future flow of tokens
- Valuing a pledge involves considering
-
- The evaluation of the terms including any Oracle-sourced rate
- The solidity of the pledge issuer
- The elapsed time between now and expected self-execution (theta for options)
- The probability that the trigger condition(s) of the pledge will be realised
- The probability of the issuer (where permitted) to change the pledge terms
-
- #2 and to some extent #3 are counterparty risk
- Risk measurement of pledges:
- Operational risk is reduced by reduction of everything to common flows through a single operating model
- Risk to a recipient:
- Issuer does not have pledged tokens on their node at settlement time
- Risk to issuer:
- Fraudulent minting of tokens purporting to pledge flows from them
- Corruption of smart tokens committing more flows from them
- Network must ensure that only issuers can edit pledges
- Only editable on their own node
- Issuer must have visibility of all their outbound pledges
- To ensure no dodgy STs
- To ensure they can see their position - flow risk
- Market risk persists
- If external rates are referenced in the contract there is an exposure to them
- What's left for business systems to do?
- Mint new STs at issuer node
- Edit pledges on tokens at issuer node
- Burn tokens (or would token do this itself?)
- Aggregate flows to show risks+valuations
- Benefits to using STs include
- Bilateral interaction of asset owners and capital issuers
- Quicker delivery of new financial products
- Wide market of investors and borrowers
- Common means of representation
- Simplification of entities and processes required
- Improved, more granular liquidity
- Granular risk
- Visibility of all assets and liabilities at all times
- Precise matching of assets and liabilities and lower hedging cost
- Elimination of order management as separate platform
- For service providers:
- New services
- Single operating model across all asset classes
- Big reduction in operational cost and complexity
- No registry/position maintenance
- No settlement management
- No income entitlement calculation, payments or reconciliations
- Simplification of corporate actions
- Simplification of cash management
- No payments
- Simplified business architecture
- No SecMaster required
- Objections to ST model include
-
- Too radical
- Cost of running TradFi is massive, and money talks
- Huge investment in current structure (too hard to change)
- Too radical
-
-
- TradFi cost argument again
-
-
- Current disintermediating entities will fight it
-
-
- There will be opportunities in new structure also
-
-
- Lots of regulation and laws around TradFi
-
-
- STs could simplify this
- It's the regulators' job to regulate this stuff
-
-
- DLT is immature and unproven at high volumes; inter-operation of ledgers is embryonic
-
-
- DLT is evolving fast
- Scale issue is temporary
- Painless inter-operation between ledgers is mandatory for success
-
-
- Security blah blah blah
-
-
- Decent trust and security is grandfathered in if blockchain is used
- Context is private ledger so no PoW/PoV required
- Probably more secure and resilient than current state
- Decent trust and security is grandfathered in if blockchain is used
-
-
- Unlimited fractionalisation may blow up volumes
-
-
- But not like telecoms or meteorology have to deal with so it's not an edge case
-
What's needed:
-
- Existing service providers to look at new service model and adjust their offerings
- Asset owners and capital issuers
- to agree to move on ledger
- Agree standards for digital issuance
- Work with regulators to ensure security of assets
- Central/commercial banks
- Do CBDC
- Custodian/corporate banks
- Do digital custody services
- Private key management
- Off-ledger storage
- Do digital custody services
- Outsourced service providers
- Look at value-add services
- Digital identities
- Federated KYC/AML
- On-ledger collateral transfer
- Operation of nodes on behalf of issuers/investors/funds
- Management of settlement node
- Look at value-add services
- Payment banks
- Develop non-CBDC cash-on-ledger services pending intro of CBDC
- Tokenising/de-tokenising fiat in and out of stable tokens as an alternative
- Figure out regulatorily safe approach to yield enhancement for clients who want to retain fiat as a preferred medium
- Develop non-CBDC cash-on-ledger services pending intro of CBDC
- Business system vendors look at
- Templating, editing, issuance, transmission, burning of STs
- Encoding compliance and triggering conditions
- Architecture for
- self-actuation of STs
- Interaction between STs and tokens they control
- Rendering risk aggregation
- Brokers, dealers, IBs to look at
- Delivery of a network service
- Designing optimal assets
- How to do asset servicing and demand matching at flow level
- IoI standards
- Regulators to
- Realise that conventional assets model won't cover digital assets
- Sort out regs and controls
- E.g. Federated KYC/AML
- Asset managers
- To design optimal digital assets with issuers in primary market
- DLT providers
- Strengthen approach to
- STs
- Token management
- Fractionalisation (esp volume)
- Strengthen approach to
- Industry associations
- Propose standards
- Pester everyone to do their bit
* Photo credit: Kelly Sikkema at Unsplash