Extend PSP staking lockup period to an epoch length or more to better align staker incentives.
Context
The PSP staking lockup period was initially set to 2 days to be permissive as new users discovered the system — leaving the DAO the control to adjust it. The time has come! To make sure PSP staking decisions are best aligned with the long-term success of the model, the lockup period can be pushed to an epoch length (14 days) or even slightly more if desired.
It’s a simple parameter adjustment, enforceable if the PSP voters agree. Several options are possible:
Keep current 2 days lockup period
Increase to half an epoch length: 7 days
Increase to an epoch+ length : 14+ Δ days, for instance 14+1
Goals
This proposal is a bit of a “governance debt”. The staking system was initially designed with a lockup period similar to an epoch length. The team decided to lower it to 2 days before release to facilitate early staking decisions of the first participants.
With now, >50M PSP staked and market maker game progressively stepping up, it’s time to lift up the guardrails. Increasing the lock-up period ensures staking decisions are consequential and prevents gaming of the staking rewards.
Means
No budget is required. The implementation effort is minimal.
Rationale
Successful implementation of the proposal will result in better rewards for a more long-term commitment from staker making savvy choices. It will also promote more responsible behaviors, and prevent panic phases such as the mini-exodus from Pool4 at the beginning of epoch 2 when no trade had been conducted yet.
Forward-thinking considerations
Further adjustment of the PSP staking logic can be voted by the DAO down the line if deemed necessary, including the Δ time delay if implemented with this proposal.
Implementation Overview
The PSP staking contracts lockup period will be increased to the option decided on Snapshot, within a week after the vote completion using the “changeTimeLock” function on each of the six ParaSwapPool contracts.
It seems to me that increasing the lockup period to the epoch time will discourage active traders from taking advantage of temporary price fluctuations. That said, we could see bigger swings on epoch end days. Perhaps epoch +3 days will help discourage this as well?
I can understand the logic behind this change and realise it will assist in stopping people being able to game the staking system by staking last minute to obtain the optimum APY rewards.
What I disagree with is your implementation timeframe. People who staked from the beginning of this 14 day epoch period paid gas fees and made their decisions based on the assumption that they needed to commit to only 15 days maximum then they could obtain their rewards and decide to sell or change staking pool.
You advise that the hold ChangeTimelock would be implemented within a week after the vote completion (8th Dec)
This would mean that people who could previously unlock/unstake and claim their rewards on 12th or 13th December are now being forced into whatever the new timelock period will be (additional 7 or 14 days).
I assume that would result in the earliest un-stake / claim rewards dates of 19th or 26th december depending on which timelock is voted for.
Technically the proposal action doesn’t really need to be rushed and applying this change from 14th of december, beginning of the next epoch makes more sense because it achieves the same goal and doesn’t penalise or force additional minimum staking periods for current stakers. The early implementation does make me question the intention and makes me wonder if this is to actually delay/mitigate stakers dumping rewards?
EDIT Just had a thought about the reasoning to get this proposal implemented before epoch claim date has arrived. It would stop people entering the pool last minute and abusing this “feature” one last time.
Do we have documentation about the concept of epoch and the motivation behind introducing it ?
I understand that rewards become claimable at the end of a given epoch, and that their are proportional to the overall performance of a market-maker withing this epoch (regardless of when this performance was the best within the epoch).
However it seems like anybody can start staking in the middle of an epoch - and similarly “commit unstake” in the middle of an epoch.
To me, it is not clear whether this proposal is about (1) simply extending the delay between unstaking being requested and unstaking being committed for 2 to 14 - in which case it seems to me that anyone can still game the system - or (2) if it is about making the staking/unstaking commit only possibly at the start/end of each epoch (similar to lyra.finance where you deposit on epoch n-1 to participate in epoch n, and have to request withdrawal before epoch n+1 if you don’t want to participate in it).
The “Goals” makes me think it is the former.
The “Implementation Overview” makes me think it is the latter.
Hello DansAfk and thanks for this interesting feedback!
I can definitely understand the concern around the implementation timeframe. We can adjust the timeframe by voting on snapshot after the competition of the first one reviewing the proposal. There’s technically no rush indeed but it seemed like a good time to move forward with the change.
It would be a simple parameter adjustment on a yet-to-be-implemented proposal, so it could be a 2 or 3 options vote: keep current + alternative(s). Would that be something helpful in your view?
The goal is to make the system more sound and synergistic, not to penalize stakers.
Your understanding is mostly correct though. Rewards are based on the market maker’s performance over the whole epoch. Meaning that as the epoch goes by, the uncertainty assumed by PSP stakers lowers:
staking on the first day: “taking a bet” on the next 14 days of performance
staking on day 7: deciding with 7 days on data + bet on 7 more days
The goal of the proposal is closer to the (1) you suggest, however increasing the lockup to at least an epoch length does prevent gaming as it makes it “unprofitable” from a game theory perspective - see the reasoning above and adjust to a 14days lockup to realize why.
Thanks for your response tokenbrice - and for the doc as for some reason I only found developer doc before.
I am trying to identify examples of behaviors / attack vectors this proposal can/can’t prevent, and I am trying to picture very concrete scenarios. But I find I still have some missing pieces (that might not be directly related to the proposal, so sorry if this pollutes the thread).
Is the PSP reward of an user after an epoch proportional to the time for which their PSP they “staked” ? If user A stakes when an epoch has just started and user B stakes when an epoch is 50% complete, does it mean user A will get 2x more rewards than user A (for same amount of PSP staked in same pool) ? Or can user B “snipe” the pool and wait until epoch is 99% complete to see what the performance of a pool is and stake at the very end of an epoch ?
→ This is the first attack vector I am imagining but I don’t know if it is valid.
Even if the distributed PSP are time-weighted, there is still an attack vector I can see:
User B is holding stablecoins and is not exposed to PSP. Pool X on Paraswap experiences an exceptional trading volume during the first half of the current epoch (like 10x the usual). User B buys PSP on the market to stake them because they know the APY is worth is for the 50% remanining of the epoch (even if pool X stops performing during this second half). In this instance if I understand correctly the only difference this proposal makes is that user B will have to be exposed to PSP for 21/14 days (end of current epoch 7 days + 14/7 days) in total instead of currently 9 days (end of current epoch 7 days + 2 days) - assuming they can hedge their position via external products during that period.
In my view, decisions about staking on a given pool for a given epoch could be broadcasted before an epoch, so decision about switching pool or withdrawing could be done anytime but executed only at epoch+1. This way you can’t just jump-in or jump-out depending on current conditions and you preserve the “betting” nature of it, while still maintaing a reasonable 14 days max lockup - in which you keep accruing rewards until your actual unlock. Note that with this model users could broadcast/change their decision to withdraw/switch first minute or last minute of epoch n-1 (with a similar result).
Ah that’s probably my bad @neozaru we lack a simple central resource with all the main links/info, I was getting the same feedback from another community member today: I’ll add it ASAP on Discord/Docs.
And no worries if the questions are a bit broader than the proposal itself, it’s good that we consider further improvements of the model too.
So in the current design, the epoch payout is reflected in the sPSP/PSP rate that increases at the end of any epoch. Each ParaSwapPool has a specific contract and dedicated sPSP tokens (ex: sPSP_PP1), with different exchanges rates against PSP. The sniping scenario is indeed something possible right now the proposal is trying to address. @Lup also discussed a bit this morning / at the CC of the potential V2 for the staking, with a “pool hoping” feature to facilitate position management for stakers.
In my view, decisions about staking on a given pool for a given epoch could be broadcasted before an epoch, so decision about switching pool or withdrawing could be done anytime but executed only at epoch+1
I was thinking along the same line for the later evolutions of the model, that’s definitely something I’d like the DAO to explore. Feel free to reach out to @disiaque.eth too, ParaSwap’s first scribe, if you’d like help to shape this into a proposal.
This is what this proposal is meant to address because your sniping example is exactly what happens today. You could implement a simple strategy where you buy $PSP an hour before epoch close, stake PSP in high performing pools, wait for epoch close, collect ~7%, withdraw 48 hours later, and then swap out. Easy money.
I think a simpler and more elegant solution than what is proposed would be
Zero Lockup
Pool rewards for a market maker are based solely on volume (ie. remove the staked $PSP from the reward calc)
Individual rewards in a pool are weighted based on how long a user were in the epoch weighted by point in time staked psp, relative to others.
p = market maker pool i = individual staker t = time integral within an epoch
The above would probably require some non-trivial refactoring but doable. I am curious if reward calcs are done off chain or on? I reviewed the typescript function, but is there a solidity contract that does the same?
However given that likely won’t be implemented as quickly AND this lockup will also be required for transferring stake across pools, I am more supportive of the 7 day lock. It gives stakers an opportunity to switch pools without missing out on an entire epoch rewards.
