DAOBet and EOS

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

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

Some parts of the eosio.system have changed! Read more below

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

Resources

An account on an DAOBet has three resources which it must maintain: RAM, CPU, and Network. RAM is a persistent resource (a user purchases it and controls it completely until they clean it out and sell it back to the blockchain), while CPU and Network are transient (an account may use it, and then it will regenerate as it is constantly rolling over).

RAM

Acronym for Random Access Memory. For speedy data lookup, a lot of data on DAOBet is stored within RAM. It is the most scarce system resource, which is why it must be purchased rather than staked for.

NET

Network, one of a user's resources, signifies the throughput capacity of the DAOBet. When you delegate tokens for Network, you are securing your right to utilize a pro-rata amount of the blockchain’s capacity.

CPU

CPU, one of a user's resources, signifies the computing power of the DAOBet. When you delegate tokens for СЗГ, you are securing your right to utilize a pro-rata amount of the blockchain’s computing power.

In DAOBet CPU and NET are not taken into consideration while voting, in comparison with EOS.

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 и имеет различия в командах:

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"

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"

Now system newaccount can take an additional argument

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