57 |
58 | ## Proposed change
59 |
60 | Existing Staking Logic contract: [0xa0a44943f84f1766b42e67273EE6091A6ccc9315](https://explorer.rsk.co/address/0xa0a44943f84f1766b42e67273ee6091a6ccc9315)
61 |
62 | New Staking Modules Proxy contract: [0xe2b4A4213c823cb3E1B90D128aED17A86F45bBc0](https://explorer.rsk.co/address/0xe2b4a4213c823cb3e1b90d128aed17a86f45bbc0)
63 |
64 | Staking logic module contracts:
65 | - StakingAdminModule: [0x382e6480d6cDe9E64953Feb6e12b33da849dA44a](https://explorer.rsk.co/address/0x382e6480d6cde9e64953feb6e12b33da849da44a)
66 | - StakingGovernanceModule: [0x039119F8f4d28491C829682B3ebD5e9729477C74](https://explorer.rsk.co/address/0x039119f8f4d28491c829682b3ebd5e9729477c74)
67 | - StakingStakeModule: [0xDf41bd1f610d0DBE9d990e3Eb04fd983777F1966](https://explorer.rsk.co/address/0xdf41bd1f610d0dbe9d990e3eb04fd983777f1966)
68 | - StakingStorageModule: [0x8Bd4ED875dAD5CcDD1F9c276aCFC8067c287baEB](https://explorer.rsk.co/address/0x8bd4ed875dad5ccdd1f9c276acfc8067c287baeb)
69 | - StakingVestingModule: [0x4Ca823CED18212876BB13092E4460CC65d2C7874](https://explorer.rsk.co/address/0x4ca823ced18212876bb13092e4460cc65d2c7874)
70 | - StakingWithdrawModule: [0x7FE861e0948df601F28e0D84664Fa2ddF4b39155](https://explorer.rsk.co/address/0x7fe861e0948df601f28e0d84664fa2ddf4b39155)
71 | - WeightedStakingModule: [0xdB8798306fbf54Cb81859f72aB444eFa3D860Ff2](https://explorer.rsk.co/address/0xdb8798306fbf54cb81859f72ab444efa3d860ff2)
72 |
73 |
74 | Proposed changes:
75 | [https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/448](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/448)
76 | [https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/486](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/486)
77 |
78 | ## License
79 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
80 |
--------------------------------------------------------------------------------
/SIP-0050.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: "0050"
3 | Title: Critical staking vulnerability fix
4 | Author: Tyrone Johnson (@tjcloa)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2022-10-18
8 | ---
9 |
10 | # SIP-0050: Critical staking vulnerability fix
11 |
12 | ## Description
13 |
14 | The Staking contract has been paused to prevent malicious use of the information disclosed by this SIP.
15 |
16 | If approved, this proposal will upgrade the Staking contract to an implementation that fixes a critical vulnerability.
17 |
18 | ## Motivation
19 |
20 | A security researcher has reported a critical vulnerability through Sovryn's [Immunefi bug bounty program](https://immunefi.com/bounty/sovryn/). The vulnerability allows any address to obtain arbitrarily high voting power that would result in an unfair advantage in the Bitocracy voting system. The Exchequer Multisig has paused staking to allow us to expose the vulnerability publicly and to vote on the deployment and acceptance of the fix, without putting our governance at risk in the meantime. It is important to note that this vulnerability has not been exploited on mainnet to date.
21 |
22 | ## Details
23 |
24 | ### The vulnerability
25 |
26 | Stakers can increase their voting power by using a vulnerability in the Staking contract `extendStakingDuration()` by submitting specific parameter values.
27 |
28 | The Staking::extendStakingDuration() function can be used to extend the "until" time for one's stake. It takes two parameters: the previous timestamp and the new timestamp. The function takes out the stake amounts and delegation amounts from the previous timestamp and attaches them to the new timestamp. It will also change the delegation in case you delegated to someone else (delegations are timestamp-specific). More specifically, in Staking::extendStakingDuration(), by exploiting the vulnerability it was possible to manipulate variables and set `previousLock == until` after verification of `require(previousLock < until, "S04"); // must increase staking duration`, therefore bypassing the initial verification.
29 |
30 | Here is the logic that does not work when `previousLock == until`, and must therefore be fixed:
31 |
32 | ```
33 | address delegateFrom = delegates[msg.sender][previousLock];
34 | address delegateTo = delegates[msg.sender][until];
35 | if (delegateTo == address(0)) {
36 | delegateTo = delegateFrom;
37 | delegates[msg.sender][until] = delegateFrom;
38 | }
39 | delegates[msg.sender][previousLock] = address(0);
40 | _decreaseDelegateStake(delegateFrom, previousLock, amount);
41 | _increaseDelegateStake(delegateTo, until, amount);
42 | ```
43 |
44 | The stake and delegate balances do indeed decrease and increase correctly. But the line `delegates[msg.sender][previousLock] = address(0)` zeroes out the delegation of the previousLock timestamp, which is the same as the new timestamp.
45 |
46 | Now that the delegation address for the currently set staking timestamp is `address(0)`, the attacker can call the `delegate()` function, which will delegate their entire balance as delegateStake to any address, but without decreasing the delegator's delegateStake balance. By repeating this call, the attacker can continuously increase an address' delegateStake without limit (because source voting power is not getting properly decreased), resulting in arbitrarily high voting power.
47 |
48 | ### The fix
49 |
50 | We introduce two small changes:
51 |
52 | Move line 143 of Staking.sol `require(previousLock < until, "S04"); // must increase staking duration` to line 150.
53 |
54 | This:
55 |
56 | ```
57 | function extendStakingDuration(uint256 previousLock, uint256 until) public whenNotPaused {
58 | until = timestampToLockDate(until);
59 | require(previousLock < until, "S04"); // must increase staking duration
60 |
61 | _notSameBlockAsStakingCheckpoint(previousLock);
62 |
63 | /// @dev Do not exceed the max duration, no overflow possible.
64 | uint256 latest = timestampToLockDate(block.timestamp + MAX_DURATION);
65 | if (until > latest) until = latest;
66 | ```
67 |
68 | is changed to this:
69 |
70 | ```
71 | function extendStakingDuration(uint256 previousLock, uint256 until) public whenNotPaused {
72 | until = timestampToLockDate(until);
73 |
74 | _notSameBlockAsStakingCheckpoint(previousLock);
75 |
76 | /// @dev Do not exceed the max duration, no overflow possible.
77 | uint256 latest = timestampToLockDate(block.timestamp + MAX_DURATION);
78 | if (until > latest) until = latest;
79 | require(previousLock < until, "S04"); // must increase staking duration
80 | ```
81 |
82 | Move line 173 of Staking.sol (delegates[msg.sender][previousLock] = address(0);) between line 167 and 168.
83 |
84 | This:
85 |
86 | ```
87 | address delegateFrom = delegates[msg.sender][previousLock];
88 | address delegateTo = delegates[msg.sender][until];
89 | if (delegateTo == address(0)) {
90 | delegateTo = delegateFrom;
91 | delegates[msg.sender][until] = delegateFrom;
92 | }
93 | delegates[msg.sender][previousLock] = address(0);
94 | ```
95 |
96 | is changed to this:
97 |
98 | ```
99 | address delegateFrom = delegates[msg.sender][previousLock];
100 | delegates[msg.sender][previousLock] = address(0);
101 | address delegateTo = delegates[msg.sender][until];
102 | if (delegateTo == address(0)) {
103 | delegateTo = delegateFrom;
104 | delegates[msg.sender][until] = delegateFrom;
105 | }
106 | ```
107 |
108 |
109 | Both changes individually fix the bug and prevent the delegate address from ever being zeroed out during the staking extensions, thereby closing the vulnerability.
110 |
111 | ## Proposed change
112 |
113 | Existing Staking Logic contract: 0x81570497e763809900A8e91c8DaF3020085e43aB
114 | New Staking Logic contract: 0xA0a44943f84f1766b42e67273EE6091A6ccc9315
115 | Proposed changes: https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/454
116 |
117 | ## License
118 |
119 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
120 |
--------------------------------------------------------------------------------
/SIP-0051.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0051'
3 | Title: Adjustment of the AMM fee-split
4 | Author: Sacro21
5 | Status: Approved
6 | Track: Parameter
7 | Created: 2022-10-26
8 | ---
9 |
10 | # SIP-0051: Adjustment of the AMM fee-split
11 |
12 | ## Description
13 |
14 | Currently, AMM swaps have a fee of 0.3% which is distributed as follows: 0.25% for AMM liquidity providers and 0.05% for the protocol (stakers).
15 | This SIP proposes to adjust the fee-split towards: 0.25% for AMM liquidity providers (unchanged), 0.1% for the protocol(stakers).
16 | This would result in a fee increase from 0.3% to 0.35%. AMM liquidity providers are unaffected, protocol revenue from AMM swaps would double.
17 |
18 | ## Motivation
19 |
20 | The related analysis, discussion and arguments can be found here: https://forum.sovryn.app/t/circle-of-tokens-regarding-protocol-revenue/2701
21 |
22 | In Summary:
23 |
24 | When we look at protocol incentives (SOV-rewards) versus protocol revenue, there's a significant deficit.
25 | With the proposed parameter change, we aim to reduce this deficit.
26 |
27 | The objectives of this parameter change are:
28 | -Increased fundamental value of the SOV token through increased protocol revenue. This would make staking of SOV more attractive.
29 | -Increased $ value of weekly SOV rewards for liquidity provider.
30 | -Increased liquidity in AMM pools OR same liquidity with a lowered amount of SOV-rewards.
31 |
32 |
33 | ## Proposed change
34 |
35 | Existing parameter(s): AMM swap fee for stakers : 0.05%
36 | Proposed change: AMM swap fee for stakers : 0.1%
37 | Change analysis: https://forum.sovryn.app/t/circle-of-tokens-regarding-protocol-revenue/2701
38 |
39 | ## License
40 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
41 |
--------------------------------------------------------------------------------
/SIP-0054.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0054'
3 | Title: Integrate Mynt with Zero
4 | Author: Ororo Munroe (@ororopickpocket), Tyrone Johnson (@tjcloa)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2023-02-23
8 | ---
9 |
10 | # SIP-0054: Integrate Mynt with Zero
11 |
12 | ## Description:
13 | Mynt is a BTC-backed stablecoin aggregator. Like BabelFish, Mynt aggregates different “basket” stablecoins (“bAssets”) into a single “meta” stablecoin (“mAsset”). By aggregating multiple BTC-backed stablecoins, each with its own stability and scalability mechanisms and limitations, Mynt is able to create a stablecoin that is more resilient and scalable than any individual stablecoin backing it. The first bAssets that will be supported by Mynt are DOC (issued by the Money On Chain protocol) and ZUSD (issued by the Zero protocol). The mAsset of Mynt is the Sovryn Dollar (DLLR).
14 |
15 | In order to provide a seamless user experience, we built a tight integration between Zero and Mynt, which allows us to perform following actions in a single transaction:
16 | * open a line of credit on Zero and convert the ZUSD into DLLR
17 | * convert DLLR into ZUSD and repay a line of credit
18 | * convert DLLR into ZUSD and deposit into the stability pool
19 | * withdraw ZUSD from the stability pool and convert it to DLLR
20 | * convert DLLR to ZUSD and redeem them for RBTC
21 |
22 | ## Proposed changes:
23 | ### Code changes:
24 | https://github.com/DistributedCollective/zero/pull/179
25 |
26 | ### Contracts updated:
27 | * BorrowerOperations: 0x6dafc71f49f9aa25325126dd9fec426624afb878
28 | * StabilityPool: 0x86cC28cdc46c515c866426Daa40d6Fc763E1c4Dd
29 | * TroveManager: 0xF365CC004d4c3826b53B943f5fc7B8aec6e43341
30 | * TroveManagerRedeemOps: 0xd4CE65a6DB60BeDD51c499b716969d57998Cd941
31 | * ZUSDToken: 0xc0B70D65A665911B0D6Dbd1eD58094F9c85F5A39
32 |
33 | ## License
34 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
35 |
--------------------------------------------------------------------------------
/SIP-0055.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0055'
3 | Title: Zero Fee Floor Update
4 | Author: John Light (@john-light), Ororo Monroe (@ororopickpocket), Tyrone Johnson (@tjcloa)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2023-03-01
8 | ---
9 |
10 | # SIP-0055: Zero Fee Floor Update
11 |
12 | ## Description:
13 | We have been running the Zero protocol with limited access since June 2022. During this time we could observe the behavior of the protocol and the market in different circumstances. In times of low liquidity of bridged stablecoins in Babelfish and deviation from the global BTC market price on the AMM we experienced an unreasonably high amount of redemptions.
14 |
15 | Before we open the Zero web app to the general public, we should take measures to protect borrowers from excessive redemptions. We therefore propose to increase the minimum redemption and origination fees from 0.5% to 2.5%.
16 |
17 | The increased redemption fee allows for a higher price deviation on the AMM before redemptions become profitable. This should not just reduce the number of redemptions, but also increase the trading volume on the AMM, which ultimately benefits the LPs and the SOV stakers.
18 |
19 | The increased borrowing fee should help with tempering the opening of new lines of credit, which leads to fewer DLLR created and therefore lower sell pressure. In the future, short term borrowers might decide to borrow from the DLLR lending pool instead, which provides an additional avenue of earning yield on DLLR and therefore BTC.
20 |
21 | The Sovryn community may consider organizing a working group to review these parameter values to assess the effectiveness of any changes and develop a repeatable process for updating them over time.
22 |
23 | ## Proposed changes:
24 | ### Code changes:
25 | Updating BORROWING_FEE_FLOOR from 0.5% to 2.5%
26 | Updating REDEMPTION_FEE_FLOOR from 0.5% to 2.5%
27 |
28 | ## License:
29 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
30 |
--------------------------------------------------------------------------------
/SIP-0056.md:
--------------------------------------------------------------------------------
1 | # SIP-0056: Sunsetting the MYNT Token
2 |
3 | ## Abstract
4 | This MIP proposes the deprecation of the MYNT token and the integration of the Mynt protocol directly into the Sovryn protocol, under governance of Sovryn Bitocracy. The Mynt protocol is expected to become a core component of the Sovryn ecosystem, issuing the Sovryn Dollar (DLLR) - which will become the standard currency of Sovryn. Due to the inability of the original developers of the Mynt protocol to continue to implement an independent roadmap it is proposed that the Sovryn community absorb it into the core Sovryn protocol. With passage of this MIP, the MYNT token will be deprecated. This MIP outlines the steps that will be taken to ensure a smooth and orderly wind-down of the MYNT token.
5 |
6 | ## Background
7 | Mynt was launched as a Sovryn subprotocol with the MYNT token as a SOV-bonded token. At the time this was viewed as an experiment in creating a more fractal Bitocracy as a path to future scaling of the Sovryn protocol. Mynt itself is poised to play an important role in the Sovryn ecosystem. However, for various reasons, many consider that the SOV-bonded token subprotocol experiment, at least in this case, was unsuccessful. These reasons include:
8 |
9 | * The increased complexity of SOV-bonded tokens
10 | * The inability of the original Mynt developers to continue to develop their anticipated roadmap
11 | * The MYNT token was launched at a particularly poor time, as the market was turning unfavourable and has suffered poor performance
12 | * The net result has been that Mynt development has slowed, and no independent Mynt Bitocracy was developed. Continued development and maintenance has fallen upon the Sovryn core developers, which the sub-protocol structure was meant to avoid. As a result, Mynt has failed to mature into an independent protocol with independent Bitocracy.
13 |
14 | With the launch of the Sovryn Dollar, time has come to resolve the structural questions surrounding Mynt.
15 |
16 | ## Procedural Context
17 | 1. Pausing of the MYNT Bonding Curve: Prior to the introduction of the Snapshot votes, the MYNT bonding curve has been paused.
18 | 2. Snapshot Votes: Two snapshot votes to be conducted to gauge the support of MYNT token holders for the deprecation proposal:
19 | - The first vote to be for MYNT token holders
20 | - The second vote to be conducted for MYNT/BTC AMM pool LP token holders, to provide these MYNT owners to participate.
21 | 3. The snapshot votes will be conducted to gauge the support of MYNT token holders for the deprecation proposal. The vote will be conducted over a period of 48 hours. The proposal will be considered to have passed if a majority of votes (>50%) cast across both votes are in favour of the proposal.
22 |
23 | ## Resolved
24 | 1. MYNT token bonding curve and the ability to mint/burn MYNT token will be replaced with a flat, pro-rata burn mechanism. Mynt token holders will be able to burn MYNT tokens to receive SOV but not mint new MYNT tokens.
25 | 2. The procedure for executing this proposal shall be as described below in the Specification section.
26 |
27 | ## MYNT Token Subordinate to SOV-Bitocracy
28 | The Mynt protocol was launched as a “Sovryn subprotocol, governed by the MYNT token and subordinate to the SOV Bitocracy.” SIP-0037 considered a situation where “it might be best to return the Mynt-bonded SOV to MYNT holders without having to adhere to the bonding curve formula. This orderly wind-down should be available as an option to be voted on by MYNT holders”. It further suggests that in “the event that MYNT governance has not been deployed before the 6 month cliff for Founders and Sovryn Core contributors ends - this vote should be held by the SOV Bitocracy. Under such a circumstance, MYNT token holders should hold a snapshot vote - of which the SOV Bitocracy should vote to uphold the majority view. It must be stressed that this cannot be guaranteed.”
29 |
30 | ## Specification
31 | 1. SIP Ratification: After the MYNT snapshot vote, per SIP-0037, an OwnerGovernor SIP will be proposed giving SOV Bitocracy the final say on the outcome of the proposal to sunset the MYNT token and bonding curve.
32 | 2. Orderly Wind-Down: Orderly wind-down of the MYNT token: deprecation of the MYNT token. The Mynt protocol is already governed by Bitocracy, and this state of affairs will be maintained. The wind-down mechanism specified in SIP-0037, stipulates that "to return the Mynt-bonded SOV to MYNT holders without having to adhere to the bonding curve formula". This procedure will be followed during the deprecation process - allowing MYNT tokens to be burned for SOV tokens on a fixed rate, pro rata basis.
33 |
34 | Communication Plan: A clear and concise communication plan will be put in place to ensure that all MYNT token holders and other stakeholders are kept informed of the progress of the deprecation process.
35 |
36 | ## Copyright
37 | Copyright and related rights waived via CC0.
38 |
--------------------------------------------------------------------------------
/SIP-0057.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 0057
3 | Title: Add Ordinal Doge Token ($oDOGE) to Sovryn AMM Pools
4 | Author: francis105d1 (@fjdone)
5 | Status: Rejected
6 | Track: Proclamation
7 | Created: 2023-03-15
8 | ---
9 |
10 | # SIP-0057: Add Ordinal Doge Token ($oDOGE) to Sovryn AMM Pools
11 |
12 | ## Proclamation text
13 |
14 | Add Ordinal Doge Token ($oDOGE) to Sovryn AMM Pools.
15 | Find the full description for this SIP:
16 |
17 | https://forum.sovryn.com/t/sip-0057-add-ordinal-doge-token-odoge-to-sovryn-amm-pools/2880/6
18 |
19 | Outline of SIP-0057 Proposal:
20 |
21 | Listing $oDOGE on Sovryn AMM. (*Possibly be renamed $SoDOGE for the Rootstock chain.) Paired with RBTC for launch so that $SoDOGE would be “ON Bitcoin”
22 |
23 | $oDOGE to seed the AMM with $50-$100k $oDOGE and $50-$100k RBTC (Bitcoin bridged to RSK through Sovryns FastBTC)
24 | The combined Sovryn and oDOGE communities will provide additional liquidity as trading begins.
25 | The $oDOGE community may withdraw the $oDOGE funds, but the minimum period before that will be possible is at least 12 months after the deposit (the oDOGE community has no motive for doing that, but it’s important to note either way).
26 | $oDOGE reserves the right to add any additional tokens to incentivize liquidity providers in the pools
27 |
28 | The $oDOGE team will provide initial liquidity to the pools, so there is no need for Sovryn to seed the liquidity. This will increase liquidity on the Sovryn protocol, increase $USD stables bridged in which will help to bolster the new $DLLR launch and will increase overall volume and trading fees for all Sovryn stakers. It creates another way to earn APY, and arbitrage any price differences between Uniswap, CEX, and our Sovryn Protocol.
29 |
30 | Motivation:
31 |
32 | For example increase trading volume and TVL on the Sovryn dApp. Find more also by visiting the following link
33 |
34 | https://docs.google.com/document/d/1c6WmkBXR7EXJxxITyXo1cBqtUJ3sbF4V4DT_KUfafK0/edit?usp=sharing
35 |
36 | ## Motivation for writing this proclamation
37 |
38 | To list oDoge tokens we still need some work to do but declaring that the Sovryn community wants to add oDoge to the list of traded assets in the Sovryn DEX is just the first step in that direction. We will still need to create probably a final SIP which will include the parameters that will allow for the AMM pool to last at least 12 months.
39 |
40 | If locking funds on the current AMM format that Sovryn uses or the way all AMM pools work on Sovryn have a locking option by default without having to create extra work for Sovryn developers it will mean this SIP will only need for Exchequer to just adhere to the will of the community, if no additional work is need to guarantee funds will remain lock for at least 365 days after the first day the AMM pool is up and working.
41 |
42 | ## License
43 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
44 |
--------------------------------------------------------------------------------
/SIP-0058.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0058'
3 | Title: Staking contract update
4 | Author: cowsant (@cwsnt), Ororo Monroe (@ororopickpocket), Tyrone Johnson (@tjcloa)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2023-03-17
8 | ---
9 |
10 | # SIP-0058: Staking contract update
11 |
12 | ## Description:
13 | After the latest investment round new vesting contracts with a duration of 4 years have been deployed. Because of the 3 year limitation on the staking contract, new contracts and a new deployment procedure needed to be developed. However, due to human mistake two steps of the process were executed in the wrong order. First, the tokens were staked and only afterwards the contracts were registered on the vesting registry. This led to incorrect accounting of the vesting stake on the staking contract, which has 2 consequences:
14 | 1. Some vesting contracts are not able to withdraw their stake.
15 | 2. The fee sharing contract considers the vesting contracts’ stakes as eligible for fee sharing, leading to lower fees for voluntary stakers. Nonetheless, the vesting contracts are not able to withdraw the fees because they are registered by now, effectively locking up the funds on the fee sharing contract.
16 |
17 | This SIP will allow us to add new vesting stake checkpoints for the dates with incorrect state. As a result the staking contract will allow the affected vesting contracts to withdraw their unlocked stake and also the fee sharing contract will read the correct vesting stake when writing checkpoints on distribution, leading to correct future fee distributions. Past fee distributions remain unchanged.
18 |
19 | We are also taking the opportunity to reintroduce the function `governanceWithdrawVesting` , which was used for canceling team vesting contracts in the past. SIP-0049 introduced the new method `cancelTeamVesting`, rendering the old function redundant. Babelfish, however, does still require `governanceWithdrawVesting`. This update allows Babelfish to keep using our staking contract code and go along with any updates we are introducing.
20 |
21 | ## Proposed changes:
22 | ### Code changes:
23 | * https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/492
24 | * https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/487
25 |
26 | ### Contracts updated:
27 | * StakingWithdrawModule: 0xf97c4751E4c75d28B600b0207519f2C71aA8902c
28 | * StakingVestingModule: 0x53C5C57302e7A6529C1A298B036426b944dC23Af
29 |
30 | ## License:
31 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
32 |
--------------------------------------------------------------------------------
/SIP-0059.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0059'
3 | Title: Zero Fee Floor Update, March 22
4 | Author: John Light (@john-light), Ororo Monroe (@ororopickpocket), Tyrone Johnson (@tjcloa)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2023-03-22
8 | ---
9 |
10 | # SIP-0059: Zero Fee Floor Update: March 22
11 |
12 | ## Background:
13 | On March 21’st, 2023, the community held the first DLLR Zero Risk Meeting. The recording and subsequent conversation can be found [here](https://www.youtube.com/watch?v=JRTM8yAlFAI).
14 | Our priorities, in order of importance, are:
15 | 1. Maintain the DLLR peg
16 | 2. Keep redemption level low
17 |
18 | In the near term we expect to see multiple DLLR demand drivers emerge. In the interim we are willing to accept significantly reduced borrowing demand. Conversely, to promote DLLR hoDLLRs, we seek to keep the lower bound of DLLR close to $1.00.
19 |
20 | The expectation is that the 5% base fee will be temporary and that fees will be reduced to the minimal advisable level over time.
21 |
22 | ## Resolved:
23 | 1. Increase the Origination fee - Base: 5%; Max 7.5%
24 | 2. Reduce the redemption fee - Base: 1.9%
25 |
26 | ## Code changes:
27 |
28 | Updating BORROWING_FEE_FLOOR from 2.5% to 5%
29 | Updating MAX_BORROWING_FEE to 7.5%
30 | Updating REDEMPTION_FEE_FLOOR from 2.5% to 1.9%
31 |
32 | ## License:
33 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
34 |
--------------------------------------------------------------------------------
/SIP-0060.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0060'
3 | Title: Add DLLR as collateral for borrowing
4 | Author: John Light (@john-light), Ororo Monroe (@ororopickpocket)
5 | Status: Approved
6 | Track: Parameter
7 | Created: 2023-04-06
8 | ---
9 |
10 | # SIP-0060: Add DLLR as collateral for borrowing
11 |
12 | ## Description
13 |
14 | If approved, this proposal would enable DLLR holders to use their DLLR as collateral when borrowing using Sovryn.
15 |
16 | ## Motivation
17 |
18 | Adding DLLR as a collateral asset for borrowing would give DLLR holders a way to short any supported asset using DLLR as collateral instead of either a less liquid stablecoin such as DOC or a less transparent stablecoin such as XUSD.
19 |
20 | A 150% collateralization ratio is proposed due to DLLR’s position as the most liquid pool on the Sovryn AMM. This is at par with the 150% collateralization required when using DOC or XUSD as collateral.
21 |
22 | ## Proposed change
23 |
24 | Add DLLR as system-wide collateral for borrowing supported assets on Sovryn, with the following parameters:
25 | - DLLR token contract address: `0xc1411567D2670E24D9c4Daaa7CdA95686E1250Aa`
26 | - Collateralization rate: 150%
27 | - Oracle: Constant value oracle
28 | - Supported assets: RBTC, BPRO
29 |
30 | ## License
31 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
32 |
--------------------------------------------------------------------------------
/SIP-0061.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0061'
3 | Title: Zero stability pool subsidies
4 | Author: cowsant (@cwsnt), Ororo Monroe (@ororopickpocket), Edan Yago (@YagoBit)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2023-04-27
8 | ---
9 |
10 | # SIP-0061: Zero stability pool subsidies
11 |
12 | ## Description
13 |
14 | If approved, this proposal will implement a Zero stability pool subsidies system with the following features:
15 | - A role “reward manager”. The reward manager role can be assigned to a Rootstock address using an OwnerGovernor proposal. The reward manager has the power to set an APR and price feed source for the subsidies system.
16 | - A subsidy pool that anyone can send SOV to.
17 |
18 | SOV will be allocated from the subsidy pool to stability pool depositors on a pro rata basis according to the set APR. The stability pool depositors will be able to immediately claim any SOV allocated to them by the subsidy pool.
19 |
20 | Example: If the set APR is 5%, and the balance of the stability pool is 1,000,000 ZUSD at the beginning of the day January 1st, and this balance does not change at all throughout the year, then by end of day December 31st of the same year the pool will have earned 50,000 ZUSD worth of SOV. (Note that in practice the algorithm will be able to handle changes in stability pool balances as needed. The example is made simple for ease of understanding.)
21 |
22 | These are the proposed initial parameters of the subsidy system:
23 |
24 | | Parameter | Value |
25 | | ---------- | ------------ |
26 | | Reward manager | 0x6c94c8aa97C08fC31fb06fbFDa90e1E09529FB13 |
27 | | SOV address | 0xEFc78fc7d48b64958315949279Ba181c2114ABBd |
28 | | APR | 5% |
29 | | Price Feed Source | SOV to RBTC: SOV AMM Pool Oracle , RBTC to ZUSD: Money On Chain USD oracle|
30 |
31 | ## Motivation
32 |
33 | Currently, there is no subsidy for depositing ZUSD into the Zero stability pool. This means that the incentive to deposit ZUSD into the stability pool is based completely on the returns earned from liquidations. Initial analysis has shown these returns to be relatively high, with [one estimate showing an APY of 127%](https://sovryn.com/all-things-sovryn/fishing-for-gains-in-the-zero-stability-pool). However this rate of return, and the frequency at which return events occur, is completely random, depending on volatility of the BTC market and the risk levels of Zero users.
34 |
35 | Zero users need a more reliable “sink” for ZUSD that can help absorb excess ZUSD supply, thereby mitigating some of the negative effects of excessive inflation such as redemptions for line of credit collateral. To this end we propose to introduce a subsidy for stability pool deposits that will pay a predictable rate of return in SOV. The SOV for this subsidy will be sourced from the [Adoption Fund](https://wiki.sovryn.com/en/technical-documents/tokenomics) to incentivize adoption of the stability pool and by extension, Zero and the Sovryn Dollar.
36 |
37 | ## For future consideration
38 |
39 | Instead of, or in addition to, paying for the subsidy using SOV from a steadily-diminishing Adoption Fund, the subsidy could be paid for using a portion of revenue earned from Zero and/or other parts of the Sovryn smart contract system that are earning fee revenue. This would require further discussion, development, and implementation as part of a future SIP.
40 |
41 | ## Proposed change
42 |
43 | New contracts:
44 | * Community Issuance Proxy: 0x9b38044A276fED8bC1703bd4a2DA1b17F2c61d16
45 | * Community Issuance Logic: 0x5059A057df377436Fc9b68369b696A23cc61Ecc3
46 | * Stability pool logic : 0x05a2dac59122f1dAcb7BB42b9736a8B27C12e193
47 |
48 | Proposed change: https://github.com/DistributedCollective/zero/pull/205
49 |
50 | ## License
51 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
52 |
53 |
--------------------------------------------------------------------------------
/SIP-0062.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0062'
3 | Title: Zero Fee Floor Update, May 12
4 | Author: Edan Yago (@YagoBit)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2023-05-12
8 | ---
9 |
10 | # SIP-0062: Zero Fee Floor Update, May 12
11 |
12 | ## Background:
13 | Following the [Zero Governance call](https://forum.sovryn.com/t/zero-governance-call-6/2961) held on May 10’th - there was clear consensus for the following recommendation to Bitocracy:
14 |
15 | - Maintain the Origination fee - Base: 5%; Max 7.5%
16 | - Reduce the redemption fee - Base: 1.0%
17 |
18 | ## Code changes:
19 |
20 | - Updating REDEMPTION_FEE_FLOOR from 1.9% to 1%
21 |
22 | ## License:
23 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
24 |
--------------------------------------------------------------------------------
/SIP-0063.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0063'
3 | Title: Fix Staking Bug to Prevent Reverting Delegated Voting Power
4 | Author: Tyrone Johnson (@tjcloa)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2023-05-26
8 | ---
9 |
10 | # SIP-0063: Fix Staking Bug to Prevent Reverting Delegated Voting Power
11 |
12 | ## Description
13 |
14 | The Staking contract has been paused to prevent malicious use of the information disclosed by this SIP.
15 |
16 | If approved, this proposal will upgrade the StakingStakeModule contract to an implementation that fixes the bug.
17 |
18 | ## Details
19 |
20 | A security researcher has reported a bug through Sovryn's Immunefi bug bounty program. The bug allows any address to revert any delegated voting power back to the delegator's address by staking any amount to the delegator's address. We have reproduced the bug and confirmed this is unintended behavior.
21 |
22 | ### Fix
23 |
24 | Add conditional check to [fix the vulnerability](https://github.com/DistributedCollective/Sovryn-smart-contracts/commit/e3b14b40c9c51fd8273f159b6c791fa14b462f3e)
25 |
26 | ## Proposed change
27 |
28 | Existing StakingStakeModule contract: 0xdf41bD1F610d0DBe9D990e3eb04fd983777f1966
29 | New StakingStakeModule: 0xDf7224A755a8cf59c6D30ECC1a1efDd83C46EE36
30 | Proposed changes: [PR#500](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/500)
31 |
32 | ## License
33 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
34 |
--------------------------------------------------------------------------------
/SIP-0064.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0064'
3 | Title: Remove Bridge Functions from Mynt
4 | Author: Tyrone Johnson (@tjcloa)
5 | Status: Defeated (no quorum)
6 | Track: Contract
7 | Created: 2023-06-07
8 | ---
9 |
10 | # SIP-0064: Remove Bridge Functions from Mynt
11 |
12 | ## Description
13 |
14 | There are two Mynt contract updates included in this SIP:
15 | - Removal of legacy code related to the Sovryn Bridge integration
16 | - Technical update of the contracts with the bytecode changed due to modified NatSpec comments
17 |
18 |
19 | ### 1) Removal of legacy bridges related code
20 |
21 | Mynt was initially cloned from Babelfish protocol as the basis for Sovryn DLLR BTC-based stablecoin.
22 |
23 | Babelfish uses bridges as trusted sources for conversions. However it was decided not to use the bridges in Mynt.
24 |
25 | To keep Mynt development on schedule, the bridge-related functionality was muted and unused, which created technical debt that we are paying back now with this SIP.
26 |
27 | Unused code in smart contracts not only causes confusion for reviewers and integrators but is also a potential source of bugs and vulnerabilities in the future.
28 |
29 | Following smart contract security best practices we have removed all the code related to bridge integration.
30 |
31 | ### 2) Technical upgrade
32 |
33 | Changes in OpenZeppelin (OZ) contract `Initializable` inherited by `FeesVault` and `MocIntegration` contracts: OZ package version upgrade to 4.8.3 among other fixes changed the NatSpec function comments, which are added by a solidity compiler as metadata to the bytecode of the FeesVault and MocIntegration contracts:
34 |
35 | 
36 |
37 |
38 | __If approved, this proposal will update the following Mynt contracts affected by the code cleanup: BasketManagerV3, MassetManager, FeesManager, FeesVault, and MocIntegration.__
39 |
40 | ## Proposed change
41 |
42 | __Existing logic contracts__
43 | BasketManagerV3: 0xb61Ff601E0b4531e39d9683c5Ab48873ccFd352B
44 | MassetManager: 0x90F16042abF49e3c08d7D37Aa5b8eDc439DF1D9d
45 | FeesManager: 0x1Cc0278c59577641E9fE38a0F698D15dA6CA47e4
46 | FeesVault: 0x0e87Fd4cF5C7e78ab0B1Cc2dEc31C2D34355D9f0
47 | MocIntegration: 0x68D06009d4DD7c189B9f5dF1D53aCffC5bF898aF
48 |
49 | __New logic contracts__
50 | BasketManagerV3: 0x4Ec09f11E667dd39E8751A07a74a2F90712Ef322
51 | MassetManager: 0x15e34a753854be868b6c99333964ae655c2bab4f
52 | FeesManager: 0xccCa715033DC18240bd30D4A99d084D3329e9B73
53 | FeesVault: 0x5ad2ef1259a1b65558f56738f73998597ef300e5
54 | MocIntegration: 0xb9d63f4ab03e92760d014c300c18b37783a5ac7e
55 |
56 | Proposed changes: Mynt [PR#13](https://github.com/DistributedCollective/mynt/pull/13)
57 |
58 | ## License
59 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
60 |
--------------------------------------------------------------------------------
/SIP-0065.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0065'
3 | Title: Permission update on the Adoption and Development Funds
4 | Author: Ororo (@ororopickpocket), Armando (@SovrynArmando)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2023-06-10
8 | ---
9 |
10 | # SIP-0065: Transfer of SOV from Adoption and Development Funds to Exchequer
11 |
12 | ## Description:
13 |
14 | The Adoption and Development Funds (collectively the “Funds”) have a predetermined vesting schedule. Once the SOV in the Funds vests, it becomes available for distribution with the goal of promoting the adoption of the Sovryn protocol and further its development. Deployment of a certain amount of vested SOV in these funds has been previously entrusted by Bitocracy to the Exchequer Committee following SIP-0015. As of June 12th, 2023, the SOV held in these Funds is divided as follows:
15 |
16 |
17 | | 20 | | 21 |Development Fund 22 | | 23 |Adoption Fund 24 | | 25 |Total 26 | | 27 |
| Starting Balance 30 | | 31 |8,368,598 32 | | 33 |37,222,239 34 | | 35 |45,590,837 36 | | 37 |
| Withdrawn To Date 40 | | 41 |2,231,626 42 | | 43 |9,925,930 44 | | 45 |12,157,556 46 | | 47 |
| Remaining Balance 50 | | 51 |6,136,972 52 | | 53 |27,296,309 54 | | 55 |33,433,281 56 | | 57 |
| Vested To Date 60 | | 61 |3,347,439 62 | | 63 |17,618,527 64 | | 65 |20,965,966 66 | | 67 |
| Remaining Vest 70 | | 71 |2,789,532 72 | | 73 |9,677,782 74 | | 75 |12,467,315 76 | | 77 |
| Period 87 | | 88 |Adoption Bounty 89 | | 90 |Bug Bounty 91 | | 92 |Contributor Bonus Grants 93 | | 94 |Contributor CompensationGrants 95 | | 96 |Development 97 | | 98 |Strategic Round 99 | | 100 |Grand Total 101 | | 102 |
| 2021 105 | | 106 |13339 107 | | 108 |3480 109 | | 110 |65602 111 | | 112 |319206 113 | | 114 |34473 115 | | 116 |436805 117 | | 118 |872904 119 | | 120 |
| Qtr1 123 | | 124 |689 125 | | 126 |127 | | 128 |129 | | 130 |9718 131 | | 132 |133 | | 134 |135 | | 136 |10407 137 | | 138 |
| Qtr2 141 | | 142 |143 | | 144 |110 145 | | 146 |30910 147 | | 148 |143005 149 | | 150 |16257 151 | | 152 |153 | | 154 |190281 155 | | 156 |
| Qtr3 159 | | 160 |12445 161 | | 162 |3315 163 | | 164 |34692 165 | | 166 |54500 167 | | 168 |14817 169 | | 170 |174304 171 | | 172 |294073 173 | | 174 |
| Qtr4 177 | | 178 |205 179 | | 180 |55 181 | | 182 |183 | | 184 |111983 185 | | 186 |3399 187 | | 188 |262502 189 | | 190 |378144 191 | | 192 |
| 2022 195 | | 196 |11925 197 | | 198 |24503 199 | | 200 |101448 201 | | 202 |950162 203 | | 204 |283161 205 | | 206 |716536 207 | | 208 |2087735 209 | | 210 |
| Qtr1 213 | | 214 |2278 215 | | 216 |2030 217 | | 218 |34782 219 | | 220 |191991 221 | | 222 |47484 223 | | 224 |250283 225 | | 226 |528848 227 | | 228 |
| Qtr2 231 | | 232 |1000 233 | | 234 |14710 235 | | 236 |66667 237 | | 238 |274017 239 | | 240 |55083 241 | | 242 |261456 243 | | 244 |672933 245 | | 246 |
| Qtr3 249 | | 250 |7346 251 | | 252 |7762 253 | | 254 |255 | | 256 |286005 257 | | 258 |108301 259 | | 260 |204798 261 | | 262 |614212 263 | | 264 |
| Qtr4 267 | | 268 |1300 269 | | 270 |271 | | 272 |273 | | 274 |198148 275 | | 276 |72293 277 | | 278 |279 | | 280 |271742 281 | | 282 |
| 2023 285 | | 286 |500 287 | | 288 |310653 289 | | 290 |291 | | 292 |309698 293 | | 294 |295 | | 296 |297 | | 298 |620851 299 | | 300 |
| Qtr1 303 | | 304 |305 | | 306 |286377 307 | | 308 |309 | | 310 |182078 311 | | 312 |313 | | 314 |315 | | 316 |468454 317 | | 318 |
| Qtr2 321 | | 322 |500 323 | | 324 |24277 325 | | 326 |327 | | 328 |127620 329 | | 330 |331 | | 332 |333 | | 334 |152397 335 | | 336 |
| Grand Total 340 | | 341 |25764 342 | | 343 |338636 344 | | 345 |167050 346 | | 347 |1579066 348 | | 349 |317634 350 | | 351 |1153342 352 | | 353 |3581491 354 | | 355 |
36 |
37 |
38 | __If approved, this proposal will update the following Mynt contracts affected by the code cleanup: BasketManagerV3, MassetManager, FeesManager, FeesVault, and MocIntegration.__
39 |
40 | ## Proposed change
41 |
42 | __Existing logic contracts__
43 | BasketManagerV3: 0xb61Ff601E0b4531e39d9683c5Ab48873ccFd352B
44 | MassetManager: 0x90F16042abF49e3c08d7D37Aa5b8eDc439DF1D9d
45 | FeesManager: 0x1Cc0278c59577641E9fE38a0F698D15dA6CA47e4
46 | FeesVault: 0x0e87Fd4cF5C7e78ab0B1Cc2dEc31C2D34355D9f0
47 | MocIntegration: 0x68D06009d4DD7c189B9f5dF1D53aCffC5bF898aF
48 |
49 | __New logic contracts__
50 | BasketManagerV3: 0x4Ec09f11E667dd39E8751A07a74a2F90712Ef322
51 | MassetManager: 0x15e34a753854be868b6c99333964ae655c2bab4f
52 | FeesManager: 0xccCa715033DC18240bd30D4A99d084D3329e9B73
53 | FeesVault: 0x5ad2ef1259a1b65558f56738f73998597ef300e5
54 | MocIntegration: 0xb9d63f4ab03e92760d014c300c18b37783a5ac7e
55 |
56 | Proposed changes: Mynt [PR#13](https://github.com/DistributedCollective/mynt/pull/13)
57 |
58 | ## License
59 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
60 |
--------------------------------------------------------------------------------
/SIP-0073.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0073'
3 | Title: Refactor Sovryn Protocol Interface with AMM
4 | Author: Ororo (@ororopickpocket), Tyrone Johnson (@tjcloa)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2023-12-12
8 | ---
9 |
10 | # SIP-0073: Refactor Sovryn Protocol Interface with AMM
11 |
12 | ## Issue
13 |
14 | The contract SwapsImplSovrynSwap serves as an interface between Sovryn protocol functionality and the Sovryn AMM to swap assets and query exchange rates.
15 | The way it is implemented is confusing and error prone because in some cases it is used as a standalone contract with its own storage and sometimes as a library executing delegated calls from the protocol modules and using its storage.
16 | Because AMM swaps and exchange rates queries are used by every protocol module - it is is a crucial part of our codebase which requires refactoring to improve robustness and clarity of our codebase, for both internal usage and external integrations implicitly improving security.
17 |
18 | ## Solution
19 |
20 | We refactored the SwapsImplSovrynSwap by converting it into a Sovryn protocol module SwapsImplSovrynSwapModule and extracting all the AMM integration functions into a library which increases the robustnessness and clarity of the AMM interface.
21 |
22 | __If approved, this proposal will update all the Sovryn protocol modules and add a new SwapsImplSovrynSwapModule.__
23 |
24 | ## Proposed change
25 |
26 | __Existing Sovryn protocol module contracts__
27 | |Contract|Address|
28 | |---|---|
29 | | Affiliates | 0xb756218F36179e26102f7b485aa43031861f5D49 |
30 | | LoanClosingsLiquidation | 0x2d7b3c5B4985A5dA5059AF1466c3FF2fbff4c0A8 |
31 | | LoanClosingsRollover | 0xc424d620bCB1e62D6A3353D6dc6D626b720f1D52 |
32 | | LoanClosingsWith | 0x88500b472a245a937D07c53B22a107Ce1901d30f |
33 | | LoanOpenings | 0x78145b66Ee07365CDCf9D79B74100950C641Ba42 |
34 | | LoanMaintenance | 0xf5Cb98bEAe74506Fafe4f5824C144bC7907869b0 |
35 | | LoanSettings | 0xab39152B4F3553c28b1b50031D654c83b10BAFc1 |
36 | | ProtocolSettings | 0xC7F237bC38356D7a5bad5C16502537658b9610DB |
37 | | SwapsExternal | 0x4010bc8A340fB7f9C98053cA2031631c9E575195 |
38 |
39 | __New Sovryn protocol module contracts__
40 | |Contract|Address|
41 | |---|---|
42 | | Affiliates | 0x83a167A96e73c35C0EdF7bC26a6041f3a62004D3 |
43 | | LoanClosingsLiquidation | 0xdC74C456457d769399e8DA8b49500E31E5b223Df |
44 | | LoanClosingsRollover | 0x2add8EfebD9477222784468f63F27e4cf6B7A8Ea |
45 | | LoanClosingsWith | 0xa9a268388D5c317E5F3EBd7C8e8E6c48a0BaFC9A |
46 | | LoanOpenings | 0x7b520c4BDB4527A2c1cA8E24c245660df9636b22 |
47 | | LoanMaintenance | 0x4BC462e2c8D106511D8e7985b05A52fD8b726464 |
48 | | LoanSettings | 0xABA8f49e4EDbd95ccd593ED37b86a5716Fde2bED |
49 | | ProtocolSettings | 0x93B1F35d9c9F5abED48E44782D58A6804B967Ee3 |
50 | | SwapsExternal | 0xBba834823b3351359A89f548504a11a601a6eD42 |
51 | | SwapsImplSovrynSwapModule | 0x8104682DF8309c5Fae7C2cB2F457a2878290e2Ac |
52 |
53 | Proposed changes: [PR#530](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/530)
54 |
55 | ## License
56 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
57 |
--------------------------------------------------------------------------------
/SIP-0074.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0074'
3 | Title: Smart Contracts Upgrade Electron
4 | Author: Tyrone Johnson (@tjcloa)
5 | Status: Ready for vote
6 | Track: Contract
7 | Created: 2024-01-16
8 | ---
9 |
10 | # SIP-0074: Smart Contracts Upgrade Electron
11 |
12 | ## Description
13 |
14 | ### This upgrade includes solution of the following issues
15 |
16 | 1. **Increase Borrowing Debt Bug: Unable to use existing excessive collateral for borrowing**
17 | When users attempt to borrow more on an existing loan using the collateral of that loan, the calculation for collateral sufficiency is incorrect.
18 | This results in users being unable to borrow a fair amount, only a fraction at best.
19 |
20 | **Solution:** The bug is resolved with [PR#520](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/520).
21 |
22 | 3. **VestingLogic Contract Refactoring: Removal of vestings cancelling & allowance for partial withdrawal**
23 | 3.1. A legacy and unnecessary Team Vesting cancelling function in the VestingLogic contract has been a source of confusion
24 | and it has already been optimized by moving it to the Staking contract.
25 | _The function is removed from the VestingLogic contract._
26 | 3.2. Vesting contracts with more than 44 unlocked periods are deadlocked due to a block gas limit issue.
27 | _A new function is introduced to allow withdrawals of unlocked amounts in chunks._
28 |
29 | **Solution:** Resolved in the Sovryn-smart-contracts repository [PR#529](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/529).
30 |
31 | 5. **EIP-2612 Bug in DLLR Function transferWithPermit: Extracting from a transaction and front-running permit causes the transaction failure**
32 | This vulnerability was reported by a researcher in the Immunefi Bug Bounty Program.
33 | Mynt DLLR contract function `transferWithPermit` is vulnerable to a griefing attack. An attacker can extract permit parameters from a transaction in the mempool
34 | and front run its execution before the transaction, causing it to fail because its nonce is already used for this permission by the attacker.
35 | The DLLR contract is not upgradable, but a workaround has been found - use a Uniswap [Permit2](https://github.com/Uniswap/permit2) contract which enables any ERC-20 token with EIP-2612 Permit functionality.
36 | All affected contracts depending on the `transferWithPermit` function in Mynt and zero-contracts repositories are to be upgraded.
37 |
38 | **Solution:**
39 | Mynt: [PR#18](https://github.com/DistributedCollective/mynt/pull/18).
40 | zero-contracts: [PR#3](https://github.com/DistributedCollective/zero-contracts/pull/3).
41 |
42 | 6. **Aggregating PR#535**
43 | This [pull request](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/535) includes a script for SIP creation and deployment data for all new contracts from the pull requests included in this upgrade, necessary for executing the SIP upgrade.
44 |
45 | __If approved, this proposal will upgrade the following contracts__
46 |
47 | __Existing contracts__
48 | | Contract | Address |
49 | | -------------------------------------- | ------------------------------------------ |
50 | | Mynt MocIntegration logic contract | 0x9363323D9c653a2b89C758f62f5043f0B2c67C71 |
51 | | Zero StabilityPool logic contract | 0x05a2dac59122f1dAcb7BB42b9736a8B27C12e193 |
52 | | Zero TroveManager logic contract | 0xF365CC004d4c3826b53B943f5fc7B8aec6e43341 |
53 | | Zero TroveManagerRedeemOps contract | 0xd4CE65a6DB60BeDD51c499b716969d57998Cd941 |
54 | | Zero BorrowerOperations logic contract | 0x6dafc71f49f9aa25325126dd9fec426624afb878 |
55 | | Protocol module contract LoanOpenings | 0x7b520c4BDB4527A2c1cA8E24c245660df9636b22 |
56 | | VestingLogic contract | 0x648Ff0C537A10414b8aFa92Fe1D40aBD4DB2479b |
57 | | VestingFactory contract | 0x2399b527b9966774c99ad600af104CcD320325B6 |
58 |
59 |
60 |
61 | __New contracts__
62 | | Contract | Address |
63 | | -------------------------------------- | ------------------------------------------ |
64 | | Mynt MocIntegration logic contract | 0x454E8deBBf6900036372407a23E1d0284Be3f12A |
65 | | Zero StabilityPool logic contract | 0x2a1950a06AD5C5113e44721820305645d671eC4F |
66 | | Zero TroveManager logic contract | 0x3d841398AcA5794b9da2f2573F473075417a0117 |
67 | | Zero TroveManagerRedeemOps contract | 0xa4161D23002e110b3d5C430EfAfF299415074c67 |
68 | | Zero BorrowerOperations logic contract | 0xD603B4c5F7BF13a2AA510F2c625546dB4138D330 |
69 | | Protocol module contract LoanOpenings | 0x000fec34466972987928d519948AA1b25EACD3E9 |
70 | | VestingLogic contract | 0x8bFf9023495ed689f2362CCc45Bfe61ba299e90F |
71 | | VestingFactory contract | 0x4DfA9759E1Ff3B7F8055a84e3fd76dF6F57BaEf1 |
72 |
73 |
74 | ## License
75 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
76 |
--------------------------------------------------------------------------------
/SIP-0075.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 0075
3 | Title: Reduce Zero Origination Fee
4 | Author: Sacro21
5 | Status: Ready for vote
6 | Track: Parameter
7 | Created: 2024-01-27
8 | ---
9 |
10 | # SIP-0075: Reduce Zero Origination Fee
11 |
12 | ## Summary
13 |
14 | If approved, this proposal will reduce ZUSD origination fee floor in the Sovryn Zero protocol from 13% to 8%.
15 |
16 | ## Background
17 |
18 | Six months ago, the origination fee floor of Zero Protocol was raised to 99% with SIP-0066.
19 | Essentially, Bitocracy paused the minting of ZUSD by setting extremely high fees to maintain the DLLR peg.
20 | Two months ago, Zero was "reopened" by setting the origination fee to 13% with SIP-0071. This fee was deliberately set quite high in order to cautiously ramp up the system again and achieve the assumed balance between supply and demand for $DLLR.
21 |
22 | Since then several key observations were made:
23 | • The total supply of ZUSD decreased from approximately 6.69 million (start SIP-0066) to 4.58 million (start SIP-0071) to 3.85 million (now).
24 | • Numbers of LoC’s declined from 150 (start SIP-0066) to 88 (start SIP-0071) to 83 (now).
25 | • The total collateral ratio increased from around 372% (SIP-0066) to 530% (SIP-0071) to 604% (now).
26 | • From SIP-0066 to SIP-0071 (8/23-12/23), Zero fee revenue was 15k USD. Since SIP-0071 (01/24) (total Zero fee revenue is 34k USD).
27 |
28 | ## Motivation
29 |
30 | Despite reopening Zero, we can still see a decline in the metrics shown above.
31 | Large parts of the excess ZUSD supply has been removed.
32 | The current 10% interest rate of DLLR lending pool also indicates strong demand.
33 | Therefore, we believe it is a good time to make Zero more accessible and to increase protocol revenue.
34 | Individual users should make sure they understand the system and specifically, redemptions.
35 | If significantly more redemptions occur than expected, Sovryn can also use the increased revenue as a safety mechanism to incentivize the holding of $DLLR via $SOV rewards.
36 |
37 | ## Proposed changes
38 |
39 | If approved, the origination fee will fluctuate between 8% and 100%.
40 | The following change will be made to the Zero Protocol base parameters:
41 |
42 | - Updating "BORROWING_FEE_FLOOR" from 13% to 8% by calling \`setBorrowingFeeFloor(uint256)\`
43 | on the \`0xf8B04A36c36d5DbD1a9Fe7B74897c609d6A17aa2\` contract
44 | with the encoded data \`0x000000000000000000000000000000000000000000000000011c37937e080000\`.
45 |
46 | ## License
47 |
48 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
49 |
--------------------------------------------------------------------------------
/SIP-0076.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0076'
3 | Title: Transfer of SOV from Adoption and Development Funds to Exchequer
4 | Author: Armando (@SovrynArmando)
5 | Status: Draft
6 | Track: Contract
7 | Created: 2024-02-07
8 | ---
9 |
10 | # **SIP-0076: Transfer of SOV from Adoption and Development Funds to Exchequer**
11 |
12 | ## Description:
13 |
14 | The Adoption and Development Funds (collectively the "Funds") have a predetermined vesting schedule. Once the SOV in the Funds vests, it becomes available for distribution with the goal of promoting the adoption of the Sovryn protocol and further its development. Deployment of a certain amount of vested SOV in these funds has been previously entrusted by Bitocracy to the Exchequer Committee following SIP-0015 and SIP-0065. As of February 1st, 2024, the SOV held in these Funds is divided as follows:
15 |
16 |
17 | | | Development Fund | Adoption Fund | Total |
18 | | ----------------- | ---------------- | ------------- | ---------- |
19 | | Starting Balance | 8,368,598 | 37,222,239 | 45,590,837 |
20 | | Withdrawn To Date | 4,231,626 | 10,925,931 | 15,157,557 |
21 | | Remaining Balance | 4,136,972 | 26,296,308 | 30,433,280 |
22 | | Vested To Date | 2,463,252 | 21,085,196 | 23,548,448 |
23 | | Remaining Vest | 1,673,720 | 5,211,112 | 6,884,832 |
24 |
25 | This SIP will approve the transfer of a total of 9,125,500 vested SOV from the Funds to the Exchequer to facilitate the ongoing development and adoption of the Sovryn protocol. It is expected that the SOV transferred as part of this SIP will be reserved in the following amounts and for the following uses:
26 |
27 | - **1M SOV - Market Maker liquidity, exchange listings**. This allocation will be dedicated to expanding SOV markets, improving trading conditions, and securing additional exchange listings.
28 | - **5.12M SOV - SOV rewards**. This includes staking rewards, LM rewards (which have been reduced over the course of 2023), and to support a more robust Bitocracy and expansion on to additional chains.
29 | - **2M SOV - Non-programmatic distributions.** This allocation will be reserved for collaboration with partners, contributor distributions, bug bounties and adoption bounties. It is expected that this bucket of distributions will be 30% lower than 2023.
30 | - **1M SOV - Reserve**
31 |
32 | Use cases and amounts might change and will be at the discretion of the Exchequer.
33 |
34 | For reference, below is the breakdown of all previous SOV distributions made by Exchequer by year and by type.
35 |
36 | ### Summary of Total SOV Distributions
37 |
38 | | **Source** | **2021** | **2022** | **2023** | **Claimed** | **Supplied** |
39 | | --------------------------------- | ------------- | -------------- | -------------- | -------------- | -------------- |
40 | | **Available for Distributions\*** | **7,741,307** | **15,838,571** | **11,829,032** | **-** | **-** |
41 | | Programmatic Distributions | 2,231,272 | 3,186,850 | 2,545,916 | 7,964,038 | 9,188,092 |
42 | | Non-Programmatic Distributions | 872,904 | 2,126,624 | 3,017,406 | 6,016,935 | 6,157,121 |
43 | | **Total Distributions** | **3,104,177** | **5,313,474** | **5,563,322** | **13,980,973** | **15,345,213** |
44 | | Remaining Balance | **4,637,130** | **10,525,097** | **6,265,710** | - | - |
45 | | Remaining Balance (%) | **60%** | **66%** | **53%** | - | - |
46 |
47 | _\* Available in the Adoption and Development Funds as per the SOV Emission Schedule at TGE. https://shorturl.at/ekrtE_
48 |
49 | ### Summary of Programmatic SOV Distributions
50 |
51 | | ***Type*** | ***2021*** | ***2022*** | ***2023*** | ***Claimed*** | ***Supplied*** | ***% (Total)*** |
52 | | ------------------ | --------------- | --------------- | --------------- | --------------- | --------------- | --------------- |
53 | | _LiquidityMining_ | _2,176,942_ | _2,838,868_ | _1,876,431_ | _6,892,241_ | _7,676,092_ | _84%_ |
54 | | _Staking_ | _54,330_ | _347,982_ | _645,428_ | _1,047,740_ | _1,462,000_ | _16%_ |
55 | | _ZeroSP Subsidies_ | _-_ | _-_ | _24,057_ | _24,057_ | _50,000_ | _0%_ |
56 | | ***Total*** | ***2,231,272*** | ***3,186,850*** | ***2,945,916*** | ***7,964,038*** | ***9,188,092*** | ***100%*** |
57 |
58 | ### Summary of Non-Programmatic SOV Distributions
59 |
60 | | **Type** | **2021** | **2022** | **2023** | **Claimed** | **Supplied** | **% (Total)** |
61 | | ------------------ | ----------- | ------------- | ------------- | ------------- | ------------- | ------------- |
62 | | Contributor Bonus | 65,602 | 101,468 | 1,890,000 | 2,057,050 | 2,057,070 | 33% |
63 | | Contributor Comp | 319,206 | 989,051 | 705,926 | 2,014,182 | 2,014,182 | 33% |
64 | | Strategic Round | 436,805 | 716,536 | 0 | 1,153,342 | 1,293,528 | 21% |
65 | | Bug Bounty | 3,480 | 24,053 | 420,980 | 448,962 | 448,962 | 7% |
66 | | Development Bounty | 34,473 | 283,161 | 317,634 | 317,634 | 317,634 | 5% |
67 | | Adoption Bounty | 13,339 | 11,925 | 500 | 25,764 | 25,764 | 0% |
68 | | **Total** | **872,904** | **2,126,644** | **3,017,406** | **6,016,935** | **6,157,121** | **100%** |
69 |
70 | ## **Proposed Changes:**
71 |
72 | - Transfer a total of 7,475,000 SOV from the adoption fund contract (0x0f31cfd6aAb4d378668Ad74DeFa89d3f4DB26633) to the Exchequer multisig address (0x924f5ad34698Fd20c90Fe5D5A8A0abd3b42dc711).
73 | - Transfer a total of 1,650,500 SOV from the development fund contract (0x617866cC4a089c3653ddC31a618b078291839AeB) to the Exchequer multisig address (0x924f5ad34698Fd20c90Fe5D5A8A0abd3b42dc711).
74 |
75 | ## License
76 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
77 |
--------------------------------------------------------------------------------
/SIP-0077.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0077'
3 | Title: Enhancement of Staking Rewards and Governance Mechanisms in Anticipation of BitcoinOS
4 | Author: Yago (@YagoBit)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2024-02-04
8 | ---
9 |
10 | # **SIP-0077: Enhancement of Staking Rewards and Governance Mechanisms in Anticipation of BitcoinOS**
11 |
12 | ## 1. Abstract
13 | This SIP proposes enhanced SOV yield to the Bitocracy rewards mechanism and governance structures in anticipation of the deployment of BitcoinOS products and the expansion of the Sovryn dApp Suite across more Bitcoin-related chains. The aim is to align incentives, enhance security, and prepare for a truly Bitcoin-native ecosystem with minimized trust assumptions outside Bitcoin.
14 | ## 2. Motivation
15 | As Sovryn expands its deployment across multiple chains and prepares for the introduction of BitcoinOS, there's a need for revised Bitcocracy participation rewards structures and incentive models. This SIP addresses the complexities of anticipating incentive changes in light of cross-chain activities, the possible reissuance of canonical SOV tokens within BitcoinOS, and the need for increased participation in governance and security of the system through Sovryn Phase Two: Infrastructure.
16 |
17 | In particular, this SIP seeks to preempt and counter three identified potential sources of misalignment:
18 | 1. **Reduced Focus on Rootstock Bitocracy**: The risk of “shiny new thing syndrome” could lead to reduced participation in Rootstock Bitocracy. We seek to avoid this by providing clear assurances of RSK Bitocracy’s continued relevance and equivalent potential rewards. Additionally, we seek to provide Rootstock Bitocracy stakeholders with a head start, befitting their earlier participation.
19 | 2. **Reduced Security and Network Participation**: Staking rewards and incentives are critical for maintaining the security and robustness of blockchain networks. Without introducing the SIP, the ecosystem might face challenges in attracting and retaining validators or stakers, which could compromise network security and performance.
20 | 3. **Slower Adoption and Growth**: Incentives play a significant role in encouraging the adoption of new technologies and platforms. The absence of a well-structured incentive mechanism through the SIP could slow down the adoption rate of the Sovryn DApp Suite and BitcoinOS rollups, hindering the project's growth and expansion goals.
21 |
22 | ## 3. Specification
23 | 1. **Introduction of SOV Rewards on Rootstock**: Stakers on Rootstock will begin earning SOV as part of the staking rewards, enhancing the incentives for participation within the ecosystem.
24 | 2. **Reward Competitiveness**: The SOV rewards for stakers on Rootstock will be designed to be equal to or higher than those available on any other platform, ensuring Rootstock remains the most attractive venue for staking.
25 | 3. **Starting Return Rate**: The max SOV reward rate will be set at 9% for max stakers, providing a clear and competitive return for those committing to the ecosystem for longer durations. This will be in addition, and supplementary to, rewards earned from protocol fees in BTC and other tokens.
26 | 4. **Non-Transferability of Rewards**: Initially, the rewards in the form of SOV will be non-transferable. This measure is in place until the reissuance of SOV occurs, ensuring a controlled distribution and utilization of rewards within the system.
27 | 5. **Reissuance and Liquidity of SOV**: Upon the canonical reissuance of SOV, the earned rewards will become liquid and transferable on the new canonical registry. This will allow for their transfer, exchange and usage within the BitcoinOS system. No newly reissued SOV tokens will be made liquid earlier, ensuring prioritization of ‘legacy’ Bitocracy stakers.
28 |
29 | ## 4. Rationale
30 | The proposed changes are designed to secure the system's integrity during a critical expansion phase, reduce uncertainties associated with cross-chain deployments, and ensure that the Sovryn ecosystem remains attractive and secure for both current and future stakeholders. By providing clear incentives for early and sustained participation, this SIP aims to bolster the project's governance and security, while preparing for a seamless transition to a Bitcoin-native environment.
31 |
32 | ## 5. Technical Specification
33 | This SIP will make use of the SIP 24 codebase with minor modification.
34 |
35 | ## 6. Implementation
36 | PR: https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/536
37 |
38 | ## 7. Security Considerations
39 | Enhanced staking rewards and decentralized governance mechanisms are designed to improve system security and resilience.
40 | The proposal includes measures to mitigate risks associated with cross-chain activities and token reissuance.
41 | Further analysis and community input will be sought to address any additional security concerns.
42 |
43 | ## License
44 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
45 |
--------------------------------------------------------------------------------
/SIP-0078.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0078'
3 | Title: Proposal for Sovryn to Launch on BOB Chain
4 | Author: Alexei Zamyatin (@alexeiZamyatin)
5 | Status: Approved
6 | Track: Other
7 | Created: 2024-03-08
8 | ---
9 |
10 | # **SIP-0078: Proposal for Sovryn to Launch on BOB Chain**
11 |
12 | ## Summary
13 |
14 | This SIP proposes the integration of Sovryn, the leading Bitcoin DeFi project, onto the BOB (Build on Bitcoin) chain, a new hybrid L2 between Bitcoin and Ethereum. By leveraging the Ethereum ecosystem’s rich functionalities and bringing Sovryn’s best-in-class Bitcoin DeFi suite to a larger market, this collaboration aims to catalyze a significant migration of users and capital from Ethereum and the wider crypto economy back to Bitcoin, capturing a massive market opportunity.
15 |
16 | The partnership between Sovryn and BOB will serve as the conduit for this movement, providing users with enhanced UI, functionality, and rewards, while simultaneously expanding Bitcoin’s reach within the DeFi space.
17 |
18 | ## Background
19 |
20 | Sovryn has established itself as a pioneering force in the realm of Bitcoin DeFi, offering users a comprehensive suite of decentralized financial services tailored specifically for Bitcoin holders. However, to further extend Sovryn’s reach and solidify its position as the premier Bitcoin DeFi project, it is imperative to integrate with platforms that can facilitate seamless interaction with the broader crypto ecosystem. BOB is the first Bitcoin L2 with full EVM compatibility & native Bitcoin support empowering everyone to build and innovate on Bitcoin. The BOB chain presents an ideal opportunity in this regard, offering a Bitcoin-centric environment while leveraging Ethereum’s extensive toolkit for enhanced functionality.
21 |
22 | ## About BOB
23 |
24 | BOB ("Build on Bitcoin") is a first-of-its kind hybrid L2 network that connects Bitcoin and Ethereum. BOB empowers everyone to build and innovate on Bitcoin today by combining EVM smart contracts with tooling for Bitcoin-native protocols and assets such as Ordinals. Merging the security of Ethereum rollup technology with Bitcoin’s Proof-of-Work makes BOB the most secure and reliable layer 2 network. Through trust-minimized bridges to both Ethereum and Bitcoin, BOB efficiently funnels liquidity from the two leading web3 economies.
25 |
26 | ## Motivation
27 |
28 | ### Benefits to Sovryn
29 |
30 | - **Expansion of Market Reach:** Integrating Sovryn onto the BOB chain will enable access to Ethereum’s vast user base of over 1 million active users, representing a largely untapped market for Bitcoin DeFi services. This expansion of market reach presents a substantial economic opportunity for Sovryn to capture a significant portion of the rapidly growing Bitcoin DeFi market, projected to reach $100 billion.
31 |
32 | - **Enhanced UI and Functionality:** By tapping into Ethereum’s rich ecosystem, Sovryn can leverage advanced UI/UX designs and incorporate innovative functionalities to enhance user experience.
33 |
34 | - **Strengthened Leadership Position:** Establishing Sovryn on BOB reinforces its status as the leading Bitcoin DeFi project, further solidifying its position within the DeFi landscape.
35 |
36 | - **Strategic Partnership:** Sovryn’s collaboration with BOB signifies a commitment to fostering interoperability within the Bitcoin and Ethereum ecosystems, paving the way for future synergistic developments.
37 |
38 | ### Benefits to Bitcoin
39 |
40 | - **Massive User Acquisition:** Integrating Sovryn onto BOB brings a substantial influx of Ethereum users into the Bitcoin ecosystem, contributing to the growth of Bitcoin’s user base.
41 |
42 | - **Increased Utility for Bitcoin:** By providing Ethereum users with access to Bitcoin DeFi through Sovryn on BOB, Bitcoin’s utility is expanded, offering more opportunities for users to utilize their Bitcoin holdings in DeFi applications.
43 |
44 | ## Implementation
45 |
46 | ### Technical Integration
47 |
48 | The technical integration of Sovryn onto the BOB chain will involve adapting Sovryn’s smart contracts and interfaces to seamlessly interact with the BOB chain’s infrastructure. This will require collaboration between the development teams of Sovryn and BOB to ensure compatibility and smooth operation. BOB’s fully EVM-compatible programming layer (OP stack) thereby enables a smooth transition.
49 |
50 | ### Partnership Commitments
51 |
52 | As part of the partnership agreement, BOB commits to supporting Sovryn, as an early adopter of BOB, with user acquisition achieved by, including but not limited to, future ecosystem growth and incentive programs.
53 |
54 | ## Conclusion
55 |
56 | The integration of Sovryn onto the BOB chain marks the beginning of a transformative journey for Bitcoin DeFi. Being the first to market with this groundbreaking integration, Sovryn and BOB are poised to capture a significant portion of the multi-billion dollar DeFi market, positioning themselves as the leaders in facilitating the migration of users and capital back to Bitcoin.
57 |
58 | By leveraging Ethereum’s expansive ecosystem and tapping into a vast pool of Ethereum users, Sovryn and BOB will spearhead a significant migration of users and capital from Ethereum and the wider crypto economy back to Bitcoin. Together, Sovryn and BOB will serve as the conduit for this movement, ushering in a new era of interoperability and collaboration between the Bitcoin and Ethereum ecosystems.
59 |
60 | ## License
61 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
62 |
--------------------------------------------------------------------------------
/SIP-0079.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0079'
3 | Title: Transfer of SOV from Adoption Fund to Exchequer Build on Bitcoin Mainnet
4 | Author: Armando (@SovrynArmando)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2024-03-22
8 | ---
9 |
10 | # **SIP-0079: Transfer of SOV from Adoption Fund to Exchequer Build on Bitcoin Mainnet**
11 |
12 | ## Background
13 | Pursuant to the successful approval of SIP-0078, Sovryn will be launching on BOB (Build on Bitcoin), once mainnet is available. As part of BOB’s launch, they will be providing certain rewards for funds that are pre-deposited in a timelock contract prior to mainnet launch (the “BOB Timelock Contract”). They announced this campaign today and some details can be found [here](https://twitter.com/build_on_bob/status/1771175967060373631).
14 |
15 | ## Description
16 | The Adoption Fund is designated to be used to further promote the Sovryn protocol and increase awareness and adoption.
17 | The Adoption Fund currently holds 13,827,325.41 SOV which is available for withdrawal and which is no longer subject to the Adoption Fund vesting schedule (as of March 21, 2024).
18 | This SIP proposes that a total of 13,800,000 SOV be transferred to the Exchequer for the purpose of pre-depositing these funds into the BOB Timelock Contract, for the duration of the timelock. Once the timelock period is complete, and the SOV deposited has met all the requirements to receive the corresponding rewards, the SOV will be returned to the Adoption Fund as soon as technically possible.
19 |
20 | The rewards generated by this pre-deposit will be used to incentivize users to provide liquidity to Sovryn’s AMMs launched on BOB.
21 |
22 | ## Risks
23 | The BOB Timelock Contract is managed by the BOB team, and grants them control over the funds deposited therein. Despite the fact that the Sovryn team has reviewed this contract, there is always the risk of an exploit or misuse of the funds in the contract, which can result in the loss of deposited funds. This risk is mitigated by the fact that the SOV deposited into the BOB Timelock Contract will be SOV bridged to Ethereum (eSOV) and in the event of a loss of funds, the bridged assets can be cancelled and the original SOV (on Rootstock) will not be affected.
24 |
25 | ## Proposed Changes
26 | Transfer a total of 13,800,000 SOV from the adoption fund contract (0x0f31cfd6aAb4d378668Ad74DeFa89d3f4DB26633) to the Exchequer multisig address (0x924f5ad34698Fd20c90Fe5D5A8A0abd3b42dc711)
27 |
28 | ## License
29 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
30 |
--------------------------------------------------------------------------------
/SIP-0080.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 0080
3 | Title: Zero Protocol Redemption Page
4 | Author: capitalist42
5 | Status: Defeated
6 | Track: Proclamation
7 | Created: 2024-06-19
8 | ---
9 |
10 | SIP-0080: Zero Protocol Redemption Page
11 |
12 | ## Proclamation text
13 |
14 | Sovryn web application (reference deployment) should always include UI option for average users to redeem their ZUSD/DLLR via Zero Protocol.
15 |
16 | ## Motivation for writing this proclamation
17 |
18 | The Zero Protocol redemption page UI was removed in an effort to reduce redemptions. However, redemptions still happen. Most of the redemptions were executed by the arbitragers who have direct access to the smart contract. To live by the standard of "you don't have to be technical to be free", all Sovryn users should have equal access to the redemption feature of the Zero Protocol.
19 |
20 |
21 | ## License
22 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
23 |
--------------------------------------------------------------------------------
/SIP-0081.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0081'
3 | Title: Burning Unclaimed and Unallocated POWA Runes
4 | Author: Hyde
5 | Status: Ready for vote
6 | Track: Other
7 | Created: 2024-07-05
8 | ---
9 |
10 | # **SIP-0081: Burning Unclaimed and Unallocated POWA Runes**
11 |
12 | ## Background
13 |
14 | More than 35% of POWA is yet unclaimed, more than 60 days after launch. We propose to burn it all.
15 |
16 | The POWA Rune token was introduced in the 2024 halving block to symbolize individual sovereignty and empowerment. The distribution of POWA tokens was based on the points accumulated during the POWA Campaign, which rewarded users for staking, trading, and influence activities within the Sovryn ecosystem. As part of the ongoing commitment to maintain the value and integrity of the POWA token, it is essential to address the unclaimed and unallocated (for which users have not provided their addresses) tokens.
17 |
18 | Token Allocation Breakdown (values might change until claiming is disabled):
19 |
20 | - Total POWA: 1,000,000,000,000.00
21 | - Pre-sale POWA: 30,769,230,769.23 (3.08%)
22 | - Marketing POWA: 169,230,769,230.77 (16.92%)
23 | - Claimed POWA: 449,004,507,628.20 (44.90%)
24 | - Unclaimed Trading POWA: 37,697,735,279.93 (3.77%)
25 | - Unclaimed Staking POWA: 125,711,756,546.98 (12.57%)
26 | - Unclaimed Influence POWA: 75,506,059,358.54 (7.55%)
27 | - Unallocated Influence POWA: 112,079,941,186.32 (11.21%)
28 |
29 | Total unclaimed and unallocated POWA: 350,995,492,371.77 (35.10%)
30 |
31 | ## Summary
32 |
33 | This proposal outlines an approach to burning unclaimed and unallocated POWA tokens to enhance the value of the remaining tokens, ensure fair distribution, and reinforce the principles of individual sovereignty and empowerment that POWA represents.
34 |
35 | Unclaimed and unallocated tokens can potentially dilute the value for active participants and create a perception of inefficiency in token distribution. By burning these tokens, we aim to remove "dead" tokens from circulation, draw attention to the initiative, and encourage more users to claim their POWA before the deadline.
36 |
37 | Influence POWA campaign participants will have a chance to provide their RSK addresses until July 8th, 2024, at 12 PM UTC. All users will have the opportunity to claim their POWA tokens until July 15th, 2024, at 12 PM UTC. The distributor contract will be stopped after this time. The Sovryn Team will perform the necessary calculations and remove the specified amounts of POWA tokens.
38 |
39 | ## Impementation
40 |
41 | ### Technical Execution:
42 | - Stop the distributor contract on 15th July, at 12 PM UTC.
43 | - Determine the amount of POWA to be burned.
44 | - Inform the community about the final amounts of tokens to be burned.
45 | - Execute the burn of the specified amount of POWA tokens.
46 |
47 | ### Burning Process:
48 | - Remove the designated POWA tokens from the distributor contract.
49 | - Send the POWA tokens designated for burning to a specified address.
50 | - Bridge the POWA tokens back to the Bitcoin chain.
51 | - Perform the burn of the bridged POWA tokens on the Bitcoin chain.
52 |
53 | ### Execution Timing:
54 | - Execute the burn of all unclaimed and unallocated POWA tokens when market conditions are favorable to maximize the effect.
55 | - Ensure the burning is completed no later than the end of September 2024.
56 |
57 | ## License
58 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
59 |
60 |
--------------------------------------------------------------------------------
/SIP-0082.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 0082
3 | Title: Reduce Zero Origination Fee Floor to 5%
4 | Author: capitalist42
5 | Status: Ready for vote
6 | Track: Parameter
7 | Created: 2024-07-15
8 | ---
9 |
10 | ## Summary
11 |
12 | If approved, this proposal will reduce the ZUSD origination fee floor in the Sovryn Zero protocol from 8% to 5%.
13 |
14 | ## Motivation
15 |
16 | The Zero Protocol is still in the bootstrap period. We should focus on growing the ZUSD/DLLR supply. The 2% to 5% redemption percentage per month is generally acceptable. For the past 30 days, there were about 7.2 BTC redemptions (~1.3%), even with fairly volatile BTC price movement. The level of redemption is generally low. Given incoming liquidity easing, the condition is perfect for reducing the origination fee. With a lower origination fee, we will likely see an increase in ZUSD supply and protocol revenue.
17 |
18 | ## Proposed Changes
19 |
20 | If approved, the origination fee will fluctuate between 5% and 100%. The following change will be made to the Zero Protocol base parameters:
21 |
22 | It will update "BORROWING_FEE_FLOOR" from 8% to 5% by calling `setBorrowingFeeFloor(uint256)` on the `0xf8B04A36c36d5DbD1a9Fe7B74897c609d6A17aa2` contract with the encoded data `0x00000000000000000000000000000000000000000000000000b1a2bc2ec50000`.
23 |
24 | ## License
25 |
26 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
--------------------------------------------------------------------------------
/SIP-0083.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0083'
3 | Title: Sovryn - BitcoinOS Contributor and $BOS Token Launch
4 | Author: FrenchVictory (@Frenchvictory)
5 | Status: Ready for vote
6 | Track: Other
7 | Created: 2024-11-08
8 | ---
9 | # **SIP-0083: Sovryn - BitcoinOS Contributor and $BOS Token Launch**
10 |
11 | ## 1. Overview
12 |
13 | BitcoinOS (BOS) is being developed to allow any code to be executed on Bitcoin, representing a fundamental upgrade to the Bitcoin protocol.
14 | As one of the key development teams, Sovryn proposes to launch this technology.
15 |
16 | Throughout BitcoinOS’s development, Sovryn has made substantial contributions through project incubation, design partnership, research,
17 | development, testing, communications, and community engagement. We commit to continuing this involvement while developing
18 | a new Bitcoin-native token standard for the BOS ecosystem.
19 |
20 | In order for BitcoinOS, developed as Open Source Software (OSS), to succeed, the project needs broad distribution and
21 | a decentralized network of users and developers. Sovryn proposes to provide the decentralized governance framework and
22 | committed community needed for this launch. As part of this service, Sovryn will contribute to the issuance and
23 | distribution of the $BOS tokens and develop core parts of the BitcoinOS technical infrastructure.
24 | To facilitate this, 10% of the total supply of $BOS tokens will be earmarked for the Sovryn community.
25 |
26 | ## 2. Background
27 |
28 | BitcoinOS has achieved significant technological milestones, beginning with the verification of the first ZK proof on Bitcoin mainnet in July 2024,
29 | followed by the release of the first open-source code for Bitcoin ZK proof verification in September 2024.
30 | Their progress in developing ZK-based infrastructure has established new standards for Bitcoin L2s, towards L1 security, trustless bridging,
31 | scalability, and native transaction privacy.
32 |
33 | Teams working on the project are currently focused on developing Grail, the first trustless Bitcoin L2 bridge, and MerkleMesh,
34 | which will bring full interoperability to users and liquidity in the BitcoinOS ecosystem. Significant ecosystems have announced
35 | their plan to integrate with and contribute to BitcoinOS infrastructure, including Cardano and leading Bitcoin sidechains such as
36 | Merlin Chain, Nubit, and B² Network. Further significant integrations with additional collaborators are developing.
37 |
38 | Given Sovryn’s role in incubating BitcoinOS, our appreciation of its technological potential and traction, and the interest already expressed
39 | in a forum posted titled “SIP-XXXX: Launch of BitcoinOS (BOS) Under Sovryn Incubation” posted on June 18, 2024, we propose to leverage our
40 | expertise in decentralized governance to perform the decentralized launch of BOS and its $BOS token and to lead the development of a much
41 | needed Bitcoin native and programmable token standard.
42 |
43 | ## 3. Sovryn Bitocracy and Strategic Alignment with BitcoinOS
44 |
45 | Sovryn has achieved genuine decentralization and effective decentralized governance, maintaining high levels of diverse stakeholder participation.
46 | Our Bitocracy model and committed community provide a robust framework for launching decentralized projects.
47 |
48 | We believe that Sovryn, by leveraging its established decentralized framework, can ensure BitcoinOS’ decentralized launch and decentralization from
49 | inception, setting a new standard in the Bitcoin-native ecosystem. Our proposal includes:
50 |
51 | - Sovryn has been a key design partner for BitcoinOS, offering valuable expertise in project incubation, research, and strategic guidance.
52 | The teams working within Sovryn will continue with these efforts.
53 | - Launching the BOS protocol and distributing the $BOS token through Sovryn Bitocracy and Sovryn’s core team.
54 | - Collaborative development between Sovryn and the teams working on BitcoinOS technology to determine a framework for equitable total token distribution.
55 | - Allow teams to leverage Sovryn Bitocracy to propose and initiate the development of technologies related and required for the BitcoinOS ecosystem.
56 | - Sovryn will consider itself one of the founding groups of the BitcoinOS ecosystem.
57 | - Sovryn and other BOS teams will collaborate in launching the Sovryn Layer as it will defined by Bitocracy.
58 | - Sovryn will retain 10% of the total $BOS token supply.
59 |
60 | ## 4. BOS Launch
61 | ### 4.1 Project Development and Launch
62 |
63 | - **BOS Development:** We will support BOS developers in their focus on building and refining the technology under an OSS (Open Source Software) framework.
64 | - **Network Launch:** Sovryn Sorcery will assist in launching the BOS network, ensuring its integration with the broader Bitcoin ecosystem.
65 | - **Token Launch:** Sovryn will issue the $BOS tokens and facilitate the initial distribution, including the portion designated for the Sovryn community.
66 |
67 | ### 4.2 Resource Mobilization and Governance
68 |
69 | Sovryn will invest in the development of the BitcoinOS open-source ecosystem. The following resources will be allocated to support the following activities:
70 |
71 | - Education
72 | - Development and distribution of technical documentation
73 | - Creation of educational content for developers and users
74 | - Organization of workshops and training sessions
75 | - Marketing and Communications
76 | - Strategic marketing campaigns to drive adoption
77 | - Community outreach and engagement
78 | - Regular updates and announcements
79 | - Market research and analysis
80 | - Technical Development
81 | - Development of a Bitcoin-native token standard
82 | - Security audits of protocol components
83 | - Comprehensive user testing programs
84 | - Development and maintenance of essential front-end interfaces
85 | - Integration support for partners and developers
86 | - Network Operations
87 | - Nomination and support of qualified node operators
88 | - Network monitoring and maintenance
89 | - Performance optimization
90 | - Infrastructure support
91 | - Strategic Initiatives
92 | - Identification and development of strategic partnerships
93 | - Ecosystem growth initiatives
94 | - Protocol integration with complementary projects
95 | - Support for developer community building
96 |
97 | Additional activities required for the success of BitcoinOS as a decentralized protocol will be undertaken as needed,
98 | subject to community governance through Bitocracy.
99 |
100 | ### 4.3 Token Distribution and Stakeholder Incentives
101 |
102 | - Sovryn will issue the $BOS tokens and distribute them to the different stakeholders.
103 | - We will collaboratively develop a framework for equitable token distribution of the 10% allocation retained by Sovryn. This token distribution will be submitted for approval of the Bitocracy in a future SIP.
104 | - Additional SIPs may be proposed to determine various aspects of Sovryn’s responsibilities and commitments to BitcoinOS.
105 |
106 | ## 5. BitcoinOS Independence
107 |
108 | To maintain credible neutrality, BOS development will remain independent of Sovryn. Sovryn Bitocracy will have no decision-making power
109 | over any element of BOS not specifically listed in this SIP.
110 |
111 | ## License
112 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
113 |
--------------------------------------------------------------------------------
/SIP-0084_part-1.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0084'
3 | Title: Deactivate Fallback Price Oracle Contract (Part 1)
4 | Author: Tyrone Johnson (@tjcloa)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2024-11-20
8 | ---
9 |
10 | # SIP-0084: Deactivate Fallback Price Oracle Contract (Part 1)
11 |
12 | ## Description
13 |
14 | The Sovryn Lending and Zero protocols currently use the Rootstock Oracle price feed on the RSK blockchain as a fallback price oracle for WRBTC in USD.
15 | This fallback oracle is triggered when the primary oracle returns a zero price.
16 |
17 | The proposed change is prompted by the upcoming discontinuation of support for the Rootstock Oracle.
18 | After extensive research and analysis, it has been decided to deactivate the fallback oracle rather than replace it with another one.
19 | The primary Money-on-Chain oracle, which is decentralized, has demonstrated robust fault tolerance and reliability.
20 |
21 | Additionally, the price feed contract logic has been updated to include a stale price parameter.
22 | This ensures that outdated prices are not used and transactions will revert.
23 | The proposed technical solution involves replacing the RSK oracle with a "dummy oracle" that always returns a zero price and marks it as stale.
24 | This approach provides flexibility to replace the fallback oracle with another reliable oracle compliant with the Chainlink interface if the community decides to do so in the future.
25 |
26 | ## Proposed Changes
27 |
28 | Note that this is Part 1 of a two-part SIP.
29 | Both proposals will need to be approved to effectuate the complete set of changes.
30 | The exact change is implemented in the [PR#549](https://github.com/DistributedCollective/Sovryn-smart-contracts/pull/549), details for this part are as follows.
31 |
32 | If approved, this SIP will replace the WRBTC price oracle in the PriceFeeds contract used for the Lending protocol with the address of the new PriceFeedsMoC oracle contract that has the DummyFallbackOracle as the fallback price oracle.
33 |
34 |
35 | __Existing contracts__
36 | | Contract | Address |
37 | | ------------- | ------------------------------------------ |
38 | | PriceFeedsMoC | 0x391fe8a92a7FC626A25F30E8c19B92bf8BE37FD3 |
39 | | PriceFeeds | 0x437AC62769f386b2d238409B7f0a7596d36506e4 |
40 |
41 | __New contracts__
42 | | Contract | Address |
43 | | ------------------- | ------------------------------------------ |
44 | | PriceFeedsMoC | 0x50C53B463B67F2aF4c7B5b8E05643a39A0A4FDB9 |
45 | | DummyFallbackOracle | 0x16261C66D8D687600E5CbF7945986044A6569cBe |
46 |
47 |
48 | ## License
49 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
50 |
--------------------------------------------------------------------------------
/SIP-0084_part-2.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0084'
3 | Title: Deactivate Fallback Price Oracle Contract (Part2)
4 | Author: Tyrone Johnson (@tjcloa)
5 | Status: Approved
6 | Track: Contract
7 | Created: 2024-11-20
8 | ---
9 |
10 | # SIP-0084: Deactivate Fallback Price Oracle Contract (Part 2)
11 |
12 | ## Description
13 |
14 | The Sovryn Lending and Zero protocols currently use the Rootstock Oracle price feed on the RSK blockchain as a fallback price oracle for WRBTC in USD.
15 | This fallback oracle is triggered when the primary oracle returns a zero price.
16 |
17 | The proposed change is prompted by the upcoming discontinuation of support for the Rootstock Oracle.
18 | After extensive research and analysis, it has been decided to deactivate the fallback oracle rather than replace it with another one.
19 | The primary Money-on-Chain oracle, which is decentralized, has demonstrated robust fault tolerance and reliability.
20 |
21 | Additionally, the price feed contract logic has been updated to include a stale price parameter.
22 | This ensures that outdated prices are not used and transactions will revert.
23 | The proposed technical solution involves replacing the RSK oracle with a "dummy oracle" that always returns a zero price and marks it as stale.
24 | This approach provides flexibility to replace the fallback oracle with another reliable oracle compliant with the Chainlink interface if the community decides to do so in the future.
25 |
26 | ## Proposed Changes
27 |
28 | Note that this is Part 2 of a two-part SIP.
29 | Both proposals will need to be approved to effectuate the complete set of changes.
30 | The exact change is implemented in the [PR#6](https://github.com/DistributedCollective/zero-contracts/pull/6), details for this part are as follows.
31 | If approved, this SIP will upgrade the PriceFeed contract on Zero protocol and will replace the fallback oracle with the DummyFallbackOracle contract. The new logic of the PriceFeed contract will revert on stale price, removes restriction on adding a dummy oracle that returns stale price and adds a new function to replace the primary oracle and the fallback oracle separately.
32 |
33 |
34 | __Existing contracts__
35 | | Contract | Address |
36 | | ---------------- | ------------------------------------------ |
37 | | PriceFeed proxy | 0x6D1d9574d67e04cf35Fa1d916F763eDDae03b75d |
38 | | PriceFeeds logic | 0x1281ECfe66c9fA632Df1eB1eC19405C3b1bbaAf0 |
39 |
40 | __New contracts__
41 | | Contract | Address |
42 | | ------------------- | ------------------------------------------ |
43 | | PriceFeeds logic | 0x867303dfCd696BE516f9C4023525F1107d903356 |
44 | | DummyFallbackOracle | 0x16261C66D8D687600E5CbF7945986044A6569cBe |
45 |
46 |
47 | ## License
48 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
49 |
--------------------------------------------------------------------------------
/SIP-0085.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: '0085'
3 | Title: Deactivate Fallback Price Oracle Contract (Part2)
4 | Author: Sacro (Sovryn community member)
5 | Status: Defeated
6 | Track: Other
7 | Created: 2024-12-06
8 | ---
9 |
10 | # SIP-0085: $BOS token distribution within Sovryn
11 |
12 | ## Description
13 | https://forum.sovryn.com/t/sip-0085-bos-token-distribution-within-sovryn/3306
14 | https://forum.sovryn.com/t/sip-0085-thoughts/3321/2
15 |
16 | ## Voting
17 | https://bitocracy.sovryn.app/governorOwner/49
18 |
19 | ## License
20 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
21 |
--------------------------------------------------------------------------------
/images/FeesVault diff example.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DistributedCollective/SIPS/3b7dbab1649ae6b5334e8620c48a2a7fb13b1c54/images/FeesVault diff example.png
--------------------------------------------------------------------------------
/images/StakingContractDesignChange.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/DistributedCollective/SIPS/3b7dbab1649ae6b5334e8620c48a2a7fb13b1c54/images/StakingContractDesignChange.png
--------------------------------------------------------------------------------
/templates/contract_template.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 'N/A'
3 | Title: Title
4 | Author: Name (GitHub username)
5 | Status: Draft
6 | Track: Contract
7 | Created: YYYY-MM-DD
8 | ---
9 |
10 | # Insert title like "SIP-X: Example title" here
11 |
12 | ## Description
13 |
14 | [Replace this line with an accurate description of what the proposed change will do.]
15 |
16 | ## Motivation
17 |
18 | ## Proposed change
19 |
20 | Existing contract(s): [Replace this line with the address of the specific smart contract you propose to change.]
21 | Proposed change: [Replace this line with a link to the specific commit of the source code for your proposed change.]
22 | Audit report: [Replace this line with a link to at least one third-party security audit report for the proposed change.]
23 |
24 | ## License
25 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
26 |
--------------------------------------------------------------------------------
/templates/issuance_template.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 'N/A'
3 | Title: Title
4 | Author: Name (GitHub username)
5 | Status: Draft
6 | Track: Issuance
7 | Created: YYYY-MM-DD
8 | ---
9 |
10 | # Insert title like "SIP-X: Example title" here
11 |
12 | ## Issuance amount
13 |
14 | [Replace this line with the number of SOV to be issued] SOV
15 |
16 | ## Destination address
17 |
18 | [Replace this line with the address that the newly issued tokens will be sent to]
19 |
20 | ## Rationale
21 |
22 | [Replace this line with a detailed explanation for why you are creating this proposal.]
23 |
24 | ## License
25 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
26 |
--------------------------------------------------------------------------------
/templates/parameter_template.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 'N/A'
3 | Title: Title
4 | Author: Name (GitHub username)
5 | Status: Draft
6 | Track: Parameter
7 | Created: YYYY-MM-DD
8 | ---
9 |
10 | # Insert title like "SIP-X: Example title" here
11 |
12 | ## Description
13 |
14 | [Replace this line with an accurate description of what the proposed change will do.]
15 |
16 | ## Motivation
17 |
18 | ## Proposed change
19 |
20 | Existing parameter(s): [Replace this line with the existing parameter, if any.]
21 | Proposed change: [Replace this line with the specific parameter change.]
22 | Change analysis: [Replace this line with a link to an analysis of the proposed change, if one is available.]
23 |
24 | ## License
25 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
26 |
--------------------------------------------------------------------------------
/templates/proclamation_template.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: N/A
3 | Title: Title
4 | Author: Name (GitHub username)
5 | Status: Draft
6 | Track: Proclamation
7 | Created: YYYY-MM-DD
8 | ---
9 |
10 | # Insert title like "SIP-X: Example title" here
11 |
12 | ## Proclamation text
13 |
14 | [Replace this line with the proclamation that you want to make on behalf of SOV Voters.]
15 |
16 | ## Motivation for writing this proclamation
17 |
18 | [Replace this line with your motivation for making this proclamation.]
19 |
20 | ## License
21 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
22 |
--------------------------------------------------------------------------------
/templates/treasury_template.md:
--------------------------------------------------------------------------------
1 | ---
2 | SIP: 'N/A'
3 | Title: Title
4 | Author: Name (GitHub username)
5 | Status: Draft
6 | Track: Treasury
7 | Created: YYYY-MM-DD
8 | ---
9 |
10 | # Insert title like "SIP-X: Example title" here
11 |
12 | ## Address of the transfer recipient
13 |
14 | ## Amount of the transfer
15 |
16 | ## Purpose of the transfer
17 |
18 | ## Recipient information
19 |
20 | Organization (if any)
21 | Name:
22 | Website:
23 | Other URL:
24 |
25 | Fill out the following information for each individual team member who will be managing funds from this transfer:
26 |
27 | Name:
28 | PGP key fingerprint:
29 | Website:
30 | Other URL:
31 |
32 | ## License
33 | Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
34 |
--------------------------------------------------------------------------------