Skip to content

A. Existential Deposit

Bette edited this page Jul 19, 2021 · 2 revisions

Existential deposit -- ED, a margin used to retain account data, the total amount of an account must be either 0 (inactive) or not less than ED(active). ED can be configured to limit the number of dust accounts on the blockchain and reduce storage, but expensive ED will also limit the use of the network by users.

ED configuration

The ED of native tokens (ACA/KAR) is configured in the runtime. The EDs of non-native tokens(e.g. DOT/KSM, AUSD/KUSD, BTC, ETH) cannot be exposed on the blockchain as constants, so SDK should maintain an EDs record. For the amount of ED, it is recommended to configure an amount equivalent to about 1 USD as the ED of the token. The adjustment of ED should always be decreased, not increased(which will cause some problems). The Ed of LP tokens is special, it is always equal to the ED of token_0 that is the first currency_id composited to the trading pair.

ED will cause some transactions to fail

At present, the implementation of transfer and deposit in pallet_balances and orml_tokens will check the ED of the receiver account, if the total amount of the receiver is still lower than the ED after the transfer/deposit, the transfer/deposit will fail, which may block other processes that calls these functions.

How to avoid failed transactions caused by ED

Accounts on the platform are roughly divided into two categories:

  1. Vault accounts (including module accounts, some special blackhole accounts)
  2. Normal accounts

For vault accounts, some extrinsics may cause the transfer/deposit to vault accounts fail. And some transfer/deposit are executed in the on_initialize/on_finalized stage, such as the accumulation for the interest of Loans and the rewards of DEX saving. If it fails, it won't block processes, but it will affect the business. It can be avoided by transferring to the ED of the related token at the beginning of opening the business. Specifically:

  • The ED for the native token (ACA/KAR) has been configured to the vault accounts in the genesis. If there are missing or newly added vault accounts, plz manually transfer ED to these accounts.
  • Non-native tokens(especially AUSD/KUSD), after enabling loans (there is no AUSD/KUSD in the system before enabling), should issued some AUSD/KUSD as soon as possible and transfer the ED to related vault accounts(e.g. the module account of cdp-treasury and the vault account of incentives dex).

For normal accounts, the failure is generally caused by some calls sended by themselves, for example swap token, claim rewards... The front-end should do some prompts or restrictions according to the ED of related tokens. Except for the transfer business, other businesses should be weakened the concept of ED, tell users that is the dust limit of the business.