Whitepaper

Disclosure

This white paper is for information purposes only and may be subject to change. We cannot guarantee the accuracy of the statements made or conclusions reached in this white paper and we expressly disclaim all representations and warranties (whether express or implied by statute or otherwise) whatsoever, including but not limited to: • any representations or warranties relating to merchantability, fitness for a particular purpose, suitability, wage, title or noninfringement; • that the contents of this document are accurate and free from any errors; and • that such contents do not infringe any third party rights. We shall have no liability for damages of any kind arising out of the use, reference to or reliance on the contents of this white paper, even if advised of the possibility of damages arising. This white paper may contain references to third party data and industry publications. As far as we are aware, the information reproduced in this white paper is accurate and that the estimates and assumptions contained herein are reasonable. However, we offer no assurances as to the accuracy or completeness of this data. Although information and data reproduced in this white paper are believed to have been obtained from reliable sources, we have not independently verified any of the information or data from third party sources referred to in this white paper or ascertained the underlying assumptions relied upon by such sources. As of the date of publication of this white paper, CRD tokens have no known or intended future use (other than on the CRD Network, as more specifically defined in this White Paper). No promises of future performance or value are or will be made with respect to CRD Tokens, including no promise of inherent value, no promise of continuing payments, and no guarantee that CRD Tokens will hold any particular value. Unless prospective participants fully understand and accept the nature of the CRD business and the potential risks associated with the acquisition, storing and transfer of CRD Tokens, they should not participate in the CRD Token event. CRD Tokens are not being structured or sold as securities or investments. CRD Tokens hold no right and confer no interests in the equity of any company. CRD Tokens are sold with an intended future functionality and utility on the CRD network and This white paper does not constitute a prospectus or disclosure document and is not an offer to sell, nor the solicitation of any offer to buy any investment or financial instrument in any jurisdiction. CRD Tokens should not be acquired for speculative or investment purposes with the expectation of making an investment return. No regulatory authority has examined or approved any of the information set out in this white paper. No such action has or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of this white paper does not imply that applicable laws or regulatory requirements have been complied with. Participation in cryptocurrency projects carries a substantial risk and may involve special risks that could lead to a loss of all or a substantial portion of your contribution.

1- Introduction

CRD Network is  delivering real world data OnChain, resulting in a  Finance 2.0 ecosystem delivered via API endpoints to the oracles, dApps and end users directly. We define Finance 2.0 as a combination of DeFi transactions and services  with CeFi (centralized finance).

Ecosystem includes KYC Data Module, Transaction Banking Module and a set of crypto and traditional finance microservices which are using Hyperledger Besu private sidechain to maintain immutability of all major events within databases. Each significant transaction is stored, broadcasted and validated by the independent set of Masternodes within Hyperledger chain, and further enhanced by regular rollups state of the system into ETH mainnet.

The Network’s infrastructure, built on Hyperledger Besu, ensures that any major transactions and sets of data (like KYC data) are stored in an immutable manner. The data cannot be counterfeited without leaving any trace, which greatly aids the compliance.

Goal of CRD Network is to create a set of unified and standardized CeFi data and DeFi protocols. Moreover, CRD network aims to reduce AML risks as well as transaction data for institutions and users.

1.1.1 The CRD Network ecosystem

CRD Network merges Decentralized Finance (DeFi) with everyday real-world data, Including financial history, real Asset prices and compliance data by creating a GDPR and AML compliant environment that lessens the points of friction between you and the future of finance.

FinTech products enjoy great flexibility due to Microservice architecture. This particular technology allows to plug and integrate new services (or blockchains) without any major changes to the system.

The main benefit of using this setup is its ability to interact and bring your everyday financial data on-chain.

CRD Network bridges the Data and Regulatory gap between the Onchain and the “offline” economy.

Currently, CRD Network consists of the following modules:

KYC+KYT Module - Identity and document verification, AML, liveness check + crypto transactions compliance.

Proof-of-KYC engine (on-demand broadcasting KYC status of the user/address without revealing user details to the 3rd parties)

Proof of Real Assets Reserves - Providing the capacity to connect your real world assets value to the onchain & DeFi world. It enables you to leverage your full asset base and interact with lending and the stack protocol.

Transactional Banking module - IBAN accounts, cards & transfers.

Crypto Custody  -  Iinsured custody, transfers & yield.

DeFi module  - Crypto decentralized trades in compliant manner.

Supplementary modules:

Node explorer (validator nodes for all major transactions)
https://netstats.crdtoken.org

Auditing module (regulator/auditor access point to verify KYC data)
https://auditing.app.crdtoken.org

Auditing tools for regulators (to trace data)

1.1.2 CRD Token

CRD is a utility token based on the ERC-20 protocol, which is issued by the Ethereum blockchain.

There are several use cases for the token:

Some transactions within CRD Network require to hold or spend CRD by the users

Private CRD Masternodes, which allows users to stake CRD and validate transactions, thus increasing the strength of the network (in development).

Several tiers of the crypto cards, where each tier requires to stake some CRD to get better rewards  (in development).

Cashback on cards in form of CRD  (in development).

1.1.3 Tokenomics

Token name: CRD

Protocol: ERC-20

Contract Address: 0xcaaa93712bdac37f736c323c93d4d5fdefcc31cc

Total Market Cap: 1 000 000 000 (pre-minted)

CRDs were initially distributed via ICO in 2018, and traded on the main exchange (Cryptaldash), as well as secondary markets, like SushiSwap and UniSwap.

Portion of the tokens was bought back with the intention of reinvesting in the project.

2 - Infrastructure Overview

CRD and the aggregate CRD Network are designed to be built upon and have Decentralized Finance (DeFi) apps deployed on them. In other words, its primary value stems from its modularity, whereby third-party developers can build virtually any FinTech application on the network.

In this section, we will be discussing proposed use cases of the CRD Network as consumer, business and institutional products. But primarily, we will showcase various products and services that are currently being developed by our DeFi innovation partner, DLTify.

2.1 KYC/AML module with immutable trails

We believe that compliance in crypto is an inevitable process which is why we strongly endorse KYC integration as a core system to all services. We understand and respect the spirit of the crypto community that endorses anonymity, however the coming regulations will require crypto compliance as it will support the wider adoption of DeFi.

By design, most cryptocurrency protocols allow anyone to create their own wallet at any time without limitations. This significantly complicates the compliance process, as it may prove very difficult - if at all possible - to understand the owner of a certain crypto wallet address.

Also, the latest surge in SmartContract usage (DeFi ecosystem) allows trading and sending of cryptocurrency peer to peer without using any centralized third party. This further complicates the process of identifying counterparties in each transaction.

These issues are big blockers for any form of DAO as well as for the future of dApps. And they greatly limit the institutional participation into DeFi. To summarize:

There are a minimum of two components required to solve these problems:

An entity which could perform KYC of each user, with the ability to link user and his crypto address

A “registry” system which would allow anyone to check compliance of the crypto address to enable risk assessment

We have built a system that allows us to perform a user check by using several KYC providers. The system also lets us store data in a unique manner (Pic 1).

First off, all user personal data and approval process logs are stored within the traditional database. And we also ensure that none of the approval process logs can be altered, thanks to Hyperledger Besu private blockchain.

To make sure that data in the blockchain cannot be altered, we have built a masternode system to validate all important actions within the network. This is performed by independent nodes. Each important operation, such as validating a KYC process, is recorded there with all the associated timestamps and hashes.

All this allows auditors/regulators to trace each KYC request lifecycle, as we show the whole sequence of events, including data queries from KYC providers for various checks we make. We also do regular snapshots of the system state to the public blockchain, thus adding an extra layer of immutability to the system.

Pic 1: KYC data processing & storing

All past transactions are stored in the blockchain and synced with masternodes. This makes it impossible to revert old data, as we operate on a PoS private network, with nodes ensuring that no previous data can be altered. And even if we would want to change something on the blockchain - for whatever reason - all traces would stay in the system, thus ultimately restricting us from altering anything.

2.2 Proof-of-KYC on chain (DeFi compliant KYC concept)

For users who successfully passed KYC, we have built a “Proof of KYC” system to openly broadcast their KYC result - without any personal data - to the public blockchain (Pic2).

This broadcast happens via publicly accessible smart contract. And it includes the following data:

Object ID (crypto address or other reference)

KYC ID (unique reference from our Hyperledger system) - this will allow us and regulators to identify the end user using our system

Object Type ID (nature of the object - is it a crypto address, social handle, etc)

KYC level

Pic 2: Proof of KYC publishing

If requested by the user, we can publish this data to the public blockchain (neither limited to ETH nor to others).As we publish on our side, there is no risk of anonymous users posting fake KYC IDs into our Proof-of-KYC smart contract.

Object ID and Object Type fields allow us to link any object to the KYC reference. Meaning, users can post their BTC address within ETH public network. Still, we do require some extra measures to ensure that this object is actually in control of a given user. This ensures that the users can't post random object ID and claim it's related to them.

Proof-of-KYC allows anyone to lookup certain objects such as ETH, BTC and other addresses in our Smart Contract registry (Pic 3).

Timestamp of KYC submission

Object ID (like cryptocurrency address)

Object type

KYC ID

KYC status

Using KYC ID, qualified third parties can request that we confirm the identity of a user. However, this is not mandatory. The fact that a user object appears in our registry indicates that this particular user passed KYC with us at some point with certain KYC status.

Certain third parties such as qualified dApps or other fintech entities can get extended info on a user. This will include logs of approval, without revealing personal data. This provides an open infrastructure for third-party organizations that may not have the infrastructure - or inclination to do KYC for the users and keep KYC data - but still have regulatory requirements to verify user’s identity based on object ID.

Each KYC status can be customized, which means that at a certain point KYC record would need to be reconfirmed with another status (after expiration).

Pic3: Validating KYC record on chain for external observer

Regulators and GDPR policy controllers need a more detailed overview of the personal KYC records (Pic 4).

We can provide extended versions of all KYC logs via Hyperledger masternode. If more information is needed, we have a module to show detailed user data from the backend system.

Pic4: Validating KYC record on chain for Regulators/GDPR purposes

In summary, the main benefits of this module are:

Gain the ability to KYC people as a service for third-party organizations that may not have the infrastructure - or inclination to do so - but still have regulatory requirements to verify users identities.

Create a “walled garden” on the CRD Network, where only vetted participants can transact. Through this method, the risk of DeFi is considerably reduced. This is because while participants don’t know each other, there is the certainty that they all have had their identities verified and the source of funds corroborated.

This ability to immutably onboard users - where other services can verify that the KYC procedure has happened and where DeFi spaces can be created - ensures wider institutional interest for blockchain technology.

This is because the biggest obstacle facing financial institutions when it comes to adopting DeFi into their business model is that it is an unregulated and non-compliant space. Verifying and guaranteeing the different users’ identities will allow financial institutions to overcome one of the biggest hurdles for participating in this nascent industry.

2.3 Proof of Physical asset Reserves

The CRD Network is able via its regulated custody contributors to offer an aggregated service of proof of Physical Asset Reserves allowing to broadcast a single source of truth related to a single public key linked to a single KYC record.

2.3.1 The Digital Proof of Ownership - Source Custody Services

Each and every ERC721 refers to the Digital Ownership of real world asset as follows:

2.3.2 Broadcasting and preventing double spend

2.3.3 Main Features & Use  of Digital Proof of Physical Asset Reserves

Effect on loan Origination

The actions outlined herein create a perfectly immutable record of loan provenance on a distributed system that acts as a ledger, registry.

Lower origination and aggregation costs - Trustless and immutable origination results in the

Reduction of QC, compliance and upfront audit costs.

Ability to pledge real time with a complete chain.

Lower deal costs - Smart contracts and immutable data provide certainty to assets,

2.4 Proof of Fiat and securities asset Reserves

Within the Bank module, it is possible to have connection to the open banking functionality by utilizing the Payment Service Directive (PSD2). PSD2 is a 2015 EU Directive regulating payment service providers throughout the Eurozone. The ultimate goal is to build a more systematized European transactions market and to increase security for customers.

This regulatory directive requires banks to provide open APIs, a protocol that enables external programs to read and interact with the bank’s data, after passing certain security checks.

We are working on utilizing three main functions of the open banking sphere: AISP, PISP and PIISP (CISP).

AISP - Account Information Service Provider. Allows to retrieve account data provided by banks and financial institutions.

PISP - Payment Initiation Service Provider. Allows to initiate payments into or out of a user’s account.

PIISP - Payment Instrument Issuing Service Provider. Also known as CISP (Card Issuing Service Provider) - the same as PISP, but for cards.

These functions will initiate payments and fetch some user info on demand - after user approval - via third-party banks. This in turn will provide better UX and user coverage.

2.5 Proof of Crypto Asset reserves & monitoring module

Maintaining a bridge between traditional finances and crypto requires the ability to generate crypto wallets and transact in the blockchain. CRD Network is integrated with licenced & insured crypto custody solution which allows to:

Create & maintain crypto accounts

Create transfer transactions in the corresponding blockchains

Real time monitoring of the balances for an address or list of addresses on chain with real-time updates and indicative values

Real-time transactions monitoring per address/list of addresses

Self-custody support (Metamask wallet)

Crypto to crypto services (cent)*

NFT storing and generating*

*in development

Each wallet is insured and stored in the external secured custody.

2.6 DeFi compliant module and DeFi Source Of funds

Currently DeFi gains generated by users are classified by financial institutions as gains generated from the Shadow financial system. This automatically classifies the gains as very high risk, thus restricting deposits and withdrawals.

In most cases, for crypto related operations users will be prompted for Source of funds for such operations. Without the ability to generate a document tracing the funds, users are faced with a dead end when it comes to integrating their DeFi gains into the real economy.

This module allows users to interact with on-chain DeFi protocols both for self custody solutions (like Metamask) and custody of CRD Network. We are developing a set of contracts which will allow users to swap, lend and stake their crypto utilizing various dApps in ETH network and other sidechains.

We are using a combination of user Proof of KYC and our smart contracts to make sure that transactions via this channel can be considered compliant. We can achieve this by always knowing at least one counterparty and can control the exact DeFi channel via smart contract (avoiding certain non reputable dApps).

This will effectively achieve two objectives:

Formation of compliant DeFi pools where all participants have passed KYC and are compliant

Ability to provide a source of funds document for DeFi transactions. This will allow users to certify any gains generated from the interaction with the DeFienvironment.

Current DeFi projects & integrations we are working on:

1inch smart contract interaction

MakerDAO*

AAVE*

Compound*

*in development

2.7 Auditing tools for regulators

Auditing tools for regulators is another microservice that works within the KYC module. Regulators are allowed to use both Hyperledger Besu Masternode (to check immutable logs of each KYC process and major transactions) and backend database portal (to view end-user data).

Another option we are building is KYT service, which can analyze both CRD Network users and their counterparties / certain addresses on demand.

Access the tool: https://auditing.app.crdtoken.org/

3 - Network Architecture

In contrast to decentralized applications, CRD Network is by design centralized - some of its key components require it to leave a “trace” in the legal world: KYC, Banking transactions and custody transactions.

Centralization is not always bad, despite what some people may think. Centralization allows to build things easier, as we are not limited by blockchain smart contracts. We are also not restricted by the blockchain fees. And we can execute certain transactions more efficiently and more scalable.

All CRD Network core services (KYC, bank, custody, APis and most of other microservices) reside on Kafka messaging system, known for its reliability and scaling ability. These services run on AWS and are connected to several database types, depending on the type of data and certain requirements from the microservice.

A chart showcasing the CRD Network’s role as a middle operator between retail banking and the decentralized financial world

A bit more sophisticated version below:

For certain complex workflows, an orchestration mechanism is needed. We use Camunda for this. Without it, it is hard to keep track of each flow and monitor errors plus it allows us to manage rollbacks.

For example, all operations in Banking modules are orchestrated via Camunda. This is because Camunda supports many operations at once, allows to build complex flows and calls to the different system objects at the same time.

This architecture allows services to interact with each other and API points in a transparent, reliable and scalable manner, aiming to provide enterprise tier solutions for the system.

4 - CRD Token use cases

While many operations in the CRD Network are free, CRD are used for certain swap, lend and transfer operations. Some of these functions will become available after staking some minor amounts of CRD to facilitate natural demand of the token.

4.1 Masternodes

Private Masternode Holders are network participants who have provided the equivalent of 1m CRD as collateral and through this method staked a CRD Network Node. This allows them to:

Validate transactions, strengthening the POS system.

Receive some parts of CRD fees from the system, proportional to their stake in the network.

Participate in the governance process on a deeper level.

4.2 Governance

The governance of the CRD Network is done via two layers:

The WACEO, a non-profit organization which maintains the organizational and regulatory requirements.

Internal decisions are made in a representative, democratic manner by holders of a minimum of 1k CRD, who get a vote proportional to their financial participation in the network.

5 - Third-Party architecture

The main design philosophy is that the more use cases are created, for which there is demand, the more widespread adoption of CRD happens. The CRD Network is designed to operate as a substrate, wherein third parties are encouraged to build and deploy their financial applications on the blockchain.

As such, the CRD Network operates as an API infra Hub, which can collate and parse through data from the fiat and crypto sphere. This approach has a greater potential for FinTech solutions than you would find in other realms.

The more innovative third-party applications there are, the more they can be restructured to enhance utility or even create new functionality.

If a promising third-party signals interest in developing an application for the CRD Network, they will be provided with CRD as a means of financing, provided that they adhere to two conditions:

They have a technological use case that can be deployed and eventually profitably executed on the CRD Network.

They have to partner with a large social influencer to design a bespoke product with built-in demand. And the application has to adhere to safety and regulatory protocols, as determined by the WACEO board.

In this way, the CRD Network acts as a bootstrapping mechanism to idea-rich- but resource-poor- developers, while simultaneously creating applications with built-in demand (given that the influencers leverage large audiences). After which, the apps will eventually pay for themselves via fees and evangelization to new audiences.

5.1 API guide

Our API documentation can be accessed here:

KYC API: https://api.crdtoken.org/docs/kyc-api/

Please contact info@crdtoken.org to get in touch and receive API keys