We’ve been working tirelessly to further enhance the capabilities of Overledger and preparing the technology for multi-chain environments.
In this release, we have enabled standardisation of objects to abstract and simplify how to interact with different types of blockchains (UXTO and Account-based) in a common model.
We’ve also created the ability to directly deploy, invoke and query smart contracts directly through Overledger.
Finally, this update sets the foundations to build the ecosystem for the Overledger Network, allowing stakeholders other than Quant to write any type (DLT and non-DLT) Overledger connectors and sets up the ecosystem with multiple entry points for Overledger Gateways.
These updates open up the integration capabilities of Overledger to 3rd parties and create the foundations for the Overledger Network.
To solve this challenge for enterprise and developers, we’ve created the following principles to Standardisation which also aligns to the work in ISO TC307 and academic work from Dr Paolo Tasca and Dr Claudio Tessone:
- Each object represents a core component of DL systems
- Each object field groups similar properties in different DLs into one field
- Each object can use an additional fields section for DL specific parameters to be added (and therefore no underlying transaction data will be lost)
Taken together, this will provide users with a clear distributed ledger data standard, which will be publicly released as we move closer to the deployment of Overledger Network. Furthermore, our object definitions will be released in versions to reflect continuing developments.
Without Overledger, you would have to individually code objects and how to interact with them manually for your applications. This is further amplified if you use different blockchain types for your application (UTXO vs Accounts Based) and further still when you have a multi-chain approach to then customise each interaction and object for all blockchains involved.
Practically, we have created the following framework to cater for objects and smart contracts:
- Firstly we have integrated the transaction and smart contract objects
- Transactions have 3 levels of inheritance, due to the inherent differences between UTXO and Accounts based-distributed ledgers.
- Smart contracts have 2 levels of inheritance. Note that for smart contracts, the UTXO/Account difference matters less than the Turing-Complete/Non-Turing Complete difference, but it is not a large enough difference to warrant 3 inheritance levels.
Demonstration 1 — Overledger Transaction Object Standards
In the SDK Update video we show:
- A UTXO standardized transaction being defined and deployed for the Bitcoin blockchain
- Object standardisation here allows for transactions with n number of inputs, m number of outputs and paves the way for future updates regarding user-defined scripts.
- Two Accounts standardized transactions being defined and deployed for the Ethereum blockchain and XRP ledger
- Object standardisation here allows for a more clear distinction between value-based transactions and smart contract ones (see demonstration 2)
Demonstration 2 — Smart Contracts through Overledger
In the SDK Update video we show smart contracts for the Ethereum blockchain can be handled through Overledger:
- being deployed
- being invoked
- being queried
What does this update mean and use cases in Financial Services?
Use Case 1 — Digital Asset Funding
Here we look at an example between a Digital Asset Trading platform implementation and a Funding platform using a pegged digital currency:
- Bank A is part of the digital asset trading consortium’s platform and has a subsidiary providing funding to its trading operations
- Settlements for Digital Asset trades during the day would include funds received
- These are managed by another organisational unit of Bank A by other parts of Bank A’s operations which is responsible for deploying capital for the Bank A Group of organisational units
- Funds would thus be moved around the group by the Internal funding platform in the form of a private digital currency (i.e. “BankA Coin”)
Overledger Architecture & Flows
- Overledger provides a bridging capability for Bank A’s node on the digital asset trading network and Bank A’s funding operations network to interconnect
- This could be achieved through additional use of a smart contract wrapper for each specific digital asset type, and a set of funding rules for that category of asset
- As new types of digital assets are introduced a highly automated smart contract templated generation and deployment mechanism would be required in both networks
- The pseudo-code could be maintained outside of the DLTs and managed centrally by the legal and compliance department of Bank A
- Overledger’s SDK smart contract capabilities allow the foundations for this templating and business logic for each digital asset and funding operation to be established
- A template could be used to generate the smart contract code and then this could be deployed by Overledger to the appropriate underlying DLT for each network
- As part of our roadmap, we’ll be integrating further templating capabilities which could then be used to interact with smart contract generators natively
- Cost reduction for Bank A through Automation as maintenance code will be reduced as features are exposed in our SDK for deployment
- Short time to market for Bank A to offer new Asset types — onboarded quickly once approved through the flexibility of Overledger to support multiple digital asset types (UTXO and Accounts based)
- Provision for a trusted and verifiable reporting source for all the Bank A’s digital asset funding rules for a regulator e.g. CRD IV Capital Adequacy buffer reporting
Use Case 2 — Business Networks Interoperability
In this use case, a Bank participant involved in multiple consortiums. Multinational “Bank M” is part of we.trade, Marco Polo, and JPM’s Interbank Information Network (IIN):
These are implemented on different DLTs (HLF, R3’s Corda, and JPM Quorum respectively)
- Bank M will require multiple nodes, supporting infrastructure, and operational capabilities
- Over time Bank M should avoid a proliferation of nodes to build, maintain and interoperate between
- Overledger provides a network gateway compatible with Enterprise DLT networks avoiding complex node interactions as shown here
- Version and multiple instance incompatibilities require a standardised gateway and API
- Bank M implements Overledger to provide a gateway node for all areas of the business in Bank M
- Internal business logic implemented against Overledger SDK abstracting away from underlying DLT and network’s APIs
- Integration options for existing Bank M infrastructure that is not an immediate good fit for DLT
- Different parts of Bank M can access underlying networks via the Overledger Gateway
- Interchange to allow for Rate conversion and broker modules
- Migration of assets made simpler as portability reduces the need for multiple intermediaries and friction introduced through off-boarding to FIAT
- Best Execution — business rules for routing and pricing choice can be implemented and managed in one place for MiFID II compliance
- Operational Cost reduction — through reduced requirement for multiple nodes, and support teams
- Transaction Cost reduction — through the opportunity to adopt new DLT standards for derivatives e.g. ISDA CDM. Implement once with consistent industry standards for trade affirmation, collateral management, portfolio compression
We’re very pleased to release this update for our clients and developers to create new possibilities and use cases with the new features and capabilities across industries. We’ve now laid the foundations to open up Overledger connectors and have a vibrant ecosystem of interoperable networks and APIs make possible by Overledger and power core of the Overledger Network.
To keep up to date to our latest updates, please visit www.quant.network or follow us on: