Fast withdraw your tokens to from L2 to L1 (Optimism) using private swap pools
Troll Bridge - non-custodial, fast token withdrawal protocol from Optimism to Ethereum. Native token withdrawal from Optimism takes 7 days, that hurts DeFi composability effect. The main idea behind Troll Bridge is that the user can trade 7 days withdrawal waiting time with some private pool in exchange of some fees. There is no way for private pool owner to cheat the user, besides private pool incentivized to clear operations ASAP, otherwise it gets penalized.
How it's made
This project consists of 3 parts: 1. Front-end, it is written in React. It uses metamask to enable user interaction with blockchain and connects to Back-end to view user transactions history. 2. Back-end, it is written in Java. It uses Web3j to enable interactions with blockchain. 3. Smart-contracts on L1(kovan) and L2(optimism-kovan). They are written in solidity. More detailed overview of each part I. Front-end: Provides service to the user :) II. Back-end: (small note: at the moment we were building the system there was none wss endpoint for L2(optimism-kovan)) It is doing 2 parts: 1. (Ideally) Listen event, that are emitted from L2Bank contract about new L2->L1 withdrawal whenever user interracts with the contract. But since we were unable to use wss endpoint, we are unable to listen any events. (How we did it) So to overcome this instead of listening we requerying L2 smart contract every 5 seconds and check for new requests from users. If we've detected 'new request' we call L1Bank.processL1WithdrawalManually function with detected 'new request' parameters and user gets his money on L1. 2. Listen events, that are emitted from L1Bank contract about: manual(by our operator), automatically(by 'optimism 7 day withdrawal contract'). These are optional for the protocol. We do this for enable better UX, being able to display L2->L1 withdrawal transactions history for the user. III. Smart-contracts: To make protocol 100% secure for user we had to solve several things: 1. Protocol has to be able to support any existing ERC20 that will be distributed on L1 and L2 (with smart contracts base provided by optimism team (OVM_L1ERC20Gateway, Abs_L2DepositedToken)). 2. L2Bank must know exact 'instantly withdrawal token amount' that are available on L1. This is required to handle case where, for example, user is trying to withdraw 100 tokens from L2 but there is only 50 tokens left in L1Bank, transaction should revert. 3. L2Bank.swap function must initiate ERC20 withdrawal to L1Bank AND trigger L1Bank function that checks if there was already processed request by operator in one transaction. We've solved these problems by: - introducing ExtendedAbs_L2DepositedToken contract, that extends Abs_L2DepositedToken, which includes 3 new methods withdrawAndCall, withdrawToAndCall, finalizeDepositAndCall. The purpose of those methods is to be able to send tokens between L2 and L1 and trigger call function of some another contract in one transaction. - introducing ExtendedAbs_L1TokenGateway contract, that extends Abs_L1TokenGateway, which includes finalizeWithdrawalAndCall, depositAndCall, depositToAndCall. Purpose of new methods is to work together with new methods of the contract above. (Our small hope is that contracts above wont be neccessary and optimism team will extend their base contracts, so every ERC20 token between L1 and L2 will have these functions.) - created wrapped token on L1 and L2 of existing L1 ERC20 token (for example - there is USDT token, so trollUSDT is created, while USDT token has simple interfaces to transfer between L1<->L2, trollUSDT has extended interface from contracts above). The purpose of wrapped token (trollUSDT) is: - to extend optimism codebase and make service to work with default ERC20 (it is invisible for user, user is working as if there was none wrapped token) - to fix the (2. L2Bank must know exact 'instantly withdrawal token amount') by wrapping default ERC20 on L1 and sending it to L2Bank, persistence of wrapped token from L1 in L2Bank is a guarantee for the user that he will receive his funds as he requested it.Technologies used