The Goal
DoraID’s goal is to provide a general decentralized autonomous DID framework. The framework should support decentralized applications that have anti-sybil attack demands and identity verification requirements.
Existing on-chain KYC systems and DID solutions rely on centralized services to verify and record off-chain identity information. These services have three problems:
- They are not user friendly, the cost to use these services is high (users often need to register in separate apps).
- Centralized services are prone to risks of being compromised.
- Because of centralized information collection, these services are lack of universality, and they are not simple to use.
In practice, many blockchain infrastructures and applications provide rights to users based on token staking. Although “Proof of Staking” has been effective, most of POS services are designed for specific use cases. For Dapps that have single functions (e.g. a voting Dapp) or Dapps that are in long-tail markets, it is expensive for users to provide proof of staking for a single operation, the entry barrier of proof of staking is relatively high in such cases, therefore limiting the scalability of a Dapp.
DoraID is designed based on the concept of “proving identity by your assets”. It provides a decentralized identify verification abstraction based on token staking and staking duration only. The service allows users to stake tokens with flexibility, and provide a set of APIs for any smart contract to query status of a specific account and verify its identity based on self-defined rules within the Dapp, which is independent of DoraID itself.
Core Features
DoraID implements a smart contract that has the following features:
- Select any ERC-20 token for staking and identity verification services.
- Set up several genesis accounts (addresses).
- Allow users to stake tokens of any amount and time period. After staking, users can only withdraw tokens from the smart contract after the staking period. However, users can add tokens to stake or prolong staking period.
- Certified accounts will obtain proof of staking credits (POS credits) by staking.
- Any uncertified account that pass the threshold of staking amount and remaining staking time requirement can be certified by another certified account. The certifying account needs to consume certain amount of POS credits.
- The smart contract offers APIs to query account status. The APIs allow any other smart contracts or organizations to check the staking status of an account.
The smart contract will not contain any admin/super account. It will not be upgradable, and it will not charge fees.
DoraID will also provide a UI for users to interact with the smart contract (add staking, withdraw tokens, prolong staking). Organizations or individuals can also query staking status of any accounts.
Identity Proof
From the smart contract, any account can query the following information:
- If an account is certified
- Current staking amount of an account
- Earliest withdraw time of an existing staking
- The account address that certified the current account (if current account is certified)
- Accounts certified by the current account (if current account is certified)
- Proof of Staking credits (POS credits)
- A note (string) submitted by account owner with the proof of staking
The DoraID smart contract is context-independent. It does not decide any application-level identity verification status of any account, or rights resulted from such verification. A Dapp needs to use identity information provided by DoraID together with other information collected by the Dapp to verify an account, or provide certain rights to the account.
In general, Dapps using DoraID can use the following criteria to verify an account’s staking status.
A. Verify if the account has been certified
Some Dapps do not need to verify accounts’ certification status if the Dapp is implementing a use case that is completely public. We do recognize that in most cases, Dapps need to verify accounts’ certification status.
B. Verify if token staking amount is larger than a threshold
Normally a larger staking means more rights in certain applications. Dapps can verify the current staking status from the system.
Since token market price is fluctuating, Dapps using DoraID can adjust the threshold on demand.
C. Verify if remaining token staking time is larger than a threshold
A Dapp must verify if the staking period of the current account is longer than required. Otherwise, a Dapp can withdraw tokens from the staking pool and create another staking proof in order to obtain additional rights in the application.
For example, a user might apply for an IDO requiring KYC that lasts for a week. In order to achieve this, the IDO smart contract needs to check if the user has a proof of staking, of which the remaining staking time is longer than a week.
D. (Optional) Check chain of certification
Although the smart contract records all account certification history, it is not recommended to check full account certification history without any specific middleware to facilitate the process, mainly because recursive operations on-chain might imply high gas fees. On the other hand, there is usually no strong relationship between rights a Dapp offers and the certification history of an account. Therefore, a Dapp should verify if it actually needs to use an account’s certification history.
E. (Optional) Publish notes associated with the account
Smart contracts normally do not process the note associated with a staking. For off-chain applications or developers who look up identity of a certain account, the note associated with the staking can be read or published.
There is no specific requirement of how the notes should be submitted. The note itself is optional too, and there is no guarantee of any note’s authenticity. However, in some use cases, it is a good practice for a user to upload a URL, which points to a place that has public information of the user’s identity. For example, a note can contain a GitHub link, and the staking information is written within the readme.md of that GitHub repo, then the GitHub account and the staking account have proven relationship during an identity verification.
Lastly, Dapps should NOT refer to the POS credit of any account, even though the credit is also open information. Because the POS credit will be consumed when certifying other accounts, and the credit itself is increasing over time, it is not an indication for proof of identity or staking.
The Consensus Behind Identity Verification
Besides providing smart contracts and its frontend services, DoraID is building a consensus mechanism based on the identity service provided by the system.
The first thing to point out is — DoraID does not provide any off-chain information behind a staking address, whether it’s owned by an individual, or an organization/team/company. DoraID is a decentralized identity verification solution, without input of off-chain information, it’s solely based on the concept of “prove identity by assets”. It guarantees that the same assets will not represent more than one identity at any point of time. For example, it greatly increases cost of sybil attacks and protect Dapps from such attacks.
Other than the concept of “stake & verify”, DoraID also initializes the smart contract with several genesis account. New accounts need to be verified by some existing account that has already been certified. As a result, the certification process will create a web of certified accounts, and the chain of any account’s certification is traceable. Even though the smart contract does not implement any fee, an account certifying another account needs to pay for gas fees on a blockchain. Accounts will not volunteer to certify other accounts without compensation or communication. Therefore this mechanism implies some weak social relationship between the two accounts in a certification transaction. Even if a certified account does anything evil, the account certified it will not take any responsibility. However, if an account certifies other account indifferently, its own behavior might not be trustworthy.
Because traversing chain of certification is costly on-chain, most Dapps will not do it. Rather, most Dapps will care about an account’s certification status, staking amount, and staking period. In other use cases that do care about an account’s certification history, they can analyze the on-chain information. Based on some input of some existing account’s credibility, the Dapps can evaluate credibility of accounts and rate them differently. For example, some community-driven use cases, this kind of credibility evaluation can provide additional information for community members.
Other Extensions and Mechanisms
Besides core identity verification features, we are adding a few mechanisms to meet some corner cases in practice. Some of these mechanism will be added to the smart contract as functions, others will be implemented via some middleware smart contracts.
Verification requests with compensations
On the smart contract level, uncertified accounts that want to be certified can send a request with a compensation together with a delegate address. Once the compensation is sent, an account that is already certified can certify this account and get paid with the compensation (in ERC20 token that the smart contract supports). In the same time, if a delegate account is specified, then only the delegate account can certify this account.
This mechanism ensures any account can compensate other accounts for verifying it. It can be based on some pre-determined compensation between the two owners, and the delegation mechanism can avoid front-running.
Withdraw immature staking
Token staking amount and staking period are self-defined parameters in the smart contract. Before the maturity of a staking, accounts can only increase the number of tokens or prolong the staking period. There is the possibility that users might set a duration that is too long, or send a wrong number (e.g. 10x more than intended) of tokens to the smart contract by mistake. The mistakes might result a near-permanent lose of tokens. As the staking smart contract is admin-free, such mistakes are unrecoverable.
Although these mistakes are made by users, rather than problems of the service itself, we can discuss a withdraw procedure in such situations — users can stake a large amount of token with a certain minimum period to overwrite a previous staking’s duration.
If we add this kind of mechanism, there is the possibility that whales could abuse the system, and the reliability of the entire identity system could be affected. However, because there is a minimum period to stake, whales cannot create infinite number of identities within a certain period of time. If some whale stake token bluntly, there is also the risk of impermanent loss. In the case that some use case could bring huge benefits for whales attacking the system, we suggest to not use DoraID. Instead, in such cases, Dapp developers can use other KYC services.