Hey Scryptonauts! Submissions to this 7th Scrypto Challenge have been, once again, very impressive. As we are getting closer and closer to Babylon, there is no doubt that builders are building full speed with the submissions integrating more parts of the Radix tech stack! With this challenge, we required submissions to include a frontend using the Radix dApp Toolkit and the Radix Wallet Developer Preview to bring us closer to a more real feel of how a dApp can look like at Babylon. It is always great to see how the power of Scrypto and the Radix Engine are used to create innovative DeFi dApps.
There were a total of 17 submissions with varying ideas around DeFi, particularly in lending, trading, portfolio management, and perpetuals. Please note that the challenge was on Betanet, the blueprints have not been updated to RCnet.
As a reminder, each entry was judged based on the following five criteria:
- Quality and asset-orientedness of the code: did the participant show a good understanding of the asset-oriented programming paradigm?
- Breadth of functionality: the more we could do with the submitted package, the more points the participant got.
- Creativity of the concept: was the idea creative and original?
- Quality of the documentation and comments in the code: did the participant provide documentation to make it easier to understand the code?
Winner: FlashyFi by backyard-coder
FlashyFi is a re-envisioning of how flash loans work enabled by native features of Radix. Existing lending protocols currently implement flash loans by utilising a liquidity pool. Users would often have to lock their tokens into this liquidity pool to be lent out to borrowers, preventing users from using the tokens they locked in the liquidity pool. FlashyFi’s approach does not require users to deposit into a liquidity pool; instead, user’s would allow a central component (FlashyFi) to temporarily withdraw them, lend them to another user, and return them before the transaction ends. A transient token is used to guarantee that the money lent out will always be returned because a condition is imposed in the transient token that the money must be returned before the transaction can end, otherwise the transaction cannot succeed. Because these sequences of instructions happen within a single transaction, this happens almost instantaneously and the users lending out their tokens never truly feel the impact of their tokens being lent out. This is possible because accounts on Radix are fundamentally components. Having accounts on Radix as components enables your account to not only act as a collection of vaults to store your tokens and other assets, but also allows your accounts to be programmable with special methods and access rules. As a result, this primitive feature of Radix allows FlashyFi to facilitate a secure peer-to-peer transaction by using the tokens in your accounts as liquidity, guaranteeing that their tokens will be returned, and doing so in such a way that feels instantaneous and without impact to the user who is lending.
We liked this submission because it is a clever way of making use of Radix’s programmable accounts in a tangible and powerful way. We believe this submission can plant seeds into developers minds inspiring how smart accounts can be used to provide features that allow users to have maximum control and flexibility with their finances.
“As always, I had a lot of fun developing with Scrypto and the other Radix toolkits. With FlashyFi, I was able to implement an intriguing concept that likely would have been either impossible or significantly more difficult to develop on other chains. I would like to highlight that I had to write comparatively little Scrypto code. Instead, I was able to leverage the flexible access rule model and the transaction manifest extensively. These are core concepts of Radix that enable a wide variety of dApps to be created without requiring a substantial amount of code.
It was also really cool to see how, bit by bit, with Scrypto, the gateway, the frontend toolkit, and the mobile wallet, all the pieces are coming together and Babylon is becoming more and more tangible.” - backyard-coder
Backyard-coder will receive the first prize of $11,500 in XRD.
Stoichiometric by avincigu, Théodore, and Guillaume
Stoichiometric is an incredible submission that fully features a “DeFi ecosystem in a box”. It integrates 3 main features: a Decentralised Autonomous Organization (DAO), an “SUSD” stablecoin, and an Automated Market Maker (AMM). This submission orients around their Collateralized Debt Position (CDP) stablecoin. This means that the stablecoin(s) are backed by loans secured by overcollateralized assets. To maintain the value of the stablecoin, the value of the collateral of the loan needs to always exceed a percentage above the loan amount. If the value of the collateral decreases below this requirement, a portion of the assets are liquidated to maintain the value of the stablecoin to its stable value. Additionally, the submission includes a Decentralised Exchange (DEX) with every pair to include the SUSD stablecoin. The goal of the DEX is to concentrate as much liquidity around SUSD as possible using a constant-sum AMM. This approach would, in theory, create more stability around SUSD. Finally, the submission has a DAO system that controls the whole stablecoin ecosystem. The point of the DAO is to allow the users of the protocol to decide and allow new tokens to be used as collateral and new stablecoin protocols to enter the ecosystem.
This submission is a wonderful example of interoperability leveraging multiple components to bring about a cohesive DeFi experience. There was a lot to unpack with this submission winning points in every category, but the sheer size, quality, and compelling use of a “DeFi ecosystem in a box” led us to place this submission in second place. Where we had hoped that this submission shined as it did in other categories was more documentation to illuminate what makes different parts of the submissions great.
“We have always been very interested in CDP stablecoins and decided to take the time to understand them properly by doing this project. For this project, we have read a lot of different papers and our main inspirations were Uniswap, TraderJoe, Curve, and MakerDao but also our prior work on Beaker. As always, we tried not to make a simple copy of something existing but to propose something new from these inspirations. The beautiful thing about Scrypto is that, as the implementation is straightforward, it gave us more time to focus on the design of our project. Even though we already had some experience with Scrypto, we believe that both the quality and quantity of code we managed to deliver in only a couple of weeks perfectly reflects the simplicity of Scrypto.“ - avincigu
Avincigu will receive $9,500 in XRD, this reward is not distributed via Devpost or the official Scrypto DeFi challenge. This pull request was submitted as per the READ ME of the scrypto-challenges repository.
ScrillaLending by aus87 and errollgnargnar
ScrillaLending is an asset-oriented implementation of Liquity’s stablecoin and lending protocol concept with Scrypto. Users can borrow protocol stablecoins using XRD as collateral with 0% interest rate. It is a single collateral design with XRD as the designated collateral of the protocol to achieve more efficient liquidations and lower collateralization requirements (110%). Scrilla will not charge interest rate on loans, but instead will charge a small fee for interactions with the protocol. On the same note, users are also rewarded with protocol tokens for interactions with the protocol as well. When protocols reward users with tokens based on their activities, it is often that the protocol has to continuously perform computation, therefore rack up fees, just for the distribution of these reward tokens. The submission designed a scalable system to handle these mechanics in a cost efficient way using Batog’s derivation of scalable reward distribution. So instead of the protocol having to immediately send users their rewards at every interaction, the protocol accumulates all rewards earned across every user in a single vault to which the protocol will calculate the rewards earned for a single user when a user is ready to claim it.
Not all creative ideas need to stem purely from one’s own imagination. We always like to see novel dApp’s built on other platforms re-implemented in an asset-oriented way. This showcases a drastically more simplistic, yet elegant design; allowing more room for enhanced features. This submission highlights all of that making it a worthy winner of third place.
“I didn't have a single line of code or even an idea of what to build when this challenge was released. I have been exploring smart contract development for less than a year, so the fact that I was able to reproduce a functional version of Liquity's lending and stable coin platform in 5 weeks is still blowing my mind. Once you understand how Scrypto works, the ideas start flowing nonstop. When I hear people pitch project ideas, I find myself unconcerned about building the logic because I know everything I have tried has not only been possible with Scrypto, but also easy to implement. Scrypto along with the rest of the Radix tech stack is a game changer for the entire industry. I will definitely be building some crazy things like this on Radix and hope to one day move to full time development.” - aus87
Aus87 and errollgnargnar will receive $7,500 in XRD, this reward is not distributed via Devpost or the official Scrypto DeFi challenge. This pull request was submitted as per the READ ME of the scrypto-challenges repository.
In this category, we wanted to encourage more developers to build and experiment with more dApp ideas around perpetuals and lending. We were pleased to see how motivated developers were with the submissions we saw in this category. The submissions we saw below are what stood out to us and are awarded with $5,500 in XRD for both sub-categories.
Perpetuals: Cup Perps by zygomeb
zygomeb built Cup Perps with a novel twist to the concept of Perpetual Swaps. Perpetual Swaps are similar to derivative contracts in traditional finance, but where perpetuals differ to traditional derivative contracts is that perpetual contracts do not have an expiration date (hence “perpetuals”). Expiration dates in traditional derivative contracts serve an important function because its mechanics create a natural incentive for the price of the derivative contracts and the underlying asset to converge ensuring the two markets remain in equilibrium. The absence of expiration dates in perpetual swaps brings a need to have a different mechanism to create this same harmony in both sides of the perpetual swap market. And most perpetual swap markets do this through what’s called a funding rate mechanism. The funding rate is a daily payout to either side of the market (longs and shorts) holding perpetual swaps depending which direction the market moves and in what magnitude. The mechanism brings about similar incentives for participants to converge the price of the perpetual swap and its underlying asset.
Cup Perps focuses entirely on different aspects of the market. Instead of focusing on incentives to match the price of perpetual swaps and its underlying asset, it attempts to create a more balanced and dynamic trading environment by incentivizing liquidity on both sides of the trade. In traditional perpetual swaps, traders that take either long or short positions have no inherent mechanism to encourage balanced liquidity. As a result, one side of the market can become heavily weighted, leading to less dynamic trading and the potential for price manipulation by larger players as there may be drastically less liquidity on one side of the market over the other.
The submission highlights Scrypto’s ethos of providing developers the quickest path from an idea to prototype. While this concept is an experimental model and its effectiveness has yet to be fully evaluated, we enjoy seeing developers use Scrypto to quickly test and experiment with novel ideas.
"Next time I'll have more than three days of dev time before deadline." - zygomeb
Lending: KL Protocol by Atoumbré
KL Protocol is a lending protocol concept that uses some liquidity pool concepts to represent deposits. Meaning you will receive “LP tokens” for the deposit you make in the form of “Pool Shares”. To borrow from the protocol, collateral needs to be deposited, however, only “Pool Shares” can be accepted as collateral. This allows the protocol to use the collateral as a way to generate yield and simplify the protocol. Additionally, borrowing requires the user to receive a Collateralized Debt Position (CDP) NFT. This is an NFT which tracks a user’s loans and collaterals.
We liked this submission because it was well documented with a clear walk through of functionality that could be demonstrated utilizing the front end tools such as the dApp toolkit giving a nice sample of interacting with the new Radix Wallet. It was also nice to see builders pushing the envelope to try and approach things in new ways yet still providing a complete feature list of what a lending protocol might require.
What we felt needed improvements with this submission is to encourage more asset-oriented design to the lending protocol. The CDP NFT design has quite complex machinery built to track loans and collateral amounts. We like that loans are represented as NFTs because this allows the loans to be tokenized and its value transferable across the network. However, much of each loan’s information is recorded off-ledger and while we realise that sometimes it may make sense to store data off-ledger, loan data may make most sense to be stored on-ledger attached to its NFT. This allows the NFT that represents the loan to own the information that makes the loan NFT itself valuable. Additionally, we saw that CDP NFT data that was meant to be stored on-chain contained two states, which is counter productive to parsing certain data to be stored off-chain in the first place. However, this earnest feedback shouldn’t eclipse an otherwise very job well-done. Congratulations!
“What Radix has active with the Radix technology Stack is game changer. After failing to start with Solidity I was a bit sceptical as I didn’t know Rust before I knew Scrypto ( I think I still have very basic knowledge). But, I’m sure that Scrypto stays out of the way between me and my idea. In fact, with the help of Radix Engine, it’s on my back watching my steps. This is just the beginning of the journey for me and I have never been that excited to build.” - Atoumbré
In the spirit of giving, we wanted to award $3,500 in XRD for the honourable submissions below for what we thought was worth noting.
MojitoSwap by dcernahoschi
MojitoSwap is a concentrated liquidity pool inspired by Uniswap v3. If you would like to see a Scrypto implementation of Uniswap v3, you can view this submission for inspiration.
Kaupa by scryptonight
Kaupa is a generic market for trading bags of tokens. It has features to support order book, limit, and market trade for single resource transactions and flash lending tokens for another arbitrary bag of tokens.
DefiFunds by tobben1998
DefiFunds is a portfolio management protocol to streamline investing in DeFi by connecting individuals with skilled fund managers. This submission impressed us for having a solidly built portfolio management dApp with its core features and we are especially honoured to have this submission as part of Tobias’s master’s thesis which can be found here.
That wraps up the winners for this challenge. We are seeing more complete submissions everytime we release challenges and the bar is higher with each Scrypto Challenge. Yet, we still continue to find newer participants both new and seasoned developers, so it’s absolutely not too late to get started learning Scrypto.
Enroll to the Scrypto 101 free course to learn everything you need to know about Scrypto to build your first blueprint!
Join the Developer Program to start earning rewards and keep in touch to hear more about upcoming Scrypto Challenges!