Variable Existential Deposit

[olanod]

Variable Existential Deposit

[Note: I'm lazy and this issue post was drafted by an AI to introduce the concept for discussion.]

Concept

We propose a new approach to Polkadot's Existential Deposit (ED) system: a Variable Existential Deposit. This system aims to lower the entry barrier for new users while maintaining protection against state bloat.

The core idea is to replace the current fixed ED with a dynamic system where:

1. New accounts start with a very low (or zero) ED.
2. The required ED increases over time for inactive accounts.
3. Accounts that remain active (through transactions, fees paid, or staking) maintain a low ED requirement.

Example Implementation

Here's a simplified example of how this system might work:

graph TD
    A[New Account: 0 DOT] -->|1 week inactive| B[0.1 DOT]
    B -->|1 month inactive| C[0.5 DOT]
    C -->|6 months inactive| D[1 DOT]
    D -->|1 year inactive| E[2 DOT]
    A -->|Active: Fees > Threshold| F[Remains at 0 DOT]
    B -->|Active: Fees > Threshold| F
    C -->|Active: Fees > Threshold| F
    D -->|Active: Fees > Threshold| F
    E -->|Active: Fees > Threshold| F

In this example:

• New accounts start with 0 DOT ED.
• The ED increases gradually for inactive accounts.
• Accounts that meet an activity threshold (e.g., paying a certain amount in fees or maintaining a stake) keep their ED at 0.

Potential Implementation

1. Track account activity (e.g., sum of fees paid) over defined periods (e.g., weekly or per era).
2. Use Substrate's scheduler to periodically check account activity.
3. Adjust ED requirements based on activity levels.
4. Implement a maximum ED cap to protect long-term holders.
5. Special accounts (like those used by pallets) would not be affected, as they are already kept alive by increasing the providers reference count.

Benefits

1. Lower entry barrier for new users.
2. Encourages network participation and account maintenance.
3. Provides a self-cleaning mechanism for truly abandoned accounts.
4. Maintains protection against state bloat.
5. More flexible than the current fixed ED system.

Considerations

• Performance impact of tracking account activity over time
• Balancing the activity threshold to encourage participation without being overly burdensome
• Impact on long-term holders and stakers
• User experience and notifications for increasing ED
• Governance implications and parameter adjustments

Next Steps

This issue aims to introduce the concept for initial discussion. If well-received, a more detailed RFC will follow, including specific parameters, implementation details, and analysis of potential network impacts.

We welcome feedback, questions, and suggestions from the Polkadot fellowship community.

[burdges]

It's pretty bad UX to permit account creation but then burn the funds because the ED increased. Instead the transactions should be rejected befoire creating the new account, which requires ED stay constant.

We always need some rate limiting, so 0 DOTs never makes sense, unless there were some other deposit, cost, or limit elsewhere. A UBI parachain could take a government id proof instead of an ED for example, but the fixed ED system is the simplest more universally applicable thing.

---

We can definitely have parachains with lower or higher EDs. There are ocasional requests to add smart contracts to AssetHub, but this'll raise the ED on AssetHub by increasing the state size, and conversely AssetHub staying simpler keeps the ED lower.

At the extreme, some balance/NFT only chain could store accounts in a flat unordered binary tree, but then have an off-chain index table that looked up account position in the tree. This would be much cheaper than maintaining an ordering in the tree like usual, but not compatlbe with our locks for staking or governance, or many types of cross chain messaging.

You could even repalce this unordered flat binary tree by an MMR ordered by account access time, so then rarely touched accounts pay slightly higher transaction costs, but have less impact upon transaction costs, and so everyone's ED becomes much lower.

[shawntabrizi]

As I understand this proposal, you are really introducing two mechanics:

1. A way for someone to trigger an "ED check" on a user, potentially destroying the account.
2. A mechanism for adjusting the ED based on various time and space factors.

I think (2) is strictly dependent on (1), and unfortunately (1) is not that straight forward given the existing system in place.

The first consideration for (1) is the choice between an automatic ED check vs a manual ED check. Today, ED is checked everytime the balance of the user is updated, and the account is destroyed on the spot, automatically when the balance is reduced below the ED threshold. I do think it is possible, and potentially a good idea to make this a manual check instead, where any user can trigger an ED check on a vector of accounts, and trigger the destruction of those accounts. In this situation, there are some account which may fall below ED just temporarily or within a small window window of time, which may not need to be destroyed. Similarly, where there are not issues about scalability of the chain (for example a chain has less than 1M existing accounts), you may not need to start enforcing strict ED requirements on those users. Having the check be manually triggered allows for the trigger point to dynamically adjust over time, and also allows external factors to determine when accounts need to be cleaned up.

That being said, the user experience of this is not super great. Someone has an account balance one day, takes no actions, and no longer has an account balance. At least with the automatic ED system, there are no state changes on an account without the account taking some initial action.

Anyway, this is simply a tradeoff, and likely impacts few people overall.

What is also not considered for manual ED checks (and the proposal above) is how accounts can be prevented from being destroyed when they have reference counters on them. So even if the ED is going up and down, this is not the only factor at play. We should not allow accounts falling below some new ED threshold to live because they have established some reference counter in our system. This would obviously be circumventing the whole ED process. With reference counters, any kind of dynamic ED (specifically where ED amount goes up) does not seem possible.