**0. Introduce StaFi’s Liquid Staking Modularity Store**

StaFi is building a comprehensive Liquid Staking Modularity Store to better serve the evolving needs of liquid staking developers and protocols. While we’ve already developed a foundation of key modules, including tools like the Validator Selection AI Agent, Solana Blinks, and more (see Appendix for details), the next logical step is to create an open platform that invites developers to contribute and expand this ecosystem.

With this proposal, we aim to open up StaFi’s modular capabilities, encouraging al developers to co-create and innovate within LSaaS (Liquid Staking as a Service) and its Modularity. This open modular stack will allow developers to craft tailored solutions that enhance the staking experience for users and drive the future of liquid staking protocols.

Together, we can build a more robust and adaptable ecosystem that fosters collaboration, growth, and innovation in liquid staking.

**1. StaFi Modularity and its Functions**
StaFi Modularity is an open marketplace within the StaFi protocol ecosystem, designed specifically for LST (Liquid Staking Token) and LRT (Liquid Reward Token) protocols. This platform allows developers to create, upload, and distribute various modules that can be seamlessly integrated into different LST/LRT protocols. The goal is to offer end-users a richer, more personalized staking experience while promoting the StaFi LSaaS (Liquid Staking as a Service) brand—a development system tailored for LST and LRT.

**Module Functions:**
- **Enhanced Functionality:** Modules can introduce additional features to protocols, such as AI based validator selection strategy, automation processes, and data analytics, making LST/LRT protocols more flexible and efficient.
- **Improved User Experience:** By integrating different modules, protocols can offer higher-quality services and customized staking experiences, such as personalized yield optimization and real-time reward systems.
- **Ecosystem Expansion:** The modular design enables protocols to easily incorporate new features, driving innovation and diversity through the StaFi ecosystem.

**2. Developer Benefits from the StaFi Modularity App Store**

- **Exposure and Visibility:** By listing modules on the StaFi Modularity app store, developers gain exposure to a broad audience within the StaFi ecosystem. This increases the likelihood of module adoption by various LST/LRT protocols, enhancing their reach and impact.

- **Monetization Opportunities:** Developers can monetize their modules directly by setting their own prices, with all earnings going directly to them. This offers a clear and straightforward revenue stream, making it an attractive opportunity for developers to capitalize on their work.

- **Promotion and Marketing Support:** Outstanding modules receive additional promotion from the StaFi marketing members. This includes featuring on the official website and in other marketing channels, further boosting the module’s visibility and adoption.

- **Innovation and Collaboration:** The open marketplace fosters innovation by allowing developers to experiment with new ideas and collaborate with others in the ecosystem. This collaborative environment encourages the creation of cutting-edge solutions that can benefit the entire StaFi community.

**3. Module Integration Rules, Requirements, and Process**

**Module Integration Rules and Requirements:**

- **Technical Standards:** Modules must adhere to StaFi platform’s technical specifications, including interface definitions, data formats, and performance requirements. Developers should follow the provided technical guidelines to ensure compatibility.

- **Security:** Although formal code audits are highly recommended, they are not mandatory. Developers should ensure their modules are secure and free of vulnerabilities, with complete documentation provided.

- **Compliance:** Modules must not contain any content that violates legal regulations or StaFi platform terms of use, including illegal content, malicious code, or infringing materials.
User Experience: Modules should follow best practices for user experience, ensuring ease of use and intuitive interaction for end-users.

**Basic Module Integration Process:**
- **Developer Submission:** Developers create a pull request (PR) on GitHub, which should primarily include frontend code and corresponding LSaaS modularity documentation, adhering to the provided standards.

- **StaFi DAO Review:** The StaFi DAO reviews the submitted PR, focusing on code quality, security, and alignment with platform standards.

- **Module Listing:** Once the module passes the review, it is listed on the StaFi Modularity app store, making it available for integration by LST/LRT protocols.

**4. Review Process and Profit Sharing Mechanism**

**Review Process:**

- **StaFi Initial Review:** Modules undergo an initial review for security, performance, and compliance. The process is designed to be straightforward to encourage quick module deployment.

- **Feedback and Revisions:** If a module does not meet the requirements, developers will receive feedback and can revise the module for resubmission.

- **Highlighting Outstanding Modules:** Exceptional modules will be featured on the StaFi official website, with a possible dedicated introduction page. The StaFi marketing team will also support the promotion of these modules, increasing visibility and adoption.

**Potential Profit Sharing Mechanisms**

Since the StaFi Modularity Store is newly established and represents the industry’s first initiative of its kind, the current profit-sharing system is designed primarily for the initialization phase. As the platform evolves, the system’s details and approaches are expected to change over time. The early-stage model serves as a flexible foundation, with the potential for future enhancements based on developer feedback and market needs.

In the future, we foresee several potential profit-sharing models that could be introduced:
- **Tiered Pricing Models:** A system where different pricing tiers could be applied depending on the module’s complexity, popularity, or feature set. This could give developers more tailored monetization strategies based on the type of product they offer.

- **Revenue Sharing:** Exploring a revenue-sharing system in which StaFi and developers split the profits based on the performance and usage of their modules. This could incentivize developers to create high-quality modules with long-term value.

- **Subscription-Based Models:** Transitioning from one-time purchase options to subscription-based models that generate recurring revenue for developers. This model would benefit both developers and users by ensuring consistent updates and ongoing support for modules.

- **Long-Term Partnerships:** Establishing partnerships with developers to continually enhance and promote successful modules. Customized revenue structures and collaborative marketing efforts could be introduced as part of these partnerships.

**Initial Phase Profit-Sharing Approach**

At the start, the StaFi Modularity Store will implement the following straightforward and flexible models:

- **Module Pricing:** Developers will have full control over setting the prices for their modules, with a focus on one-time purchase models. StaFi will not take a commission from these sales, giving developers complete freedom in determining their pricing strategies.

- **Listing Fees:** Developers may be charged a listing fee by StaFi, depending on the module’s type and the nature of the collaboration. These fees will be assessed on a case-by-case basis, ensuring fairness and alignment with the value of the module being offered.

- **Incentives and Rewards:** To encourage the development of high-quality modules, StaFi will provide additional rewards for those achieving high usage or excellent ratings. Developers can also earn extra rewards by participating in platform-sponsored competitions or promotional activities, further boosting their visibility and success within the StaFi ecosystem.

This flexible system will be regularly reviewed and updated to ensure it meets the evolving needs of developers and aligns with the growth of the modularity store.

**5. Vote**
**For:** Support the proposal for liquid staking modularity App store.
**Against:** Do nothing.

Please read the full proposal [here](https://dao.stafi.io/t/liquid-staking-modularity-app-store/208).

***Appendix: Overview of Existing Modules***

*1. Validator Selection AI Agent*
- *Functionality: An AI-based validator selection tool that automatically selects the best validators for users based on historical data, real-time performance, and other key metrics.*
- *Purpose: Helps users choose the highest quality validators from multiple options, maximizing returns and minimizing risks.*

***2. Solana Blinks***
- *Functionality: The Solana Blinks module converts Solana actions into shareable links with rich metadata, enabling seamless on-chain interactions directly from any web interface, like triggering transaction previews in wallets.*

- *Purpose: This module enhances the StaFi ecosystem by providing LSaaS protocol users with easier, more direct interactions with the Solana blockchain, streamlining the staking experience across multiple platforms.*

***3. Point System***
- *Functionality: A point system module that allows protocols to issue points based on user activity and engagement. Points can be redeemed for rewards or used to elevate user levels.*

- *Purpose: Encourages users to actively participate in staking activities through gamification, thereby increasing user loyalty.*

***4. Chainlink Clip***
- *Functionality: A module that integrates Chainlink Oracles to provide real-time market data, offering reliable price feeds and external data access, ensuring protocol transparency and security.*

- *Purpose: Ensures that protocols can execute financial operations based on the latest and most accurate data, reducing risks and increasing user trust.*

***5. Frontend Module***
- *Functionality: This module offers a customizable user interface, allowing protocols to quickly build or update their front-end presentation layer without needing to design the UI from scratch.*
- *Purpose: It accelerates the frontend development process, enabling protocols to launch faster and enhance user interaction experiences.*

The Proposal For Liquid Staking Modularity App Store

# Proposal #
We propose to burn 100% of the FIS tokens that continuously flow into the treasury address. This action is intended to reduce FIS inflation from 10% to around 6%, transitioning the token towards a deflationary model.

# Motivation #
Given the current circulation of FIS tokens, we recommend implementing a burn strategy to control inflation. FIS tokens are currently used for rewarding LSaaS adopters, covering the protocol’s daily operations of the DAO and marketing efforts. The existing treasury can support these needs for several years.

As StaFi transitions from an rToken-based model to LSaaS(Liquid Staking as a Service), changes to the FIS tokenomics will further diversify income and strengthen support for FIS. With costs covered and continuous income, we believe we can effectively manage and reduce FIS inflation.

The initial goal is to reduce inflation from 10% to 4-6%. Once the protocol generates more value, we can aim to further reduce inflation to 1-3%. This will be achieved by activating the burn function, established in the chain’s genesis, and burning all inflated tokens flowing into the treasury.

As a first step, we propose burning 100% of the inflated FIS that goes to the treasury, moving towards a deflationary model for StaFi.

# FIS Circulation #
## Overview ##
FIS tokens were first generated on September 7, 2020, with StaFi Chain operational for nearly four years. Currently, the circulating supply is 145.829 million FIS. From the 10% inflation rate, 6.2% of inflated FIS goes to stakers and validators, while 3.8% is allocated to the address trsry([33DgUpArHKJgYMepNaqkXFEzYipuD8UYfZsXDmG8ZbHStWAw](https://stafi.subscan.io/account/33DgUpArHKJgYMepNaqkXFEzYipuD8UYfZsXDmG8ZbHStWAw)) in the treasury. All data can be viewed from the [Explorer](https://apps.stafi.io/#/explorer) or the [Subscan](https://stafi.subscan.io/).

## Inflation ##
StaFi has 2 appchains, StaFiChain and StaFiHub, FIS inflation is crucial for incentivizing validators and stakers to secure the network, similar to PoS models in Ethereum and Cosmos. And it can be seen as an important way to make the chains decentralized.

The inflation rate is fixed at 10% in the genesis of StaFiChain, with dynamic distribution based on staking rates, it determines how many FIS goes to trsry and how many FIS goes to the stakers and validators. Furthermore, part of trsry is allocated 2mil FIS yearly to reward validators in StaFiHub.

# FIS Treasury #
The StaFi Treasury was made public in 2023 and consists of three main components: inflated FIS, vested FIS from genesis, and protocol income generated from services like rETH and rATOM. Detailed information is available [here](https://dao.stafi.io/t/assessing-the-current-state-of-the-dao-community-treasury-and-the-potential-for-staking-fis/123). This paragraph provides an update on the Treasury.

## Inflated FIS ##
The address (trsry) ([33DgUpArHKJgYMepNaqkXFEzYipuD8UYfZsXDmG8ZbHStWAw](https://stafi.subscan.io/account/33DgUpArHKJgYMepNaqkXFEzYipuD8UYfZsXDmG8ZbHStWAw)) currently holds the majority of inflated FIS and continues to receive inflated FIS from StaFiChain. As of August 19, 2024, the total amount in this address is 18,458,032 FIS. Part of these funds are used to incentivize StaFi Hub validators, total 4mil FIS is distributed to addr stafi1exjtrqc6xlqvp502dwk5ac5y8867lk8444jv0x as the pool to reward validators.

## Vested FIS ##
Five multisig wallet addresses hold a total of 19,773,464 FIS, with 96.7% (19,123,343 FIS) staked.
|Multisign Wallet Address|FIS Amount|Staked|
| --- | --- | --- |
|[32khQjt9vK6HBcUGgVJsxQXwRXPz5E9E83WKuvfMoK5CnPw9](https://stafi.subscan.io/account/32khQjt9vK6HBcUGgVJsxQXwRXPz5E9E83WKuvfMoK5CnPw9)|1,782,342|1,782,342|
|[34wBXY2fzPnfikEXpGbUzqWV3r2B44iJgV5wPaB5YNrxpj3Z](https://stafi.subscan.io/account/34wBXY2fzPnfikEXpGbUzqWV3r2B44iJgV5wPaB5YNrxpj3Z)|3,112,346|3,112,315|
|[33aRRH6B8YyUBBhR2Cppj6s7S8dJfsmMpievnLiMY4JRUsmD](https://stafi.subscan.io/account/33aRRH6B8YyUBBhR2Cppj6s7S8dJfsmMpievnLiMY4JRUsmD)|3,130,309|3,130,226|
|[31FTe87cgmBdp4DueiCrEqVNoc4mpmwERQ2nGPyHduASuAEa](https://stafi.subscan.io/account/31FTe87cgmBdp4DueiCrEqVNoc4mpmwERQ2nGPyHduASuAEa)|4,153,830|4,153,823|
|[335ye5dGBCM74P1m6gfNytbUfk5cHVXnqBDvUakqvGANDp1Q](https://stafi.subscan.io/account/335ye5dGBCM74P1m6gfNytbUfk5cHVXnqBDvUakqvGANDp1Q)|3,066,911|3,066,911|
|[31VApuoJa5raPEzjQNKRjyrwuRsbN7YjHzrypxnPCwXLUAfo](https://stafi.subscan.io/account/31VApuoJa5raPEzjQNKRjyrwuRsbN7YjHzrypxnPCwXLUAfo)|4,527,726|3,877,726|

Two genesis addresses hold a total 6,155,429 rFIS, which equals 11,833,196.7096 FIS in stake.
|Address|rFIS Amount|Equal to FIS|
| --- | --- | --- |
|36JkR8Gzx2tAUaVzHeRQhbsfL5J14j1hrCrYo1F851FLcM4V|3,737,606|7,185,173.7744|
|31XQjajM9x14JvUoXE6tMqkRzf2NfGxqmk45szTwHsF7vkq7|2,417,823|4,648,022.9352|

Additionally, a portion of the FIS from the genesis allocation was designated for StaFi Hub. This staked value was intended to secure the network’s consensus and serve as an incentive for the rTokens campaign at the launch of StaFi Hub. Currently, this address holds 5,922,505.151361 FIS.

|Address|FIS Amount|
| --- | --- |
|[stafi1n0tpw5wtzderaftx8lfuzve39sx3gzsdgsjjqn](https://www.mintscan.io/stafi/address/stafi1n0tpw5wtzderaftx8lfuzve39sx3gzsdgsjjqn/)|5,922,505.151361|

## Protocol income ##
Protocol income is generated from fees charged by rToken services. You can find detailed information [here](https://analytics.stafi.io/). As of August 19, 2024, the total value of protocol income in FIS is approximately 2,373,903.
|Token|Amount|
| --- | --- |
|rETH|102.75|
|rFIS|579,790|
|rATOM|2,890|
|rMATIC|5,220|
|rBNB|40.45|
|rSOL|26.11|
|rIRIS|278,000|
|rHUAHUA|56,290,000|
|rSWTH|247,310|
|rSEI|144.83|

## Summary ##
The StaFi Treasury currently holds a total of 55,987,197.860 FIS, including 6,155,429 rFIS, which accounts for roughly 38.39% of the total supply. Of this, 55.82% is staked, while 44.17% remains in the treasury. Protocol income has accumulated approximately 2,373,903 FIS(value in FIS).

## Usage ##
Currently, treasury spending is made [public](https://dao.stafi.io/c/finance/14) on a monthly basis in the DAO forum. The focus of spending has shifted from DeFi incentives to LSaaS development and adoption. As LSaaS adoption grows, we know that spending will increase accordingly, although it is currently modest.

# FIS Burn Proposal #
We propose burning 100% of inflated FIS every 30 days that newly flow into the treasury address if the community passes the proposal. The current reserved FIS in the treasury remains sufficient to cover future expenditures, resulting in:

1. A total treasury of 55,987,197.860 FIS + Protocol income + 0% inflation FIS.
2. A decrease in FIS inflation from 10% to approximately 6%, depending on the staking rate.

**Tip:** Current FIS in address trsry should be transferred to the multisig address before activating the burning.

## Reasons ##
There are several compelling reasons to activate the burning mechanism on StaFiChain:
1. The burning mechanism was originally outlined in the 2019 White Paper, and now is the appropriate time to implement it to reinforce the value of the FIS token within the StaFi Protocol.
2. The current FIS reserves in the treasury are sufficient to cover anticipated expenditures for the coming years, based on the spending history over the past four years.
3. With the ongoing launch of more rTokens, protocol income is increasing, and the transition from StaFi rToken to LSaaS is expected to further boost revenue. We are confident in this direction and believe it will provide strong financial support for the protocol.
4. Reducing inflation from 10% to 0% should be the ultimate goal of the community. With protocol income covering all treasury expenses and providing rewards to stakers and validators, this would move StaFi towards a deflationary model.

## Future Burn ##
The goal of FIS is to establish a deflationary model that adds value for token holders. While the current burn proposal is a significant step, there are additional deflationary strategies we could consider in the future, including but not limited to:

**1. LSaaS Growth:** As LSaaS aims to help StaFi regain a strong position in the future LST/LRT market, we anticipate an increase in protocol income. Although the current reserves may not support a buy-and-burn mechanism at this time, it is a potential strategy we could adopt in the future as income grows.
**2. Further Inflation Reduction:** After implementing the current burn proposal, we could consider lowering the inflation rate of StaFiChain from 6% to around 1-3%, further strengthening the deflationary model.
**3. Decoupling rToken from StaFi Chain and StaFi Hub:** As StaFi progresses towards decoupling rToken from its appchains, FIS and rFIS could be migrated to an Ethereum contract as the primary chain. This would streamline processes by reducing unnecessary actions related to appchain cross-chain transactions.

All of these proposals must undergo thorough discussion within the community before being put to a vote. If approved, they should be carefully evaluated in light of the current business environment.

# Next Steps #
Discussion: The community must engage in a thorough discussion in the DAO forum, followed by a vote by FIS and rFIS holders after fully discussing.
Action: Upon approval, the development team will prepare for the upgrade, with the community finalizing it on a later date.

# Vote #
For: Support the proposal to burn 100% of the FIS tokens that continuously flow into the treasury address.
Against: Do nothing.

Please read the full [SIP](https://dao.stafi.io/t/fis-burn-proposal-discussion/203) here. You can read discussion around this in the forum thread.

FIS Burn Proposal

As mentioned in StaFi 2.0, StaFi's product positioning is shifting from being a Liquid Staking protocol for PoS chains to a Liquid Staking infrastructure provider. **This means that the positioning of rLaunchpad is also undergoing a change—from listing rTokens to listing LSD stacks.** 

Launchpad Introduction: [[SIP-10] rLaunchpad Program](https://proposals.stafi.io/proposal/sip10/)
rLaunchpad Season1 Vote: [[rLaunchpad #1] Season1 rToken Listing Vote](https://voting.opensquare.io/space/stafi/proposal/QmaeB2BV6AhWJEzjrGn33yfJRxXv9LVYnCXrGdWoKsJHjE)

**Season2 rToken/Stack Listing Proposal**
- [rBTC](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-rbtc-babylon-on-rlaunchpad-season2/187)
- [rVARA/Stack](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-rvara-on-rlaunchpad-season2/190)
- [rTON/Stack](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-rton-on-rlaunchpad-season2/191)
- [rMOVEMENT/Stack](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-rmovement-on-rlaunchpad-season2/193)
- [rALEO/Stack](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-raleo-on-rlaunchpad-season2/189)
- [rMONAD/Stack](https://dao.stafi.io/t/proposal-for-new-rtoken-listing-rmonad-on-rlaunchpad-season2/192)
- [Gravity Stack](https://dao.stafi.io/t/proposal-for-new-stack-in-lsaas-gravity/197)
- [Namada Stack](https://dao.stafi.io/t/proposal-for-new-stack-in-lsaas-namada/195)


[rLaunchpad #2] Season2 rToken/Stack Listing Vote

## 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.