Skip to content

Latest commit

 

History

History
51 lines (39 loc) · 4.51 KB

SIP-0004.md

File metadata and controls

51 lines (39 loc) · 4.51 KB
Raw
SIP Title Author Status Track Created
0004
Minting of Additional cSOV
Edan Yago (@YagoBit)
Approved
Treasury
2021-01-28

SIP-0004: Minting of Additional cSOV

Abstract

Due to demand massively exceeding anticipated demand, it is proposed to increase the Genesis reserve allocation of cSOV.

Background

On Monday, January 25'th 2021, Sovryn launched the Genesis Reservation system. This allowed users to reserve an allocation of SOV at a price of 2500 sats. Despite the fact that participation was limited only to addresses active prior to the snapshot on January 8'th, demand far exceeded supply and expectation. Within a matter of minutes, the funds received exceeded the allocation.

The approved allocation (SIP 0003) was to allow 2,000,000 cSOV tokens to be reserved for 50 BTC. In practice, 67.956 BTC were received, from some 800 addresses. From these, 66.04865467 BTC were correctly received for investing. The remainder was received as a surplus (or excess) without proper allocation rights. This amount is redeemable.

Motivation

The goal of Genesis was to allow the cohort of early users, who were using the system, to become stakeholders in its future. Trade-offs (discussed below) notwithstanding, expanding the eligibility would appear most congruent with this goal.

Proposal

Resolved:

  1. Increase the supply of cSOV through the minting of an additional 641,946.1868 cSOV.
  2. Distribute these cSOV at a rate of 2500 sats/cSOV to all addresses from which funds were received during Genesis.
  3. Reduce the allocation of SOV for future programmatic sales by 641,946.1868 cSOV.

Trade-offs

Sovryn Treasury

  1. SOV is earmarked for programmatic sales in order to provide the Sovryn protocol with a treasury of funds to support the future growth, maintenance and security of the protocol. Reducing the allocated SOV for this purpose, risks also reducing the potential treasury.
  2. However, the unanticipated demand indicates that the future price of SOV may also be higher than anticipated. This may allow future programmatic sales to occur at a higher price per SOV, which would allow for adequate capitalization of the treasury.
  3. Further, while funds are important, the value of a dedicated, motivated community is immeasurable. Any question of treasury capitalization must be measured against the opportunity to reward Sovryn's earliest, high-conviction users.

Moral Hazard

  1. Genesis was clearly communicated as having a limit of 2,000,000 cSOV distributed on a first-come, first-served basis. Changing any decision retroactively introduces the risk for moral hazard and reducing the credibility of Bitocracy decisions. However, this change is not a retroactive change. No past state is being changed. Instead, only future allocations, which remained undecided and had not been subject to vote, are being "changed".
  2. Further, no participant is being disadvantaged in this proposal. Indeed, only further benefit is being provided. The "victim" is only the protocol itself, and as expressed above, it is unclear that this proposal is not to the advantage of the Sovryn protocol.
  3. Additionally, the mechanism for first-come, first-served was not clearly articulated - a learning for the future.
  4. Finally, Sovryn is still in alpha, as is the Bitocracy system. The purpose of Bitocracy is to provide a degree of flexibility to the protocol. Never will this be more needed than when the system is in alpha.

Additional Considerations

  1. While return of funds to users in order to maintain the 2,000,000 cap is possible, it would impose costs upon the dev team, whose time can better be spent on other tasks. This true in particular due to users sending funds from exchange addresses - to which the funds should not be returned.
  2. Many more users who wished to participate in genesis were unable to within the few minutes it was live. Should we not extend cSOV to them as well. We propose that this would be a step too far. It was clear that Genesis must be limited and this would be completely counter to that spirit.

Learnings

  1. Future distribution events must make clear if resale is intended. If not, access codes or NFTs should be non-transferable.
  2. Distributions should ideally be designed to minimize the potential for over-distribution. This is particularly important when allowing BTC deposits. It is recommended to allow for pre-funding in future events.
  3. Efforts must be made to provide greater clarity on the mechanism for enacting distribution rules (eg. first-come, first-served)