Your “dev” seem to know more about smart contracts than anyone in Paraswap, maybe you should team up and build a competitor. I’m sure you both have all the skills 
Paraswap’s dev have to prove their point like everyone else. Their words are not gospel to me.
If they can’t do that. Then this proposal is null and void.
All the measures in the proposal are just fine words with no actual demonstration for the time being.
We hear you and thank you for your opinion. The previous answer still applies and Xut analyses is not based on the new code which is not yet ready 
I can’t wait to see if the code works so that I can vote on your proposal. When will it be ready for us to make a choice?
The proposal is not only about gas as you can read earlier, it’s for user protection, fixing revert issues due to rebase tokens, simplifying the process for long tail tokens…
The vote should start soon
Interesting.
Go there. If you think you’ve answered the questions ^^
Hello,
I noticed that you are about to launch the vote, and I’d like to summarize the proposed ideas to fully comprehend them.
The plan is to establish a whitelist of tokens subject to surpluses. You believe this will reduce gas costs for tokens with diminishing revenue but still contributing to volume. However, Xut argues that this change may negatively impact tokens generating both volume and paraswap revenue.
So, are you prioritizing tokens with no revenue for the DAO and speculative volume? Additionally, creating a whitelist could hinder the potential revenue from new tokens that could significantly benefit the DAO. This is why I’m voting against it.
Are you imposing a revenue cap at 1%? Currently, there seems to be no justification for this, especially as the protocol continues to gain more users, volumes, and revenue. The argument about customers leaving doesn’t seem convincing to me. This is another reason I’m voting against it.
Moreover, your new code isn’t ready, as per your last message. I find it perplexing that assertions are being made based on assumptions. Do you expect us to accept these assertions without a concrete foundation? I don’t understand how you can propose changes without a fully developed code.
In my view, the core team has consistently performed well. You are typically responsible for ensuring the smooth operation of proposals by requesting service providers to justify their suggestions. However, this proposal seems to rely solely on ideas, and the associated risks make it unsuitable for my vote.
I am against it.
The cap is not for the revenue, is for the surplus. This is based on multiple cases we’ve seen publicly over time as explained earlier. We’re maximizing on growth and market share, not on revenue.
1 Like
Surplus = Revenue … But ok we can play with word.
Thanks everyone for the discussion, just wanted to share a couple thoughts myself on the latest posts
Prior proposals that required a lot of new code-focussed development did not require the improvements themselves to be upfront. This is because, like in any other organisation, it makes sense to first approve a project before working on concluding it. This was the case for PIP32 , PIP44 , PIP38 , PIP34 , the PSP 2.0 proposal… , etc. This flow is normal in any organisation, especially with something as man-hours intensive as this. First you request for approval to work on something, and then you work on finalising the product . Usually, if these proposals don’t uses DAO resources these upgrades can be pushed without a vote once the final proven product is out, but as this modifies the revenue currently owned by the DAO this is the reason we had to opt for this approach.
However, like most of these proposals, preliminary viability analyses have been made, and the gas improvements have already been accounted for. As illiquid and ineffective as these minority tokens are to convert, this proposal wouldn’t be pushed forward if there was confidence that there was something to gain from it.
Regarding the surplus cap, these cases are usually abstracted away from the DAO, but we can find many such instances already on the Discord where the core team had to deal with explaining the situation, and the only solution being a governance proposal. These situations are never nice to deal with, and having to explain to partners that users losing a large amount of a trade by design hinders our relations with these teams. Losing a potential partner because of a single high surplus incident can lead to missing hundreds of additional trades and growth worth a lot more than that single trade.
3 Likes
Really ? what about ? OP Grant Application - Reducing gas costs on Optimism and Arbitrum - Governance Proposals / Optimism Grants - ParaSwap DAO
Really ?
That’s not what lup said 2 messages above. The code is not ready. Here’s what it looks like today
The surplus pays the DAO, and the DAO is run by the stakers, who are also paid by the surplus. So I’m sorry to be concerned.
It’s all talk. Nothing proves it.
We heard you @stikers, you expressed your opinion very well a few times & you’ll be able to by using your vote when the proposal goes live on snapshot
It will be great if you can leave room to other community members to freely express their opinions too.
1 Like
Yeah, sorry about that. I’m having a hard time not opening it. I promise I’ll be quiet
Everyone is free to express their opinions no matter what direction they support, that shouldn’t mean stopping others from exercising the same right
I understand the general meaning of this proposal, which aims to optimize transaction gas costs; however, I agree with some of the previous remarks about protecting users from significant price slippage.
The suggested whitelisting part needs further refinement. Indeed, we need to find a flexible and quick process for modifying this list without going through countless requests and votes.
Regarding the 1% surplus cap, I find it very restrictive for the DAO’s future revenues. As the majority of our income is based on the surplus, capping it immediately affects us. I also understand the principle of wanting to protect the user or partner from excessive slippage, but as you yourself pointed out, these are very rare events, due to exceptional pricing bugs
So, this represents a permanent and costly measure for exceptional occurrences. I understand the intention, and it requires consideration, but the proposed solution does not seem to be the best.
In essence, I agree with addressing gas costs issues or even removing the myriad of tokens that are expensive to convert into income and represent only 2.1%, if your figures are accurate.
However, at the moment, the presented approach seems moderately convincing to me.
4 Likes
Hey everyone, thanks for all the discussion we’ve had.
This is just a heads up that I believe the proposal is ready to advance to the next stage, and will aim to push the vote for next Tuesday!
Proposal is live!
https://snapshot.org/#/paraswap-dao.eth/proposal/0x89a3709e25a80864239c0c353181cd4865ba62efb0fadea5b6ae9911c7b8b3ea
Hello, sorry for being late to the discussion, better late than never.
Positive slippage/surplus is high with highly volatile assets that generates lots of volume with significant slippage, especially tokens in the first hours/days of listing. This materializes into revenue for the DAO and stakers. With a whitelist they will ALL be excluded from the profit sharing program.
I have no doubt that ParaSwap’s developers are top tier and we are all extremely grateful of all that has been delivered in recent years, but adding conditions (whitelist + 1% surplus cap) in a smart contrat increases execution cost, that’s just a fact.
This will directly lead to higher prices, leading to lower volumes generated and once again lower revenue for the DAO and the stakers. This is the complete opposite of what we are aiming for.
I think, trying to fix a UI/UX partner issue by adding conditions to a smart contract is a terrible idea, therefore I’m against this proposal.
Thanks for your reply. We addressed those concerned before, but here are some TLDRs:
From the 1 year data we showed, that’s a small fraction of “theoretical” revenue that we never had.
The small overhead is negligible compared to the rest of the code which should make ParaSwap, not only better than its current version but more optimized than its competition.
The goal is the exact opposite actually.
The increase in volume, market share & reliability are the main goals of this proposal.
No you don’t understand what I’m saying here, by adding a whitelist you will de-facto exclude futur tokens that will generates huge volume on DAY ONE and that are not even out yet, and you won’t generate any revenue on these tokens. You will only be able to update the list post-listing once the volatility that generates positive slippage/surplus came down, that’s where the action is.