zeroDAO Meta Transaction Lending

Problem Statement

zeroDAO has been working for the past 2 years on solving key problems in the interoperability space. Specifically, we’ve been engaged with handling BTC within EVM chains.

1. Bridging Non-EVM assets to Smart Contract Platforms is inefficient and requires multiple steps for users to receive funds. These steps can take upwards of 1-2 hours in total and can be frustrating to follow.
2. Bridging to an EVM address requires it to be funded by another wallet. Without having funds in the destination wallet, you are unable to release the funds, leaving the funds stuck in a purgatory of bridging. Additionally, funding an address on a public ledger leads to compromises of privacy.
3. The amount of time it takes for a BTC transaction to reach an acceptable level of finality is also upwards of 1-2 hours. Anyone who has experience in the fickle nature of the crypto trading markets knows that this can lead to massive changes in pricing. This, subsequently, leads to large opportunity costs which we refer to as “time slippage” while holding funds safe on a BTC wallet or ledger.

zeroDAO has developed two pieces of technology that are suited to handle these three items, and allow for a pure BTC on EVM experience. All this while retaining the security of keeping your funds on their native chain until “Just In Time” execution. What we’ll be discussing in this article specifically handles the problems above, Meta Transaction Lending.

Architecture

Lending is made up of a number of components:

• Client - A user wishing to perform some action on an EVM chain with a non-EVM asset
• RenVM - Permissionless bridging protocol which handles custody of BTC funds
• Gateway Address - the native asset address you would send your funds to, generated by renVM
• zeroP2P - Decentralized peer to peer communication network where clients can communicate with keepers
• Keeper - Transaction forwarder which executes the Meta Transaction for the user
• Module - A smart contract with a defined action on the destination EVM platform

Executing Logic

Imagine we have someone wanting to swap native BTC → USDC using a DEX on the Ethereum network.

Traditionally, to swap you’d need to perform a number of actions - these below are specific to bridging via RenVM, but timing stays largely the same for bridging funds onto ETH:

1. Generate the BTC Gateway Address using specific mint parameters
2. Send your BTC to the gateway address
3. Notify RenVM of mint parameters
4. Poll RenVM for a signature
5. Submit mint() transaction on the BTCGateway contract on Ethereum
6. Approve the Uniswap Router to spend your renBTC
7. Swap renBTC to USDC

A timeline for this is displayed below. This traditionally takes around 1.5 hours on average to complete, with the bulk of the time being spent in BTC confirmation time:

As indicated by the blue boxes, the bridging requires a number of actions done by the user to complete the bridge and swap. This process takes upwards of 1.5-2 hours to complete. This often leads to significant price shifts during bridging, with price swings of up to 5% during that time frame. For a swap, this could result in a loss of funds, or needing to wait for a better entry. Even worse, if a user was trying to add collateral to a loan that is in danger of being liquidated, it could lead to a partial or full loss of their collateral.

Another example would be adding collateral to Maker to support an existing loan. We’ll use a centralized custodian (FTX) in this example to bridge to Ethereum:

1. Login to FTX and generate a BTC deposit address
2. Send BTC to the deposit address
3. Wait for FTX to credit your deposit
4. Swap BTC → wBTC on FTX
5. Withdraw to your destination address
6. Approve wBTC for spending on the Maker vault
7. Deposit wBTC into the vault to increase collateral

Using a centralized exchange still has the same timing issues mentioned before and a large number of user actions required to complete the desired outcome. If a user has an urgent position that needs to be collateralized quickly, this time frame may be unacceptable and cause loss of funds due to liquidation. In order to execute transactions immediately, a user would need to have funds on an exchange or wrapped on a smart contract platform, which gives up the security advantages in holding BTC natively in a private wallet.

Enter: zeroDAO Meta Transaction Lending

zeroDAO solves the “time slippage” problem by implementing both a lending platform and a peer to peer network of keepers who execute actions for users via Meta Transactions. A client need only generate a BTC address and send funds to it. Once the keeper detects the transaction, they will post collateral for the loan, execute the logic, and then send the funds to the user. This gives the user an experience similar to a DEX or funds being on chain, but retaining custody of your BTC until just in time execution.

zeroDAO modules can be adapted to perform any business logic, allowing users to enter leveraged positions, top up their maker vault collateral, quickly swap for different assets and easily enter LP positions, just as an example. A user signs a Meta Transaction (a transaction within a transaction) and includes the data in the bridge for the keeper to execute on their behalf, with the lending vault taking the gas cost out of the output of the logic.

In a future article, we will deep dive into the functionality of the vaults and how they can be leveraged in different ways, as well as the future of how we plan on increasing the capacity of the system and improving the user experience.