Since this time last year, an incredible amount of progress has been made and we’re ready to go into detail about what’s been happening behind the scenes with Overledger.
Last June we released Overledger 1.0, based on several years of work and experience with on-premise customers. Overledger 1.0 was SaaS-based, but relied heavily on client SDK-based logic and released an experimental set of technologies to the community in the form of “Overledger Gateways” for testing and feedback.
Between June 2020 and January 2021, we have been working on extending the Overledger 1.x product, but also drastically expanding the product architecture into Overledger 2.0. In January 2021, Overledger 1.5 went live. This release allowed MainNet access on Bitcoin, Ethereum and XRP Ledger, and integrated compliance KYC checking for access to MainNets.
During this time, Overledger 2.0 was being designed, built, and tested. This table illustrates what’s changed:
OAuth 2.0 standard (allowing SSO)
Proprietary (BPI Keys)
In API, seamless updates
In SDK, re-download for updates
Full abstraction across all DLTs
Partial, DLT-specific edge cases
REST / JSON APIs from OVL Core
Proprietary P2P (experimental)
Time to Deploy
32 minutes (CI / CD pipelines)
QNT Utility Token / Treasury
Optimised, audited smart contracts
Experimental smart contracts
Optimised to scale fast – 23 Microservices
Hardened proof of concept
– 9 Microservices
Transaction Routing Algorithm
6 factor, game theory optimised
Experimental P2P emergent
Cloud native (scaling / resilience)
Standalone DB deployments
REST API calls direct to OVL, integrated smart contract back end
apps call smart contract functions
This evolution has taken us some time but has been worth it. Several experimental technologies were evaluated, some were retained and optimised, others we abandoned in favour of more industry-standard technology. We’re very grateful to everyone who has installed and run the first-generation gateways – the data from the tests on that network allowed us to get to where we are now.
The second-generation remote connector gateways are in final testing and will release immediately following the Overledger 2.0.x API releases that have been released since the beginning of June. We phased our work with API releases to initially make it compelling and easy for our customers and community to migrate from Overledger 1.0/1.5, release and develop their mDapp applications on Overledger 2.0 and benefit from the new technology and innovation it brings. Simplicity. This is the theme of the Overledger 2.0.x release train – expand the API, bring better tutorial applications and projects and make it even easier to build interoperable, stable cross-platform mDapps for enterprise and community developers.
These mDapps create volume on the Overledger Network (OVN), they are essentially the demand side of the platform and the OVN ecosystem. We wanted to have that ready to go, in the hands of partners, customers and the community to migrate to Overledger 2.0 prior to rolling out the supply side of the network – that is, Remote Connector Gateways (RCGs).
With Overledger 2.1.x, the second generation Remote Connector Gateways will be available as a download from the Overledger Portal. Connection to MainNets requires a paid license. Once downloaded and installed, the operator of an RCG points the connectors to their DLT and blockchain nodes (Bitcoin, Ethereum and XRP Ledger will be supported for the initial rollout, further supported DLTs will be added with the release of production connectors), a connectivity check occurs and they can set a price for transaction processing in QNT through their RCG, in addition to the mining rewards blockchain nodes already provide operators.
The routing algorithm ensures the best priced RCGs receive the most transactions, while fairly weighting the traffic flow. There are also price caps to ensure developers pay a sensible average price with no “single massive transaction cost” to encourage economic competition. In future releases, traffic flow will also be adjusted to take into account the availability, speed and accuracy of particular RCGs as well as a staking factor when staking is enabled on the live network.
What This Means For Quant
While we build for our developers, we also built Overledger in order to create our own customer and product mDapp-based solutions on top of the platform. Just like our community and developers, we are our own customer and aspiring mDapp developer! Using the functionality of Overledger 2.0, we are building out a small number of client and product solutions, with a pipeline of further solutions in the backlog.
Our focus on financial services and payments continues to be strong, with our new Multi-Ledger Token System (MLTS) innovation and technology. MLTS is an interoperable payment system that finally solves an industry challenge hindered by siloed decentralisation, balancing the openness, privacy, speed and flexibility requirements for interoperable CBDC, regulated stablecoins and other types of retail payment systems demanded by institutions and a foundation for mainstream DLT adoption. MLTS is being initially developed and deployed for our Latin American partnership with LACChain for tokenised money and is the basis for a number of other large-scale engagements.
SeeQ, our multi-DLT analysis tool, is being developed into a second iteration, based on target market feedback and will be generally available later in 2021, allowing customers such as financial institutions, compliance teams, authorities, law enforcement and others to integrate advanced multi-DLT transaction searches with smart visualisations and case management.
MLTS, our CBDC solution, is only possible because Overledger lets us connect to multiple private and public DLTs, use address subscriptions via API, payments via API, and add custom mDapp logic.
50% Quant team has grown by over 50% and will continue to do so
OVL1.0 to 2.0 Release schedule accelerated, moved to much more frequent automated updates
– Previously, last major update was seven months, then in early 2021 moved to three months (Jan and March)
and then to monthly (April and May). We’re now moving to fortnightly releases.
2.5X Overledger is now 2.5x bigger (April)
2.0 Re-engineered the entire 2.0 architecture
Open API 3.0 for easy integration into developer workflows
OAuth 2.0 for single sign on for enterprise customers
Cloud Native Scalable and resilient already, now deployable automatically
New OVN API
OVL 2.0 Developer portal 2.0
What’s coming soon in our accelerated release cycle:
Releases to date
1.0.0: was June 2020
1.5.0: was January 2021
2.0.0 preview: was April 2021
2.0.0: was May 2021
2.0.1: API Update (Native txns, subscriptions for txn, address and smart contract-based events)
2.0.2: API Update (SC invoke, SC read, extended search)
2.0.3: API Update (ERC20 payments API)
2.0.4: Demo Application Release
2.0.5: API Update (ERC721 transfer API)
2.1.0: Community RCG Preview Release (QNT payment not enabled)
2.1.1: Community RCG Full Release (QNT payment-enabled)
2.1.2: API Update (cross-DLT atomic swaps simplified API)
1.0.0: Preview Release (KYC and Fiat Treasury, BTC, ETH, XRP)
1.0.1: Full Release
1.0.2: DLN Update (R3 Corda)
1.0.3: DLN Update (Stellar)
1.0.4: DLN Update (HLF Sandbox)
1.1.0: Signing Service
1.2.0: Enterprise RCG
2.0.0: ODAP Inter-Gateway Routing MVP (2022)
For Application Developers and Enterprise Customers
Overledger 2.0 is targeted at radically improving our developer experience. We are moving functionality from the SDK into the API, standardising and extending that functionality, so that the features and functionality of any blockchain can be built into any app, using a simple REST API. Providing stability and interoperable cross-platform Multi-DLT applications (mDapps) that are simple to develop and stable to maintain, abstracting the complexity and changes of underlying DLT updates behind our API.
We now support OAuth 2.0 for authentication and single sign-on, Open API 3 API standards for improved developer workflow, and in general the 2.x Overledger is much more adherent to industry standards.
We are going to provide a tutorial project / mDapp to make it easier to developers to build Overledger functionality into their applications. The demo application will showcase all the features of the API and will continue to be maintained as the API is extended over the coming weeks and months. Find out more: developer.quant.network
The Overledger Advantage: Making an ERC20 Payment
As an example of how Overledger makes development simpler, let’s take a look at the knowledge and steps required to make a simple payment of an ERC20-based token from an app.
Without Overledger a Developer must:
1. Integrate a signing method and the native signing libraries
2. Add or pass the private key for transaction signing
3. Set up an Ethereum node (or connect to a public node)
4. Know the ERC20 smart contract address and function name and parameters
5. Understand and calculate Ethereum fees for the transaction
6. Code a valid Ethereum transaction in the native format to invoke the smart contract function
7. Perform transaction signing with the signing method above
8. Connect to the node with the node’s own API
9. Send the signed transaction
10. Consult a blockchain explorer website to check the confirmation status of the transaction
In order to then do another transaction on XRP Ledger or Bitcoin, all of the steps must be done again (bar the smart contract parts) with different configuration and code.
With Overledger this Process is Simplified:
1. Add a private key to the SDK (or signing service in 2.2)
2. Call the endpoint https://api.overledger.io/payment with the required information:
- From Address: Sending Address
- To Address: Recipient Address
- Type: e.g. ETH, USDC, QNT
- Network: e.g. Ethereum, Ropsten
- Urgency: Overledger will handle fee calculations for each network-based on desired urgency of the payment
- Optional: Callback URL – status updates will be sent direct to the application as the transaction confirms on the DLT
This single API call works across all the supported DLTs. In order to do a transaction on XRP Ledger or Bitcoin, the only changes needed are to change the “Type” to BTC or XRP and “Network” to the relevant Bitcoin or XRP Ledger TestNet or MainNet.
We are adding more functionality into this framework all the time, which will include ERC721 asset transfers, escrows, cross-DLT atomic swaps, cross-DLT asset transfers and much more.
For Remote Connector Gateway Operators
Remote Connector Gateways 1.0 (known as Overledger Gateways at the time), were based on experimental and proprietary peer-to-peer protocols, and tightly integrated with the Overledger 1.x architecture.
The 1.0 RCGs went into performance testing since late 2019 with public testing since June 2020.
We have been reviewing the feedback and performance of the RCG 1.0 design and moved to a more robust and standardised framework covering routing, token economics, staking, pricing and transactions. We updated the RCGs for the Overledger 2.x architecture in preparation for ODAP and removed the legacy peer-to-peer functionality, as the longer-term strategy has moved away from p2p back-end gateways to whole Overledger instances being able to connect in a peer-to-peer fashion in a standards-based way using the Open Digital Asset Protocol (ODAP).
At a protocol level we initiated the development of ODAP in 2020 with MIT and are developing ODAP along with others within the IETF, the home of today’s internet protocols and standards such as TCP/IP and HTTP. In our future ecosystem with multiple Overledger instances globally, each Overledger has an associated fleet of RCGs and DLTs spread geographically, and the Overledger instances can pass secured traffic to one another in a global network of networks. During 2021, we have rebuilt RCGs with new RCG 2.0 architecture which integrates tightly with Overledger 2.0 and the new features and technologies it provides behind the API. The new RCGs are currently in final testing for release in Summer 2021, immediately after the ongoing June Overledger 2.0.x updates on TestNets and MainNets.
RCGs will launch with Overledger 2.1 and will allow RCG Operators to transact and process MainNet digital assets and QNT. We are not launching them immediately with the Overledger 2.0 release as the initial release is focused on the developer experience and it ships first to provide developers time to migrate from OVL 1.0 / 1.5 and adopt the new 2.0 APIs to build and launch mDapps on the Overledger Network (TestNets and MainNets) with the new features and technology of Overledger 2.x.
In Overledger 2.1, mDapp DLT traffic will be distributed across the set of Remote Connector Gateways. This introduces a couple of new mechanisms in the Overledger Portal. RCG Operators will register their DLT connectors and will set their own pricing to process transactions and be paid (within limits). A new routing algorithm will balance traffic to encourage competition and volumes so that application developers pay a fair weighted average for their traffic – RCGs with lower prices will receive more traffic but all RCGs will receive some traffic. Over time the routing algorithm will be updated to factor in staking, correctness, uptime, and performance of the RCGs.
Pricing on the Overledger Community Network will be QNT denominated. Fees paid by applications will be distributed to RCG operators based on the number of transactions they process and the price they set. Quant network fees are applied at the transaction level. Pricing tiers for developer and RCG operator annual subscriptions will be formally announced with the release.
Overledger CDK – For DLT Connector Developers
We are building a Connector Developer Kit (CDK), to allow maintainers and developers of commercial and academic blockchains and distributed ledgers to open their systems to Overledger applications. This kit will include examples and specify the standards and conventions that Overledger 2.0 uses. Connectors developed with the CDK will undergo thorough testing with Overledger before being added to a supported release of Overledger. This innovation will enable the continuous addition of further DLTs and blockchains, Distributed Ledger Networks (DLNs) and business networks to the OVN ecosystem, increasing the value of the network to our users and expanding the possibilities of cross-network transactions, use cases and mDapps.