PIP51: Update Community Token List to Increase Quote Competitiveness & Gas Efficiency

Governance Proposals
1

PIP51: Update Community Token List to Increase Quote Competitiveness & Gas Efficiency

Abstract

Currently, ParaSwap smart contracts accrue surplus revenue for every trade in which this event occurs, regardless of the token pair on which this trade happens. Because of this surplus event, the gas spending of the trade increases, which leads to lower trade efficiency and, thus, lower overall volume.

After analyzing the last 365 days of the amount of revenue generated by the thousands of tokens traded through ParaSwap, we have noticed that the top 461 tokens account for 97.94% of the total fees generated. However, even with the large majority of fees concentrated in a few tokens, ParaSwap checks and takes surplus from every single token, increasing gas consumption and making ParaSwap’s quotes less competitive than its competitors.

This proposal aims to amend the community token list into the tokens responsible for 97.94% of the revenue generated by the DAO and only to take surplus fees from these tokens. Additionally, we aim to simplify the ParaBoost volume metric, increasing the amount of overall trades that will be eligible.

We expect this new list to not only significantly affect volume thanks to the increased gas efficiency but also reduce the amount of $PSP emissions in gas refunds per trade compared to prior methods. Thanks to these efficiency improvements, we expect to increase ParaSwap’s competitiveness in the market.

Goals & review

The main objective of this proposal is to increase the gas competitiveness of ParaSwap contracts and thus bring more volume thanks to this increased efficiency. To do this, it is essential to remove any unnecessary gas spent whenever possible, such as the changes done in PIP 32

The justification for this change in whitelisting comes from an analysis of the fees generated in the last year. In this graph, we can see the distribution of the ~$1.45M of fees generated over the last year over each of the tokens that have been processed:

1118×402 37 KB

As we can see above, there is a ‘long tail’ distribution of fees happening, where of over ~21,400 tokens accruing fees by ParaSwap, the vast majority of them do not constitute a significant share of the total accrued and are very hard to convert to ETH without losing a big part of the amount in gas and slippage. Additionally, unusual tokens, such as rebase tokens, are not supported by our Fee Claimer but are still collected, which leads to reverts on swaps.

As these unusual tokens tend to be paired with more common ones, we also suggest a simpler system for counting Paraboost which will make many trades more eligible: destTokens will be checked for sell orders, and srcToken for buy ones.

In addition to the long tail, another trend we see is a few tokens driving the vast amount of fees generated by the protocol. To clarify, only 461 out of 21,467 (2.1%) accounted for 97.9% of fees generated. In addition, we decided to include a new token list for Base and zkEVM, which previously did not have community token lists. Due to the relatively recent deployments on these chains, we propose to add the major tokens from each chain.

Outside of these tokens, the additional gas intensity caused by the action of fee collection generates a higher opportunity cost from volume missed than any fees accrued from it.

Because of this, we wish to increase the efficiency of the protocol by enabling fee generation only when the benefit outweighs the gas cost.

Means

The following proposal is a technical upgrade similar to PIP-32, which successfully led to gas efficiency improvements and revenue growth.

We propose to implement a whitelist feature to the ParaSwap protocol contract consisting of the following tokens list and to add a security measure by capping the surplus at 1% max to ensure that users won’t suffer any significant loss due to exceptional pricing bugs, as well as excluding rebase tokens from this list, as in the past fee claiming of rebase-type tokens has lead to issues claiming it from the Fee Claimer contract.

Future tokens can be added through a governance proposal to ensure that tokens are added swiftly if needed.

Additionally, to ensure partners do not suffer a hit from this efficiency improvement, they will not have any changes compared to their prior experience.

Implementation Overview

  1. Implement a smart contract update to allow whitelisting
  2. For ParaBoost calculations, only check eligible tokens on the destTokens for sell orders and srcTokens for buy orders.
  3. Introduce the following tokens onto the community token lists
  4. Allow for the repository maintainers + governance proposal to amend the list as needed, as long as the token is not a rebase-type token nor a well-known scam
  5. Cap the surplus at 1% maximum

Voting options

  • YES, let’s upgrade

  • NO, let’s not upgrade

  • Abstain

7 Likes
2

Great initiatives!
This is indeed very important to remove these extra gas fees as well as protecting the users for exceptional slippage impacts on badly priced tokens.

Definitely for this proposal if the gas cost for tracked tokens doesn’t increase much due to this extra check.

2 Likes
3

One hundred percent in support of any proposal that is aimed at making Paraswap the number one aggregator in the market.

2 Likes
4

It’s complete nonsense.
I don’t even know how you can consider such a measure.
So if I understand correctly, from now on we’ll have to vote for tokens to be covered by the surplus?

Are you pretending that 3% of revenue is negligible for stakers and the DAO?

Do I need to remind you that the DAO earns its money from these revenues?
So we’re going to cut off sources of revenue based on what you say? What are the graphs, the metrics, the proof of your claims?

Are we going to have to white list the tokens that earn income for the DAO and the stakers?

So this is the only way you’ve found to reduce costs and make Paraswap competitive. Eliminate revenue ^^

I propose that the DAO pay for slippage. That way users will have positive slippage. I think that Paraswap will then have a monopoly on volume.
Completely against.

5

Compared to the gas cost of having to execute a transfer to the fee claimer vault, the gas computation of the check should be much lighter, allowing for stronger efficiency :star_struck:

No, we are saying that the gas improvements could offset this 3% , for which most is not even converted right now, as liquidity is too low for these tokens for mimic to swap into anything meaningful. Please read the proposal for more details, as well as see this onchain with the tokens held in the current mimic vault.

Please read the proposal to see the graph we attached, the amount of tokens selected as metrics, and the reasoning behind this.

Please engage in good faith with discussion, sarcastic/trolling behaviour will lead nowhere and is not the kind of behaviour the forum is for.

The assessment behind this porposal came from technical and smart contract analysis, if you wish to suggest an alternative method to increase volume and revenue for the protocol or a separate list, you can analyse our fee contracts to provide your own technical insights.

1 Like
6

1 chart to cut 3% of revenues. A little light?

It’s not for me to do the research to believe what you say. It’s up to you to justify such heresy.

I’ve got one. Improved the code rather than going for the simplest.

The idea behind it is disgusting.
Because we’re talking about tokens that are little known/little traded, and therefore not very liquid. This means that the volumes linked to these tokens are also negligible.

The idea behind this proposal is to create a white list of tokens that take the surplus. In future, this would mean voting on all the new tokens on this list.

If we look at the time it takes to vote on the addition of tokens for Paraboost, this will mean that in future the stakers and the DAO will never benefit from the surplus because we will have to identify/vote on and add the tokens to the contracts each time.
So why have a white list?
Create a black list now. List the tokens on it after the vote and it will all come back to the same thing.

I didn’t mention that either
 If Paraswap decides to become a not-for-profit organisation, we’ll have to put in a request to that effect. I’d be less surprised

7

Great job guys! Looking forward to see Paraswap N°1 :muscle:

1 Like
8

I support the essence of this proposal. This strategy to enhance quote competitiveness and gas efficiency by focusing on the most profitable tokens is a significant step forward. It aligns us with competitors who prioritize gas management.

However, I recommend automating the whitelist process. The web3 sector is rapidly evolving, and a manual DAO process for adding or removing tokens might be too slow and impractical to keep up with market changes.

You agreed to the burn of 200M PSP, and now you’re voicing concerns about the DAO’s financial health. Isn’t that a bit contradictory?

I believe it’s reasonable to accept the cut in revenue, which ultimately seems to be a loss, in order to be fairer to our users.

3 Likes
9

Hello,

Thank you for your proposal and the time you took for it.

I see two topics to discuss:

  • The whitelist for the fee claim
  • The 1% cap on surplus

Whitelist part

While I’m 100% in favor of gas saving, I don’t see the benefit of it in your proposal. Here’s a quick example of why:

Your proposal will basically something like this:

if(isShouldTakeFee(token)){
 takeFee();
}

It’s true that not running transfers for tokens not whitelisted will save around 20k gas. However, adding an if statement plus a check on a mapping for isShouldTakeFee will add ~2k gas based on my quick tests.
Here’s the contract for quick tests run on remix with a mainnet fork:

// SPDX-License-Identifier: AGPL-3.0-only
pragma solidity 0.8.23;

contract CheckGasCost{

    mapping(address token => bool takeFee) private isShouldTakeFee;

    uint256 public value;

    function addToWhitelisted(address a) external {
        isShouldTakeFee[a] = true;
    }

    function takeFeeWithWhitelist(address a) external{
        if(isShouldTakeFee[a]){
            value++;
            return;        
        }
        value++;
    }

    function defaultLogic(address a) external{
        value ++;
    }
}

Here are the results:

In conclusion, your proposal would reduce the gas cost for tokens that account for less than 3% of the fee revenues and thus are not the majority of the volume by ~20k gas. But it would increase the gas cost by ~2k for tokens that make up the majority of the volume and revenue.

For this reason, I can’t support this proposal. :confused:

1% cap of surplus

I’m confused about this part. You describe it as a security measure, but aren’t the fees taken from positive slippage? Therefore, wouldn’t the price impact/slippage tolerance accepted by the user address this issue?

All the DAO and staker revenue come from market volatility. By implementing this, we add another check in the code (thus more gas, which somewhat contradicts the goal of the proposal) and drastically reduce DAO and staker revenue.

In conclusion

I can’t support this proposal. I suggest investing time in rewriting the contract for more gas efficiency, possibly using Assembly (where @Bach could assist), upgrading contract to the latest pragma version that would eliminate heavy libraries/external logic like SafeMath, etc.
Finally, we could approach a gas-lite company for a gas audit, which could make a significant difference.

2 Likes
10

Thank you for the support, as well as understanding how efficiency and volume growth can help us offest the loss of these illiquid tokens!

Sadly, this manual process is the current status quo, which has made it very difficult to keep up with new tokens. The proposal allows the repo maintainers to also amend the list as needed, but if the DAO can think of other automatic selection criteria to make a token worth the inclusion that could help considerably as well. Perhaps we could see tokens which generate significant revenue for partners which are not part of the main whitelist?

1 Like
11

Thanks for your detailed feedback.

As I’m sure you may know, writing production smart contracts is more complex than the basic examples you shared. We have some of the best engineers in the space, and the volumes that were generated (mostly through third parties) speak for themselves
 We can’t share the code yet, but it’s highly more efficient than the actual one :slight_smile:

The V5 is fully open source, don’t hesitate to share any concrete code improvement if you can come up with advanced ideas (As Chab did before) :wink:

If you swap and lose 50% because ParaSwap took it, you’ll never come back and make sure everyone knows that ParaSwap is not the best place to trade. 1% fee is already way too high


We have some ideas for whitelist automation, we’ll revert back with another proposal when ready. Meanwhile, the whitelisting doesn’t have to stay manual as it is today, few automation tools with potential incentives can take over.

4 Likes
13

Makes sense, you have our support on this proposal!

2 Likes
14

Better gas efficiency, more volumes, more traders, more integrations, more fees.
I presume the team conducted thorough research, and the high-level rationale appears sound.
I bet they are working on something bigger and this is just a teaser. Either we assume proofs are sufficient or we keep debating for weeks. The opportunity cost looks too big, worst case scenario: back to status quo.

LFG I support this proposal :rocket:

2 Likes
15

Reading the discussion, it appears to me that the 3% in question generates a “theoretical revenue” for the DAO as it is split on more than 10,000 tokens which is the equivalent of less than 40$ per token on average + the 40$ in this case is a best case scenario as there are thousands of cases where it is less than 1$ of theoretical revenue. The implication is the following: it doesn’t make economic sense to do 10,000 transactions to sell these tokens to ETH, as the gas fees for the transactions themselves will cost much more than the 3% theoretical revenue in question.

In other words, this is the equivalent of receiving an airdrop of a token and the value of the airdrop is so low that it doesn’t make sense to stake it or sell it anyway.

For the smartcontract gas side, this could be part of a larger list of gas optimisations; as one follows the evolution of paraswap’s smartcontracts over the years, it can be noticed that there is tremendous work and emphasis that is put on gas costs. This is a central piece of paraswap’s competitiveness and ability to offer the best swap rates in various market conditions.

The proposal is pushing things in the right direction and looks reasonable. I support it as well.

4 Likes
16

So we have a coder explaining that we’re going to in crease the fees on the tokens on which it’s interesting to be competitive and everyone applauding iterations with no basis or justification?

Chab must have tested his code before his proposal was voted on. He constantly provides us with updates on his tests to prove that his predictions are correct.

But here we are accepting “possible” improvements, gas fees on shitcoins.
When will Paraswap start treating everyone the same?

Come back with some tests already.

17

In any case, the gas cost will increase for tokens that are not impacted by this proposal, and these tokens constitute the majority of the volume on ParaSwap.

Additionally, implementing the 1% security cap check, which is not currently in place, will also increase the gas cost for these tokens.

What is the estimated increase in gas cost per transaction for the real tokens?

This seems more like an issue related to the integration of the DEX library and the data/prices returned by the API, rather than the contract itself. :confused: How did you arrive at the 1% figure? Why not 5%?

I had already checked it before posting my message, sir :slightly_smiling_face:. However, I would have preferred an open-source GitHub repository for this part, rather than navigating through documentation and Etherscan to find the implementation addresses.

1 Like
19

Please do not attack DAO members personally.
In my opinion, your message should be deleted or corrected, as it in no way respects the values of the ParaSwap DAO.

3 Likes
20

I didn’t refer to anyone in particular. Burning = value destruction and burners are value destroyers. How is this an attack ?

ParaSwap deserves better
 Good luck to the builders, they really need it !

1 Like
21

Let’s keep the focus on the proposal please.

2 Likes
22

Still no response. So this proposal is just a nice story?