ICO PASS Technical Overview
Author:
Gugun189: https://bitcointalk.org/index.php?action=profile;u=1366850
MyEth: 0xa4ee0e08D280B1b2AdFb0c942E70BFB22152446a
Gugun189: https://bitcointalk.org/index.php?action=profile;u=1366850
MyEth: 0xa4ee0e08D280B1b2AdFb0c942E70BFB22152446a
Introduction
While legally KYC checks are increasingly more important, there are many ICO organizers that choose the path of the least resistance (and don’t gather KYC information at all). So one of the end goals of ICO Pass is to enable KYC verification as easily as possible for the ICO organizers.
While legally KYC checks are increasingly more important, there are many ICO organizers that choose the path of the least resistance (and don’t gather KYC information at all). So one of the end goals of ICO Pass is to enable KYC verification as easily as possible for the ICO organizers.
Additionally, KYC verification does not guarantee that the ICO organizer will be able to get in touch with the contributor. Should a bank, or a regulatory agency ask for more information regarding a specific contributor, ICO Pass aims to have a way to allow ICO organizers to get in touch with the contributor.
Even with contact information and KYC information available, there is the matter of tooling. There are no KYC management systems that can interact with blockchain-based data. Also, different ICOs use different smart contracts to manage their crowdsale. Often crowdsale contracts are audited, and may not be easily changed.
Working back from these assumptions, we have decided on a few design goals:
- payments from non-eligible addresses should be refused at the smart contract level. This will reduce the amount of work required afterwards to refund non-eligible contributors
- enabling contributor verification should be simple - ideally with no more than just a Solidity function modifier. This should ease auditing constraints.
- additionally, a proxy contract can be deployed to forward only verified funds. However, since an audited crowdsale would have to audit the whole setup, then a proxy contract does not offer significant advantages over a Solidity function modifier.
To satisfy these constraints, the KYC data needs to be queryable from Ethereum. On the blockchain, ICO Pass consists of a suite of contracts, which facilitate:
- proving ethereum address ownership to a verifier;
- a claim registry, where subject addresses can be matched to data (signed by a given verifier);
Initially ICO organizers who would adopt the ICO Pass, would have to trust the ICO Pass verification key signatures - because there would be no other verifiers.
However, in theory, new verifiers could appear and submit information about ethereum addresses.
However, in theory, new verifiers could appear and submit information about ethereum addresses.
Additionally, ICO Pass provides a few non-blockchain services as well:
- a mobile application for gathering information (including contributor photos);
- a webservice for interacting with the mobile application, and signing the KYC information gathered with the ICO Pass mobile application.
The mobile application will be open-sourced after the ICO Pass crowdsale. At no point will it ask for private keys from the end-user.
The webservice, which performs KYC verification and submits signed information to the blockchain, will not be made open-source initially.
Since storing data in the blockchain is expensive, most of the data would have to be stored elsewhere. The blockchain-based registry will store only a value, which can be:
The webservice, which performs KYC verification and submits signed information to the blockchain, will not be made open-source initially.
Since storing data in the blockchain is expensive, most of the data would have to be stored elsewhere. The blockchain-based registry will store only a value, which can be:
- nationality index as an integer value
- short text strings for public entity identification
- URLs to encrypted content of personal information
- additional Ethereum addresses, e.g. for address linking:
What about non-Ethereum funds?
Formally, ICO Pass only supports Ethereum addresses. However, cryptocurrencies that use the same elliptic curve for its user keys should be verifiable as well.
ICO Pass currently does not support smart contracts for contributor verification on non-Ethereum platforms. It has not been tested with Counterparty.
Formally, ICO Pass only supports Ethereum addresses. However, cryptocurrencies that use the same elliptic curve for its user keys should be verifiable as well.
ICO Pass currently does not support smart contracts for contributor verification on non-Ethereum platforms. It has not been tested with Counterparty.
Document Guide
This document will focus on technical aspects of the product. For business analysis see Prospectus.
This document will focus on technical aspects of the product. For business analysis see Prospectus.
Scope
This document aims to describe the internal operations of the product. Among other things, this includes:
This document aims to describe the internal operations of the product. Among other things, this includes:
- what components the product consists of
- data flows among the internal components
- how the KYC checks are carried out
- how the verified identity is associated with one or more Ethereum addresses
- how the information is stored and accessed by the ICO organizers
This document does not describe non-technical aspects of the product. Non-technical information can be found in the ICO Pass prospectus document which can be found here.
Structure
The document is divided into multiple parts.
The first part describes the workings of the main ICO Pass components - the mobile client, the verification webservice, the KYC providers and the smart contracts used to store and retrieve information about ethereum addresses
The second part describes the mechanics of the token sale.
Finally, at the end of the document, there are multiple appendices. These include more in-depth explanations, as well as the full source code of the Ethereum smart contracts at the time of publishing this document.
The document is divided into multiple parts.
The first part describes the workings of the main ICO Pass components - the mobile client, the verification webservice, the KYC providers and the smart contracts used to store and retrieve information about ethereum addresses
The second part describes the mechanics of the token sale.
Finally, at the end of the document, there are multiple appendices. These include more in-depth explanations, as well as the full source code of the Ethereum smart contracts at the time of publishing this document.
Mobile Client
The mobile client acts as a device for gathering information:
- it allows taking a photo or video recording of the user
- it allows taking photos of documents, and immediately giving feedback about the quality
- it allows verifying the phone number
It also offers a way to give easy feedback to the contributor: - when the KYC checks are done
- if more information is required
- perform ICO address trustworthiness evaluation by indicating that candidate ICO has not been registered
Finally, it can automate tasks for the end-user, which improves the user experience. It can perform automated wallet key ownership verification and personal information storage for reuse in subsequent ICOs.
First Run
When the ICO Pass mobile application is first launched, it will generate an ethereum keypair, and store it in the devices keychain.
When the ICO Pass mobile application is first launched, it will generate an ethereum keypair, and store it in the devices keychain.
NOTE: this key is never exposed externally.
Then it performs onboarding with the verification webservice. The webservice will send a verification e-mail, and an SMS code to the e-mail address and phone number supplied by the end user.
The webservice will send a small amount of ethereum to the internal address. The application will use it to pay for the key ownership proof transaction (see: KeyProof contract in the infrastructure smart contracts documentation).
Afterwards, the application will consider the user to be onboarded.
Afterwards, the application will consider the user to be onboarded.
Submitting Data for ICOs
When the end-user wishes to enroll for an ICO, they will have to perform an in-app purchase.
The in-app purchase receipt will be sent to the verification webservice, which will validate the receipt. If the receipt is valid, KYC verification will commence.
The user will be asked to take a photo of themselves, and of their chosen identity documents. They will also enter their address and date of birth.
The in-app purchase receipt will be sent to the verification webservice, which will validate the receipt. If the receipt is valid, KYC verification will commence.
The user will be asked to take a photo of themselves, and of their chosen identity documents. They will also enter their address and date of birth.
This information will be re-usable, unless an ICO specifies expiry dates.
The verification webservice will use this information to perform KYC verification against multiple sources:
- is the document valid
- does the document match the photo of the person
- is the person in PEP/global sanction lists
If the person is in PEP or sanction lists, the identity verification will cease.
If the person’s document does not match the photo, the verification will cease.
If the person’s document image is invalid (e.g. invalid machine readable code), can not be scanned, or it is expired, then the verification will cease.
If the person’s document does not match the photo, the verification will cease.
If the person’s document image is invalid (e.g. invalid machine readable code), can not be scanned, or it is expired, then the verification will cease.
Full details about how the KYC checks are carried out, and about all the possible failure cases, can be seen in our GitHub repository.
As far as the mobile client is concerned, however, it only gathers data, then sends this data to the verification webservice.
For each verification attempt, the webservice can respond (asynchronously) with:
- ok
- failed, ineligible (e.g. user is a PEP)
- failed, please repeat (e.g. user’s passport image was too blurry)
Verification Webservice
After the mobile client gathers information, the verification webservice analyzes it and orchestrates the delivery of this information to the recipient (i.e. the ICO organizer).
It cross-references the gathered information with multiple backing data providers, and signs it. Then it encrypts this information against the ICO organizer’s address, and publishes it to the claim registry.
After the mobile client gathers information, the verification webservice analyzes it and orchestrates the delivery of this information to the recipient (i.e. the ICO organizer).
It cross-references the gathered information with multiple backing data providers, and signs it. Then it encrypts this information against the ICO organizer’s address, and publishes it to the claim registry.
Team
RoadMap
1
February, 2017
ICO launch. Product launch.
Technically: validate that the owner of
an Ethereum wallet has passed an ID
background check stating that they are
not part of a restricted set of users (e.g. US
citizen or individuals on official watchlists).
The background check is run via a third
party, namely Onfido. The ICO Pass team
has set up a smart contract system to
record the outcome of the background
check on the public Ethereum blockchain,
i.e. whitelist Ethereum addresses that are
owned by non-restricted users.
Legal point of view: doublecheck with
all the regulators in different countries
how to even more effectively meet their
requirements.
Business: attract first ICOs from Europe.
1
February, 2017
ICO launch. Product launch.
Technically: validate that the owner of
an Ethereum wallet has passed an ID
background check stating that they are
not part of a restricted set of users (e.g. US
citizen or individuals on official watchlists).
The background check is run via a third
party, namely Onfido. The ICO Pass team
has set up a smart contract system to
record the outcome of the background
check on the public Ethereum blockchain,
i.e. whitelist Ethereum addresses that are
owned by non-restricted users.
Legal point of view: doublecheck with
all the regulators in different countries
how to even more effectively meet their
requirements.
Business: attract first ICOs from Europe.
2
Mar, 2018
New databases are added for higher
accuracy.
Mar, 2018
New databases are added for higher
accuracy.
3
April, 2018
Video identification with live agents added.
April, 2018
Video identification with live agents added.
4
May, 2018
ICO organizer communication tool added
for contacting ICO contributors.
May, 2018
ICO organizer communication tool added
for contacting ICO contributors.
5
June, 2018
Integration with US State Revenue
Service or Banks to automatically
determine if the investor is accredited.
First US based ICO.
June, 2018
Integration with US State Revenue
Service or Banks to automatically
determine if the investor is accredited.
First US based ICO.
6
November, 2018
Integration finished with Banks who in
EU are providing their APIs under PSD2
regulation. Automatically determines if
the person is accredited investor.
November, 2018
Integration finished with Banks who in
EU are providing their APIs under PSD2
regulation. Automatically determines if
the person is accredited investor.
7
December, 2018
Interest payout functionality in app.
December, 2018
Interest payout functionality in app.
For More Information:
Komentar