The DAObet blockchain is based on EOS. DAObet inherits the features of EOS, such as bandwidth, performance, and smart contract execution environments. We improved the finality by implementing the RANDPA algorithm, increasing the number of validators, and introducing other useful changes, while maintaining compatibility for decentralized applications.

compatibility

Smart-contracts

DAObet is fully compatible with EOS smart contracts. Thus, if you have your decentralized application based on EOS smart contracts, then you can easily deploy it to DAObet without any changes.

Node API interface

The DAObet-node fully implements the EOS-node interaction interface..

Libraries

DAObet is fully compatible with all libraries created for EOS.

System accounts

DAObet has the same system contracts as EOS:

• eosio.system

• eosio.token

• eosio.msig

• eosio.prods

• eosio.vpay

• eosio.bpay

• eosio.saving

• eosio.names

• eosio.ram

• eosio.ramfee

• eosio.stake

• eosio.rex

System contracts

DAObet works on the basis of such system contracts as

• eosio.token

• eosio.bios

• eosio.system includes:

  • producer_pay.cpp

  • delegate_bandwidth.cpp

  • voting.cpp

  • exchange_state.cpp

  • rex.cpp

  ​

Keosd

DAObet-node and DAObet-cli are fully compatible with keosd. DAObet comes with the DAObet-wallet. You can use keosd instead of DAObet-wallet

incompatibility

Finality

At the heart of DAObet is a new finality mechanism. Read more about RANDPA.

Governance

Another governance mechanism is deployed in the DAObet, which allows changing the number of validators from 21 to 102 and the emission rate from 20 to 10% depending on the Activated stake.

Validators number

In the DAObet, we have a flexible mechanism for determining the number of active validators depending on the activated stake. The number of validators is determined by the rule:

if (activated_share <= 33) {
  return 21;
} else if (activated_share > 33 && activated_share < 60) {
    return 21 + (activated_share - 33) * 3;
} else {
    return 102
}

Thus, with an activated stake of up to 33%, the number of validators = 21. After 33%, the number of validators increases by 3 with each percent. After 60%, the number of validators becomes 102.

When the number of active validators changes, the number of validators will change gradually according to the rule:

// _gstate.schedule_size_step = 3
​
if (block_time.slot - _gstate.last_schedule_size_update.slot >= 2 * _gstate.schedule_update_interval) {
  int target_amount = get_target_amount(activated_share);
  if (target_amount > schedule_size) {
    schedule_size = schedule_size + _gstate.schedule_size_step;
    } else if (target_amount < schedule_size) {
      schedule_size = schedule_size - _gstate.schedule_size_step;
    }
    _gstate.last_schedule_size_update = block_time;
  }

Every 24 hours, a new number of validators is calculated. If the new number of validators is greater than the current value, then it increases by 3. If the new number of validators is less than the current value, then it decreases by 3. Changes are possible only once every 24 hours. Thus, an increase or decrease in the number of validators occurs gradually.

Activated stake

An activated stake plays an important role in our governance system, and we changed the rule for calculating activated stake. In DAObet, the activated stake is the number of stakes that have been staked in the VOTE. An activated stake can either increase or decrease.

Emission

Emission in the DAObet network depends on the activated stake and is determined by the rule:

if (activated_share <= 0.33) {
   return 0.2;
} else if (activated_share >= 0.66) {
   return 0.1;
}
   return -10. / 33 * (activated_share - 0.33) + 0.2;

With an activated stake of <33%, the annual emission is 20%. With an activated stake of > 66%, the annual emission is 10%. In the interval between 33 and 60 activated stakes, the annual emission smoothly varies from 20% to 10%, depending on the activated stake.

VOTE

DAObet has revised the mechanism of staking and voting. Now the CPU and NET have no weight when voting for a validator and serve only to ensure bandwidth. An additional VOTE resource was introduced in DAObet especially for voting, which is staked on a par with CPU and NET and is used only for voting. This resulted in changes to the system contract and changed the signatures of such methods as:

• delegatebw read more here​

• undelegatebw read more here​

Sponsorship transaction

One of the features of DAObet is the sponsorship transaction. This transaction allows a third party to bear the costs of the transaction. In this way, decentralized applications can provide their users with completely free transactions. Read more about sponsorship tx.​

Minimal stake

DAObet has a minimal stake for active validators. In order to be an active validator, one must have their own stake (CPU + NET + VOTE) of at least 0.1% of the total supply of BET Tokens.

System token

System token DAObet is BET

• symbol: BET

• decimals: 4

• example: 1.0000 BET

eosio.system

In DAObet, the eosio.system contract methods that deal with resource staking have been changed. Now the eosio.delegatebw and eosio.undelegatebw methods accept another stake_vote_quantity parameter, which determines the number of BETs for stacking under VOTE

eosio::delegatebw

• from account holding tokens to be staked

• receiver account to whose resources staked tokens are added

• stake_net_quantity tokens staked for NET bandwidth

• stake_cpu_quantity tokens staked for CPU bandwidth

• stake_vote_quantity tokens staked for VOTE

• transfer if true, ownership of staked tokens is transfered to receiver

eosio::undelegatebw

• from account whose tokens will be unstaked

• receiver account to whose benefit tokens have been staked

• unstake_net_quantity tokens to be unstaked from NET bandwidth

• unstake_cpu_quantity tokens to be unstaked from CPU bandwidth

• unstake_vote_quantity tokens staked for VOTE

DAObet-cli

DAObet-cli based on cleos и имеет различия в командах:

​delegatebw​

Now delegatebw requires another argument stake_vote_quantity

• from TEXT - The account delegating bandwidth

• receiver TEXT - The account to delegate bandwidth from

• stake_net_quantity TEXT - The amount of BET to delegate for network bandwidth

• stake_cpu_quantity TEXT - The amount of BET to delegate for CPU bandwidth

• stake_vote_quantity TEXT - The amount of BET to delegate for VOTE

example:

daobet-cli system delegatebw accountname1 accountname2 "1 BET" "1 BET" "1 BET"

​undelegatebw​

Now undelegatebw requires another arguments stake_vote_quantity

• from TEXT - The account undelegating bandwidth

• receiver TEXT - The account to undelegate bandwidth from

• unstake_net_quantity TEXT - The amount of EOS to undelegate for network bandwidth

• unstake_cpu_quantity TEXT - The amount of EOS to undelegate for CPU bandwidth

• stake_vote_quantity TEXT - The amount of BET to undelegate for VOTE

example:

daobet-cli system undelegatebw accountname1 accountname2 "1 BET" "1 BET" "1 BET"

​system newaccount​

Now system newaccount can take an additional argument

• --vote-stake TEXT - The amount of BET delegated for VOTE bandwidth

​

​