ARC-2: Delist Functionality for Specific Tokens in Generator

Proposals ARC (Astroport Request for Comments)
1

References

Summary

Add functionality in the Generator contract to prevent specific tokens from getting ASTRO emissions.

Abstract

Add the possibility to prevent specific tokens from receiving ASTRO emissions from an Astro Generator. The only tokens that cannot be prevented from receiving emissions would be ASTRO itself and Terra native assets.

Motivation

Some protocols may abuse the ASTRO emissions mechanism.

As a concrete example, in November 2021, the Curve community had an incident where a stablecoin protocol called Mochi tried to maximize their CRV token emissions in an unusual way. Mochi minted its own governance token and swapped large amounts to CVX (the governance token of the Convex protocol) which allowed them to boost their CRV emissions.

As a result, the Curve community decided to remove all CRV emissions directed to Mochi’s stablecoin. The main reason was that a large part of the Curve community believed that Mochi’s tactics (minting a brand new governance token and use it to get emission boosties) is questionable at best.

Specification

Proposed Code

There is no implementation made available just yet.

Test Cases

Test cases are not yet available as the smart contract implementation is not done.

Security Considerations

The main risk associated with this Generator contract update is making sure the currently staked LP tokens in the Generator will not get stuck.

Auditor Information and Report

Given there’s no implementation yet for this proposed Generator change, there are no audit reports.

Licensing

GNU General Public License v3.0

Governance Action

Since the Astroport protocol is not yet under direct ASTRO governance control, we request non-binding social-signal-boosting of support for the proposal. Because xASTRO/vxASTRO voting has not yet been activated, we request that social support be signaled by replying here.

Additionally, of course, we encourage further discussion and suggestions on the same topic.

Disclaimers/Conflicts of Interest

The author is a paid service provider of Delphi Labs Ltd. Additionally, the author has a development stake of ASTRO tokens.

7 Likes
2

I agree there should be a blacklist function, under the control of the Astral Assembly.

The reason why Mochi was blacklisted from rewards was because it was essentially a fraudulent scheme which could be bailed-out by CRV emissions; that might work for a little while but is ultimately unsustainable. As it acquired more and more governance power it could have been essentially a self-perpetuating Madoff-like thing that, when it crashed, would bring down the entire community.

It’s important to have blacklist functionality so that the community can police itself and prevent bad actors from gaining an unbreakable toehold on governance through fraudulent means.

To maintain credible neutrality, I would suggest that the community also endorse some principles describing when the blacklist powers would be used, and that these principles should focus the blacklisting capability on preventing fraud and coercion which pose an existential threat to the sustainability of Astroport.

5 Likes
3

Should this be an automated thing or a governance vote type of thing?
Also should there be a basic set of rules to go after to implement it or would it be more of a from case-to-case type of function?
Having to pass a vote before implementing this function in every case would take time and could possibly see a scenario were the damage is already done after the vote has passed. So if there needs to be a vote for each specific token then the best thing would be to also have a “paused token emissions until gov vote is finished” type of function, or something similar, being a part of this functionality?

4

This can’t really be automated. One example that code couldn’t handle was with Mochi.

I do agree the community should have a basic set of rules used to judge whether a token should not be allowed to get incentives. This proposal is deferred for now so I’d say we can come back to it once the Astral Assembly is up.

One strategy inspired by Curve is to have a guardian/emergency contract managed by several (known) community members that can prevent tokens from getting emissions (or re-enable emissions later on).

5

I think an alternative solution would be that before getting a pool fully blacklisted there should be a temporary 10 days pause for emissions.

This pause can be called twice every 30 days (so that it’s not abused) by a guardian/emergency contract who would listen to an off chain voting result to remove the emissions (something like snapshot) and if more than 51% decide to pause the emissions the emissions would be paused for 10 days. I suggest the off chain voting period be 2 days. (If possible a contract controlled by the Astro Assembly or the Astro Assembly can itself listen to this off chain proposal and would be able to pause the emissions for 10 days).

After the pause an ARC would be propsed which can be discussed upon for 2 days after which the post would be frozen for one day. Then an on chain voting will take place to vote on what’s present in the ARC which would last 7 days.

If the ARC passes the token/pool would be permanently blacklisted from getting emissions if it dosen’t pass it would continue getting emissions as per the gauge voting.

Accoring to my proposal it would take a minimum of 12 days to permanently blacklist emissions. And during this 12 day’s period the token/pool would only receive emissions for 2 days (during the off chain voting period).

6

From what I’ve seen in practice, when a pool gets blacklisted, there’s a serious reason for that. I’m not really convinced pausing incentives helps, I think there could be a snapshot vote to blacklist and then another vote to whitelist back if blacklisting was a mistake.

7

Yes blacklisting is a serious deal and that’s the reason I think having some period where the community get’s to properly vote on it is required. The 12 days pause is mainly just to get the consensus required to make a proper decision it’s not a stop gap measure or a warning to the token/pool.

Your idea of just having a snapshot to the blacklist is also fine in my opinion if it’s possible to whitelist that token again. I just don’t want think it’s correct to give this blacklisting power to community members because it’s not as decentralized as having a vote.

8

I am all for adding this functionality:

Emissions are used to better incentivize users and volume, not reward nefarious actors.

Rewards are tasty - they must be earned and deployed effectively. As ASTRO grows and encompasses more tokens and communities, the likelihood of this happening increases.

@lex_node brings up a good point:

Being able to approach “blacklisting,” in a neutral and consistent way is valuable. The community must be able to reach a consensus when deeming a pool dangerous or unfit for emissions.

9

Absolutely, we need a list before this ever (hopefully never) has to be used

10

It is possible to whitelist back. Personally I see blacklisting as something that should be done in an emergency, hence why I’m not sure about the 12 day delay

11

From my first understanding I thought being blacklisted once meant you would be permanently removed. I still think some sort of snapshot/transparent off chain voting should take place (maybe even only for 12 hours/1 day). As blacklisting a token could cause a lot of negative consequences to the protocol and having such high power in just a few hand’s is not good for decentralization in my opinion.

12

What’s the state of the art on Terra right now for snapshot voting?

13

I don’t think there is any Snapshot type voting protocol in Terra so if Astroport needed to implement this they would have to make that.

14

Know that this is kind of an old topic now but was there any solution found for a snapshot vote?
If not maybe we could ask community members if anyone is interested in trying to create something? Maybe even a flipside bounty or “exclusiv/elevated discord role” or something lol

15

Looking through the contracts and development on github a delist function is being implemented.

Other than that no one I know off is developing a Snapshot vote for Terra. I think snapshot voting is required in Terra in general. It might be a public good for Terra if Astroport gives a bounty to have a snapshot voting for Terra (just like how Astroport made LBP’s for Terra).

16

I might possible have an idea i could try and set up in the meantime.
But yeah trying to get a bounty for it as Incentive to get more people working on it would def benefit the community

1 Like