## Motivation
After months of testing, rSEI is ready for mainnet deployment, coinciding with the upcoming SEI EVM mainnet launch. The core team recommends preparing rSEI for release and applying for FIS from the Treasury for incentives. As the winner of rLaunchpad season 1 and developed by LSaaS stack, rSEI's performance is crucial for LSaaS adoption.

## Specification

### Overview
Pre-mainnet launch, three incentivization strategies will be implemented:
- rSEI mint drop to encourage SEI staking and rapidly increase TVL.
- Initial liquidity provision for the rSEI/SEI pair.
- Incentives for rSEI/SEI pair LP to deepen the liquidity pool.

Unstaking functionality will be unavailable initially, unlocking after one or two quarters for security and stability reasons.

### rSEI Mint Drop
The mint drop serves as a primary incentive for users to stake SEI on StaFi, with rewards granted upon staking. Drawing from data of previous ETH mint drops, it's estimated that acquiring 1 ETH required approximately 100 FIS incentives. Applying this ratio to SEI, 100 FIS could yield around 5,800 SEI. Consequently, approximately 10,000 FIS could potentially contribute to a TVL of about 0.3M, while 33,000 FIS could lead to roughly 1M TVL. Reward distribution will follow a linear timeline, with a set duration of 40 days, meaning that staking rewards will be fully obtained after this period. Regarding reward allocation, incentives can be provided either in FIS or SEI. Opting for SEI rewards can enhance visibility within the SEI community and eliminate the need to establish additional liquidity. However, this approach necessitates additional development effort.

### Incentive rSEI Liquidity
The liquidity for the rSEI/SEI pair requires contributions from two sources: the core team and LP providers. For the initial liquidity, the core team anticipates providing $50,000 - $100,000, which will be acquired through FIS conversion, requiring approximately 150,000 FIS.

Regarding LP liquidity incentives, there is limited available data for reference. Based on previous incentive amounts, approximately 10,000 FIS is expected to be allocated for LP incentives. However, LP providers also have the option to receive rewards in SEI. In terms of implementation, a vesting mechanism can be introduced for LP rewards. For example, LP incentives can be received as oFIS or oSEI, requiring vesting before conversion to FIS or SEI. Vesting periods would be linear, with options for full redeem after 8 or 16 weeks. If participants exit prematurely, rewards would be discounted based on the number of vested weeks. However, this approach would entail additional development costs.

Furthermore, we will collaborate with the SEI ecosystem's DEX to apply for additional LP incentives, which will not be funded from the treasury.

## Summary
In summary, we will apply for approximately 193,000 FIS for rSEI incentives. The community can vote on the following execution options:

**Option 1:** Allocate 33,000 FIS for mint drop, 160,000 FIS for initial liquidity, and 10,000 FIS for LP incentives. All rewards will be in FIS. Mint drop rewards will be linearly released over 40 days, while LP incentives will be distributed directly.
**Option 2:** Allocate 33,000 FIS for the mint drop, exchange 155,000 FIS for SEI, and provide LP incentive rewards in SEI. Mint drop rewards will be linearly released over 40 days, and LP incentives will be distributed directly.
**Option 3:** Allocate 33,000 FIS for mint drop, 150,000 FIS for initial liquidity, and 10,000 FIS for LP incentives. Mint drop rewards will be in FIS, linearly released over 40 days, while LP incentives will be in SEI with an 8-week vesting period.
**Option 4:** Allocate 33,000 FIS for mint drop, 150,000 FIS for initial liquidity, and 10,000 FIS for LP incentives. Mint drop rewards will be in FIS, linearly released over 40 days, while LP incentives will be in SEI with a 16-week vesting period.


Launching rSEI and Boosting Adoption

## **Introduction**
rLaunchpad program is a community-driven initiative designed to sustainably expand the StaFi ecosystem and introduce new rTokens to the platform. This proposal outlines the program’s structure, lifecycle, core units, participation guidelines, and future plans.

## **What is rLaunchpad?**
rLaunchpad is a community-led program that empowers StaFi’s FIS token holders to select promising Layer 1 projects for integration into the StaFi ecosystem. Through a voting process, FIS token holders can choose the most compelling project proposals, paving the way for the introduction of new rTokens on the StaFi platform.

StaFi provides a variety of services to launchpad participants, including:
- rToken backend technical development
- rToken frontend UI development
- rToken technical support after launch
- Marketing and community building support

## **rLaunchpad Lifecycle**

The rLaunchpad lifecycle encompasses several key stages:
**1. Project Listing Proposals:** Layer 1 projects or StaFi DAO draft initial project listing proposals, highlighting potential Layer 1 projects for integration.
**2. Community Voting:** StaFi FIS token holders cast their votes to select the most promising Layer 1 project from the proposed list.
**3. Development Evaluation:** The StaFi development team assesses the development costs and feasibility of integrating the chosen project.

⚠️ Note: In addition to 61Lab, the community and foundation can also promote the participation of third-party teams in development, or lead a team. We will then release an open plan. This plan will be based on one-time incentives and subsequent rToken yield incentives. Before that, 61Lab, as the builder of the Stafi protocol, will continue to develop new rTokens.

**1. Development and Launch:** Upon successful evaluation, the StaFi development team initiates the integration process and launches the new rToken on the StaFi rToken app.
**2. Incentivization Programs:** To attract users and encourage staking, each new rToken will undergo targeted mining campaigns and incentive programs.

⚠️ Note: StaFi DAO and community will monitor the performance of these teams and adjust the incentives as needed. If an rToken is not performing well, StaFi DAO may consider delisting it. This would be done to protect the interests of the Stafi community and to ensure that only high-quality rTokens are listed on the platform.

## Season 1 rToken Listing Proposal
- [rAVAX](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing/144)
- [rINJ](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing/144)
- [rSUI](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing/144)
- [rFTM](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-2-rftm-rnear-rmetis/145)
- [rNEAR](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-2-rftm-rnear-rmetis/145)
- [rMETIS](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-2-rftm-rnear-rmetis/145)
- [rASTR](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-3-rastr/146)
- [rSEI](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-4-rsei-and-rxpla/152)
- [rBGT](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-4-rsei-and-rxpla/152)
- [rXPLA](https://dao.stafi.io/t/proposal-for-rlaunchpad-new-rtoken-listing-4-rsei-and-rxpla/152)
- [rMANTA](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-manta-on-rlaunchpad/155)

⚠️ Note: Due to the lack of transfer support, rBGT currently has no technical pathway, and thus will not participate in this vote. Similarly, due to its multi-chain nature and the complexity involved in implementation, AVAX will also not participate in this vote.

[rLaunchpad #1] Season 1 rToken Listing Vote

**Abstract**
To further enhance the security model of StaFiHub rTokens, this SIP is a follow-up proposal to the [Tokenomic 2.0](https://dao.stafi.io/t/sip-2-stafi-tokenomics-v2/84), moving the rToken decoupling forward to the native chain. The idea here preferably proposes to migrate StaFiHub to [Neutron](https://www.neutron.org/) after comparing the deployments among Cosmos ICS(Interchain security), Smart Contract platforms and Celestia DA.

**Motivation**
StaFiHub is an appchain of the StaFi Protocol that serves the CosmosSDK based projects to issue LSTs. In the Tokenomic 2.0, decoupling rToken from the appchain security to the native chain security is essential, the solution is to migrate StaFiHub deployment from a solo chain to a native chain, hence gain a high level security, especially from the aspect of economy. The TVL of rToken in StaFiHub is about $2.5Mil, while the FIS staked value of StaFiHub appchain is about $1.05mil(3mil FIS), for further increase target of rToken TVL, a consumption is the stake value of an appchain should be far more than TVL built upon on chain.

Currently, the FIS stakes of StaFiHub are from Treasury in StaFi Chain, 2 Mil FIS rewards to the validators each year in StaFiHub for their contribution to the network, the reward rate is about 2%. Supporting security by continuously distributing reward to appchains is not sustainable, either it can’t gain a big staked TVL, nor it can’t reward more to the validators. The current StaFiHub is permissioned, it also brings concern to the coming stakers.

The motivation is simple here, aiming to more rToken TVL by eliminating the security concern. StaFi Protocol has experience in launching LSTs in EVM chain, deployment in a smart contract layer and gaining security from the underlying layer will change the security model of rToken, it is called decoupling.

Neutron is a one of the few blockchains in Cosmos that brings Smart Contracts into the Cosmos using [CosmWasm](https://cosmwasm.com/), it is secured by the Cosmos ICS, fully inheriting the security from CosmosHub, where StaFiHub can gain security from CosmosHub.

**Specifics**

**The Redeployment**
The redeployment of the StaFiHub in Neutron not only changes the security model of the appchain, but also updates many aspects, such as the way that stakers interact to the rToken app, the usage of FIS in the Cosmos ecosystem, the rBridge, the rDEX, it also changes the way how StaFi rToken solution serve to the CosmosSDK based projects and etc. Ultimately, although the redeployment will take up a lot of resources, it is worthy to do it for security and sustainability.

**How to?**
Combing the Nuetron’s ICS(Interchain Security), ICA(Interchain Communication) and ICQ(Interchain Query), the StaFiHub can be restructured as below. The core part of StaFiHub will be a set of CosmWasm smart contracts, the Off-chain service will manage the era trigger and validator selection.
![](https://dao.stafi.io/uploads/default/optimized/1X/bed9f355cbcfb5ca14fe51f14120856b4a829108_2_1178x1000.jpeg)
Deployment in Neutron will form new user flows as well. If you want to stake ATOM, new ATOM will go to contract of Neutron via the IBC hook on the Cosmos Hub network, instead of going to appchain directly, and contract will handle the rToken minting and sends the corresponding amount back to the user via IBC/ICA/ICQ.

A following deep dive into the tech is needed, this proposal won’t go into it.

**Why Neutron?**

**Precondition**
StaFiHub will still remain in the Cosmos ecosystem and sever as a LSD solution for CosmosSDK based projects, while enjoying the IBC(interchain community) infrastructure for easily enabling the interoperability and maximally maintain the usability of the current structure of StaFiHub to save the recreation of flywheel.

**Comparison**
There are comparisons among the solutions that can be used to redeploy StaFiHub.
| Solutions | Smart Contracts（SC）| Permissionless | Security | Incentive | Validator | Development | Interoperability |
|------|------|------|------|------|------|------|------|
| Neutron | Yes | Yes | Cosmos ICS | No | No | 😀😀😀 | Yes |
| Cosmos ICS | No | No | CosmosHub | Yes | No | 😀😀 | Yes |
| Celestia DA | // | Yes | Appchain | Yes | Yes | 😀 | Yes |

Simply speaking, deployment in a Smart Contract(SC) platform will remove the validator set and kill the inflation of StaFiHub. ICS also supports non-validator sets, but incentives should be created to reward those validators who are willing to provide resources in CosmosHub(V1 Ver of ICS needs all validators in CosmosHub set to support consumer chains), that does not kill the inflation with ICS. Celestia mainly supports Data availability and modules that bring flexibility in development, but there will not be a big difference in the change of economic set when using Celestia. Other Smart Contract platforms in Cosmos eco, such as Juno and Evmos, deployment is workable but I don’t recommend at the current stage as the lack of dev community, and their underlying security is still appchain.

For the conclusion, there are principles for selecting layers.

1. Security Model: **Cosmos ICS → CosmosICS+SC → CosmosSDK Appchain + SC → CosmosSDK Appchain**
2. Economic Model: **CosmosICS+SC → Cosmos ICS → CosmosSDK Appchain + SC → CosmosSDK Appchain**

**Where now**
Neutron and Stride can represent Cosmos ICS(StaFiHub can be one)
Neutron represents CosmosICS+SC(Only one atm)
Evmos and Juno represents CosmosSDK Appchain + SC
StaFiHub represents CosmosSDK Appchain

StaFiHub can apply to be a Cosmos consumer chain using ICS, but it is complex(even ‘permissionless’), but StaFiHub will still need to face the economic sustainability issues. For better security and economy, Neutron is an optimal solution.

**Former works**
The decoupling is ongoing, see progresses

1. [Some of the Bridges connections are removed](https://dao.stafi.io/t/sip-6-proposal-to-remove-redundant-bridges-on-the-rbridge/107/1)
2. [rDOT and rKSM are removed from StaFiChain appchain, rSOL is migrated from StaFiChain to Solana](https://dao.stafi.io/t/sip-9-remove-rdot-and-rksm-from-stafichain-migrate-rsol-to-the-solana/130/1).

**Possible Actions**
If this proposal works, there will be the following actions needed before the relaunch.
1. StaFi-Neutron solution of rToken only supports ICA(Interchain account) enabled CosmosSDK based chain, while current IRISnet and Chihuahua do not support ICA, a discussion on how to deal with the rIRIS and rHUAHUA should be raised in a later stage.
2. The ICA enabled chains, Carbon(rSWTH) and CosmosHub(rATOM) should be migrated to the StaFi-Neutron, a following plan should be raised and well discussed.
3. Infra and builtin apps, such as IBC relayer, rBridge and rDEX, should be discussed how to move to the next(cease or migrate).
4. The Inflation set of FIS in the Cosmos ecosystem should be well discussed, how to move to the next steps, and what is the strategy.

**Vote**
For: Support migrate StaFiHub to Neutron.
Against: Do nothing.

Please read the full SIP [here](https://dao.stafi.io/t/discussion-draft-migrate-stafihub-to-neutron/143).


[Discussion Draft] Migrate StaFiHub to Neutron

**Abstract**
To further enhance the security model of StaFiHub rTokens, this SIP is a follow-up proposal to the [Tokenomic 2.0](https://dao.stafi.io/t/sip-2-stafi-tokenomics-v2/84), moving the rToken decoupling forward to the native chain. The idea here preferably proposes to migrate StaFiHub to [Neutron](https://www.neutron.org/) after comparing the deployments among Cosmos ICS(Interchain security), Smart Contract platforms and Celestia DA.

**Motivation**
StaFiHub is an appchain of the StaFi Protocol that serves the CosmosSDK based projects to issue LSTs. In the Tokenomic 2.0, decoupling rToken from the appchain security to the native chain security is essential, the solution is to migrate StaFiHub deployment from a solo chain to a native chain, hence gain a high level security, especially from the aspect of economy. The TVL of rToken in StaFiHub is about $2.5Mil, while the FIS staked value of StaFiHub appchain is about $1.05mil(3mil FIS), for further increase target of rToken TVL, a consumption is the stake value of an appchain should be far more than TVL built upon on chain.

Currently, the FIS stakes of StaFiHub are from Treasury in StaFi Chain, 2 Mil FIS rewards to the validators each year in StaFiHub for their contribution to the network, the reward rate is about 2%. Supporting security by continuously distributing reward to appchains is not sustainable, either it can’t gain a big staked TVL, nor it can’t reward more to the validators. The current StaFiHub is permissioned, it also brings concern to the coming stakers.

The motivation is simple here, aiming to more rToken TVL by eliminating the security concern. StaFi Protocol has experience in launching LSTs in EVM chain, deployment in a smart contract layer and gaining security from the underlying layer will change the security model of rToken, it is called decoupling.

Neutron is a one of the few blockchains in Cosmos that brings Smart Contracts into the Cosmos using [CosmWasm](https://cosmwasm.com/), it is secured by the Cosmos ICS, fully inheriting the security from CosmosHub, where StaFiHub can gain security from CosmosHub.

**Specifics**

**The Redeployment**
The redeployment of the StaFiHub in Neutron not only changes the security model of the appchain, but also updates many aspects, such as the way that stakers interact to the rToken app, the usage of FIS in the Cosmos ecosystem, the rBridge, the rDEX, it also changes the way how StaFi rToken solution serve to the CosmosSDK based projects and etc. Ultimately, although the redeployment will take up a lot of resources, it is worthy to do it for security and sustainability.

**How to?**
Combing the Nuetron’s ICS(Interchain Security), ICA(Interchain Communication) and ICQ(Interchain Query), the StaFiHub can be restructured as below. The core part of StaFiHub will be a set of CosmWasm smart contracts, the Off-chain service will manage the era trigger and validator selection.
![](https://dao.stafi.io/uploads/default/optimized/1X/bed9f355cbcfb5ca14fe51f14120856b4a829108_2_1178x1000.jpeg)
Deployment in Neutron will form new user flows as well. If you want to stake ATOM, new ATOM will go to contract of Neutron via the IBC hook on the Cosmos Hub network, instead of going to appchain directly, and contract will handle the rToken minting and sends the corresponding amount back to the user via IBC/ICA/ICQ.

A following deep dive into the tech is needed, this proposal won’t go into it.

**Why Neutron?**

**Precondition**
StaFiHub will still remain in the Cosmos ecosystem and sever as a LSD solution for CosmosSDK based projects, while enjoying the IBC(interchain community) infrastructure for easily enabling the interoperability and maximally maintain the usability of the current structure of StaFiHub to save the recreation of flywheel.

**Comparison**
There are comparisons among the solutions that can be used to redeploy StaFiHub.
| Solutions | Smart Contracts（SC）| Permissionless | Security | Incentive | Validator | Development | Interoperability |
|------|------|------|------|------|------|------|------|
| Neutron | Yes | Yes | Cosmos ICS | No | No | 😀😀😀 | Yes |
| Cosmos ICS | No | No | CosmosHub | Yes | No | 😀😀 | Yes |
| Celestia DA | // | Yes | Appchain | Yes | Yes | 😀 | Yes |

Simply speaking, deployment in a Smart Contract(SC) platform will remove the validator set and kill the inflation of StaFiHub. ICS also supports non-validator sets, but incentives should be created to reward those validators who are willing to provide resources in CosmosHub(V1 Ver of ICS needs all validators in CosmosHub set to support consumer chains), that does not kill the inflation with ICS. Celestia mainly supports Data availability and modules that bring flexibility in development, but there will not be a big difference in the change of economic set when using Celestia. Other Smart Contract platforms in Cosmos eco, such as Juno and Evmos, deployment is workable but I don’t recommend at the current stage as the lack of dev community, and their underlying security is still appchain.

For the conclusion, there are principles for selecting layers.
1. Security Model: **Cosmos ICS → CosmosICS+SC → CosmosSDK Appchain + SC → CosmosSDK Appchain**
2. Economic Model: **CosmosICS+SC → Cosmos ICS → CosmosSDK Appchain + SC → CosmosSDK Appchain**

**Where now**
Neutron and Stride can represent Cosmos ICS(StaFiHub can be one)
Neutron represents CosmosICS+SC(Only one atm)
Evmos and Juno represents CosmosSDK Appchain + SC
StaFiHub represents CosmosSDK Appchain

StaFiHub can apply to be a Cosmos consumer chain using ICS, but it is complex(even ‘permissionless’), but StaFiHub will still need to face the economic sustainability issues. For better security and economy, Neutron is an optimal solution.

**Former works**
The decoupling is ongoing, see progresses

1.[ Some of the Bridges connections are removed](https://dao.stafi.io/t/sip-6-proposal-to-remove-redundant-bridges-on-the-rbridge/107/1)
2. [rDOT and rKSM are removed from StaFiChain appchain, rSOL is migrated from StaFiChain to Solana](https://dao.stafi.io/t/sip-9-remove-rdot-and-rksm-from-stafichain-migrate-rsol-to-the-solana/130/1)

**Possible Actions**
If this proposal works, there will be the following actions needed before the relaunch.
1. StaFi-Neutron solution of rToken only supports ICA(Interchain account) enabled CosmosSDK based chain, while current IRISnet and Chihuahua do not support ICA, a discussion on how to deal with the rIRIS and rHUAHUA should be raised in a later stage.
2. The ICA enabled chains, Carbon(rSWTH) and CosmosHub(rATOM) should be migrated to the StaFi-Neutron, a following plan should be raised and well discussed.
3. Infra and builtin apps, such as IBC relayer, rBridge and rDEX, should be discussed how to move to the next(cease or migrate).
4. The Inflation set of FIS in the Cosmos ecosystem should be well discussed, how to move to the next steps, and what is the strategy.

**Vote**
For: Support to migrate StaFiHub to Neutron.
Against: Do nothing.

Please read the full SIP [here](https://dao.stafi.io/t/discussion-draft-migrate-stafihub-to-neutron/143).

The proposal to migrate StaFiHub to Neutron

**Introduction**
rLaunchpad program is a community-driven initiative designed to sustainably expand the StaFi ecosystem and introduce new rTokens to the platform. This proposal outlines the program’s structure, lifecycle, core units, participation guidelines, and future plans.

**What is rLaunchpad?**
rLaunchpad is a community-led program that empowers StaFi’s FIS token holders to select promising Layer 1 projects for integration into the StaFi ecosystem. Through a voting process, FIS token holders can choose the most compelling project proposals, paving the way for the introduction of new rTokens on the StaFi platform.

StaFi provides a variety of services to launchpad participants, including:
- rToken backend technical development
- rToken frontend UI development
- rToken technical support after launch
- Marketing and community building support

**rLaunchpad Lifecycle**
The rLaunchpad lifecycle encompasses several key stages:
**1. Project Listing Proposals:** Layer 1 projects or StaFi DAO draft initial project listing proposals, highlighting potential Layer 1 projects for integration.
**2. Community Voting:** StaFi FIS token holders cast their votes to select the most promising Layer 1 project from the proposed list.
**3. Development Evaluation:** The StaFi development team assesses the development costs and feasibility of integrating the chosen project.

**💡 Note:** In addition to 61Lab, the community and foundation can also promote the participation of third-party teams in development, or lead a team. We will then release an open plan. This plan will be based on one-time incentives and subsequent rToken yield incentives. Before that, 61Lab, as the builder of the Stafi protocol, will continue to develop new rTokens.

**1. Development and Launch:** Upon successful evaluation, the StaFi development team initiates the integration process and launches the new rToken on the StaFi rToken app.
**2. Incentivization Programs:** To attract users and encourage staking, each new rToken will undergo targeted mining campaigns and incentive programs.

**⚠️ Note:** StaFi Dao and community will monitor the performance of these teams and adjust the incentives as needed. If an rToken is not performing well, StaFi Dao may consider delisting it. This would be done to protect the interests of the Stafi community and to ensure that only high-quality rTokens are listed on the platform.

**Core Units of rLaunchpad**
The rLaunchpad program revolves around three core units:
**1. Community:** The StaFi community, represented by FIS token holders, plays a pivotal role in selecting promising Layer 1 projects, in the near future, we will also take corresponding layer 1 community members’ vote into consideration.
**2. StaFi DAO:** The StaFi DAO facilitates the project proposal process and ensures community engagement throughout the rLaunchpad lifecycle.
**3. StaFi Development Team:** The StaFi development team / cooperated development team evaluates project feasibility, oversees development, and launches new rTokens.

**How to Join**
To participate in the rLaunchpad program, StaFi FIS token holders can:

1. Stay informed about project listing proposals through the StaFi forum and community channels.
2. Actively participate in the voting process to select the most promising Layer 1 project.
3. Contribute to discussions and feedback on the rLaunchpad program’s evolution.
4. Take part in monitoring the performance of those new listed rTokens and deciding incentives and delisting adjustments as needed.

**Future Work If Passed**
We are committed to continuously improving the rLaunchpad program and expanding its scope once it gets passed. Future plans include:

1. Exploring alternative voting mechanisms to enhance community participation.
2. Introducing a more comprehensive project evaluation framework.
3. Developing innovative incentive programs to attract users and promote rToken adoption.
4. Expanding the rLaunchpad program to include other types of projects beyond Layer 1 integration.

**Conclusion**
The rLaunchpad program aligns with StaFi’s mission to operate sustainably and empower the community. By introducing new rTokens based on community votes, StaFi fosters a decentralized and inclusive approach to ecosystem expansion.

We are currently in the process of gathering feedback from the community on this proposal. A series of community discussions and polls will be hold to gauge interest and gather suggestions. We encourage you to participate in these discussions and share your thoughts on the proposal.

**Project Participation Guidance**

**Project Application Process**
To apply for the StaFi Launchpad, please follow these steps:
1.Submit a completed application proposal in StaFi forum according to the guidance.
2.Provide a detailed overview of your project, including the following information:
- Chain Name: The name of the layer 1 chain that the protocol is launching its liquid staking solution on.
- Applying Reasons: The reasons why the protocol is applying to launch its liquid staking solution on the StaFi rLaunchpad.
- Provided Liquidity: The amount of liquidity that the protocol offer for its liquid staking solution through rLaunchpad will be carefully considered to maintain a healthy token economy and prevent excessive token dilution. Ideally, the initial token amount should fall within the range of $1-$5 million USD or represent 1%-3% of the overall token ratio.
- Predicted TVL Once Launched: The predicted TVL of the protocol’s liquid staking solution once launched.
- Chain TVL and Information: The TVL, Tokenomics and other relevant information about the protocol’s chain.
- Contact Person: The contact information for the protocol’s team.

3.Explain why you are interested in launching on the StaFi Launchpad.
4.Provide a roadmap for your project.
5.Submit any other relevant information that you think would be helpful for the StaFi DAO to evaluate your application.

**Project Criteria**
The StaFi DAO will evaluate applications based on the following criteria:

- Mainnet: The protocol must have a working mainnet.
- Commitment: The protocol must be committed to working with StaFi to ensure the success of its liquid staking launch. This includes cooperating with StaFi on marketing and community building initiatives to promote the LST token after launch.
- TVL: We consider TVL to be one of the most important criteria for rLaunchpad listing, as it is a key indicator of a project’s adoption and liquidity. A high TVL will benefit both the project and the StaFi community, as it will increase the demand for the project’s LST token.
- Team: The StaFi DAO will look for projects with experienced and qualified teams in order to have sustainable cooperation.
- Tokenomics: The StaFi DAO will look for projects with well-designed tokenomics.
- Use cases: The StaFi DAO will look for projects with clear and compelling use cases.

**Project Selection**
The StaFi DAO will select a limited number of projects to participate in the StaFi Launchpad each season.

**1. List Proposal (Apply Listing)**
Projects interested in participating in the StaFi Launchpad must submit an application. The application should include a brief overview of the project, its team, its liquid staking solution, and its marketing and community building plans.

**2. Community  Select (Forum application selection in community call) - Est. 2 Months / Call**
The StaFi DAO will review all applications and select a subset of projects to present their proposals to the community in a forum call. The community will then vote on which projects they would like to see participate in the Launchpad.

**3. SIP Vote (in Snapshot) - 7 Days Voting Period**
The StaFi DAO will then create a Snapshot proposal to list the projects that were selected by the community in the forum call. The DAO will vote on the proposal by FIS / rFIS token in ERC20 format to confirm the final list of projects that will participate in the Launchpad.

**4. List confirm - Est. 7 Days**
Once the SIP proposal is passed, the StaFi team will work with the selected projects to confirm their listing and finalize the launch procedures and requirements.

**5. Develop - Normally 2-3 Months**
In the early stages, the 61lab team will develop the LST tokens for the selected projects and integrate them into the rToken App. In the future, third-party development teams can apply for funding to develop LST tokens. However, the results of third-party development still need to be reviewed by the 61lab team.

**6. Launch (in rToken App)**
The LST tokens for the selected projects will be launched in the rToken App, where users will be able to stake their native tokens to earn rewards.

It is important to note that this is just a high-level overview of the selection process. The StaFi DAO may make changes to the process at any time.

**Benefits**
Projects that participate in the StaFi Launchpad benefit from a variety of advantages, including:
- Access to a large and engaged community of investors.
- Marketing and community building support from the StaFi.
- Technical assistance with the rToken launch process.
- Possible co-incentive campaigns and revenue sharing benefits.

**Vote**
For: Support StaFi rLaunchpad Program.
Against: Do nothing.

Please read the full SIP [here](https://dao.stafi.io/t/sip-10-rlaunchpad-program/140/1).

[SIP-10] rLaunchpad Program

Abstraction
As described in StaFi [Tokenimic V2](https://dao.stafi.io/t/sip-2-stafi-tokenomics-v2/84), continuously decoupling rTokens from appchain security is essential to scale StaFi LSD solution. rBNB and rMatic have completed the decoupling, gained security from BSC and Polygon directly, and the whole process is going well. Next step is to migrate rDOT, rKSM and rSOL. After deeply reviewing the stat of the contributions at a protocol level, I propose to remove rDOT/rKSM, while migrating rSOL to Solana only.

With the coming launch of rLaunchpad, a product that sustains the development of rTokens in the future LSD market, StaFi protocol will extend the capability to roll on the new release of the rToken, hence, keep the StaFi Tokenomic scalable.

In a nutshell, this is a proposal to migrate the remaining rTokens in the StaFi chain to the target chain while making sure the future plan can support the developing growth in the LSD industry.

**Motivation**
While considering the migration, we think the value added from the migration, as this migration will be a heavy workload arranged to the dev team. To save the limited development resource, we have to think about the following factors, which should be reasonable to benefit the protocol:

- Protocol contribution

Staked TVL and gained reward are two important factors to evaluate the contribution. Those 2 factors are positively related, rewards are from a percentage of staking reward, while staking reward is proportional to its staked value, which means a big staked TVL will lead to more rewards. It is clear to check the rTokens contribution and make a decision.

- Tech possibility

In order to be more decentralized, decoupling needs technical support from protocol level. rToken solution, theoretically speaking, can be deployed in any PoS layer1s, while the solution has to sacrifice some meaningful specifications to some extent, such as decentralization, UIUX and security. Most of the decouplings are aiming for interoperability and scalability, hence, an EVM-based rToken in target chain is ideal. Migration should think about its relaunch and see if it can be well supported and make sure the top priorities can be guaranteed.

- Future development

We also have to think about its future development if we input the dev resources. Without the TVL and reward, and even there is no foresee on its growth potential, removal should be the right direction. There are trending projects in the marketing, especially in Crypto, technology is growing rapidly, always following the trends can expose StaFi to more and more communities.

Taking these 3 aspects into account, I can come to a conclusion on the migration, rDOT and rKSM should be removed, rSOL should be migrated.
| Reasonable Aspect | rDOT | rKSM | rSOL |
| ------------ | -------------- | --- | ---------------|
| Staked TVL | Relatively low | Low| Relatively low |
| Contribution | Relatively low | Low| Relatively low |
| Tech support | Inaccessible | Inaccessible | Accessible |
| Development | Relatively Inactive | Inactive| Active |

Furthermore, seeing from the the [analytics](https://analytics.stafi.io/), rKSM has $3.993K in staked and rDOT $72.129K, both contribute relatively low that can be even ignored in a day(marked at the end day of Oct). rSOL has $58.018K in staked and contribute a relatively low in a daily base as well, an average reward can be calculated, StaFi protocol collects rKSM 0.003 ksm/ day, rDOT 0.5334966225 dot/day, and rSOL 0.126804645 sol /day. However, the tech possibility is accessible and the development activities in Solana are still active. If you compare the Polkadot/Kusama, I can foresee the future development of rSOL while I can’t see the rDOT and rKSM.

More importantly, there is no direct solution that rDOT and rKSM can be deployed in Polkadot or Kusama as their relay-parachain module. The EVM compatible parachain, such as Moonbean is the option, but the rToken solution will be more distorted in a decentralization manner, if rDOT deployed in Moonbean, so even someone has different scene of Polkadot and Kusama in the future, the second aspect is an obstacle for the migration.

**Specification**
The strategy of migration and removal are similar to before operations, migration can follow the same route of [rBNB](https://dao.stafi.io/t/sip-3-a-new-implementation-of-rbnb-using-evm-lsd-architecture/87), while removal can follow the route of [rBridge](https://dao.stafi.io/t/sip-6-proposal-to-remove-redundant-bridges-on-the-rbridge/107).

**Migrate rSOL to Solona**
Same strategy to rBNB and rMATIC, rSOL will be rebuilt, then redeployed to Solana. As the Solana is EVM compatible, there will be 2 options to deploy rSOL. The first is to deploy the Solana chain directly, the second option is to deploy in Neon, an EVM with the scalability and liquidity of Solana. The second solution is similar to rBNB and rMatic, but it depends on the growth of the projects in the Neon ecosystem, not Solana itself. I think the dev team still needs to balance the development resource and growth demands, then determine a final solution.

Once decided, the rSOL will enter into a development stage, the bridge migration will follow this direction as well. A detailed plan will be released if the proposal gets passed.

**Remove rDOT and rKSM**
An unstaked period is set to enable the removal from the users side. Considering the unstake period of rDOT is about 28-day long, the unstaked period will last for months.

Beside that, we will follow the rule set in the migration of rBridge, there will a deadline for unstaking rDOT and rKSM, the frontend service will be removed firstly and then the back end, there will be no service for the non-unstaked user to redeem their staked DOT and KSM after the deadline.

**Risk**
There is no foreseeable risk seen in this proposal. The migration of rSOL is a relaunch, so a new audit is needed.

**Next Step**
This is a proposal to collect feedback from the community, any ideas are welcome. The StaFi Governance is building alongside with the proposing, there is no certainty which process will be launched beforehand, we will wait and see if this proposal can be voted from the governance.

**rLaunchpad**
rLaunchpad needs to be introduced to develop the new rToken in a scalable way, more detailed plans should be planned and get approved by the community.

**Vote**
For: Support StaFi to remove rDOT & rKSM from StaFiChain, migrate rSOL to the Solana.
Against: Do nothing.

Please read the full SIP [here](https://dao.stafi.io/t/sip-9-remove-rdot-and-rksm-from-stafichain-migrate-rsol-to-the-solana/130).

[SIP-9]Remove rDOT and rKSM from StaFiChain, migrate rSOL to the Solana

Motivation
DVT (Distributed Validator Technology) enhances the decentralization and security of ETH staking. Currently, SSV DVT integration into StaFi has been deployed on the mainnet, and SSV has launched the [Mainnet incentive program](https://forum.ssv.network/t/incentivized-mainnet-program/1203). Additionally, the successful completion of SSV Grants Milestone 3 requires the operation of 25 validators on SSV.

To drive the adoption of SSV within StaFi, and acquire more ETH staking, the core team proposes the following measures:

- Staking treasury ETH in StaFi.
- Applying for approximately 400,000 FIS from the DAO treasury to incentivize new ETH staking and facilitate ETH exchanges.
- Migrating a portion of the existing trust node validators run by the foundation to SSV.

**Specification**
The [SSV grants program](https://forum.ssv.network/t/incentivized-mainnet-program/1203) consists of three milestones:
- Testnet integration and launch, $10,000 SSV token.
- Mainnet integration and launch, $10,000 SSV token.
- Running 25 validators on SSV, $20,000 SSV token.

Currently, [two milestones](https://forum.ssv.network/t/ssv-x-stafi-grant-proposal-protocol-integration/1089) have been completed and one has been accepted. To further drive SSV adoption and complete the grants program, new ETH staking is needed in StaFi.

StaFi will acquire new ETH through the following methods:
Firstly, 5% of the rewards obtained from users’ ETH staking in StaFi will be allocated as a commission fee to the DAO treasury. This amounts to approximately 101 ETH, which can run 3 validators. Extracting this portion and staking it in StaFi requires development efforts and contract upgrades. To support this quickly and complete the acceptance and rewards of grants milestone 2, approximately 360,000 FIS will be needed to exchange for 64 ETH(taking into account the pool’s buffer of 32 ETH).

Secondly, ETH staking incentives can be used to quickly acquire new ETH for staking. Based on past statistics, around 38,000 FIS can acquire approximately 330 ETH staking, equivalent to approximately 10 validators. However, this incentive also has its tradeoff, as the withdrawal option is currently available. This means that newly acquired ETH may be withdrawn by users after they receive the incentive.

Lastly, if the quantity is still insufficient, migrating existing trust node validators run by the foundation to SSV will be considered.

Economically, although the DAO treasury needs to allocate FIS, it can be compensated through SSV grants and incentives. Upon completing grants milestone 3, $20,000 worth of SSV tokens will be added to the DAO treasury. Additionally, the SSV mainnet incentive will continue until September next year. If each validator receives an average median of 51.14 SSV tokens per month, and considering 25 validators running for 10 months, approximately 12,785 SSV tokens will be obtained. Based on a valuation of $13/SSV token, this amounts to approximately $170,000, which will also be added to the DAO treasury. The income from these two sources will exceed the expenditure of 400,000 FIS. Thus, from an economic standpoint, this approach appears viable, disregarding the costs associated with SSV network fees and operator fees.

**Action**
If this proposal undergoes thorough community discussion without any objections, the DAO will stake the treasury ETH in StaFi and allocate 400,000 FIS from the DAO treasury for ETH staking incentives and exchanges. If the aforementioned measures still cannot meet the requirement for 25 validators, the remaining quantity will be migrated from the some of the trusted validators run by the foundation to SSV as a last resort.

Vote
For: Support StaFi DAO to stake the treasury ETH in StaFi and allocate 400,000 FIS from the DAO treasury for ETH staking incentives and exchanges.
Against: Do nothing.

Please read the full SIP [here](https://dao.stafi.io/t/boosting-dvt-adoption-and-decentralization-of-ethereum-staking-through-collaborative-co-incentive-programs-with-ssv/133).

Boosting DVT Adoption and Decentralization of Ethereum Staking through Collaborative Co-Incentive Programs with SSV

## Motivation

StaFi is committed to achieving decentralization and becoming a contributor-driven DAO. A crucial step in this process is engaging the community through proposal submission and voting. This inclusive approach empowers FIS and rFIS holders to actively participate in the governance of the StaFi protocol by submitting and voting on proposals.

## Specification

### **Submitting A Proposal**

- **Conception:** Proposal author Proposal authors can submit new proposals on the [StaFi forum](https://dao.stafi.io/c/proposal/5) under the “**Proposal/Finance” category** and adds the Discussion Draft tag.
- **Request for Comments(RFC):** A period of reviewing by the community and attendant redrafting begins. The minimum duration of this period is one week.
- **Fulfilled Feedback Period Requirements:** After the proposal has fulfilled the RFC phase, it is ready for Formal Submission.
- **Formal Submission:** Once the proposal has successfully fulfilled the feedback requirements of the RFC phase, it moves on to Formal Submission. And the proposal is published on the [OpenSquare](https://voting.opensquare.io/space/stafi) for FIS/rFIS holders to vote on. The minimum duration of voting is one week. The type of voting is single choice.
- **Accepted/Rejected:** The proposal is voted on. If it passes, it is officially accepted and is given the `Accepted` status. If not, the proposal is rejected.

Proposals can cover various categories, including StaFi Improvement Proposals (SIPs) that propose protocol enhancements, budget proposals, grants, and more. For financial-related proposals, it is recommended to submit them under the **"Finance" category** on the forum. If unsure about the specific category, proposals can be conveniently submitted under the general **"Proposal" category**.

Since FIS is the native token of the StaFi Chain built on Substrate, Snapshot compatibility is not available. Therefore, [OpenSquare](https://voting.opensquare.io/space/stafi) has been chosen as the voting tool, supporting both the StaFi Chain and Ethereum, which encompasses the majority of FIS/rFIS holders.

### Off-Chain Voting Progress

To initiate a vote on OpenSquare, a minimum of 10,000 FIS is required. This threshold has been set primarily for security considerations, which will be further discussed in the security section. Once initiated, both FIS and rFIS holders can participate in the voting process. Since the vote is conducted off-chain, only the verification of the token quantity held in the account is necessary. OpenSquare supports both ERC20 and the StaFi Chain native tokens.

The voting duration lasts for one week, and participants can select a single choice from the available options. FIS can be obtained from both centralized exchanges (CEX) and decentralized exchanges (DEX). For more details, please refer to the [provided information](https://docs.stafi.io/fistoken/). Additionally, if you are unable to acquire 10,000 FIS (equivalent amount of rFIS) but your proposal has been approved through the Request for Comments (RFC) process, the core team will assist you in initiating the vote on OpenSquare.

## Security

Ensuring security in the governance process, several measures have been implemented. Firstly, a threshold of holding 10,000 FIS (equivalent amount of rFIS) is required to initiate a vote. This threshold ensures that only holders with a significant investment can initiate a vote, reducing the risk of malicious governance attacks. Additionally, a **quadratic balance-of** strategy has been implemented to mitigate the influence of large holders on the voting process.

Furthermore, since our voting process is **permissionless**, it is possible for proposals to be directly submitted on OpenSquare without going through the community discussion process. While these proposals directly enter the voting phase, we consider them valid. However, to prevent misuse, we have introduced a **quorum** parameter in the voting mechanism. We have set the quorum at 40,000 FIS (equivalent amount of rFIS), meaning that a vote is only considered valid if it reaches the specified Quorum threshold.

These parameters and strategies will be managed by the DAO to ensure security. Additionally, due to OpenSquare's lack of support for dynamic exchange rate configuration, the voting power of FIS and rFIS can currently only be manually configured based on the exchange rate. Moreover, OpenSquare does not support floating-point exchange rates, so rounding is currently used for compatibility in the configuration. This may result in a deviation of 0.7 in the voting power. We will rely on OpenSquare's support for dynamic exchange rate configuration to address this issue.

## Future Work

The reason for not introducing an on-chain mechanism is that the governance framework for DAO is currently under discussion. There is a leaning towards choosing Ethereum for governance, which would be entirely different from the current governance conducted on the StaFi Chain. The progress of this matter can be tracked on the  [forum](https://dao.stafi.io/c/proposal/5), where you can also find updates and are welcome to join the discussion.

## Vote
A testing & experience vote for users is live on OpenSquare. For or Against? Exercise your right now!


Submit & Vote Proposals in StaFi DAO

## Motivation

StaFi is actively undergoing decentralization, aiming to become a permissionless, contributor-driven DAO. In order to enhance transparency and promote long-term sustainability, we are releasing the details of the DAO treasury. Here is the list of the treasury's contents:
| Address | FIS Amount | Available FIS Amount | rFIS Amount | Type |
| --- | --- | --- | --- | --- |
| [36JkR8Gzx2tAUaVzHeRQhbsfL5J14j1hrCrYo1F851FLcM4V](https://stafi.subscan.io/account/36JkR8Gzx2tAUaVzHeRQhbsfL5J14j1hrCrYo1F851FLcM4V) | 40,146 | 40,416 | 3,737,606 | Genesis(StaFi Chain) |
| [31XQjajM9x14JvUoXE6tMqkRzf2NfGxqmk45szTwHsF7vkq7](https://stafi.subscan.io/account/31XQjajM9x14JvUoXE6tMqkRzf2NfGxqmk45szTwHsF7vkq7) | 1,686,969.923 | 1,686,969.923 | 2,417,823 | Genesis(StaFi Chain) |
| [33UFoCxwXDJwWKKDBx6xp68X7rtBLXun5TvSxtoKmB6KwZnP](https://stafi.subscan.io/account/33UFoCxwXDJwWKKDBx6xp68X7rtBLXun5TvSxtoKmB6KwZnP) | 0 | 0 | 0 | Genesis(StaFi Chain) |
| [3327TuapxKGaDVaj6rSyywBQWmbZkiCNHRjfs8hCUzK3eeux](https://stafi.subscan.io/account/3327TuapxKGaDVaj6rSyywBQWmbZkiCNHRjfs8hCUzK3eeux) | 6,300,000 | 6,300,000 | 0 | Genesis(StaFi Chain) |
| [34e1uL9Y8pJnb2F13x1K3ppHJ4UF9txUYbM2CgqcdSewfsa2](https://stafi.subscan.io/account/34e1uL9Y8pJnb2F13x1K3ppHJ4UF9txUYbM2CgqcdSewfsa2) | 6,300,000 | 6,300,000 | 0 | Genesis(StaFi Chain) |
| [31ocHCL7Dw8YJC9zeHT7UXiA4ZgjDwzWQgphRKGbSX41fcCg](https://stafi.subscan.io/account/31ocHCL7Dw8YJC9zeHT7UXiA4ZgjDwzWQgphRKGbSX41fcCg) | 6,308,683.771 | 6,308,683.771 | 0 | Genesis(StaFi Chain) |
| [33DgUpArHKJgYMepNaqkXFEzYipuD8UYfZsXDmG8ZbHStWAw](https://stafi.subscan.io/account/33DgUpArHKJgYMepNaqkXFEzYipuD8UYfZsXDmG8ZbHStWAw) | 14,004,813.98 | 14,004,813.98 | 0 | Inflated reward(StaFi Chain) |
| [stafi1gy5jtfmxw9nyr0p4mkfh9lakegm3jxn3sjdvea](https://www.mintscan.io/stafi/address/stafi1gy5jtfmxw9nyr0p4mkfh9lakegm3jxn3sjdvea) | 4,224,875.39 | 52,568 | 0 | StaFiHub |

We have a total of 36,231,969.82 FIS and 6,155,429 rFIS in the Treasury, which includes both the Inflation Treasury and the Community Treasury allocated from Genesis Sumup. This represents approximately 34.61% of the total supply. 

Upon examination, it is evident that a significant portion of the FIS remains unused in the wallet balance, without being utilized by the core team or the community. This results in a substantial loss for the treasury and undermines the confidence of FIS holders. To address this issue and enhance the treasury's effectiveness, we propose staking the majority of the treasury FIS on the StaFi Chain.

Furthermore, we will ensure transparency by providing regular updates on the status of this portion of the treasury in the monthly financial reports. 

## Specification

Currently, the primary purpose of FIS in the treasury is to incentivize liquidity providers (LPs) to contribute liquidity to rTokens across various DeFi protocols and reward StaFi Hub validators for securing rTokens in the Cosmos ecosystem. LP incentives are regularly disclosed in the financial report, while the annual incentives for StaFi Hub validators amount to approximately 2 million FIS. Based on calculations, the combined annual expenses for LP and validator incentives total around 5 million FIS, which represents approximately 13.8% of the FIS held in the treasury.

To maintain flexibility and reserve funds for the next two years, as the one-year incentive of 2 million FIS for StaFi Hub is set to expire and requires reallocation. The plan is to designate approximately 9 million FIS (25%) as working capital, which includes the new one-year incentive for StaFi Hub. The remaining 27 million FIS will be staked on the StaFi Chain.

## Action

If this proposal undergoes thorough community discussion without any objections, the core team will proceed with staking approximately 27 million FIS on the StaFi Chain. The earnings generated from this staking and the expenses from the treasury will be transparently disclosed in the monthly financial report.

## Vote
For: Support StaFi DAO to stake Treasury FIS.
Against: Do nothing.

Please read the full SIP [here](https://dao.stafi.io/t/assessing-the-current-state-of-the-dao-community-treasury-and-the-potential-for-staking-fis/123).
You can read discussion around this in the forum thread.