Optimism Deployment to PSP- Next steps
Following the official launch of ParaSwap on the Optimism L2, it is now time to begin considering how to implement the points outlined for the first ParaSwap proposal that was passed in the Optimism governance forums. For those that missed the proposal, it can be summarised in roughly three points:
- 225,000 OP: Introduction of a dApp developer grant for Optimism
- 157, 500 OP: Establishment of OP-PSP, a protocol-owned liquidity pool
- 67, 500 OP: Encouragement of DexLib integrations through ParaSwap with special grants
Although these three steps are roughly easy to understand, there are many different ways to deploy these directives. This proposal aims to explore not only how to approach each of these three points, but also discuss the amount of PSP that should be matched for each one of these proposals. It will be important to refine each of these points to make them proposal ready!
Selecting a Source of liquidity
Of the OP requested, 157 500 OP are devoted to providing a permanent source of liquidity for a PSP-OP. This allows for a solution that is more sustainable in the long run, while also minimising the impact of this grant on the price action of $OP. However, what kind of liquidity pool will be the best long-term option for this OP-PSP pool?
Personally, the only requirement we should consider is to not go with a simple 50/50 asset pool. As we are dealing with two assets that are not correlated with one another, any form of decoupling on either side will result in a large amount of Impermanent Loss on the assets.
Due to this, the current proposed LP will be in Beethoven X, with its Balancer-style skewed pools. Of all the possible ratios, I believe a pool where 70 to 80% of the assets is OP is the best option for this grant. By adding more OP to the pool, we would:
- Minimise the risk of impermanent loss for the OP granted : This way, we are safely taking care of the OP provided on this first phase.
- OP might become a boosted asset in Beethoven X in the future, allowing for the earning of yield of these assets long-term were this to happen.
Another potential option is to deploy a Uni V3 pool, however, that would require creating a special strategy from scratch, and depending on flexibility of this strategy it might require more micromanagement. However, if anyone has an idea for this (or even other DEXes), feel free to bring it up!
PSP Vote Tl;dr: Match OP with PSP at a ratio that gives us a skewed pool.
Grant Selection Process
The main purpose of the grants provided are to allow growth of the Optimism ecosystem while also encouraging the use of ParaSwap to encourage dApp developers to best access all DeFi services. For that reason, it is important to determine that the grants are used correctly. Here’s a rough idea of potential categories that we could use:
-
Optimism deployment for existing dApps - Encouraging onboarding to the Optimism ecosystem - I don’t think there’s more to explain
- Novel applications of ParaSwap - New uses of ParaSwap (even on apps that are using ParaSwap for something else already), so instead of a porting it’s a new integration
- ParaSwap-Optimism synergistic apps - Uses that are directly related to improving the experience in Optimism of either the ParaSwap protocol or the DAO. Some examples could be an alternative frontend or a batch bridging transaction. These , in my opinion, should be incentivised the most.
However, how should we split the grants between each of these categories? What will we request of grantees to make sure the proposal is honest? Should we implement a system similar to the OP grant system?
DexLib
Thanks to the DexLib grants, developers will be encouraged to integrate new DEXes into ParaSwap , even if it is not their own DEX!
This part of the proposal is pretty straightforward, we reward people with a bounty for successful integrations. However, I wanted to also make sure that the higher quality submissions received more reward, and that there is a quality control to avoid sub-par submissions. For this reason, I’d suggest:
- 3-strike system: Sometimes, an integration does not go as expected. For that reason, we can allow people to try a couple of times to do a successful integration and receive feedback from the team. Anything more than that and we’d be awarding bounties to a job mostly done by others!
- Volume specific targets: The bigger the catch, the greater the rewards. Integrations that have a higher volume and TVL at the time of integration should receive appropriate rewards! Additionally, if the DEX receives a surge in volume after a ParaSwap integration, we should also reward that appropriately. Important point to discuss: What scale should we establish: What specific scales do we want for rewards? A logarithmic scale?
- PSP Matching: Finally, as promised in the previous proposal I think we should match the PSP to OP 1:1
Let’s discuss these ideas, be optimistic, and get them ready for a proposal!