This proposal aims to allocate PERP to fully compensate all users who lost funds in Perp V1 by minting PERP. We propose for the PERP to start vesting linearly over 12 months (with a cap of 3.3% of circulating supply being released each month). Emissions will start on the next first of the month 4 months after the vote finishes.
It’s crucial to come to a solution that rings close to fair, especially for V1 users, as they were massive contributors to the early growth of Perp Protocol. It is also only right to have safety of user funds as the forefront of protocol’s mandates.
To reduce concerns on selling pressure: a previous proposal published by a PERP team member called for the community to unlock 20.5m PERP to be used for reward, partnerships/ bounties, DEX liquidity (See section called Rewards: Proposal: Unlocking Perp Tokens for Growth). A 4m USDC weekly cap was set on the 13m PERP reward program unlock to ensure limited selling pressure. With our current model, less than 4m USDC is released into circulation monthly.
Note that minting is on Mainnet, and emissions are on Gnosis Chain (xDai).
Proposal 1: Mint PERP and fully compensate everyone proportionally (A cap of 3.3% PERP tokens will be released each month)
Proposal 2: Support minting PERP tokens for V1 users but not this proposal
Proposal 3: Against minting PERP tokens for V1 users
*the price of PERP will be a 7-day TWAP of the last week of every month which will be used to calculate the amount of PERP that should be minted to make all of V1 users whole each month
To check how much funds will be distributed to each user (Margin + unrealized PnL according using index price and slippage according to original k values.):
Timeline: proposal is live on snapshot > assuming it passes > PERP tokens will be locked for 4 months > PERP tokens will be unlocked for the next 12 months, amount each user will receive will be based on the TWAP mechanism suggested
Assuming the 4 month lock up ends in October, the TWAP will be calculated between 24-30 September (last week of the month) and announced on 1 October so that users know how much they’re getting. If the monthly cap is interfered, the vesting schedule can be extended beyond 12 months.
The author of this post will work closely the core team as the core team will be minting and issuing the tokens. The author can help to calculate the monthly token allocation to facilitate the process.
“Sell pressure” section references a token unlock, not a token mint
Hi and thanks for reposting! I switched you to a higher forum role so you can post links etc., more easily (sorry I didn’t do that earlier). E.g. I think you can also link to the Unlocking PERP tokens for growth post (link)
Sorry for the additional questions:
You mention both 3.3% and 3% monthly cap
4 month lock up applies to each batch of tokens minted every month? E.g. the first batch is minted Sept 1, locks for 4 months, then begins vesting over 12 months? So a user will get the Sept batch in Jan, and the Oct batch in Feb, etc.?
How do recipients get tokens, claim or airdrop? Will this be on Ethereum or Optimism?
Am I correct to assume the calculation, minting and issue of tokens is to be done by the core team?
This is just a suggestion but the token issuance seems complex (monthly issuance locked 4 months then vested over 12 months, so each month you add a new set of payments for each recipient.) It’s hard to figure out what you’ll receive as a user, and a lot more work for whoever has to calculate the payments. Maybe there’s a way to simplify it? E.g. split the amount (in USD) to be paid to each user in 12 or maybe 18 monthly payments and pay that amount in PERP according to the TWAP you proposed (E.g. a user will get x USD paid monthly in PERP). This way v1 users know exactly what they will get and when. Locking for 4 months IMO does not make a real difference. In fact recipients will probably not want to sell right away anyway since they will likely get frontrun (ie. I guess there will be a dump every month before the issuance if they are selling predictably).
For Proposals 2 and 3 it might be good to specify “Support minting PERP tokens for v1 users but not this proposal”
Sorry! I re-edited the forum post to show 3.3% monthly cap
No, once proposal is live on snapshot > assuming it passes > PERP tokens will be locked for 4 months > PERP tokens will be unlocked for the next 12 months, amount each user will receive will be based on the TWAP mechanism suggested
If proposal passes, details will be discussed with the team then posted on the forum. Ideally, it will be the same format and chain as how Sunsetting Perp V1 was done.
Calculation can be done by me which can be cross checked by the core team. Minting and issuing of tokens would, of course, have to be done by the core team since public participants can’t do this I suppose. Happy to provide any help as possible to get this rolling though!
RE 2. your idea is simpler than I thought However how will you mint and lock the PERP for 4 months without knowing how much you’ll be giving out (since amounts given depend on TWAP calculated each month). It sounds like the same effect can be obtained by placing a 4 month delay on minting, then mint the amount needed each month based on the TWAP. E.g. if the total USD amout needed is 30m, then each month you need 2.5m, so you’ll mint 2.5m worth of PERP based on TWAP each month.
This could also interfere with the 3.3% cap. What would be done in case the monthly amount > 3.3%?
Hi, I got some comments from core team members about a few details we missed.
Can you note in the spreadsheet that “Margin + Unrealized PnL” is based on Index price and original k values?
The “sell pressure” section references a token unlock, not a token mint. Can you note this?
The initial 4 month lock and the 12 month (or more) emission schedule are not compatible because you cannot mint+lock before you know how many tokens you need. I suggest either removing this lock or changing it to a 4 month delay (emissions will start on the next first of the month 4 months after the vote finishes, e.g. if vote passes Sept 7, emissions will start Feb 1).
PERP minting happens on Ethereum mainnet but some wallets may only be able to access funds on xDai/Gnosis Chain (e.g. contract wallets are likely to be unable to access funds on mainnet). So it might be best to state that minting is on Mainnet, and emissions are on Gnosis Chain (xDai).
There are some confusing statements and may make this proposal being interpreted in different ways:
I assume the previous proposal you mentioned is this. If that’s the case, that proposal ( let me call it 245 ) didn’t mint any PERP. My definition of “mint” is the contract call to the $PERP contract . However, $PERP has never minted any token after genesis. There are some locked PERP tokens in this multisig , and 245 propose to unlock 13m for reward, 4m for partnerships + bounties, and 4m for DEX liquidity. It’d be more clear if we updated the proposal itself instead of adding notes at the bottom of the proposal.
Due to the potential misunderstanding of the “mint”, could you clarify do you propose to use the locked PERP like 245, or mint new PERP?
From your proposal, there’s a 4m USDC weekly cap, but you propose to distribute monthly. Does it mean it’s a 16m USDC monthly cap? If it’s a typo, could you fix it?
In proposal 1, could you elaborate more on “compensating everyone equally”? For example, if Alice is eligible to receive 10 USDC, and Bob is also eligible to receive 30 USDC, the total USDC amount that will be sent this month is 10. How much should Alice and Bob receive?
In proposal 1, you mention a 3.3% PERP cap, so we have both USDC cap & PERP cap. Is it true?
I didn’t fully review the spreadsheet you shared, but there’re some errors inside the cells. Could you help to check if we should treat all of them as 0?
Btw, just want to make have better transparency on the numbers of v1 margin + unrealized PnL you shared.
The core team help to reconstruct the numbers in this spreadsheet
However, due to the nature of v1’s vAMM design, there’re at least 4 different ways to simulate the margin + unrealizedPnL as listed in the spreadsheet above.
settle_in_mark_price_w_slippage: Numbers can be verified on chain. This is how much each user will get if they are the first one closing position using the May 2022 updated k value to calculate slippage.
settle_in_mark_price_w_slippage_old_k: Numbers can not be verified on chain since it’s simulating original k (pre-May 2022). This also assumes everyone is the first one closing position to calculate slippage.
settle_in_index_price: Numbers can be verified on-chain. This is how much a user will get if she’s the first one closing position starting from the index price rather than the market price. Slippage is based on the May 2022 k value.
settle_in_index_price_old_k: Numbers can not be verified on-chain since it’s simulating the original k. This also assumes everyone is the first one closing the position starting from the index price rather than the market price. Slippage is based on the original pre-May 2022 k value. Note： This was the method used for the V1 Sunsetting vote option 1, 2, 3 and this proposal
There’s no USDC cap, only PERP cap. The USDC cap was referring to your team’s proposal. Based from this sheet, <$4m USDC will be distributed each month assuming the tenure is 12 months ($34m/12 = $2.8m) Mint PERP to Sunset V1 Users - Google Sheets
Hi @carview1987 thanks for taking suggestions into consideration
For 3, although it may not affect the proposal itself, still want to remind that “unlock 13m PERP to be used for strategic partnerships” is a false statement. The proposal 245 unlocked 13m PERP for reward, 4m PERP for partnerships + bounties, and 4m PERP for DEX liquidity, and the 4m USDC weekly cap is just for the 13m PERP reward program. Besides, this proposal ( 904 ) didn’t mention it’s assuming “the tenure is 12 months” it would have more clarity if we could put it into the proposal or just simply remove the wrong statement.
For 4, it would be great if we could have an example instead of clarifying from replying comment, or just change the word “equally” to “proportionally”? Or any other word that could make it more precise
For 6, could you make this spreadsheet’s version history open to everyone? Ideally, we should export it to CSV and upload it to IPFS or Arweave to make it immutable but it should be fine by checking the edit history from the google sheet
I just reworded this proposal to address (3) so that is is a true statement.
I wrote in the proposal “We propose for the PERP to start vesting linearly over 12 months (with a cap of 3.3% of circulating supply being released each month)” and also in the notes section “Timeline: proposal is live on snapshot > assuming it passes > PERP tokens will be locked for 4 months > PERP tokens will be unlocked for the next 12 months, amount each user will receive will be based on the TWAP mechanism suggested” - hope this clarifies things?
I reworded it to “proportionally”.
I don’t think that’s a feature in Google Sheets. Would you be able to provide your email/ any relevant address so that I can add you guys as editors?
Sweet, I updated to included the IPFS version! Thanks!
I wrote in the proposal this: “. A 4m USDC weekly cap was set on the 13m PERP reward program unlock to ensure limited selling pressure. With our current model, less than 4m USDC is released into circulation monthly.” which refers to the reward program - hopefully that’s clear?
Been watching this for a while and had to create an account as I’m actually not sure what the point of this vote is. Large token holders have expressed their view to not support any form of compensation with previous votes and it seems like a waste of time to attempt something again.
V2 is doing very well in current market conditions and continues to grow. I’d rather the team just stop working through a proposal that is clearly going to fail and focus on the main thing that matters right now: growth.
It’s good but the 13m is still wrong – it’s 20.5m total for all the programs you mentioned. Sorry for being picky, we just want to try to get everything correct before going to a vote.
Welcome and thanks for your input! For better or worse, proposals and voting are a part of the decentralization process. Our community team will do the best we can to handle proposals so the dev team can focus on building! I’ve personally been away from work a lot in the past month+ but starting next week I’ll be back full time and will be spending more time on governance.