Proposal: Implementing Curve/Convex Wars to Bring Value to Astroport

1. Summary
Astroport incentivzes certain liquidity pools (LPs) by emitting $ASTRO tokens who provide liquidity to those LPs. Per Astroport’s documentation, Astroport governance will eventually allow xAstro stakers to vote on which LPs obtain the most $ASTRO emissions (see Calibration - Astroport).

My proposal is to add an additional layer on top that would allow anyone (namely, other protocols) to pay “bribes” to voters to vote for particular LPs. For example, Apollo might offer a $100k UST “bribe” to anyone who votes for the Apollo-UST LP. The $100k UST bribe would then be distributed amongst all of the people who voted for the Apollo-UST LP, in proportion to the # of xAstro tokens that they voted with. These bribes are effectively another form of yield paid to xAstro stakers.

Per Astroport’s documentation, the votes occur every two weeks (and each voting period determines the $ASTRO emissions for the next two weeks), meaning that xASTRO holders can expect to receive bribes every two weeks from the protocols that went to incentivize their own LPs.

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).

2. Case Study / Background
One of the DEX’s in the Fantom ecosystem, Beethoven ( announced that they’d be implementing their gauged voting + bribing system in late December (when their token was trading around $0.15) and fully implemented it in February. Since then, the token has increased to a high of $1.30. (DEX Screener). Notably, this increase is in spite of the ecosystem’s native $FTM token going down in value by about 50% from mid-January to present (DEX Screener).

One of the community members keeps a spreadsheet showing how the past voting rounds & bribes have played out.
(See Beetoven Bribes - Google Sheets). Here’s how the last round went (the “Vote 2” tab in the spreadsheet):

One protocol offered $6,350 in $USDC stablecoins for every 1% of the vote that went to their LP. They ended up capturing 4.66% of the vote, meaning that they paid out $34,735. Not bad.
Another protocol, Statera (which isn’t even native to Fantom), took a different approach: They’d been steadily acquiring $BEETS (the dex token, equivalent to $Astro), and offered 10,000 $Beets for every 1% of the vote they received. They wound up with 18.36% of the vote, which meant an overall payout of $168,192 worth of $BEETS.

Taking all the bribes into account, as well as looking at the # of fBeets (xAstro) holders that voted, the average payout was 2.6 cents per fBeets (see cell 21:L of the spreadsheet). fBeets was trading at ~92 cents back then, so the average ROI was 2.8% over a two-week period. If you extrapolate that out over a year, the APR would be 2.8*26 = 72.8% just from bribes alone. That’s on top of the APR you get from staking $fBeets as a governance holder.

On top of all that, the protocols that participated in the bribe wars saw their own tokens shoot up in price. If a protocol acquires a lot of votes, then their LP ends up having a higher APR (due to more $Beets emissions), which encourages people to buy that protocol’s token in order to farm those high APRs. And since stacking $Beets gives you more votes, which means more voting power (for protocols) and more bribes (for users), people continued to hold onto the $beets rather than dumping.

I think a similar system would play out really well here. There are a lot of new protocols popping up $Astro, many of which have limited liquidity. They would benefit from being able to issue “bribes” in order to incentivize people to deposit in their LPs, and the whole “bribe wars” narrative would also serve as a useful marketing tool.

And for $Astro holders, the bribe mechanic makes $Astro insanely valuable. Staking more $Astro means you get more votes, and therefore a larger share of all bribe payouts. On top of that, protocols will be trying to buy up $Astro directly so that they have more control over the votes.

3. Proposed Implementation
As discussed above, Astroport is already implementing the gauged voting system, so we just need to implement the bribing system. (Note: One small tweak to the gauged voting system would be to make it so votes are reset every two weeks, and xAstro stakers need to re-decide which pools to vote for. That helps with maintaining active involvement, which is important for the bribe wars to play out. Currently, the docs say that your votes will stay the same each period unless you manually change them, which incentivizes people to stop paying attention to their votes.)

Here’s how I’d propose implementing the bribing system:

Create a new page in the Astroport Assembly page called “Voter Incentives” (or some catchier name). The page would look similar to the “Pools” page in that it would list all of the available LPs. However, next to each LP would be a button called “Add Incentives” that anyone can click on. After clicking on the button, they get a pop-up that allows the user to select any number of tokens from their wallet to deposit. Those deposited tokens would then serve as a “bribe” on that LP.

Voters who vote for that LP receive all of the deposited bribes, paid out proportionately based on how much xAstro they committed. (For example, if the xAstro you voted with was 10% of the total # of xAstro used to vote for the Apollo-UST pool, you’d get 10% of all the bribes from that pool).

For the voters, the “Voter Incentives” page would also display all of the current bribes (in a column called “Current Incentives” (or some other catchy name). The bribes would show up next to each of the LPs (after the “Add Incentives” button). For example, if Apollo decided to bribe their pool, then the Apollo-UST LP might show a bribe of, say, 100,000 $APOLLO + 50,000 $Astro + 10,000 $UST.

*Bonus Addon #1:*  Let protocols offer a bribe that adjusts based on how many votes are cast for the protocol.  For example: "we'll pay out $5,000 for every 1% of the vote we get."  Protocols obviously love this because then they don't lose as much $ if it turns out that no one voted for them.  On the flip side, if they're already getting lots of votes, users will continue to be incentivized to vote for them because the pool of bribes keeps increasing, rather than there being a fixed pool that gets diluted as more and more people vote for it.  This has been the most popular type of bribe in the Beethoven bribe wars.  

I think this feature would be part of the “Add Incentives” popup. There’d be a tab (or “Advanced Options”) toggle that brings up an option to pay out bribes per % of votes acquired. The user would still need to deposit the total amount upfront, and the “Current Incentives” column would make clear that a total of, say, $50k UST is being offered, paid out as $5k UST per 1% vote.

Over time, as $UST continues to grow and the Terra ecosystem becomes more integrated with other chains, we can see protocols from other chains coming in to participate in the $ASTRO wars as well, simply because there aren’t many dex’s that give protocols this ability to attract liquidity.

4. Considerations
Potential gaming of the system: Since votes occur at a set time every two weeks, we might see a situation where people buy up $ASTRO right before a vote to get bribes / influence voting, and then dump right after. This isn’t ideal. One way to get around this would be to take a random snapshot 1-3 days ahead of the vote and use that snapshot to determine how many votes each user gets (and how many bribes they can receive).

**Bad actors**:  One potential giga-brain strategy would be for someone to accumulate a ton of $ASTRO, then create their own bullshit LP consisting solely of coins they minted for themselves (e.g. $DO and $KWON).  They'd then deposit their $DO and $KWON into the LP and, since they're the only one with liquidity in that pool, they'd get 100% of the $ASTRO emissions.  This would potentially allow them to continue increasing their share of $ASTRO allocations over time (because more and more of the future $ASTRO emissions would go to them), and ultimately allow the bad actor to gain control over the protocol.  **NOTE:  This can happen even without the bribing system, and the bribing system would actually help prevent this by incentivizing others to participate in active governance.**

One way to fix this would be to allow “antagonistic voting,” i.e., people can also use their xAstro to vote against a particular LP getting emissions. That way, if a bad actor pursues this strategy, then everyone else would vote against him, and he’ll wind up having bought a ton of $ASTRO for no benefit.

5. Community ask
The purpose of this proposal is to gauge community interest. It’d likely require a significant amount of dev work and audits to make sure it works properly, so it’s not worth bringing up to them unless the community is actually interested in this. If everyone is silent, the devs will (rightly) assume that no one really cares about whether or not we have this system in place, so it’s not worth doing. Accordingly, if you like this idea, please reply below.

Conversely, if you see problems with this idea (or my proposed implementation), or have suggestions for how to do it even better, please share your thoughts as well! The more brains we get involved, the better the protocol will be.


This is an excellent and well-thought out idea that helps optimise the value accrual for $ASTRO and reduces the tendency for $ASTRO to be farmed and sold. As more projects launch their tokens on Terra, there will likely be a competition for Astro emissions to bootstrap their liquidity on Terra’s most popular AMM.

I think that the suggestion of resetting the votes every two weeks is vital to the whole voting and bribing mechanism, as this would incentivize $ASTRO holders to participate frequently and actively in the ecosystem.

One further suggestion: $ASTRO holders that participate in the bribing can opt for token bribes received to be swapped for $ASTRO automatically if they don’t want to hold such tokens. This is helpful especially if the $ASTRO holders use their voting power across multiple LPs and receive a bunch of tokens that they do not want to hold. This will further increase the buy pressure on $ASTRO.

This mechanism is similar to the union function on llama airforce for Convex (Llama Airforce)


Great summary of the Governance Wars from BeethovenX’s aspect! I agree with you that having a Bribing platform on Astroport will be vital to facilitate the inevitable “Star Wars” that will be happening with the launch of voting gauges.

I feel that a way that we can also reduce the gaming of the voting is to allow only vxASTRO holders to receive bribes, rather than to allow both $xASTRO and vxASTRO holders to get it. $xASTRO holders can still vote as it will benefit them if the Liquidity Pools that they have a stake in receives more emission rewards. Given that acquiring vxASTRO requires locking up your $xASTRO for a certain duration, this will prevent users from buying $ASTRO to stake for $xASTRO just to participate in the voting and exit their positions immediately given that there are no limitations on $xASTRO.

Furthermore, only allowing vxASTRO holders to receive bribes can also further incentivize more users to lock up their $xASTRO, which is generally a positive maneuver for the price action of $ASTRO

However, a potential problem that I’ve read about here is that there is a chance that users may be incentivized to vote for increased emission rewards for liquidity pools that have low trading volume just because of the bribing rewards. This may be detrimental for Astroport because trading volume is essentially our revenue source. Incentivizing Liquidity into Pools that do not need it means that other higher volume pools may be neglected. The suggestion offered to this issue was to allow for voters to only receive fees from the pools that they voted. This means that if someone voted for a LP with low transaction volume, he or she can will earn a lot lesser as compared to someone who voted for a high volume pool. However, given that $xASTRO and vxASTRO are already coded to receive fees from all pools as long as there are trades happening, this may be an issue that is difficult to resolve.

Which is why I believe that your concept of “Antagonistic Voting” may be useful in this scenario! Based on this, we can even implement a 2 stage voting:

Stage 1 Voting:
to vote for which are the liquidity pools to qualify for the gauge voting. This can be based off a few criteria such as trading volume, quality of protocol and other important metrics which the Astral Assembly can decide on. During this stage, voters can even vote away pools with poor performance or pools formed under your “Bad Actors” scenario

Stage 2 Voting:
to vote for the amount of increased emissions for the liquidity pools.

1 Like

@FarmerTuHao is right in the sense that vote incentives should go to vxASTRO because in the long run, vxASTRO holders vote on how to distribute ASTRO emissions.

Separately, I don’t really agree with resetting votes every two weeks because it doesn’t actually encourage more (productive) governance. From the perspective of a vxASTRO holder, if incentives change, I will either way change my vote distribution. If they don’t, I simply want to keep my current distribution for the pools I already selected. Resetting my votes would just force me to recast them on the same exact pools I had before.

I think receiving fees only from the pools I voted for is an interesting idea. At the same time and for the sake of having vxASTRO out as soon as possible, Astroport could initially use a vanilla implementation for emissions voting where fees go to all vxASTRO holders. Subsequently, an Astroport community member can propose an upgrade to direct a specific portion of the fees to a vxASTRO holder that voted on specific pools.

Finally, vxASTRO is already a complex mechanism in its current form. Adding metrics such as the quality of a protocol (which I’m not even sure how to judge) may be detrimental.

1 Like

I really like the idea of limiting bribe rewards to vxASTRO holder — it’s simpler and cleaner than my snapshot idea for preventing people from gaming the system.

On the piece about people voting for low-volume pools, I think part of the appeal of bribe wars is that it’s a way to attract liquidity towards those pools so that they can generate more trading volume.


This is a great idea. 100% this should be implemented. The gauge vote / reward narrative is the strongest one going on in the industry today. If Astro - the 2nd largest DEX in existence - implements something like this, then the positive consequences will not just resonate with Astro (which they will), but they will spur collaboration and spread out to affect all participating protocols in the Terra community.

Doesn’t Astro also have the equivalent of LBPs like BeetX does? If so, that makes this even more of a no brainer. Tokens can launch on Astro in an LBP, then participate in the gauge vote and receive additional liquidity and incentives. Astro will be a launching pad for new protocols.

For a second I thought we were going to participate in the Curve wars :sweat_smile:

Bribing is becoming inevitable in multiple ecosystems - Votium, Votemak, or Bribe are all clear testimonies that bribing is here to stay.

Embracing bribing on Astroport and creating our own UI, integrated into the dApp seems to limit nefarious actors or others coming in and taking advantage of the community.

I will mirror @stefan and agree that this idea is interesting:

This feature is lacking in current bribing infrastructure - and would create a more informed, and diligent voting experience.

What sort of resources would you need for this build?

Mainly someone to write a proposal and settle on an architecture to implement and someone to build the smart contract infrastructure

Does writing the proposal require writing out code? I unfortunately don’t have any coding skills, but I could write out the general logic/structure of how the bribe system would work (based on my initial post + the helpful suggests proposed by others).

You don’t need to write code but do need to use the technical proposal template when you post it:

I took a shot at putting the proposal together:

It’s my first time, so if I bungled it up, please let me know and I’ll do what I need to do to fix it.