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.systemeosio.tokeneosio.msigeosio.prodseosio.vpayeosio.bpayeosio.savingeosio.nameseosio.rameosio.ramfeeeosio.stake
System contracts
DAOBet works on the basis of such system contracts as
eosio.tokeneosio.bioseosio.systemincludes:producer_pay.cppdelegate_bandwidth.cppvoting.cppexchange_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
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:
1
if (activated_share <= 33) {
2
return 21;
3
} else if (activated_share > 33 && activated_share < 60) {
4
return 21 + (activated_share - 33) * 3;
5
} else {
6
return 102
7
}
Copied!
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:
1
// _gstate.schedule_size_step = 3
2
3
if (block_time.slot - _gstate.last_schedule_size_update.slot >= 2 * _gstate.schedule_update_interval) {
4
int target_amount = get_target_amount(activated_share);
5
if (target_amount > schedule_size) {
6
schedule_size = schedule_size + _gstate.schedule_size_step;
7
} else if (target_amount < schedule_size) {
8
schedule_size = schedule_size - _gstate.schedule_size_step;
9
}
10
_gstate.last_schedule_size_update = block_time;
11
}
Copied!
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:
1
if (activated_share <= 0.33) {
2
return 0.2;
3
} else if (activated_share >= 0.66) {
4
return 0.1;
5
}
6
return -10. / 33 * (activated_share - 0.33) + 0.2;
Copied!
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:
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
eosio::delegatebwfromaccount holding tokens to be stakedreceiveraccount to whose resources staked tokens are addedstake_net_quantitytokens staked for NET bandwidthstake_cpu_quantitytokens staked for CPU bandwidthstake_vote_quantitytokens staked for VOTEtransferif true, ownership of staked tokens is transfered toreceiver
eosio::undelegatebw
eosio::undelegatebwfromaccount whose tokens will be unstakedreceiveraccount to whose benefit tokens have been stakedunstake_net_quantitytokens to be unstaked from NET bandwidthunstake_cpu_quantitytokens to be unstaked from CPU bandwidthunstake_vote_quantitytokens staked for VOTE
daobet-cli
daobet-cli based on cleos и имеет различия в командах:
Now
delegatebw requires another argument stake_vote_quantityfromTEXT - The account delegating bandwidthreceiverTEXT - The account to delegate bandwidth fromstake_net_quantityTEXT - The amount of BET to delegate for network bandwidthstake_cpu_quantityTEXT - The amount of BET to delegate for CPU bandwidthstake_vote_quantityTEXT - The amount of BET to delegate for VOTE
example:
1
daobet-cli system delegatebw accountname1 accountname2 "1 BET" "1 BET" "1 BET"
Copied!
Now
undelegatebw requires another arguments stake_vote_quantityfromTEXT - The account undelegating bandwidthreceiverTEXT - The account to undelegate bandwidth fromunstake_net_quantityTEXT - The amount of EOS to undelegate for network bandwidthunstake_cpu_quantityTEXT - The amount of EOS to undelegate for CPU bandwidthstake_vote_quantityTEXT - The amount of BET to undelegate for VOTE
example:
1
daobet-cli system undelegatebw accountname1 accountname2 "1 BET" "1 BET" "1 BET"
Copied!
Now
system newaccount can take an additional argument--vote-stakeTEXT - The amount of BET delegated for VOTE bandwidth
Last modified 2yr ago