BUILDING ON @virtuals_io - Part 2: The Vampire Attack Strategy
1. Background
After your token is bonded via the @virtuals_io, 42.5k $VIRTUAL and 125M tokens are paired together and deployed into an LP position:
On Base, it is a Uni V2 LP with 0.3% fee
On Solana, it is a @MeteoraAG Dynamic Pool with 1% fee
Every transaction that goes through this pool will be taxed 1%, paid in your project token.
If a user buys 100 tokens, they get 99, and 1 is taxed.
If a user sells 100 tokens, they sell 99, and 1 is taxed.
After the tax reaches 100k tokens, it is dumped directly into the pool, $VIRTUAL is taken out and sent to another wallet.
In the example below, 100k $TRUST was dumped to the pool, and 207 $VIRTUAL was sent to wallet 0x7e26173192d72fd6d75a759f888d61c2cdbb64b1
Tax is bad for business, both in real life and in the Virtual world:
It doubles the trading fees - now instead of paying 0.3%/1% + slippage, users have to pay 1.3%/2% + slippage
It creates constant selling pressure on the market
The Vampire Attack Strategy targets these pools and minimizes the tax effect in the long term.
2. The Principle
Currently, most people use an aggregator to perform swaps, for example: @KyberNetwork on @base or @JupiterExchange on @solana. The aggregator finds the best route to save users fees + slippage.
The strategy is simple: make the aggregator believe your custom pool would benefit users, so it will route more volume via your pool and less via Virtual's default pool.
3. On BASE.
BASE is a hard battlefield because the tax is actually a hidden fee, and aggregators don't take that 1% into account when routing. So you will need to compete with the ultra-low fee of Uni V2 LP: 0.3%.
There are two ways to deal with this:
1. Instead of 1% fees, deploy a 0.3% fee on Uniswap V3 - This is suitable for projects with limited LP funding
Reason: Since the fees are the same, the aggregator will route more volume to your pool.
Result: More volume through your pool means less volume through Uni V2, resulting in less tax for users and less constant selling pressure on your token
2. Pair your token with all ETH, USDC and $VIRTUAL on Uniswap V3 with 1% fees - This is suitable for projects with deep LP funding
Reason: Since you're not competing on fees, you're competing on slippage. With a network of deep LPs, you force the aggregator to use your pool for the best route, even with higher fees.
4. On Solana.
Solana is much easier for implementing this Vampire Attack Strategy because VIRTUAL pools their token versus SOL and AI Agent token in @MeteoraAG Dynamic Pool with 1% fee.
To implement the strategy here, you simply need to deploy your LP with <1% trading fees.
Here's the $TRUST case as an example:
1. First, I have the Raydium TRUST/SOL pool with 0.25% fee
2. Second, I deployed a @MeteoraAG DLMM with 0.6% fee between $TRUST and $VIRTUAL
Now, you can see 0.6% + 0.25% = 0.85% < 1%:
Users swapping SOL to TRUST? Most will route via Raydium 0.25%
Users swapping VIRTUAL to TRUST? Most will route through my DLMM 0.6%
Users swapping SOL to VIRTUAL? A portion of their SOL will buy TRUST on Raydium, then sell TRUST on Meteora for VIRTUAL
Additionally, because the combined trading fees of the two pools are still <1%, arbitrage bots will take advantage of this to balance the price >>> boost your token trading volume >>> generate more fee rewards.
5. Conclusion.
@virtuals_io is a good platform to launch your token, but their tax system is not good for long-term economics. While there is no way we can eliminate it completely at the moment, with the Vampire Attack Strategy, you can minimize its negative effects. In the $TRUST case, we managed to reduce the tax from 1% to an average of 0.35%.
This article was published through a Knowledge Grant from @wai_combinator.
All grant proceeds will go 100% to the $DATDAO wallet.
Last updated