Token Wizard

Inspiration

I was inspired because I know people that are collectors of various items that hold some significant value, yet they live paycheck to paycheck, and if something unexpected arises they would either have to borrow money from someone they know or sell/lose something they currently have.

What it does

Users can potentially borrow any amount of liquidity by using something they own as collateral. At the same time, any user can become a lender and lend to anyone they choose to, with a list of customizable contract financial terms. This project is the foundation of that, in such a way that anyone may build on top of it (either on the frontend or the backend) to better fit their desired needs.

How we built it

Started with a TokenWizard contract that contains information regarding the contract, such as interest rate, interest compounding interval, etc. I then added functionality requiring both parties involved to approve the contract's terms on-chain. After that, I added a couple of functions that allow the borrower to send money to pay off the contract. Next, I decided to allow users to input a price feed address so that the borrowed amount was in whatever currency the involved parties decided on. To wrap up my TokenWizard contract I decided to implement chainlink automation to update the contract's terms if interest or late fee needed to be added. From there I changed the contract name to TokenWizardAuto. Finally, I made a TokenWizardAutoFactory contract that anyone can call to deploy their own TokenWizardAuto contract.

Challenges we ran into

I ran into a tremendous amount of obstacles and challenges along the way. A lot of them were choices about how to structure the contract and write the logic. Such as the approved contract feature, at first, lenders could approve the contract automatically by being the address to deploy the contract, but I couldn't access the price feed equivalent of the borrowed amount until after the contract was deployed. After tinkering with it for a while I decided that the lender would have to call approveContract() after the contract was deployed. None of that ended up mattering because I added TokenWizardAutoFactory at the end instead of having the contract deployed directly. (which still may be reverted/changed in the future) Another big issue I ran into was contract size. Ever since Spurious Dragon and IEP 170, contracts have had a size limit of 24,576 bytes. Initially, before I refactored the entire contract, TokenWizardAutoFactory was just over this limit at 25,000 bytes.

Accomplishments that we're proud of

I am proud that currently, TokenWizardAutoFactory lives on the goerli testnet allowing anyone to interact with and deploy their own TokenWizardAuto contracts! Also, I am proud to have put in a huge amount of effort and learned so many new things since the last chainlink hackathon.

What we learned

I learned about Ethereum's 4th hard fork and that minor changes to the way you write your code can have big changes in the size of your contract. I strengthened my understanding not only of chainlink automation but also utilizing chainlink's data feeds. I learned a lot of cool stuff about interacting with contracts such as using hardhat's native tasks, plus I created a few of my own to help make my video demo!

What's next for Token Wizard

I will take a much-needed nap and not touch anything that connects to the internet for at least 7 hours. Then I'll get back to the grind and keep upgrading my repo. I want to create a cheaper alternative to TokenWizardAuto: a TokenWizard contract that doesn't use chainlink automation and only updates the contract's terms when someone interacts with the contract. I plan to brainstorm and think about any logic changes or further gas optimizations I can make as well.

Built With

• chainlink
• hardhat
• javascript
• solidity