RateSwap

• 

  Logo

Finals update:

Refer to the github repository: link

For the final round, I am excited to present the MVP front-end integrated with the orderbook and fyUSDC contract, as well as a deployable collateral management contract. The primary focus has been to continue to build out these projects, as well as shifting that building to the Neutron track. Users require testnet fyUSDC and USDC to place orders.

We chose to move to Neutron to take advantage of the permissionless deployment environment, making it advantageous for testing and development. We used the developer UI, CW20 templates, and cosmos front-end kit for this project.

This period has helped us to start to bring the project to life, the focus was to move quickly to chain, and continue to iterate as we test in a live environment. We have the base models for each component, and will work on refining each feature moving forward.

From a product perspective, it is clear that the focus will be on deep liquidity for the orderbook, which will require incentives for market makers, as well as the borrowers. Borrowers lock up capital, meaning their opportunity cost is higher than lenders, so moving forward with yield-bearing collateral will continue to be a priority. The RSP token providing collateralization discounts for borrowers will further help to align incentives and increase capital efficiency. For market makers, short term incentive may be sufficient as a means to bootstrap liquidity, for this airdrops and token compensation could be ideal. On top of that, reducing capital commitment to place multiple orders at different prices should reduce frictions.

Watch the original submission video here: link

Inspiration

The inspiration for Rateswap came from using a Pendle-based strategy for GST and then seeing that this was a suggested topic for this competition. Having researched previous attempts at stable yield on stable assets in the Cosmos ecosystem (i.e. UST), it was clear that there is a need and an opportunity for such a product.

What it does

Please refer to the concept paper here link

The project at its core is a CDP issuer that mints a fyUSDC derivative as the borrower's loan. Borrowers can then sell fyUSDC for USDC at a slight discount to use elsewhere in the ecosystems. When borrowers repay the loan, that value (1 fyUSDC = 1 USDC) is then passed forward to the fyUSDC holder, who redeems USDC and burns fyUSDC.

How we built it

This project is built using CosmWasm v0.14 for the smart contracts, and built on the Osmosis blockchain.

Challenges we ran into

I'm certainly not fluent in Rust, with some experience in Solidity instead, so learning the general logic and syntax was a challenge. There are still some open questions around certain interactions highlighted in the concept paper. Generally there isn't much precedence for dApps built on Osmosis, making accessing certain resources difficult.

Accomplishments that we're proud of

I'm very proud of the concept, I'm confident that the token adds value to the community, empowers them to take leadership within the project, and doesn't tax the core action space for users. Token holders truly benefit from maintaining the protocol, instead of diluting passive holders or imposing fees on regular users. The direction that the project is heading after the core MVP really shows how it can tightly integrate with the network, and offer something to users that is low friction and novel to the Cosmos ecosystem.

What we learned

Beyond hard skills, I learnt a lot about the Osmosis ecosystem and the development background. Setting up the local testnet and deploying lighter versions of the contracts was a big step in realizing the vision.

What's next for RateSwap

What's next is to keep developing. A MVP by the end of the finals possible is a realistic goal, beyond which the next steps outlined in the concept paper is truly the core goal. My immediate focuses for the next weeks are:

1. Oracle contract should just pull pool information (done)
2. Experiment with token factory for fyUSDC, won't need it's own contract and can handle everything from coll_man
3. Let liquidations be it's own contract, this way governance can change massive strategies without impacting core contract functionality. Start it off by auto-liquidating to GAMM pools
4. Built out RSP token contract, this one may be better as a dedicated CW20 contract
5. Add in contract to contract references, order of instantiation
6. Testing and bring on front-end member.

It is worth flagging that pending next steps, I have arranged for 1-2 additional members help with the front-end and testing phases.

Built With

• cosmwasm
• rust