Many members of Blockchain Chicago have personal experiences attempting to day-trade the cryptocurrency market through the years, with each member ultimately being more profitable by “investing” rather than attempting to time the market swings. We deemed that an automated Dollar-Cost Averaging protocol would not only be more profitable and relieve stress for most traders/investors in the market, but also serve as a good on-boarding protocol for new entrants more familiar with traditional methods of investing.

What it does

The project uses Cross-Program-Invocations to access other Solana protocols to maximize the user’s experience. For instance, we use Solend to gain yield on the deposited tokens as well as using Raydium for swapping to the desired token.

How we built it

AgriFi makes it possible for users to keep their funds safe while generating maximum yield on their assets. Normally, if a user wanted to manually do everything that we automate, they’d need to: deposit an asset into solend to generate yield, keep track of how often they’d want to do a recurring payment, set some reminder or some way to ensure they actually make the purchase habitually and regularly, whenever they decide to do a recurring payment then they’d need to calculate what percent of their funds to withdraw from Solend, then swap to their desired token, then take these tokens and stake them into Solend, and once that is done and all of the DCA purchases have been completed, finally withdraw from Solend one last time. Was that hard to follow? That’s because it is super inconvenient and unrealistic to expect someone to regularly do this on a daily basis. TL;DR when users want to manually DCA while generating yield, they need to go through many steps that, frankly, most people don’t want to, or don’t have the time/effor to do. AgriFi lets users complete all of these steps, and all they need to do is deposit and redeem.

The core contract has various instructions that allow the client side to interact with it seamlessly and easily. We start by creating a PDA (program derived address -- account) that will host all the PDA’s of each yield and swapping accounts per user. The call-flow for this starts with initializing the Distributor PDA, then when the user deposits, we open up a YieldAccount PDA for them (derived from the distributor and the user). Here, each user’s deposits and yield will be separate from others. Then from this YieldAccount PDA, we call a CPI (cross-program invocation) to Solend to deposit the reserve currency given to us by the user to DCA with. This is an authored PDA call that needs to be signed by the PDA to keep everything secure. Once it is time to do the swap from the deposited token to the desired token, we will withdraw x tokens from the Solend protocol and then call a CPI to Raydium to execute a swap. After this swap occurs, we will still hold the user’s tokens, and continue to generate yield by lending them on Solend with a CPI as well. This way, the user will always be generating yield on their assets and will be incentivized to hold tokens for a longer term instead of price-watching and trying to sell trends. Lastly, the user will be able to redeem their rewards whenever they want (as well as withdraw their initial deposits which will require a CPI call to Solend to withdraw). All of these components come together to allow the user to maximize their yield while keeping their accounts safe from attackers since the PDA’s need to sign all transactions from the moment the user deposits to the moment they redeem.

Challenges we ran into

Most of the challenges we ran into was how to integrate a CPI from a non-Anchor Solana program. With Anchor, it makes it very easy to do an Anchor Program to Anchor Program, however, when dealing with a pure Rust Solana program, there is more that needs to be done. Both Solend and Raydium use pure Rust so we encountered difficulties implementing these CPI’s, however, we were able to talk with a very helpful person (shoutout spacemandev) who helped us understand the differences and what we needed to do in our program to account for the difference and learn how to CPI successfully.

Accomplishments that we're proud of

We are especially proud of how we overcame the various obstacles we faced. We are very pleased with the progress we made on the project, and we think its an interesting idea that could generate serious value for users.

What we learned

While Lex had some experience developing Solana smart contracts, this was his first time implementing CPIs, as well as building a full stack dApp and communicating with the UI. Luke designed the UI with no prior development experience, quickly picking up the basics of HTML and CSS, as well as figuring out how the frontend should function in conjunction with the backend.

What's next for AgriFi

In the future, if AgriFi were to successfully build a large treasury of assets, we could look into more complex yield strategies, such as leveraging pooled stablecoins by collateralizing them then borrowing against them to build on our lending positions, or providing liquidity to the token and stable pair. We would also like to implement more complex parameters to allow users to have more control over their DCA strategy if they wish. Ultimately, the protocol could serve primarily as a stable yield optimizer, with the added benefit of de-risking the accrual of volatile tokens.

To add even more, we could launch our own AgriFi governance token. We think the best tokenomics model for aggrify would be a form of the vote escrow model. We could allow users to lock up the AGR token to receive governance power and boosted yield. We would turn the various collateralized stablecoins into gauges which can be voted on to receive extra AGR emissions.

Share this project: