A Detailed Overview of the Oracles & Compliance Concept in Smartlands Network
Last week, light paper on Smartlands Network — a new blockchain solution for financial markets from Smartlands — was released and immediately got a sharp attention from our community. The document provides a detailed overview of the key pillars on Smartlands Network ecosystem, yet there is much more to share with all of you! Smartlands Network aims to become a leading public ledger for the blockchain-based capital market of the modern world — a distributed ledger, that is flexible enough to automate settlement of all possible transactions for all classes of fungible assets. Starting from issuing and transferring assets and up to MTF trades and post-trade settlements.
This ambitious positioning influences architecture selection and the overall concept of the system. The network frankly speaking must facilitate transactions with any type of assets, starting from non-regulated utility tokens, and up to, what is even more important, opportunity to conveniently handle all possible transactions with digital securities in every possible legislation.
Every security token or tokenised fiat money is usually heavily tied to the Issuer, a regulated financial institution, usually licensed by authorities, and responsible for complying with appropriate local securities legislation, internal and global KYC & AML policies. In many cases, especially those related to equity shares of non-public companies in well-established legislation, these policies are complex enough to require the Issuer to have to be reliably notified and explicitly validate and execute every transaction with the asset. In other words, the issuer should explicitly approve every transaction with his digital signature. After checking the transaction across a set of flexible rules, that itself heavily depends on the wide range of real-world (off-chain) data and also can frequently change over time.
Within the existing implementation of Smartlands technological solution on the Stellar Network Blockchain — these requirements inevitably lead to a multisig architecture. For every licensed entity in the ecosystem, there should be a separate signing private key added directly to the investors’ wallets.
Therefore every entity in the ecosystem has to explicitly approve every transaction, even non-related to the specific asset. This approach can quickly become a major burden in the case of multiple independent regulated entities in the ecosystem, introducing additional unwanted complex business logic (entities synchronisation, wallets management, etc.) required to be implemented by every ecosystem participant — wallets and/or exchanges. “Multisig” even raises significant security concerns — the failure of the particular independent ecosystem entity (compromising or loosing of the signing private key) can leave all involved investors’ wallets permanently locked with all the assets.
Avoiding the “Multisig” scheme was the main goal for Smartlands technology for years since the current implementation was significantly limiting the ecosystem development and all aspects of the user experience on the Platform.
With this article, we are now launching a series of detailed descriptions of Smartlands Network components aiming to extend the library of documents. We will start with the Oracles and Governance concepts — the cornerstones of the Network design. Who will become Oracles’ operators, what participants in the Network ecosystem are, and how everything will work together — this and more information you can find by following the link below!
