veSHN

[Nxo]

As there has been some discord discussion about veSHN style token where people could lock their SHN for up to 4 years and get some benefits out of it (e.g. farming rewards, % of raising fee etc.), I am trying to outline all important questions which should be answered before investing any serious resources into this topic.

Feel free to share your thoughts and ideas.

1. Which chain should be used for veSHN?
   • a) What are the implications for using a particular chain?
   • b) Are users able to participate in a chain A sale if tokens are on chain B (note that ve tokens are not transferable)
   • c) Is it possible to take a snapshot of veSHN tokens?
2. Should the veSHN contract be upgradeable?
   • a) Even though its nice to have upgradeable contracts this adds immense complexity and opens a potential attack surface which many protocols faced.
3. Can veSHN be used for governance?
   • a) Governor Bravo and Governor Alpha are market standards in web3. How compatible this is with ve style tokens.
   • b)What happens if someone locks their tokens for 4 years and its not possible to participate in the governance?
   • c ) What happens in case of off chain governance? Is it possible to connect snapshot to ve style tokens?
4. Gauges
   • a) It seems that the existing ve style token codebases also include gauges mechanisms (e.g. Curve & Frax). Should we remove those things from the system?
   • b) What are the complexity & security implications of doing that?
5. Do we need an audit for this?
   • a) Can DAO afford it?
   • b) If we extend the system in the future in any way can we afford even another audit?
6. Will the veSHN be compatible with the things that might come in the future.
   • a) As we are dealing with lock up periods up to 4 years, how confident are we that the system is going to be interoperable with anything that comes in the future. Note that blockchain code is immutable.
7. Reward contracts + veSHN
   • a) How to stake veSHN which is not transferable to a staking contract which could issue rewards?
   • b) What about rewards that consists of multiple tokens? How to structure that? Separate contracts for every token?
8. How to deal with the lack of documentation?
   • a) Technical documentation for the ve style token is not really available out there. As it stands right now everything would have to be understood from solidity or vyper files.
   • b) How confident are we that we can understand everything from those files? How many persons do we need? What is the timeline?

[0xRock]

Made some calculations and compared the veCRV model (1SHN + 4-year lock = 1veSHN, decaying to 0 veSHN) with veFSX model (1SHN + 4-year lock = 4veSHN, decaying to 1 veSHN).

In case you wanna play with numbers, you can use the veCRV locker calc, or veFXS locker calc.

Current Status

Tier	SHN	Estimated Value	Lockup Period	veSHN
TIER 1	15000	$150	/	/
TIER 2	50000	$500	/	/
TIER 3	200000	$2000	/	/
COMMITTEE	400000	$4000	/	/

---

Below I will compare veCRV and veFXS approaches.

TL;DR: we should go with veFXS approach because veCRV is too extreme with decaying to 0 overtime.

---

veCVR

1SHN + 4-year lock = 1veSHN, decaying to 0 veSHN

Locking SHN for 7 days

Tier	SHN	Estimated Value	Lockup Period	veSHN
TIER 1	15000	$150	7 days	70
TIER 2	50000	$500	7 days	240
TIER 3	200000	$2000	7 days	960
COMMITTEE	400000	$4000	7 days	1920

Locking SHN for 4 years

Tier	SHN	Estimated Value	Lockup Period	veSHN
TIER 1	15000	$150	4 years	15000
TIER 2	50000	$500	4 years	50000
TIER 3	200000	$2000	4 years	200000
COMMITTEE	400000	$4000	4 years	400000

---

veFXS

1SHN + 4-year lock = 4veSHN, decaying to 1 veSHN

Locking SHN for 7 days

Tier	SHN	Estimated Value	Lockup Period	veSHN
TIER 1	15000	$150	7 days	15,000
TIER 2	50000	$500	7 days	50,000
TIER 3	200000	$2000	7 days	200,000
COMMITTEE	400000	$4000	7 days	400,000

Locking SHN for 4 years

Tier	SHN	Estimated Value	Lockup Period	veSHN
TIER 1	15000	$150	4 years	60,000
TIER 2	50000	$500	4 years	200,000
TIER 3	200000	$2000	4 years	800,000
COMMITTEE	400000	$4000	4 years	1,600,000

[0xRock]

veSHN Research Workshop

Mar 3rd, 2022

1. Which chain should be used for veSHN?

We should be using Polygon chain. If there is a sale happening on the other chain, we could:
a) Take a snapshot of veSHN on Polygon
b) Create a “one-time dummy token” on other L1, L2
c) Airdrop a dummy token and conduct a sale on other L1, L2

Users won’t even notice what is happening in the backend.

Action step:
Investigate how to do a snapshot of ve style tokens.

Should the veSHN contract be upgradeable?

It seems like upgradability is adding a lot of complexity and opportunities for potential exploits. Since contracts are immutable, our idea is to implement emergency_unlock of all tokens in case we’d be forced to change something in the future. That would return all locked tokens to their holders and migrate to the new contracts. We are proposing this because it is going to be unlikely that we will have to upgrade them, but if we have to, we can do that without being stuck in the lock.

Action step:
Investingate emergency_unlock implemented in veFXS.

3. Can veSHN be used for governance?

Yes, but it does require additional configurations.

Action steps:
Investigate Governer Bravo compatibility with ve style tokens
Investigate Tally and Snapshot compatibility with ve style tokens

4. Gauges

We won’t need gauges for now.

Action step:
Investigate if we should keep or remove Gauge contracts.

5. Do we need an audit for this?

Probably yes.

Action step:
Let’s try to get qutes in later dev stages.

6. Will the veSHN be compatible with the things that might come in the future?

In the worst-case emergency_unlock allows us to release locked tokens and migrate new smart contracts with additional benefits for veSHN holders.

Action step:
We should think about how moonshot ideas like Tokemak or Olympus pro for new projects could impact the veSHN design.

7. Reward contracts + veSHN

For V1 implementation we could skip reward contracts and even manually airdrop rewards to veSHN holders based on snapshots. But if it’s easy to implement, we should do it.

Actions step:
Define requirements and explore implementation.

8. How to deal with the lack of documentation?

The universe did this for us, Curve Documentation was just released.

[DinkyDew]

I am pretty sure I am missing a vital piece of the conversation, but what is the reasoning behind building a curve for SHN? Are we worried about not enough people adopting the token? I haven’t been checking for any heavy trades? Is the goal to create demand via incentivization?

On item 1.) I agree using MATIC. Most EVM compatible chains are going to have addresses that persist across chains that should make airdropping seamless and transparent.

On item 2.) I agree their needs to be a failsafe to unlock funds but it needs to be a kill switch of sorts. No “unlocking” due to financial hardships or some other personnel “event”. The emergency unlock should only be used if there is financial shenanigan’s (criminal acts) by committee members and or if ETH where to do something really crazy from a technology standpoint that would render the contracts inoperable on a new chain.

Cheers!

[0xRock]

We are exploring voting-escrowed token designs because:

1. We wanna incentivize users to stake SHN and avoid them buying SHN right before the sale and dumping it right after.
2. We wanna introduce an additional token utility (sharing launchpad fees and potentially treasury yield with veSHN holders).
3. We wanna allocate more voting power and more benefits to long-term holders of SHN through veSHN.

I agree with points 1.) and 2.) - we should only use emergency_unlock when it’s absolutely needed. @Nxo was pointing out that having upgradable contracts adds a lot of additional complexity and opportunities for exploits. So the tradeoff is:

a) Investing way more recourses, time, and effort to make the contracts upgradeable.
b) Making contracts non-upgradable and using emergency_unlock if the upgrade is really necessary (we don’t think that is likely to happen)