MYKEY is a Self-sovereign Identity System. The underlying protocol is called KEY ID.

The purpose of this document is to explain the differences between MYKEY account and traditional EOS account.

Meanwhile, document will demonstrate the simple way to make your code compatible with MYKEY App.

What are the differences on MYKEY?

To improve user experiences and lower the threshold of EOS usage, MYKEY designed to resolve the problem of private key management and resource consumption management based on KEY ID protocol.

More details in MYKEY Whitepaper

MYKEY has re-designed the native EOS account by KEY ID Smart Contracts that split two parts on EOS mainnet.

In EOS, MYKEY supports features like key recovery, privilege level, free account, free usage, authentication, sub account and so on. For easy understanding, MYKEY tries to hide technical concept for end users. In MYKEY App, user do not have to care about CPU/NET/RAM of their EOS account.

But at the same time, user's account still stays self-sovereign, authority belongs to users. More details will be disclosed in coming documentation and open-source plan.

MYKEY account structure

There are two types of key in MYKEY account structure: Admin Key and Operation Key. In SmartContract, Admin Key cannot sign any general transaction except sign transaction to replace Operation Keys with time-lock.

MYKEY account system and private keys authorization structure

The private key of Admin Key generated by mobile device which can be cold-backup through recovery code or hardware wallet during registration. The private keys of Operation Keys generated and secure stored by mobile device.

The public keys of Admin Key and Operation Keys are used to signup account and stored in SmartContract for further on-chain signature verification.

With those novel design principle, MYKEY can help dapp build their own native dapp without any explicit sign between dapp and 3rd party wallets. What's more, users can safely manage their asset, vault account, dapp accounts, data by different operation keys which is in one single account, we call it Self-sovereign Identity.

Keys in table keydata

Every keys of MYKEY account will be stored in table keydata of contract mykeymanager, we can use ACCOUNT_NAME as scope to query all keys in MYKEY account.

Use following account mykeyhulu521 for example,

MYKEY predefined four keys for every account during sign up. Details shown in the following table




AdminKey: Top privilege, can manage other operation keys


OperationKey 1/Asset key: only use for transfer assets


OperationKey 2/Adding key: For creating more new operation keys


OperationKey 3/Reserved key: For other actions without specific operation keys

Integrate EOS dapps with MYKEY

Because MYKEY does some customization on EOS account structure, there're some good tips for dapp developers.

1. Ignore the CPU and NET monitor

Because MYKEY take care all resource status for users. Every MYKEY account always stake 0 CPU and 0 NET on EOS chain. So dapps user interface should ignore resource warning for MYKEY account.

2. For dapps compatible with Scatter

MYKEY almost compatible with interfaces of Scatter protocol. The only difference from traditional wallet is MYKEY will use one of its 3rd OperationKey/Reserved Key to sign transactions instead of the EOS owner/active key.

Any actions of original contacts will be wrapped by MYKEY app, then send to mykeymanager for verify signature and then forward to the target contracts. In most of cases, anything works correctly without any changes in code.

How to check dapps are running in MYKEY webview

There are two methods to check if dapps are running in MYKEY client.

  1. Use navigator.userAgent to check. MYKEY webview will append MYKEY/[version] after the original userAgent.

function isMYKEY(){
return navigator.userAgent.indexOf("MYKEY") > -1;
  1. Use scatter.getIdentity to check if the response data contain type:'MYKEY',

    the return data snippet

accounts: [{authority: 'active', blockchain: 'eos', name: [ACCOUNT_NAME], type: 'MYKEY'}],
publicKey: [OperationKey 3/Reserved key]

If dapp dependents on getArbitrarySignature or other server side authentication

For dapps are using method scatter.getArbitrarySignature or other method to verify account authority in sever side. The code for verifying signature should be refined for MYKEY account.

In this case. MYKEY uses the reserved key which index is 3 to sign through scatter.getArbitrarySignature. Server side of dapps need use the corresponding public key of reserved key to verify signature, it can be queried by backend code in table keydata of contract mykeymanager by scope ACCOUNT_NAME.

We already implemented some sample code for reference. Please check it out.

3. For native dapps

MYKEY Development Toolkit, aka MDK, a toolkit for developers to develop applications based on the MYKEY account system. It contains MYKEY Client SDK, JSBridge Lib and SimpleWallet protocol extension. This suite of development toolkit can help applications wake up MYKEY to login, transfer, contracts invoke, sign and other on-chain operations. This tooklit only support EOS chain by now, and will extend to other public chains with the roadmap of MYKEY for multi-chain.

Native dapps can use MYKEY Development Tool to use MYKEY to authorize, transfer, contract, sign. I

4. Application Op Key support(coming soon)

MYKEY support dapps develop their own native application. Dapps can generate one keypair locally in their own application. Then bind the generated public key to MYKEY account via inter-application calls.

In this model, Dapps can use MYKEY SDKs to sign and push transactions locally and unnecessary to wake up 3rd wallet. By authority leveled design, user can decide how much assets they want to put into sub-account for one specific dapp, the risk of the asset can be controlled easily.

Details coming soon!