The Apollo team would like to enable a buy and sell tax on Apollo Vault Token/APOLLO pools, in order to enable our Volatility Farming for Liquid Staking Tokens.
The Proposal
Volatility Farming uses the volatility of the crypto market combined with the static (unless traded through) nature of DEX LPs to create arbitrage opportunities, driving trading volumes and earning fees. You can learn more about Apollo’s plans for Volatility Farming here: Supercharging LSD Yields on Cosmos - Part II, Becoming the Captain of Sustainable Yield
Apollo have already successfully launched our initial Tax pools and this proposal is to create pools with a buy and sell tax for the following pools:
(stTIA/TIA)VT/APOLLO
(wstETH/wETH)VT/APOLLO
(wstETH/NTRN)VT/APOLLO
STRD/APOLLO
The buy and sell tax are both set to 3 percent.
The Apollo team have already made the minor changes necessary for this addition to Astroport, and would just need governance approval to whitelist the codeid.
Risks
The risks for this new pool will be limited as the updated code for this new pool type has very minor changes and will be reviewed by the Astroport team ahead of launching. These are the same changes used to launch our initial APOLLO pools.
I think this is a bad idea and adds complexity to contracts using the pools and relying on received token amounts and calculations.
These kind of fees and taxes also feel very predatory to “capturing” users, leading to extraction of value from real users, and disincentivizing real usage. Feels for me like a LUNC community move to be completely honest.
What is the use case Apollo wants to use?
Which XYK pool are you talking about, just listing a new pool type that can be used, or migrating existing pools?
It would just allow the option for new pools, no project would be forced to do it. The use case for Apollo is to create a deflationary Apollo token from launch. The would be no extra complexity added to current pools.
Our idea is to pass a small amount of value from traders to token holders and the taxes will be clear. This is not a novel idea in crypto and is used by quite a number of new utility projects launching on ETH.
I agree with what Phillip said about unnecessary added complexity.
I also wonder if it would just be better for projects that wish to do something like this, especially with their own token, to just setup their own POL. They can then redirect the fees that are continuously earned through that position. This way the project’s team still benefits from increased trading activity, and also obtains that desired influx of spending power that can be considered income or redirected for any purpose (extra staking revenue, burned, etc.). It also then wouldn’t take away from the community’s ownership of the pool with added extra fees that would be extracted from all traders using the pool.
I can’t recall if Apollo has a community pool to utilize for this or if there are other reasons that the above wouldn’t work for them or other projects. Feel free to add on!
tdlr;
More fees = more complexity, lower trading activity, less earned
More liquidity (POL) = less slippage, more trading activity, more earned
My understanding is that Apollo’s goal here is to break away from the VC funded, low float, high FDV, down only token launch. To enable Apollo and other project to do open fair launches where the supply is immediately in the hands of the community and the funding and upside comes from the actual demand for the project’s token through the buy/sell trading tax.
I think it’s an elegant way to turn speculation into long term funding and revenue to holders (for example by burning a part of the tax), and to move the bulk of the profits from VCs to the community.
The change seems minimal, and Astroport’s strength in an ecosystem of cosmos sdk DEX is in flexibility: having access to an array of pool types whereas appchains are more rigid. I think it’s a win win and I’d vote in favor.
First I am unsure about the “unnecessary added complexity”, who is it more complex for? Neither projects or users would be forced into anything.
Apollo will most likely be providing POL, however this is completely different. I think Spaydh has said it very well below, but this is about changing the funding paradigm.
Currently there are two main ways for crypto projects on Cosmos to fund themselves:
Take money from VCs, who will receive tokens in return, which they will sell on the open market.
Sell tokens to users either prelaunch or post launch.
Both of these approaches use token holders as exit liquidity to fund the projects and is one of the reasons that many Cosmos tokens have struggled to perform well in tough market conditions.
Instead if there is a transparent tax on buying and selling, projects can not only fund themselves without, but can also add benefits to long term holders including:
Burning some of the token supply with each trade
Building up POL
Rewarding holders with yield.
Buyback $ASTRO
While yes more fees will result in lower trading activity, based on a large amount of evidence from tax usage on Ethereum, we can empirically say that more is earned with taxes. Projects like Unibot have added nearly $2.5m to their POL from taxes and this is just one project.
The whole point is just to provide more some more options to projects launching on Astroport and foster more innovation.
As long as this is just an optional feature for new pools then I see no glaring issues. Would this feature come with a maximum tax cap to prevent possible exploitation? The tax should also be made explicitly clear in the UI so there is no confusion.
Yes there will be a tax cap. This wasn’t something that was originally included, but it has been mentioned and will be added before this becomes and ARC. And completely agree it needs to be explicit in the UI.
Thanks Bruce! To be clear, I am not against this prop and just wanted to make sure some things were considered and accounted for.
I am not a developer, so I recognize that perhaps I may not have the full picture in regards to complexity. This may not big as big of an issue as I think, but I will explain my line of thinking on it at least:
If devs wished to integrate all XYK pools into something bigger built on top, now a select amount of pools from the total pool list would require different logic to include. Would they decide to exclude them for this reason? The first thing that came to mind about this was in regards to auto-compounders. An additional tax would decrease efficiency and would variably affect the time period in which compounding should happen, depending on the tax amount set by each protocol’s LP. I assume it would also affect how the “Zap” function would work. This is why when I saw Phillip’s response I thought it might have confirmed my thoughts.
On the user side, would this tax be charged when adding/removing liquidity or just for swaps? I agree with the importance of how this is displayed for users on the UI (as well as the cap) that Jager_Master mentioned as well.
More may be earned for the protocols but I was referring to amount earned for LPers here. I think POL doesn’t detract from volume and both protocol and users benefit, but I get that is seen as a different additional approach and requires upfront funding.
tldr;
Why wouldn’t taxes fit better tacked onto transactions via that specific project’s app activity rather than just swapping their token on a DEX? What if the token were listed elsewhere without the tax?
Adding a brand new XYK pool type in the factory does increase complexity. It might even lead users to mistakenly create a pool with buy/sell taxes instead of a vanilla XYK one and then they’d have to pass a governance proposal just to deregister the deployed pool and recreate it.
The cleanest way imo is to have individual governance proposals that upgrade normal XYK pools to XYK with buy/sell taxes.
Besides this change in the governance flow, I think the proposal looks great
This post has been updated to ARC-116 Part II, to reflect that additional Tax pools that Apollo would like to create in order to enable our Volatility Farming. These are:
(stTIA/TIA)VT/APOLLO
(wstETH/wETH)VT/APOLLO
(wstETH/NTRN)VT/APOLLO
STRD/APOLLO
We have also linked to our article on Volatility Farming for more info.
