# [IP] Increase the Degen ETH (dgnETH) Backing_buffer from 0.03% to 0.10%
[https://forum.reserve.org/t/rfc-increase-the-degen-eth-dgneth-backing-buffer-from-0-03-to-0-10/878](https://forum.reserve.org/t/rfc-increase-the-degen-eth-dgneth-backing-buffer-from-0-03-to-0-10/878)
# Summary
Increase the Degen ETH (dgnETH) Backing_buffer from 0.03% to 0.10%
#### Current Backing_buffer
0.03%
#### New Backing_buffer
0.10%
# Abstract
This proposal recommends increasing the Degen ETH (dgnETH) backing buffer from 0.03% to 0.10%. The backing buffer determines the amount of extra collateral held in the BackingManager to absorb potential losses due to trading slippage during rebalancing. The current buffer of 0.03% is insufficient, posing a risk of a slashing event where RSR stakers may lose their stake if the buffer fails to cover slippage. Such a low buffer could also lead to preemptive unstaking by RSR holders, destabilizing the protocol. Raising the backing buffer to 0.10% enhances protection for stakers, aligns with industry standards, and ensures long-term stability for the protocol.
# Problem Statement
Currently at 0.03% backing, the rate is too low and could cause a slashing event to RSR stakers. The backing buffer is a percentage value that describes how much extra collateral to hold in the BackingManager. This can be important for preventing RSR seizure during normal rebalancing as a result of trading slippage. If the backing buffer is set too low, it’s possible to get into a situation where RSR stakers begin individually unstaking before rebalancing proposals to avoid being slashed. The backing buffer should be high enough to prevent this outcome for expected rebalances.
# Rationale
By increasing the backing buffer to the default value of 0.01%. RSR holders are incentived to stake Degen ETH knowing there is a higher backing buffer protecting its users. 0.01% is the default value for RTokens. The current buffer of 0.03% is insufficient and poses a risk of slashing events, where stakers could lose assets if the buffer fails to cover slippage. By raising the buffer to 0.10%, the protocol not only provides better protection for stakers but also prevents preemptive unstaking, which could destabilize the system. This increase aligns dgnETH with industry standards, ensuring it remains competitive and attractive to users while contributing to the long-term stability of the protocol.
# Risks
Reward distributions could decrease for a period of time as the backing_buffer is filled reducing the distribution to staked Degen ETH (sdgnETH) holders. Generally for long-term holders this shouldn’t be an issue, but short term stakers will be affected.
# [IP] Adjusting the ETHPLUS (ETH+) Reward Ratio from 2 weeks to 1 week
[https://forum.reserve.org/t/rfc-adjusting-the-ethplus-eth-reward-ratio-from-2-weeks-to-1-week/876](https://forum.reserve.org/t/rfc-adjusting-the-ethplus-eth-reward-ratio-from-2-weeks-to-1-week/876)
# Summary
Change the ETH Plus (ETH+) Reward Ratio from 2 weeks to 1 week.
#### From
2 Weeks: 0.000000534833333333
#### To
1 Week: 0.000001069666666666
# Abstract
This IP proposes changing the ETH+ reward distribution period from 2 weeks to 1 week, altering the reward ratio from 0.000000534833333333 to 0.000001069666666666. By moving to a 1-week distribution period, the protocol aims to establish a more sustainable and equitable reward system that ensures consistent reward flows and enhances long-term participation. This adjustment is designed to better align the protocol’s incentives with its goals of stability and fairness in the staking ecosystem.
# Problem Statement
The current reward distribution mechanism is set to distribute rewards over a period of 2 weeks corresponding to a reward ratio of 0.000000534833333333. The current model is too rigorous and reduces the reward distribution Early stakers may not be adequately incentivized, and the fast-paced distribution could cause inefficiencies in the reward system, impacting long-term user engagement and the stability of the protocol’s incentive structure.
# Rationale
The proposed change to extend the reward distribution period from 2 weeks to 1 week is driven by the need to create a more sustainable and equitable reward system within the protocol. The current rapid distribution schedule may lead to inefficiencies and diminish the incentive for early stakers, as rewards are quickly diluted with the influx of new participants. By slowing the distribution pace, the protocol can ensure a more consistent reward flow, enhancing long-term engagement and better aligning with the overall objectives of stability and fairness in the staking ecosystem.
By transitioning to a new reward ratio of 0.000001069666666666, which corresponds to a 1 week distribution period, This will create a more balanced and sustainable reward system that better aligns with the protocol’s long-term objectives.
# Risks
One potential risk is that it could introduce opportunities for people to stake, get yield, and then unstake. However, this is unlikely to be profitable with the 2 week unstaking delay.
# [IP] Collateral Basket Change: Adding apxETH to the Staked Degen ETH (sdgnETH) Yield Basket
[https://forum.reserve.org/t/rfc-collateral-basket-change-adding-apxeth-to-the-staked-degen-eth-sdgneth-yield-basket/868/1](https://forum.reserve.org/t/rfc-collateral-basket-change-adding-apxeth-to-the-staked-degen-eth-sdgneth-yield-basket/868/1)
# Summary
This proposal looks to diversify the Degen ETH (dgnETH) collateral basket by adding apxETH to the underlying yield strategy. At 9% APR adding apxETH will increase the staked Degen ETH (sdgnETH) base APY.
# Abstract
The proposed change involves adding apxETH to the collateral basket of sdgnETH. Currently, sdgnETH’s base yield stands at 5.27%, derived from Convex ETH+/ETH and Morpho Blue Re7 WETH Vault strategies. By incorporating apxETH, the new basket yield is projected to increase to 6.95%. The updated collateral exposure will consist of 35% Convex ETH+/ETH, 25% Morpho Blue Re7 WETH Vault, and 40% apxETH. apxETH, built by Dinero (Redacted Cartel), offers a 9.01% APY by auto-compounding rewards from staking pxETH. The integration of apxETH is expected to elevate the staking yield of sdgnETH from 12.8% to 17%, assuming the current percentage of dgnETH staked remains constant. This addition aims to enhance the overall yield of sdgnETH by leveraging the higher returns provided by apxETH.
# Problem statement
At $2 Million market cap, Degen ETH is growing rapidly and will continue to. The long term vision is to keep sdgnETH staking yield between 10% and 20% by keeping a high base yield and total % dgnETH staked below 50% of the total supply. Currently, the sdgnETH base yield 1 stands at 5.27% which means at 50% ratio of sdgnETH to dgnETH, sdgnETH yield stands at the lower boundary of its yield goals at 10%. This signals the opportunity to add more yields to the basket to drive up base APY.
# Rationale
By adding apxETH to the sdgnETH collateral basket, another highly respected DeFi product is being added increasing the overall collateral basket to
The current sdgnETH basket yield earns a base yield of 5.27% from two strategies
## Current Basket Yield = 5.27%
| Collateral Exposure | APY |Collateral Exposure |
|--------|--------|--------|
| Convex ETH+/ETH | 7.07% |50.00% |
| Morpho Blue Re7 WETH Vault | 3.47% |50.00% |
**Convex ETH+/ETH:** Token obtained by providing liquidity to the ETH±ETH liquidity pool on Curve Finance and staking the LP token on Convex Finance. This variable yield is generated from a combination of native asset yield, CVX rewards, and boosted CRV rewards leveraging Convex’s veCRV power.
**Morpho Blue ETH (Re7):** ETH lent to a vault that supplies deposited assets to Morpho Blue markets whitelisted by the vault Curator. The Curator can set supply caps for each market. If the supply cap is reached, deposited assets will be supplied to another whitelisted market. This vault is curated by Re7 and aims to outperform staked ETH yields by lending WETH against a diverse set of Liquid Staking and Liquid Restaking Token collateral markets.
## New Basket Yield = 6.95%
| Collateral Exposure | APY |Collateral Exposure |
|--------|--------|--------|
| Convex ETH+/ETH | 7.07% | 35.00% |
| Morpho Blue Re7 WETH Vault | 3.47% |25.00% |
| apxETH | 9.01% |40.00%|
**Staked pxETH (apxETH):** Built by Dinero (Redacted Cartel), apxETH is obtained by depositing pxETH into Dinero’s auto-compounding rewards vault (i.e. staking their ETH). Depositing pxETH into the vault results in a boosted staking yield for apxETH, as not all pxETH is staked. Each apxETH benefits from the staking rewards of more than one staked ETH, amplifying apxETH’s yield.
The current staking yield of sdgnETH stands at 12.8% which is 243% times the 5.27% base yield. With the additions of apxETH, the base yield increases to 6.95%. At the current % of dgnETH staked, the staking yield will increase up to 17%.
Dinero’s apxETH has completed 3 audits including 2 audits by Spearbit and 1 by Pashov (independent researcher). Adding apxETH drives up base yield, adds a well-audited yield product to the collateral basket, and is integrated with Redacted Cartel, a well-recognized group in the DeFi space.
# Risks
Risks include smart contract risks added from adding apxETH, exploit likeliness can be significantly lowered through audits and bug bounties but the chance is never 0. Volatility apxETH is variable yield, adding another variable yield product adds more dependencies which means a dip in apxETH yield lowers the overall yield.
image
# [IP] Collateral Basket Change Proposal: Adjusting ETH+ Collateral Basket To Address Liquidity Constraints
[https://forum.reserve.org/t/rfc-collateral-basket-change-proposal-adjusting-eth-collateral-basket-to-address-liquidity-constraints/841](https://forum.reserve.org/t/rfc-collateral-basket-change-proposal-adjusting-eth-collateral-basket-to-address-liquidity-constraints/841)
## Summary
ETH Plus (ETH+) has seen significant growth in the past year, with market growing from $15 million to $116 million since March 1st. As ETH+ grows, rETH is experiencing liquidity constraints, making it difficult for minters to access the token without higher slippage. Currently, rETH makes up 33% of the ETH+ basket, so limited rETH liquidity may hinder ETH+’s further growth. This RFC proposes two potential solutions: (a) adding cbETH to the collateral basket, and/or (b) increasing the percentage of stETH in the basket. By implementing a solution, ETH+‘s collateral basket will become more liquid, allowing it to easily be minted without liquidity constraints. New solutions introduced will be included as proposed in the reply section of the forum.
## Abstract
This RFC explores the liquidity challenges faced by rETH as ETH+ continues to expand. To mitigate these constraints, this proposal offers two potential solutions: (a) incorporating cbETH into the basket, and/or (b) increasing the allocation of stETH. Each option is evaluated based on its potential impact on liquidity, risk, and overall performance of the basket.
## Problem statement
rETH’s current backing collateral for ETH+ is over $42 Million, but the largest rETH liquidity pool holds only $51 million in liquidity. It’s time to consider adjusting the collateral basket to handle ETH+’s growth. Without adjusting the collateral basket, ETH+ growth will be limited due to liquidity constraints. If this is not addressed soon, it will create significant issues for the user experience of large users, as their ability to mint large amounts of ETH+ will be deterred.
## Rationale
Solutions 1 & 2 of the RFC will be combined to create an optimal community solution. cbETH will be added to the ETH+ collateral basket and wrapped stETH exposure will be increased as well.
| Token| Allocation| APY= 3.02% |
|--------|--------|--------|
| rETH | 15%| 2.77%|
| Wrapped stETH | 40%| 3.03%|
|sfrxETH| 22.5%| 3.26% |
| cbETH | 22.5% | 3.00% |
#### Diversification:
Adding cbETH further diversifies the ETH+ collateral basket, furthering the original mandate. By diversifying, ETH+’s exposure to the risks of any particular LST (e.g., slashings or depeg) is reduced.
#### cbETH plugin is already available:
The plugin for cbETH has already been created which means no time will be needed to be set aside to build and audit the plugin as it already has been completed.
#### Liquidity:
stETH (wstETH) has over $300 million in liquidity on the Ethereum blockchain paired against other ETH-pegged stable pairs. By increasing % exposure to stETH, ETH+ will gain higher exposure to the most liquid LST within its collateral basket, allowing it to scale more easily with fewer liquidity constraints. Limited Basket Adjustment:
## Risks
When considering the risks of these two LSTs, risk reports from Llama Risk will be utilized to establish key considerations for the community. The risk factors pulled from the report will be Liquidity, Smart Contract, Dependency, and Decentralization. By using a standard and reputable research group for both, the community can more easily evaluate this decision. Both reports are linked in the RFC.
### Adding cbETH to the ETH+ Collateral Basket
#### Liquidity
“cbETH is okay on liquidity because although it ranks 2nd by LSD market share after stETH, >97% of liquidity is on Coinbase and an $18.1m on-chain swap produces a similar slippage as a $300m stETH swap.”
Additional Notes on Liquidity Risk: Since this report, cbETH has even less on-chain liquidity. At current liquidity, a swap of 1,000 ETH for cbETH could create significant slippage. For ETH+, minters can obtain cbETH directly from Coinbase at a 1:1 ratio, but the on-chain liquidity of cbETH should be noted as a potential risk to the underlying basket.
#### Smart Contract Risk
“cbETH is ranked excellent in smart contracts because the contract architecture is straightforward, managed by permissioned Coinbase addresses, based on battle-tested contracts, is audited, and the contracts themselves do not handle user funds.”
Additional Thoughts on Smart Contract Risk: Though rated well on smart contract risk, it’s important to note that adding another layer of smart contract risk increases total exposure. This must always be considered when adding another LST to the basket.
#### Dependencies
“cbETH is ranked good in dependencies for having a reliable price feed available. A centralized service can be an advantage when managing system accounting, withdrawal processing, and unforeseen network issues (high withdrawal demand, Ethereum network issues, etc.).”
#### Decentralization
“cbETH is ranked poor in decentralization because it is a centralized service operated by Coinbase and users are thus exposed to counterparty risk. The User Agreement does offer assurances that users retain legal ownership of their staked ETH. Coinbase does make an effort to reduce centralization of its validators by diversifying across several software clients.”
### Solution 2: Increase Exposure to stETH (wstETH) in the Collateral Basket
stETH (wstETH) Risk Rating by Prisma Risk
#### Liquidity
“stETH is rated excellent on liquidity for being the clear market leader with the deepest liquidity.”
#### Smart Contract Risk
“stETH is rated good in smart contracts for being heavily audited, having a bug bounty program, and having a long history of securing billions in TVL without major incident. The recent upgrade to V2 increases smart contract uncertainty.”
#### Dependencies
“stETH is rated good in dependencies for having a reliable price feed available. Dependency on Lido oracle daemons can result in disruptions that can cause incorrect reward distribution or liquidity mismanagement.”
#### Decentralization
“stETH is rated good in centralization for having core system controls with a DAO that has reasonable backstop measures. Multiple multisigs are employed with limited privileges for specific precautionary functions.”
# [IP] Important Steps to be Completed Before Finalizing Release 3.4.0 Upgrade for ETH+
[https://forum.reserve.org/t/rfc-important-steps-to-be-completed-before-finalizing-release-3-4-0-upgrade-for-eth/804](https://forum.reserve.org/t/rfc-important-steps-to-be-completed-before-finalizing-release-3-4-0-upgrade-for-eth/804)
## Summary
Following the RFC to guide the ETH+ community through the next steps to finalize the upgrade to the 3.4.0 smart contract release by Reserve Protocol, the following prerequisites have been completed
- All reward token balances should be claimed beforehand
- All rebalancing and revenue auctions must run to completion
Once these steps are completed The final step to upgrade ETH+ to release 3.4.0 can proceed. This RFC will not follow a normal governance cycle, this RFC is designed to prompt the community to complete the required prerequisites, so the upgrade to release 3.4.0 can be finalized. Once these steps are completed, the second IP to finalize the upgrade will be launched.
## Abstract
ETH+ is in the last step of upgrading to the new contract release 3.4.0. Before the upgrade can be completed, governors must work with the community to ensure these two prerequisites are completed before executing the final upgrade. Once the prerequisites are completed, the second IP will go live to finalize the ETH+ contract upgrade to release 3.4.0.
## Problem Statement
Upgrading ETH+ to release 3.4.0 is a two-step process. Step 1 upgrades the core contracts and registers new collateral plugins. After Step 1 is executed, a new TimelockController and Governance will administer the RToken. Step 2 cleans up old plugins. Before executing Step 2, there are two important prerequisites:
All reward token balances should be claimed beforehand.
All rebalancing and revenue auctions must run to completion.
Once these steps are completed, the upgrade to release 3.4.0 from Reserve Protocol can be completed after the second IP is executed.
## Rationale
The community has already passed the initial IP to begin the upgrade to release 3.4.0. To finalize the upgrade, this last cleanup step is needed to complete the upgrade. Once the prerequisites are completed, ETH+ will be fully upgraded to release 3.4.0.
**Following the prerequisites,**
**All reward token balances should be claimed beforehand**
For ETH+ token holders, there are no additional reward tokens because collateral is wstETH, rETH, sfrxETH. There are no requirements for ETH+ holders to do for this step
**All rebalancing and revenue auctions must run to completio**n
All auctions for ETH+ must be completed, after being settled, ETH+ is ready to move forward with the second IP needed to finalize and upgrade ETH+ to release 3.4.0. Following this RFC, the cleanup step IP will be posted.
As you can see [here](https://app.reserve.org/ethereum/token/0xe72b141df173b999ae7c1adcbf60cc9833ce56a8/auctions), all auctions have been settled.
## Risks
The latest smart contract upgrade 3.4.0 has been audited by Trust, however, there is always a chance of a bug as there is with all smart contracts. If a new auction appears or any have not run to completion then capital will be lost as the governor and timelock contract have been updated. If the final step is not completed, ETH+ will not complete the final step to finalize the upgrade to release 3.4.0.
# [IP] Upgrade ETH+ to Release 3.4.0
[https://forum.reserve.org/t/rfc-upgrade-eth-to-release-3-4-0/750](https://forum.reserve.org/t/rfc-upgrade-eth-to-release-3-4-0/750)
## Summary
This proposal recommends upgrading ETH+ to version 3.4.0 of the Reserve Protocol to keep its infrastructure up to date with the latest smart contract upgrades. This is a two-step process and will have two RFCs as well as two IPs. This first RFC and IP is the upgrade step to move ETH+ over to the 3.4.0 governance contracts. The second RFC and IP is a cleanup step and will be released after the execution of the first IP. Multiple steps need to be completed before the second IP can be executed. The second RFC will go over this in detail.
**Required steps to be completed before second IP can be executed**
- All reward token balances should be claimed
- All rebalancing auctions must run to completion
- All revenue auctions must run at least until all surplus balances are below the minTradeVolume
## Motivation
Following the recommendation from [ABC Labs](https://myreserve.notion.site/3-4-0-Upgrade-7015f3efa3bd4c03a9b0de20e5dba834), this is a governance proposal to gather feedback from the community on whether there is an agreement to upgrade the ETH+ RToken smart contracts to the latest upgrade.
## Specification
Draft instructions have been provided for upgrading ETH+ to release version 3.4.0 of the Reserve Protocol:
#### Detailed Instructions:
Reference: [Reserve Protocol Release 3.4.0](https://github.com/reserve-protocol/protocol/pull/1096)
Upgrade Spell: [3.4.0 Upgrade Spell](https://github.com/reserve-protocol/protocol/pull/1134/files#diff-595dd5ecc5057f953763a4ffb710d00041c7e4f669f32fcca955b97b8afeda95)
Governors Implementation Guide: [3.4.0 Upgrade Guide](https://myreserve.notion.site/3-4-0-Upgrade-7015f3efa3bd4c03a9b0de20e5dba834)
#### Steps for Upgrading ETH+:
| Description| Target Contract |Method | Data|
|--------|--------|--|--|
| Assign OWNER role to the spell| Main Contract Address | grantRole| OWNER_ROLE to <0xB1Df3a104D73FF86F9AAaB60B491A5c44b090391>|
| Assign TIMELOCK_ADMIN_ROLE to the spell | Timelock Contract Address | grantRole | TIMELOCK_ADMIN_ROLE to <0xB1Df3a104D73FF86F9AAaB60B491A5c44b090391> |
| Execute the upgrade spell | Spell Contract Address | castSpell | RToken Address <0xE72B141DF173b999AE7c1aDcbF60Cc9833Ce56a8> governor_address <0x239cDcBE174B4728c870A24F77540dAB3dC5F981> |
## Conclusion/Next Steps
This RFC aims to begin a discussion on the pros and cons of upgrading the ETH+ contract to 3.4.0 release of Reserve Protocol, and when is the best time to integrate ETH+ as it is the largest RToken at a $57 Million market cap.
1. **Review upgrade**
Governors should review the proposed upgrades carefully, ensuring they understand and agree on each step.
1. **Discuss proposal**
Please express any concerns, queries, or suggestions related to this upgrade in the reply section. Do not hesitate to discuss on the discord for support or clarification as well.
1. **IP upgrading ETH+ contracts**
With the completion of the IP, a new governance contract will be created with the 3.4.0 upgrade.
1. **Preparing for cleanup step for ETH+ contracts**
With the completion of the first step, a second RFC will released to guide the community on the required steps needed to be completed in order for the second IP to be executed, completing the upgrade.
# [IP] dgnETH revenue distribution change
[]()
The goal of this IP is to adjust the revenue distribution for DegenETH (dgnETH).
Currently with the RToken launched as is, 100% is going to RSR stakers. It will be adjusted to 95% staked degenETH (sdgnETH) and 5% to RSR stakers.
Originally in the RFC, it was 5% Protocol Owned Liquidity (POL), 5% RSR stakers 90% to dgnETH stakers.
After deliberation, this will be the new yield distribution model.
The RFC Introducing dgnETH, will be edited to match this new yield distribution
1: Take appropriate risks to capture high DeFi yields and sustainably outperform the LST market.
2: Distribute revenue to maximize staking contract yield.
1: Take appropriate risks to capture high DeFi yields and sustainably outperform the LST market.
2: Distribute revenue to maximize staking contract yield.
1. Take appropriate risks to capture high DeFi yields and sustainably outperform the LST market.
2. Distribute revenue to maximize staking contract yield.
# Resubmission ETH+ Issuance and Redemption Throttle Changes (With Update)
[https://forum.reserve.org/t/rfc-resubmission-eth-issuance-and-redemption-throttle-changes-with-update/667/1](https://forum.reserve.org/t/rfc-resubmission-eth-issuance-and-redemption-throttle-changes-with-update/667/1)
### Summary
This resubmitted proposal seeks to increase issuance and redemption throttles for ETH+, aimed at optimizing the experience for large-scale users. The [initial submission](https://forum.reserve.org/t/rfc-eth-issuance-and-redemption-throttle-changes/611) did [not pass quorum](https://app.reserve.org/ethereum/token/0xe72b141df173b999ae7c1adcbf60cc9833ce56a8/governance/proposal/75651631275193256868410638391501300223286510728542345115994000137977116585206) in the on-chain vote, but received significant support from the community, so we are pushing this forward for another vote. Please note, that the increase in the issuance and redemption is higher than the original proposal.
### Background
Currently, the ETH+ issuance throttle is set to whichever is higher: 250 ETH or 5% of the ETH+ market cap. Similarly, the redemption throttle is determined by the higher value between 500 ETH or 7.5% of the ETH+ market cap. In discussions with large minters, the feedback we’ve received indicates that the current offering is too limiting because they wish to mint and redeem in as few transactions as possible.
### Specification
```
Throttle Current Cap Proposed Cap
Issuance 250 ETH or 5% 1,700 ETH or 10%
Redemption 500 ETH or 7.5% 2,000 ETH or 12.5%
```
### Rationale
The original vote was to increase the redemption to 625 ETH or 12.5% and the issuance to 500 ETH or 10%. Based on comments from the [original RFC](https://forum.reserve.org/t/rfc-eth-issuance-and-redemption-throttle-changes/611/10). Increasing the redemption and issuance throttle further could be prudent.
The current throttle settings are too restrictive. Whales are dealing with long wait times for minting and unnecessary gas fees. These limits worsen the customer experience for RToken issuance and slow down the growth of Total Value Locked (TVL). We need to adjust the issuance and redemption throttles to make the process smoother and to more easily integrate large users into Reserve.
### Risks
Reserve has rigorous smart contract audits, from some of the best in the industry, particularly Trail of Bits. This significantly reduces the likelihood of any exploit from a bug. The issuance throttle safeguards against attacks during collateral defaults, exploiting RSR-funded recapitalizations. Given that ETH+ holds minimal $RSR collateral, it is less vulnerable to such exploits.
### Conclusion
This proposal, with revised throttle limits, seeks to grow the issuance and redemption throttle further than what it was previously. By doing this, ETH+ will become a more attractive product for whales to invest in ETH+ with less friction. The community’s insights and opinions are invaluable in refining and validating these adjustments. Feedback is encouraged to ensure these changes align with the collective goals of enhancing functionality and user experience while maintaining robust security measures.
# Collateral Basket Change Proposal: Adding Staked frxETH (sfrxETH) to the ETH+ Collateral Basket
[https://forum.reserve.org/t/rfc-collateral-basket-change-proposal-adding-staked-frxeth-sfrxeth-to-the-eth-collateral-basket/685/1](https://forum.reserve.org/t/rfc-collateral-basket-change-proposal-adding-staked-frxeth-sfrxeth-to-the-eth-collateral-basket/685/1)
## Summary
This proposal recommends integrating staked frxETH (sfrxETH) into the ETH+ collateral basket to enhance the diversification of our index LST following the mandate to add value to ETH+ holders through diversification.
## Abstract
Staked frxETH (sfrxETH) represents a staked version of frxETH that accrues yields from Frax Ether validators. All profits generated are passed to sfrxETH holders, making it an attractive option for staking. This proposal suggests allocating 33.3% of the ETH+ collateral to sfrxETH, evenly distributing staking diversification across Lido ETH, Rocket ETH, and Frax ETH.
## Problem Statement
The ETH+ collateral basket currently comprises only two types of diversified staking collaterals, limiting the risk spread and potential yield enhancement. There is a clear opportunity to broaden this spectrum by incorporating trusted, high-performance tokens like sfrxETH, further aligning with our diversification mandate.
## Rationale
Frax.Finance is a pillar within the DeFi ecosystem. All their products are audited and have stood the test of time against exploit risk. The current APY for sfrxETH stands at 4.81%, which is higher than ETH+'s existing components (rETH at 2.66% and Wrapped stETH at 3.10%).It seems to be a logical next step to integrate a product such as this into the ETH+ collateral basket.
**Enhanced Diversification:** Adding sfrxETH diversifies the sources of yield within the basket and mitigates risks associated with the concentration in fewer staking platforms.
**Yield Improvement: frxETH** is designed to be loosely pegged to ETH, capitalizing on Frax’s proven strategies in the synthetic asset market to potentially offer higher yields.
## New ETH+ Collateral Basket
Token Allocation APY = 3.52%
rETH 33% 2.66%
Wrapped stETH 34% 3.10%
sfrxETH 33% 4.81%
[Defillama](https://defillama.com/yields)
## Risks
Adding another asset as collateral adds additional counterparty risk. However, frxETH has gone through rigorous smart contract audits and has existed for a long time with no exploit occurring.
It’s important to understand the staking and yield dynamics between staked frxETH (sfrxETH) and frxETH. The documentation to frxETH is linked [here](https://docs.frax.finance/frax-ether/overview) for the community to explore further.
## Conclusion
Please provide any questions or feedback in the comments to enhance the discussion and help the DAO in making this decision.
# ETH+ Issuance and Redemption Throttle Changes
## Summary
This RFC suggests a change that would increase the issuance and redemption throttle for ETH+. The goal of this proposal is to enhance the user experience for large capital allocators who are looking to mint ETH+ in size. We are seeking the community’s feedback on whether this should be implemented.
[Link to Discussion](https://forum.reserve.org/t/rfc-eth-issuance-and-redemption-throttle-changes/611)
The change will be implemented with two proposals.
In this proposal, we are voting on increasing the issuance throttle.
## Background
Currently, the ETH+ issuance throttle is set to whichever is higher: 250 ETH or 5% of the ETH+ market cap. Similarly, the redemption throttle is determined by the higher value between 500 ETH or 7.5% of the ETH+ market cap. In discussions with large minters, the feedback we’ve received indicates that the current offering is too limiting because they wish to mint and redeem in as few transactions as possible.
## Specification
This proposal aims to adjust the issuance throttle to the higher of either 500 ETH or 10% and the redemption throttle to the higher of either 625 ETH or 12.5%
Following is a comparison of the proposed changes:
| Throttle |Current Cap| Proposed Cap
|--------|--------|--------|
| Issuance| 250 ETH or 5% | 500 ETH or 10%|
| Redemption | 500 ETH or 7.5% | 625 ETH or 12.5% |
## Rationale
Issuance and redemption throttling are important mechanisms designed to safeguard RToken & $RSR stakers from being drained from malicious actors attempting to drain funds or inject large amounts of defaulting collateral into the protocol.
However, the current throttle settings are too restrictive. Whales are dealing with long wait times for minting and unnecessary gas fees. These limits worsen the customer experience for RToken issuance and slow down the growth of Total Value Locked (TVL). We need to adjust the issuance and redemption throttles to make the process smoother and to more easily integrate large users into Reserve.
## Risks
Increasing the throttles can result in more volatility for ETH+ TVL figures, however, contributors believe that throttle levels can be increased while still remaining conservative. These changes would result in improved user experience while maintaining safety and security.
## Conclusion
This proposal aims to raise the issuance and redemption thresholds for ETH+, to enhance the platform’s efficiency and user satisfaction. In doing this, there are potential risks as well as opportunities to grow the Reserve vision further. We are asking the community to provide their feedback, supporting or critiquing, to ensure these changes meet our collective goals and standards.
# ETH+ Issuance and Redemption Throttle Changes
## Summary
This RFC suggests a change that would increase the issuance and redemption throttle for ETH+. The goal of this proposal is to enhance the user experience for large capital allocators who are looking to mint ETH+ in size. We are seeking the community’s feedback on whether this should be implemented.
[Link to Discussion](https://forum.reserve.org/t/rfc-eth-issuance-and-redemption-throttle-changes/611)
The change will be implemented with two proposals.
The redemption throttle is being voted on in this proposal. The issuance throttle will be voted on in the second proposal.
## Background
Currently, the ETH+ issuance throttle is set to whichever is higher: 250 ETH or 5% of the ETH+ market cap. Similarly, the redemption throttle is determined by the higher value between 500 ETH or 7.5% of the ETH+ market cap. In discussions with large minters, the feedback we’ve received indicates that the current offering is too limiting because they wish to mint and redeem in as few transactions as possible.
## Specification
This proposal aims to adjust the issuance throttle to the higher of either 500 ETH or 10% and the redemption throttle to the higher of either 625 ETH or 12.5%
Following is a comparison of the proposed changes:
| Throttle |Current Cap| Proposed Cap
|--------|--------|--------|
| Issuance| 250 ETH or 5% | 500 ETH or 10%|
| Redemption | 500 ETH or 7.5% | 625 ETH or 12.5% |
## Rationale
Issuance and redemption throttling are important mechanisms designed to safeguard RToken & $RSR stakers from being drained from malicious actors attempting to drain funds or inject large amounts of defaulting collateral into the protocol.
However, the current throttle settings are too restrictive. Whales are dealing with long wait times for minting and unnecessary gas fees. These limits worsen the customer experience for RToken issuance and slow down the growth of Total Value Locked (TVL). We need to adjust the issuance and redemption throttles to make the process smoother and to more easily integrate large users into Reserve.
## Risks
Increasing the throttles can result in more volatility for ETH+ TVL figures, however, contributors believe that throttle levels can be increased while still remaining conservative. These changes would result in improved user experience while maintaining safety and security.
## Conclusion
This proposal aims to raise the issuance and redemption thresholds for ETH+, to enhance the platform’s efficiency and user satisfaction. In doing this, there are potential risks as well as opportunities to grow the Reserve vision further. We are asking the community to provide their feedback, supporting or critiquing, to ensure these changes meet our collective goals and standards.