LockJar v2 is the second iteration of LockJar. LockJar v1 was inspired by an over-the-counter market for locked JEWEL tokens from the game DefiKingdoms. This secondary market allowed exchange between those that were bullish on future unlocked JEWEL tokens and those that wanted immediate access to their JEWEL tokens. The prices at which these exchanges happened gave interesting market insight such as gauging long-term bullishness. In DeFi, a type of commonly locked token is the liquidity provider (LP) token. We wanted to allow liquidity providers to lock their LP tokens while having the ability to trade a token with the unlocked LP token as the underlying asset. This system would allow liquidity lockers to liquidate their position while maintaining liquidity depth in the market.
Though the original idea was for locking liquidity provider tokens, our original protocol can lock any ERC-20 token. In LockJar v2, we give users the ability to lock any ERC-721 tokens. With this upgrade, Uniswap v3 liquidity providers can now lock their liquidity with our dApp.
What it does
When a user locks their token(s) through our official frontend, the interface calls the proper lock function (depending on ERC-20 vs. ERC-721) to the Jar smart contract. The smart contract then takes in the token(s) to be locked in for the specified amount of time. In return, the user receives ERC-1155 token(s) that are associated with the user-specified unlock time. The user can no longer access their ERC-20/ERC-721 token(s), thus the smart contract has effectively "locked" the token and the user is left with a "bond" that they can redeem after the "maturity", or unlock, time.
How we built it
For the backend, we coded the smart contracts in Solidity and used Remix to deploy/test. For the frontend, we used React and the ethers.js library to interface with the smart contracts.
Challenges we ran into
Because we are adding a new type of token to the protocol, we needed to rewrite how the tokens are handled and how the bond data is stored due to the differing structures of the tokens. Thankfully, we originally used the ERC-1155 token standard for the issuance of bonds, so we did not have to make drastic changes in the way bonds worked.
Accomplishments that we're proud of
We are proud of developing a working dApp that has real-world utility. We can see our product providing value to decentralized exchanges and the broader DeFi economy. We are also proud of our teamwork because we could have not done this project without our mutual commitment and collaboration.
What we learned
Since LockJar v1, we have improved upon our Solidity and React skills. We are now more familiar with the ERC-721 token standard and creating interactive forms in React. Because this hackathon was remote, we collaborated on code using a git repository, so we bolstered our git skills.
What's next for LockJar v2
Currently, LockJar v2 is still a minimum viable product. We would like to improve the image of the LockJar brand so that it can be marketable. However, before we do this, we want to improve upon the user interface. We would like to create a better design and a better user experience. For example, we want to get the number of decimal places of the specified ERC-20 token and automatically multiply the inputted amount by 10 to the power of the number of decimal places. We also want to build a simple marketplace to give more utility to our protocol. The smart contract for the marketplace is written. However, we need to build a frontend around it.