PIP-55- Reward Mechanism Automation proposal

Governance Proposals
1

PIP-55- Reward Mechanism Automation proposal

Abstract

WakeUp Labs aims to collaborate with ParaSwap to optimize and automate the reward distribution processes, reducing manual work, minimizing human error, and supporting decentralization while ensuring compliance.

This proposal originates from discussions we held across the forum (Streamlining PSP Incentives: Automating Processes?), during various conferences, and in connection with a recently approved proposal: PIP-53: Streamlining of the Staked PSP Incentive System, which simplified the staked PSP incentive system.

Now is the ideal time to automate these processes.

The objective is to automate the reward distribution for both the Reward and the Gas Refund Program. WakeUp Labs will develop scripts to gather data, calculate token allocations, and post proposals on Snapshot. Once approved, it will then be executed automatically using third-party smart contracts and oracles.

This proposal also aims to streamline the Gas Refund mechanism, noting the following:

The Gas Refund program distribution will remain active on both Optimism and Ethereum. However, the refund calculation will be based solely on mainnet activity.

This is because, although users claim the gas refund on the network they stake $PSP, in the last 6 epochs, more than 95% of the total gas refunded came from Ethereum mainnet transactions, which only accounted for 22% of the valid transactions.

The remaining 78% of valid gas refund transactions happened on the rest of the chains where the program is currently live (BSC, Polygon, Optimism, and Fantom) and didn’t generate significant refunds for users, an average of $0.06 refunds per address, only adding operational complexity to the tracking and computation of the program.

Chain PSP Refunded USD Refunded Avg USD received per address Number of Transactions
Ethereum 4,042,016 $67,357 $59 16,354
Rest of the chains 201,212 $3,151 $0.06 55,182

[Figures for epochs 19 to 24]

The Gas Refund program calculations will be maintained as outlined in PIP-53. This will adhere to the new staking score formula and apply exclusively to trades executed via the Augustus V6.2 and ParaSwap Delta contract sets.

The entire solution will be open-source and communicated publicly through the forum to enhance transparency and trust within the ParaSwap community.

About WakeUp

WakeUp Labs is a software development company specializing in helping DAOs and startups build complex digital products. We have collaborated with major clients, including Arbitrum, Optimism, Coinbase, Num Finance, and Mokens League. To date, we have successfully launched over 40 projects across Latin America, the U.S., and Europe.

Goals and Review

Based on the discussion through our talks, shared information, and identified needs with Laita Labs, the following criteria must be met for the project to be considered successful:

  • Deliver a set of solutions that, without the direct involvement of Laita Labs (the team currently responsible) , fully automates reward calculation, distribution, and transfer for both the Reward and Gas Refund Programs.

  • The service will be managed, hosted, and operated by WakeUp Labs, enhancing ParaSwap’s decentralization as a protocol.

  • A brief product and technical feasibility phase will be conducted with the team to validate the solution’s effectiveness and minimize unnecessary back-and-forth with ParaSwap and DAO teams once development begins.

  • The project will be open-source, with clear documentation provided on GitHub and in the open-source repository.

  • As this is a DAO initiative, significant milestones and progress updates will be shared on the ParaSwap forum, similar to WakeUp Labs’ communication approach with other DAOs like Arbitrum.

  • Based on discussions, the target deadline is to have the automated distribution tested in parallel with the manual process by the end of December, with the first live automated distribution set for the end of January 2025.

    • The Technical Kick-Off should have taken place at least 35 business days before the Distribution Mechanism for January.

Means

Description
Time ~35 business days
Price USD 25,400
Fee on future transactions for these programs 0.75%
Monthly max cap on future transactions fee $1,500

Warranty

  • WakeUp will continue receiving a 0.75% fee per epoch, capped at a maximum of $1,500 monthly. In return, we will take responsibility for maintaining the service.

Payment Method and Revenue Model

Payments will be made in cryptocurrency. Since the quote was valued in USD, even if the payment is made in $ETH or $PSP, the amount to transfer will be calculated on the payment date to ensure it is equivalent to the USD value.

The payment structure is as follows:

  • 50% at the kickoff of the project, paid in $ETH.
  • 50% upon final delivery, paid in $PSP.

The second payment will be made once both teams are satisfied with the work performed, using this proposal as a reference.

WakeUp is committed to delivering work that meets ParaSwap’s expectations and will make an extra effort to address any details that may not have been fully captured in this proposal.

Furthermore, WakeUp will charge:

  • A 0.75% fee on the total amount of ETH paid for these programs will be charged, with a maximum cap of $1,500 USD.
  • $500 USD will be allocated to cover hosting servers, virtual machines, and an operator for any necessary manual work. If the service goes down, WakeUp Labs will be responsible for restoring it.
  • The remaining fee will be allocated to development hours at a rate of $75 USD/hr. These hours can be optionally used at the end of the month; if utilized, a developer will be assigned specific tasks to be developed in the following month.
    Otherwise, the funds will simply remain as profit for WakeUp.
  • If the work required exceeds the amount covered by the fee and the implementation is still desired, the ParaSwap DAO will be responsible for covering the balance, subject to successful governance approval.

Implementation Overview
The project deployment will be carried out in 4 milestones and will have a duration of 35 business days.

Milestone 1: Architecture Definition, and Technical Specifications

Timeline: 5 Business Days

  • Define the internal architecture for implementing the solution.

  • Validate the system flow with both the Laita Labs team and WakeUp Labs’ technical team.

  • Develop a Proof of Concept (PoC), conduct testing, and validate with ParaSwap using third-party protocols such as UMA and oSnap.

  • Design the database, if required.

  • Establish the technical integration details for smart contracts, if necessary.

  • Simplify the Gas Refund program so users can claim on the network where they stake $PSP, but the refund amount is calculated solely based on Ethereum Mainnet.

Milestone 2: Build Scripts to Gather Data and run them.

Timeline: 15 Business Days

  • Check ParaSwap APIs to temporarily obtain the correct amount of tokens to assign to rewards.

  • Calculate rewards using on-chain information based on the definitions in PIP-53 and the previously agreed Gas refunds; these should match the values returned by ParaSwap’s APIs.

  • After running the scripts, determine the ParaBoost Score for each address by Epoch, along with the total reward amounts that need to be allocated to each Escrow.

Milestone 3: Configure Snapshot, submit proposals, and set up everything to avoid manual signatures

Timeline: 5 Business Days

  • Using the information gathered in Milestone 2, we will automatically submit a proposal to Snapshot displaying the calculations for assigning the corresponding rewards. And the on-chain transaction if needed.

  • DAO participants will be able to vote for or against the proposal if they wish to approve the allocation of these rewards.

  • Next, we will configure oSnap by UMA so that, once the proposal is approved by the DAO, the process continues automatically without requiring specific signatures from Multisig members.

  • Finally, the funds will be transferred to Escrow contracts, allowing users to claim their rewards seamlessly.

Milestone 4: Documentation, testing, deployment to production, and release.

Timeline: 10 Business Days

  • Conduct comprehensive testing internally and with users to ensure the solution remains stable.

  • Provide a detailed developer guide on GitHub.

  • Deploy the solution to production.

  • Announce the formal closure of the project through social media and the ParaSwap forum.

Testing & QA

Extensive testing will be conducted to ensure that:

  • API information and on-chain gathered data produce consistent results.

  • The user experience aligns with ParaSwap’s objectives.

  • Transactions are executed directly and accurately, without intermediaries.

  • Technical documentation is clear and accessible, maximizing value for developers and ensuring transparency.

Potential Unknowns and Timeline Impacts

  • Lack of a clear API or accessible information needed to perform reward calculations.

  • Greater-than-expected involvement from the ParaSwap team needed, such as defining the flow, approving plugins, and establishing agreements with other projects, especially if team availability is limited, which could lead to delays.

  • Changes in protocols to be integrated, or restrictions encountered during their implementation.

  • Changes in regulations, third-party policies, or software updates that may impact interactions with user funds.

  • It may happen that some parts of the Uma/oSnap/Snapshot workflow are not fully automated and require manual intervention to ensure the entire workflow functions correctly. In such cases, a member of the WakeUp team will resolve it manually.

  • Issues that arise post-testing and QA that fall outside the responsibility of WakeUp Labs.

Clarifications / Assumptions

  • The milestones don’t need to be sequential; in fact, overlapping phases is feasible, which could reduce the overall development time.

  • No UI will be provided

  • This mechanism must work for both the ETH mainnet and OP.

  • Server costs (AWS or Vercel) and other related services are the responsibility of WakeUp Labs.

  • As WakeUp will continue to receive a monthly fee in every epoch, we will take responsibility for maintaining the service.

  • WakeUp Labs will not be responsible for driving long-term adoption of the project. (ParaSwap).

  • Hosting and production deployment of Web2 services developed by WakeUp Labs will be on WakeUp Labs servers (preferably AWS).

  • Any item not explicitly mentioned in this budget is considered outside the scope of this proposal.

Team

  • 1 Senior Full Stack Developer - Full Time.
  • 1 Technical Lead / PM - Part Time.
  • 1 QA Engineer - Part Time.

All team members are highly qualified to execute this implementation and deliver a robust platform.

6 Likes
4

Thank you for this proposal. It is something we need.
But In the case of a hack or any error leading to a loss of value (small or big), who will be responsible for reimbursing the losses?

1 Like
5

Thanks for the proposal, it is something very necessary in ParaSwap!

Will the gas refund calculation still be manual for Optimism? Although it is not significant, the gas refund is also in effect in Optimism and needs to be calculated and distributed to users, will you take care of this or will it continue to be done by the GovCo as it is now?

2 Likes
6

That’s an excellent question, Julio.

The idea here is not to change the mechanism, the contract, or how end users receive their rewards.

Once the funds are transferred to the existing Escrow Contracts, these contracts will handle the distribution by generating the appropriate Merkle Tree and calculating the amounts for each user.

Our role will be to automate this process while ensuring everything is thoroughly tested before moving it to production.

That said, there doesn’t seem to be any additional risk.

If any risks do arise, WakeUp will not be held responsible for any incidents.

In fact, the idea is quite the opposite—to reduce operational risk. The only action that should occur on-chain is a transfer.

Nonetheless, we will work very closely with the Laita Labs team to prevent any unforeseen issues and ensure full alignment with them before moving to the production phase.

1 Like
7

Hey @SEEDGov!

It’s great to hear it’s seen as necessary for ParaSwap!

To clarify, the gas refund will continue to be distributed on both Mainnet and Optimism based on the amount staked on each chain, just as it is now.
However, refunds will only apply to Mainnet transactions, as they represent over 95% of the total refunds issued in the last six epochs.

The proposal aims to fully automate the distribution process for Mainnet refunds, eliminating the need for manual intervention by GovCo or the Laita Team.

Regarding Optimism, since gas refunds will no longer be issued for OP transactions under this proposal, manual calculations for Optimism would no longer be necessary.

2 Likes
8

Hello,

Thank you for this proposal and the efforts put into its preparation.

If, in the future, the DAO wishes to reintroduce other chains, extend this program to blockchains that ParaSwap does not currently support, or adjust certain reward parameters, what would be the technical and operational implications?

Would these adjustments entail additional costs, or are they included in the support ?

2 Likes
9

As the team operationally managing the distribution process, Laita Labs wants to strongly signal its support for PIP-55.

The current manual reward calculation and distribution process is time-consuming and prone to errors. Automating this mechanism will significantly enhance efficiency, reduce operational overhead, and improve reliability. Additionally, were oSnap to be configured this would allow the entire DAO to verify the process in a transparent manner.

We’re excited about the potential improvements this proposal brings and look forward to its successful implementation.

3 Likes
10

Cay, thanks for your question.

The goal is to always maintain a buffer that allows for small adjustments without the need to request additional funds from the DAO. This is why we charge a monthly fee, from which:

We anticipate this fee will be sufficient to assign a senior developer to manage these adjustments.

3 Likes
11

Thanks you for your response! We have a few more questions.

We have three questions on this:

  • Currently, a GovCo controlled multisig is responsible for approving and making transfers to users once the gas refund distribution calculations - currently done manually - have been made. If this proposal is approved, how will this be done? Will the funds remain as they are now in the custody of the GovCo, which will continue to execute the transactions with the multisig it controls after the DAO has approved the distribution, or will the funds need to be previously transferred by the GovCo to another wallet controlled by WakeUp Labs, which will execute the final transfer to the users? Can you describe in detail what the proposed new flow would look like if the proposed distribution of funds is approved? I.e. how would the allocation of funds, distribution and transfer of funds to end users work? Who would be involved in this process?
  • According to the current governance framework, it is necessary to have 100k PSP voting power in order to be able to submit a proposal to Snapshot. From which wallet will proposals be automatically submitted to Snapshot? Are you considering that this wallet must have at least 100k PSP of voting power? Or will another wallet from another person/entity/delegate with sufficient VP be in charge of submitting each proposal? If so, which wallet would be in charge of that?
  • If at any point the DAO decides to end the relationship with WakeUp Labs, how would the process of transitioning to a new service provider be handled? We consider it necessary that an eventual transition can be smooth and permissionless.

How would this process work? How would WakeUp Labs prove that the amount covered has been exceeded? We would like to see a cap, so that an unlimited or substantial additional budget is not required, and the DAO is not put in the awkward position of having to decide whether to pay it or lose the committed development and the budget paid up to that point.

12

Every DAO needs to cut down on manual work and make everything run faster and more smoothly. It also helps keep reward and gas refund processes decentralized and transparent. I’m all for it and would vote yes :slight_smile:

3 Likes
13

Let me try to clarify item by item:

The first one:

In this case, we envision that by successfully integrating Snapshot, UMA/oSnap, and the SAFE Multisig, proposals related to the reward mechanism submitted to Snapshot and approved by the DAO will include on-chain transaction execution information. This integration will enable direct execution of transfer transactions, allowing the multisig to move funds without requiring coordination from the GovCo.

It’s possible that the initial setup will require coordination from the GovCo, but this shouldn’t be necessary afterward. I’m not fully aware of all the responsibilities of the GovCo, but ideally, they shouldn’t be burdened with new tasks related to this particular topic.

The flow would look something like this, based on what oSnap describes on its page:

  1. Submit transactions to Snapshot - Let your community vote to implement exact transaction data.
  2. Transactions are validated by UMA - UMA validates that the transaction was approved in Snapshot and writes it on-chain.
  3. Transaction executes in Safe - The transaction is automatically executed via the oSnap module.

You can read more about it here: oSnap | Secured by UMA.

That said, as explained in the proposal, the idea is…

…before starting any productive development.

1 Like
14

The second one:

We weren’t aware of the necessary voting power, however.

WakeUp Labs will receive 50% of the project payment upon final delivery in $PSP.

This should be sufficient to cover that requirement, and since our intention is to contribute to ParaSwap DAO in the long term, we can ensure holding that amount of PSP with the goal of being able to submit proposals to Snapshot.

Regarding the wallets, we can hold the required amount of PSP in WakeUp Labs’ multisig and delegate the necessary voting power to the Governance Wallet (the one with the ENS) or to the smart contract in the case of full automation.

1 Like
15

Third question:

As a DAO, the ideal approach would be to go through another DAO process with an open vote on the new provider or a new mechanism that eliminates dependency on WakeUp Labs.

That said, it’s understandable if a faster process is desired. If SEEDGov or @Laita identifies another possible solution, we are open to discussing and considering it.

1 Like
16

Regarding the last question:

To address this, we would handle it like any client relationship that consumes hours of work from our engineers.

We usually use a simple Excel table to track tasks and hours transparently, with the following structure:

ID TASK Hours to allocate Hours finally allocated
n Description 15 X

Tasks are then marked as completed, along with the actual hours they required.

Ideally, this back-and-forth would be managed directly with Laita Labs, allowing us to track time efficiently and avoid the delays that are often inevitable within a DAO.

Anyway, this table would be shared with the DAO through the forum to ensure all members are informed about progress and any adjustments.

Regarding extra tasks outside the defined scope, these will be quoted separately. This ensures that tasks unrelated to the current scope are clearly identified and not included in this budget, even considering the monthly fee.

With this approach, we aim to maintain transparency, respect budget constraints, and avoid putting the DAO in the uncomfortable position of deciding between additional payments or losing progress.

1 Like
17

@0xGonzacolo Thank you for your detailed responses! We confirm that we will support this proposal.

1 Like
18

I will support this proposal.

1 Like
19

Bring it to Snapshot—I believe we must proceed with PIP-55. The reward mechanism automation promotes efficiency, minimizes errors, and enhances overall trust in ParaSwap’s incentive system, so it’s a ‘yes’ from me!

I share some of the concerns raised by @SEEDGov, though most were addressed. As a safeguard, any unforeseen additional payments should be well-documented and brought to the DAO for approval.

If this situation arises repeatedly, we could propose a 6-12 month budget for unforeseen expenses, with a set cap. If that cap is reached, the DAO would need to vote again. Although this process might feel lengthy, it encourages honesty by requiring the team to justify expenses to the community. In the long run, if this proves overly burdensome or costly, we can explore other solutions.

Kudos @0xGonzacolo thanks for taking on the challenge !

2 Likes
20

Given the positive reception of the proposal by the DAO, both on the forum and as demonstrated during today’s Community Call hosted by @SEEDGov (Community Call Invitation Post), and with all questions addressed—both here and during the AMA—we believe the necessary time for discussion has passed, including the idea phase.

With that in mind, we’re ready to proceed with the voting process on Snapshot.
This will take place tomorrow evening.

Thank you to everyone who participated and contributed to this process!

2 Likes
21

At the request of the proposer @0xGonzacolo, we have submitted the proposal to Snapshot with our delegation address.

The voting is live: https://snapshot.box/#/s:paraswap-dao.eth/proposal/0x18e2ef2f53440f764f9bd2f99e9eb3710445fdf34fa32466dea6c96128be92b4

2 Likes
23

Hi @0xGonzacolo ,

Thank you for the proposal. After carefully reviewing it, along with the questions and feedback from delegates, we generally favor automation within DAOs, and the budget seems reasonable.

However, we would like to understand more about which parts of the mechanism are centralized and which are decentralized.

Thanks in advance!

1 Like