Adding a Blacklist for Random Inflation

This post details a proposal to introduce a blacklist for the Random Inflation monetary policy lever. To recap, the Random Inflation mechanism allows Trustees to allocate ECO tokens to a random subset of addresses. Every ECO address is eligible to be selected through a verifiably random selection process and is able to be selected multiple times. In the initial implementation, the probability of being selected for each claim is directly proportional to the voting power from ECO tokens in an address. Read more about Random Inflation here.

The main drawback of this architecture is that addresses that hold a large number of ECO tokens and thus voting power have a higher chance of winning Random Inflation. This means that the Protocol Treasury, Eco Association addresses and the Eco App addresses that hold tokens earmarked for user distribution would have a high chance of winning random inflation, which we don’t believe is appropriate. This also applies to contracts that hold a lot of ECO tokens, such as the univ2 pool.

To make the distribution fairer, we propose introducing a blacklist mechanism to exclude certain addresses from Random Inflation. The blacklist will initially make the following addresses ineligible for Random Inflation:

  • 0x8c02d4cc62f79aceb652321a9f8988c0f6e71e68 (Community Treasury)
  • 0x98830c37aa6abdae028bea5c587852c569092d71 (Association)
  • 0xa201d3c815ac9d4d8830fb3de2b490b5b0069aca (Eco Inc.)
  • 0x99f98ea4a883db4692fa317070f4ad2dc94b05ce (Association)
  • 0x09bc52b9eb7387ede639fc10ce5fa01cbcbf2b17 (uni v2 pool address)

Addresses can be added to or removed from the blacklist through governance. This mechanism will ensure that through governance the Eco community can dictate which addresses should not be eligible for random inflation winnings.


No questions here, these addresses should be blacklisted from random Inflation. We might have to blacklist some other addresses in the future, for example possible bridge pools, etc.


This makes sense, though I wonder why the current system is based on quantity Eco as a whole. Would it not be better if there was a minimum ownership, and any wallet with at least that amount, excluding the ones on the blacklist, would be eligible? Then, through governance, we can adjust that minimum amount?

This could lead to some people creating multiple small accounts and spreading ECO holdings to maximize their chances of winning.

But if tied to EcoID, would that not be prevented?

I depends, if Discord account is enough to create ECO ID, basically anyone can mint unlimited amount of IDs.

I have observed projects throughout the years that entirely ignored many participants, including their own community, in order to benefit from inflation and other factors by utilizing the entire supply they possessed—a supply that was supposed to be provided to the community as part of their mission.

It’s wonderful to see this being suggested at the outset of the protocol, primarily by the team as a self-initiated choice. This proposal has my wholehearted support, and I’m pleased with it because its proponents are the first to act in the interests of their ecosystem and community.


Very much appreciate this proposal. You have my full support.

I support the proposal despite the apparent usefulness in additional possible rewards for delegates due to the following ECO token inflation mechanism [Monetary Policy Levers - Eco Protocol]: Delegating voting power derived from ECO gives the chance to win random inflation to the delegate selected by an address. Please be aware of this when delegating ECO. Because ECOx is not eligible to win random inflation, delegating ECOx does not have this same effect.

When I first read about this mechanism, I envisioned it as an opportunity for a random user of the eco protocol to get more eco into their wallet as a result of this mechanism. If that’s what it ends up looking like, I’ll be glad.
At the moment, as far as I understand it also takes into account the balance of eco (the more, the better the chances), I would remove even this.