ARC-7: Implement Bribed Voting Mechanism for vxASTRO Holders

References

Summary

Allow protocols/users to “bribe” vxASTRO holders to vote for specific LPs as part of the biweekly ASTRO emissions calibration. vxASTRO holders receive these “bribes” for the pools that they voted on.

Abstract

Create a new interface in the Astroport app for “bribers” to deposit tokens as “bribes” for specific LPs, which are paid out to vxASTRO holders who vote for those LPs to receive Astro emissions during the biweekly ASTRO emissions calibration (where Astral Assembly votes to decide which pools get the $ASTRO incentives). vxASTRO holders who vote for a particular LP receive all of the “bribes” that were placed on that LP, in proportion to the # of votes they put in for that LP.

Motivation

Astroport incentivzes certain LPs by emitting $ASTRO tokens to the people who provide liquidity to those LPs. Per Astroport’s documentation, Astroport governance will allow xASTRO and vxASTRO holders to vote on which LPs obtain the most $ASTRO emissions ( see Calibration - Astroport).

These votes carry substantial value. The LPs with the most votes will receive the most $ASTRO incentives, meaning that they’ll have higher APRs. The tokens associated with those LPs will generally increase in value, and liquidity for those tokens will increase as well.

As a result, other protocols may want to “bribe” voters to vote on the LPs that use the protocol’s token. We’ve seen this happen with other protocols, such as Curve/Convex and Beets.fi. These “bribes” result in significant value for ASTRO holders, because locking ASTRO as vxASTRO would now give you a share of all those bribes, in addition to the protocol fees you’d otherwise get.

Other dex’s that have implemented this feature have seen their dex tokens explode in value. And for dex’s that don’t implement this “bribe” feature, inevitably another protocol comes along and does it (e.g. what Convex did to Curve), which results in the other protocol capturing a lot of that value (e.g. people fighting over Convex tokens instead of Curve). This is described in more detail in this post.

More broadly, Terra is quickly becoming the natural onramp for retail investors, due to apps like Kado and Alice allowing for cheap, direct onboarding of Fiat → UST. I anticipate this will lead to a boom in defi on the Terra blockchain. Implementing a bribe protocol helps enable a defi boom by allowing protocols to incentivize liquidity for their tokens (via bribes). The whole “bribe wars” dynamic also creates great marketing for the different protocols, for Astroport, and for Terra overall.

Specification

  1. Create a new page in the Astroport app called “Voting Incentives” where users can deposit and view “bribes” for each of the Astroport LPs.

  2. For users who want to deposit bribes, they would just need to press the “Deposit Incentive” button next to the respective LP. Bribes can take the form of any token in the user’s wallet that has been verified by Astroport (e.g., UST, aUST, Luna, Apollo, MINE, ANC, etc.). The bribe is then locked via smart contract.

  3. Subject to technical feasibility, the bribe can also be set up so that the size of the bribe would depend on the amount of votes that the LP receives (e.g., “We’ll pay $1,000 UST for every 1% of the vote this LP gets, up to $50,000.”) Users submitting this “per % vote” type of bribe would still need to deposit the max amount of tokens (using the above example, $50,000 UST), but could reclaim unpaid bribes after the vote (using the above example, $25,000 if the LP only received 25% of votes).

  4. Anyone can access the “Voting Incentives” page to view the bribes in play for the upcoming calibration vote. Bribes are locked 24 hours before each vote (meaning no new bribes may be submitted).

  5. The calibration voting process is modified to include one additional step: xASTRO and vxASTRO stakers can also use their votes to vote against an LP.

This modification is necessary to combat an existing flaw in the Astroport governance system:
Without this modification, a bad actor could launch a “vampire attack” by creating an LP with coins that only they control (e.g., two brand new tokens minted specifically for this strategy), vote/bribe to have $ASTRO emissions directed to their LP, and then farm the LP to collect 100% of those emissions (because only the bad actor would have the coins necessary to farm the LP). That LP would provide 0 value to the protocol due to lack of trading fees, but direct substantial $ASTRO emissions to the attacker. Antagonistic voting allows xASTRO and vxASTRO holers to vote down such behavior in order to protect the protocol. xASTRO and vxASTRO holders would be incentivized to vote against these vampire LPs because revenue paid to stakers depends on Astroport generating trading fees, which depends in part on incentivizing the LPs that are the most heavily transacted (in order to attract more liquidity, and therefore lower-slippage trades for traders). Again, this “vampire attack” strategy is a vulnerability with Astroport’s current voting implementation, not a flaw introduced with this proposal. However, the “antagonistic voting” feature would help safeguard the protocol.

  1. After calibration voting is completed, vxASTRO stakers (not xASTRO stakers) will receive bribes for the LPs they voted on, paid out in proportion to their share of the votes they placed for each LP. In other words, if a vxASTRO holder submitted 50% of the votes for a particular LP, then that holder gets 50% of the bribes for that LP. These bribe rewards can be collected through the same interface used to collect LP rewards.

Important Note: While both xASTRO and vxASTRO holders are able to vote, bribes are paid out only to vxASTRO holders. This is to prevent gaming the system, and to reward long-term holders. Without this limitation, bad actors could simply buy up ASTRO right before a vote, stake it for xASTRO, vote to obtain bribes, then unstake and sell the ASTRO right after calibration votes. vxASTRO holders must lock their tokens, thus preventing this behavior.

However, xASTRO holders can still participate in voting and antagonistic voting, and they are financially incentivized to vote for LPs that would enhance protocol revenue (b/c that results in stakers being paid more), and to vote against LPs that would harm the protocol (like the vampire attack I discussed above). xASTRO holders can also lock their xASTRO for vxASTRO to participate in the bribes.

Proposed Code

I unfortunately lack the coding skills necessary to propose code here, so would request an allocation of funds from the treasury to fund development of this interface. This would be a good investment for the protocol because it will drive significant value to the ASTRO token.

Test Cases

TBD

Security Considerations

This is a complicated interface and subject to smart contract risk. In particular, the smart contracts that hold and pay out the voter incentive “bribes” would potentially be holding and transferring significant amounts of money, and a security exploit could lead to a loss of deposited bribes.

Auditor Information and Report

TBD

Licensing

TBD

5 Likes

Wow this is an extremely detailed write up with very strong justifications for the implementation of a Bribing Interface on Astroport! I am in full support of this.

Just 1 point which I would like to ask about. I understand that from Astroport’s documentation, the gauge voting will likely take place every 2 weeks. With regards to this point:

  1. Can voting against a Liquidity Pool only happen once every 2 weeks?

  2. If I were to delegate a portion of my votes to vote out a Liquidity Pool, does that mean I will have lesser votes for the Liquidity Pools which I want to vote for?

Thank You!

In response to #1: Yes. The calibration phase currently tallies all the votes and assigns $ASTRO emissions based on the # of votes each LP received (as I understand it). My modification would just mean that the calibration phase would also look at votes AGAINST each LP, and net those out against the votes in support of the LP. The $ASTRO emissions would then get allocated accordingly.

In response to #2: That’s right. So there’s a slight opportunity cost to voting down a pool, which means stakers would only do it when they feel there is a strong need to do so. I considered giving out some “free” antagonistic votes (in proportion to a voter’s total # of votes), but I think that could lead to voters just trashing on each other’s LPs without good cause. Free antagonistic votes would also undercut the value of bribes, because a negative vote for someone else’s LP is almost as good as a positive vote for your LP (since the calibration phase looks at the proportion of votes each LP received to determine emissions.)

On top of that, xASTRO stakers don’t receive bribes - they just get their share of revenue protocol. So they’d still have an incentive to vote down vampiric LPs, without the opportunity cost of losing out on bribes.

1 Like

This is a very interesting and well detailed proposal!

A quick note on the attack you mentioned: the Assembly or a delegate can be allowed to blacklist specific tokens from getting ASTRO emissions. It’s just a matter of making a proposal to upgrade the current Astroport code.

As for the current proposal you wrote: you described the UI but more importantly, we need a detailed description of how the smart contracts work. Is it like Votium with off-chain snapshots? Is it different?

You mentioned you don’t have the coding skills to build this but teaming up with a community member that can help sketch how the smart contracts could work would be very useful.

2 Likes

Thanks for the helpful insights.

Any community members with sufficient knowledge about smart contracts to help flesh out the proposal?

Glad to see this posted in a more structured format.

As discussed earlier - this idea has merit, has been validated elsewhere, and would be valuable for the Astroport community to own as part of the existing UI.

I respect your candor around your ability to create smart contracts - please let us know if we can help in the search for a qualified developer.

Thank you! I’m open to any suggestions re: a good developer who can suggest a good way to implement the smart contracts. (I assume writing out the actual code would be a very substantial undertaking, but from what I understand, it’d be sufficient to sketch out the logic at a high level.)

Thank you for the extremely detailed reply!

The current proposal is phrased such the antagonistic voting will happen concurrently with the incentivized voting.

Do you think it might be a good idea to separate them to remove the opportunity cost factor?

Here’s my idea: Instead of the above happening bi-weekly, we can have a 3 week cycle instead. Antagonistic Voting can happen on the 2nd week, 3-7 days prior to Incentivized Voting. Once that has passed, the increased $ASTRO emissions for the pools voted down can immediately be cut and that will kick start the Incentivized Voting on the 3rd week. Doing this can potentially remove the opportunity cost of voting down the pool as these will be 2 separate voting events. Users can then not worry about having lesser voting power for Incentivized Voting and Antagonistic Voting can even gain focus from more users.

The con to this concept is more voting events to take note of, which may seem troublesome.

What do you think!

Great idéa! having bribes shown and voting, would be a pretty cool addition to an already successful dex, and would definitely be something that could benefit long term Astro holders

1 Like