LockJar

• 

  Website Home

• 

  Lock Interface

• 

  Unlock Interface

• 

  Dark Mode

Inspiration

We were inspired by dfk.market, an over-the-counter market for locked JEWEL tokens from DefiKingdoms. The OTC market spawned a secondary market for future JEWEL tokens, which allowed for interesting market insight (gauge long-term bullishness). Our idea initially started out as a dApp that allows users to lock Uniswap LP tokens, but receive a tradable token. This system would allow liquidity lockers to liquidate their position (likely at a premium) while maintaining liquidity depth in the market. The transparency of the blockchain will also allow market participants to predict when liquidity depth may drop. For example, if someone buys a locked liquidity position for a very low cost, they are very likely to unlock the LP token and redeem it for the underlying assets, so they can profit from their trade.

As we started development, we realized that this dApp should be available to all ERC20 tokens in general, so it is now a general token locking protocol.

What it does

When a user locks their ERC20 token using our smart contract's lock function, the contract transfers the ERC20 token to the contract and mints an ERC1155 token representing the underlying ERC20 token to the user. The smart contract then associates the user-specified unlock time with the ERC1155 token. The user can no longer access their ERC20 token, 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.

When a user unlocks their ERC20 token using our smart contract's unlock function, the contract first checks that the block's timestamp is at or after the token's unlock time. If it is past the unlock time, the contract transfers the ERC1155 token "bond" to the contract and burns it. The contract then returns the user's ERC20 token back to them.

How we built it

We used Scaffold-eth, a dApp framework that uses React for the frontend. Solidity, of course, is used for the smart contracts, and ethers.js is the library used to interface with the smart contracts from the frontend.

Challenges we ran into

No one in our team has ever made a dApp, and have no Solidity experience outside of small workshops in our blockchain club. Thus, we were faced with the task of developing contracts for production, which is much more challenging than writing a small contract on Remix for local deployment. More specifically:

• Figuring out how ERC1155 tokens work
• Figuring out how to interact between contracts, more specifically calling functions from the ERC1155 contract in the main contract
• Figuring out how to use ethers.js to interface with smart contracts from the frontend

Accomplishments that we're proud of

We are proud of developing a working dApp that has real world utility. We are very proud of our first attempt being a success because we were learning throughout the entire process and conquered each obstacle as we developed.

What we learned

First and foremost, we learned a lot about Solidity development. We learned how to write Solidity functions, use Solidity libraries, compile Solidity files, and deploy the compiled Solidity contract. Additionally, we learned how frontends connect with the blockchain and how smart contract functions are called by a client.

What's next for LockJar

LockJar only supports ERC20 tokens as of now. Following the locked LP token inspiration, we plan to implement support for locking ERC721 tokens, which is the standard that Uniswap v3 LP tokens use. This feature will bring LockJar to a whole new market. The NFT space is rapidly expanding and may find use in our dApp. Because most of the development time was spent designing the smart contracts, we were not able to spend that much time on the frontend. We would like to perfect the user interface and make the website more informative and useful.

Built With

• ethers.js
• evm
• harmony
• html
• javascript
• react
• remix
• ropsten
• scaffold
• solidity
• typescript