Dappaccount_demo_rn NPM

Dappaccount Subscriber Model

This is a simple example of a subscriber contract which is using liquidApps services to achieve virtual account functionalities. The code sample contains two actions describing how dapps can authorize any action with virtual user's permission, i.e an action can be pushed with an account's permission without the need of actual EOS accounts.

The hpp file has included some dependencies for virtual account service from liquidapps. dapps need to clone the service files into their include folder and declare the include path accordingly.

How to include and use liquidapps library files can be found here.

Contract explained

In the .hpp file, dapp needs to add the #define VACCOUNTS_SUBSCRIBER definition to specify that the contract will act as a subscriber model where the HOST is dappaccount contract. Also add #define HOST "dappaccoun.t"_n definition in the .hpp file. Every action which has the authorization of virtual users, must take its parameters as a payload structure, as defined in this sample code.

  struct hello_action
  {
    name vaccount;
    asset balance;
    uint64_t dummyid;

    EOSLIB_SERIALIZE(hello_action, (vaccount)(balance)(dummyid))
  };

where name Vaccount must be added in the structure where the action has the virtual account's permission.

Action testdappact

The first line of this action defines how we need to authorize the action with virtual user's permission. It is done by simply passing the virtual account name in the require_vaccount() method. To use this method, dapps must include the liquidapps library files with a correct path as stated above.

Action testtwofact

This example action defines how to define an action of higher security level with two factor authentication - first factor is verifying user's email / contact with access code within smart contract (through an inline action call) and then with user's signature. If dapp doesn't want to use verification of email / phone while calling action, it can follow testdappact action only.

Note : The user's keys, through which signature is generated and later verified in action like stated above, are always added by verifying email / contact at the time of user registration on dappaccount for every user. So, this depends on dapps and the security level of the action , that whether the access code verification is needed at the time of action call or not.

All the informations about level id and other parameters of this inline action call, can be found on the docs If this verification method is followed, dapps need to request for access code using dappaccount library, given in the docs under section 3.2.e.

Steps needed before dapp can start using dappaccount

Deploy contract and give eosio.code permission to the account
Select and Stake DAPP to use DSP package for Vaccount service. Details Can be found here

Dapps must stake to VRAM and VACCOUNT services to use this sbuscriber model. Please refer to this liquidapps doc for a better understanding about available DSP packages.

Note : Please refer to the Section 3.3 of docs before selecting any DSP.

Run xvinit as state here

< if using VACCOUNTS_SUBSCRIBER>

export HOST_ACCOUNT_NAME=dappaccoun.t
cleos -u $DSP_ENDPOINT push action $DAPP_CONTRACT_ACCOUNT xvinit "[\"$HOST_ACCOUNT_NAME\"]" -p $DAPP_CONTRACT_ACCOUNT

DSP_ENDPOINT - it is specific to the DSP dapp has selected and staked to. dappaccoun.t is staked to blockstartac provider

Whitelist Contract on dappaccount contract It cannot be done with DAPP's permission now. It will need dappaccount's authorization. Please contact dappaccount team for the same. The whitelisting includes defining a quota which is done by dappaccount for now. Later it will be a automated process which can be initiated by dapp itself. Please find the information about Quota below. Contact through Telegram
Once the contract is whitelisted, DAPP needs to whitelist its action with the specific security level. Information about security level and action whitelisting , can be found on the docs. Specifically , under Section 2.3

Dapps need to call action adddappact of dappaccoun.t contract

cleos -u $EOS_ENDPOINT push action $HOST_ACCOUNT_NAME adddappact '{"dappaccount":<DAPP_CONTRACT_ACCOUNT>, "levelid": <1 OR 2>, "actionlist": [action1, action2]}' -p $DAPP_CONTRACT_ACCOUNT

This action registers an array of action of the DAPP contract under a particular security level. If action1 needs less security, it can be marked as level 1 and high security action can be marked as level 2. Details on level id and action whitelisting can be found under Section 2.2 and 2.3 of the docs

After these steps , DAPP will be ready to register its users on dappaccount and then use their signatures to authorize action. How to register users on dappaccount and then user their signature to authorize dapp's action can be found here under Section 3.2

QUOTA - Quota is a limit set by dappaccount initially, and later can be increased by a dapp following certain steps. Those will be defined soon. Quota is a number which describes the number of transaction that can be performed in a day by a particular dapp. And here the transaction means action with virtual account's (dappaccount for user) permission (like described in this sample contract). The quota is reset in every 24 hours automatically. The registration or login / recovery does not come under any quota. That is unlimited.

Dappaccount token contract -

This repo also contains a sample of dappaccount token contract which is responsible for all the balance handling, stake unstake functionalities. Dappaccount has two separate contracts, One is HOST contract i.e for maintaing the virtual account informations which are created by dapps, And other is the token contract which handles all the transfer functionlities. The token contract also acts as a subscriber model to the dappaccount HOST contract. The sample code contains few example actions to show how the things are managed.

Action transfervacc

This action basically handles the transfer between two virtual accounts registered on dappaccount HOST contract. the transfer simply modifies the accounts table within the token contract.

Action transferacc

This action acts as a withdraw action where dappaccount user can send token to actual EOS account. This withdraw functionality has two methods based on the withdrawal amount. Below a certain limit (set by dappaccount authority), this action is used for amount withdrawl. And if the quantity is more then used needs to do a two factor authentication before actually sending token to EOS account. For this 2nd type, the below action is used.

Action withdraw

This action is used for large amount withdraw from dappaccount contract. It also performs two factor auth before transferring token to EOS account. It is done ina similar way as described in the sample subscriber contract for Dapps.