Wormhole is excited to put forth its proposal in enabling cross-chain lending and borrowing. The Wormhole team has already built out a reference example for Venus and is committed to helping build out the full solution while providing on-going product and smart contract support to Venus and its community. (Github)
Before that, a quick intro to Wormhole — Wormhole is the leading cross-chain interoperability protocol, allowing generic messaging over 15 heterogenous blockchains and soon to be many more. As a matter of fact, we’ve just announced our launch on Aptos devnet.
Since launch on mainnet in August 2021, 1.2 million messages have been transmitted. Some are regular messages (e.g. Pyth oracle data), some are token bridges, and all usage has come organically — no incentives.
Venus is a cornerstone project to the BNB ecosystem. We believe Wormhole is the best cross-chain solution for Venus for 3 key reasons:
Robust design and implementation — Details matter, particularly in the context of a complex protocol that will serve as the foundational layer for future development and composable applications. The Wormhole team has thought deeply about this new paradigm and subsequently built out an example reference example, specifically for Venus.
Security model and decentralization — Wormhole has nineteen guardians comprised of the leading PoS validators who jointly attest to messages. Each guardian holds equal weight in governance and consensus. Wormhole requires over two-thirds of the 19 guardians to gain consensus and pass verification, thus we assume that at least one-third of our guardian set is trustworthy.
Wormhole has a comprehensive security plan consisting of all development in the open, one of the largest bug bounty programs ($10 million and counting), including 5 quality audits (e.g., Neodyme, Kudelski, Ottersec) of its full codebase (audits by Certik, Trail of Bits, etc. underway).
Simplified and consolidated integration stack — Pyth will go cross-chain via Wormhole; thus Venus’ planned integration with Pyth will involve reliance on Wormhole. With this dependency in place, it will be optimal to use Wormhole for other elements of Venus’ cross-chain goals instead of introducing a new set of bridging dependencies and trust assumptions. The Wormhole integration would also streamline future maintenance of the oracle mechanism, since the oracle and generic cross-chain messaging would be dictated by the same underlying interoperability standards.
Design quality matters a lot. There are a number of important details that determine the dynamics of cross-chain borrow-lend; thinking through and laying out these details beforehand is vital for any quality integration proposal. Wormhole has spent many cycles thinking about this breed of cross-chain application, and we foresee several different options that trade off between complexity and functionality.
The status quo is straightforward: for nearly all borrow-lend protocols, there are no cross-chain capabilities. Each chain is isolated, and users who want to borrow and lend across different blockchains have to manage and monitor separate balances on different contracts and protocols. The borrower in the scenario below is unable to deposit ETH on Ethereum and borrow SOL from Solana.
Status Quo: Independent Chains
How can Venus go cross-chain? There are a number of possibilities and the Wormhole team is open to collaborating with Venus to develop sequential rollouts or target the development of the most-complex implementation from the get-go. We suggest leaving this decision to XVS holders and encourage Venus delegates to debate the merits of each approach. There are two main variants: single-chain and multi-chain vaults.
In the base implementation, Wormhole could enable single-chain collateral pools, where a user can deposit collateral on any one chain and borrow on any other chain and vice versa. Pyth would concurrently stream prices to the protocol, enabling collateral monitoring on the origin chain. Users would repay the loan on the chain they borrowed tokens from and then withdraw their collateral on the origin chain. We illustrate the workflow below.
Moving to a more sophisticated rendition — a borrower may seek to deposit two or more separate forms of collateral on two or more distinct chains. Here we have multi-chain collateral pools on any supported chain allowing users to borrow on one designated chain. Users would repay the loan on the designated borrow chain and then withdrawal each form of collateral on their respective chains. We illustrate the workflow below.
Case two introduces additional complexity into the design as we now have to synchronize between more than two chains. Borrowers could borrow from one designated chain while supplying collateral on heterogenous chains. Here we only need to account for the collateral supplied on all other chains on the selected chain that users are borrowing assets on, but every other chain just needs to keep track of the collateral supplied on its respective chain. The user would then initiate the borrowing on each borrow chain, breaking up the borrower’s total loan on a per-collateral basis. This design allows us to maintain liquidations on each borrower chain as the liquidator could check if the ratio of collateral on that chain to the amount borrowed originating from that chain is below the liquidation ratio.
We provide a reference example for how the single-chain vaults could work with BNB and Ethereum. (Please note that this is a lightly tested proof-of-concept and should not be used in production). We allow for 1 ERC-20 token to be used as collateral on BNB and another ERC-20 token to be borrowed on Ethereum and vice-versa. This design could then be adapted to integrate with the existing Venus codebase.
In our example, a user can deposit BUSD on BNB as collateral and borrow WETH on Ethereum using the following functions:
- The user first calls addCollateral(collateralAmount) in the BNB contract with the amount of BUSD they’d like to supply. This transfers the collateralAmount to the contract and then this amount is reflected in their account’s deposited assets and the total BUSD liquidity in the contract.
- Then the user calls initiateBorrow(borrowAmount) in the BNB contract with the amount of WETH they’d like to borrow on Ethereum. This will calculate the maximum amount of WETH they’re allowed to borrow based on the collateralization ratio for BUSD/WETH and then send a message to the Wormhole contract on BNB.
- Lastly, the user calls completeBorrow(signedWormholeMessage) in the Ethereum contract with the signed Wormhole message produced in step 2. The Wormhole message will then be decoded and there will be a check if there is sufficient WETH liquidity for them to borrow. The borrowAmount specified in the message is transferred to them and then this amount is reflected in the account’s borrowed assets and the total WETH liquidity in the contract. If there is not sufficient WETH liquidity for them to borrow, a Wormhole message will be sent back to the BNB contract to allow them to withdraw their collateral.
The user could then repay the WETH loan on Ethereum and get their BUSD collateral back on BNB as follows:
- The user first calls initiateRepay(borrowAmount) in the Ethereum contract with the amount of the loan they want to pay down. To repay the entire loan the user could also call initiateRepayInFull(). Either of these functions will transfer the repayment to the contract and update the account’s borrowed assets and the total WETH liquidity in the contract. A message will then be sent to the Wormhole contract on Ethereum, indicating how much of the loan has been repaid.
- Lastly, the user calls completeRepay(signedWormholeMessage) in the BNB contract with the signed Wormhole message produced in step 1. The message is then decoded and checked if the loan has been repaid in full. If it has and completeRepay has been called within the defined grace period, then the account’s borrowed assets will be set to zero and WETH liquidity in the BNB contract will be reduced by the amount repaid. If completeRepay wasn’t called within the grace period, then a message will be sent to the Wormhole contract on BNB, identifying that the loan wasn’t repaid in time. If the loan hasn’t been repaid in full, then the account’s borrowed assets and the WETH liquidity tracked in the BNB contract will be reduced by the amount repaid.
Although we do not implement liquidations in our reference example (we do provide an example workflow), the liquidator would:
- call initiateLiquidationOnTargetChain on the BNB contract which should determine if a particular position is undercollateralized by querying the accountAssets state variable for the passed account. If an account is undercollateralized, this method should generate a Wormhole message sent to the Wormhole contract on BNB.
- call completeRepayOnBehalf(signedMessage) on Ethereum with the signed Wormhole message produced when you call initiateLiquidationOnTargetChain. If the borrower has not yet paid the loan back by the time the Wormhole message arrives on the target chain, this function will transfer the borrowed funds owed from the liquidator to the contract and send another Wormhole message to the Wormhole contract on Ethereum. As with the completeReplay function, there should be revert functionality with a message back to the source chain if the borrower has already paid back the loan.
- call completeLiquidation(signedMessage) on BNB with the signed Wormhole message produced when you call completeRepayOnBehalf. The borrower’s collateral would then be sent to the liquidator minus protocol determined liquidation fees.
- Note: for a liquidator to see the health of positions, a function would need to return the list of addresses with open positions and another function that allows you to query the accountAssets state variable for a particular account.
Venus could potentially integrate Wormhole with the following additions to the codebase:
- keep the existing infrastructure around entering and exiting markets as these methods solely permit the user to then try to borrow these assets
- as we’re tracking deposits on the source chain (in the first model), we can keep the mintFresh function as is
- add initiateBorrow logic in a new borrowFreshXChain function that mimics the logic of borrowFresh but instead of transferring the borrowed token amount to the user, the function would send a message to the Wormhole contract on BNB as shown in the initiateBorrow function in the reference example
- add completeBorrow logic in a completeBorrowXChain function that allows a relayer/user to submit the signed Wormhole message to the VToken.sol contract on Ethereum that will actually transfer the borrowed funds to the user
- add repay logic in a repayBorrowFreshXChain function that mimics the logic of repayBorrow but instead of transferring the borrowed tokens plus interest back to the contract, the function would send a message to the Wormhole contract on Ethereum as shown in the repay function in the reference example
- add completeReplay logic in a completeReplayXChain function that allows a relayer/user to submit the signed Wormhole message to the VToken.sol contract on BNB that will return the collateral to the user
Wormhole relies on a PoA consensus with 19 guardians. Each guardian runs their own node for each chain and holds equal weight in governance and voting. Of the 19 guardians, Wormhole requires more than two-thirds to reach consensus and pass verification—thus, we assume that at least one-third of our guardian set is honest. Our guardian set is comprised of the leading PoS validators with billions in active delegations across the biggest PoS chains — P2P, Chorus One, Everstake, Staked.us to name a few.
However, despite Wormhole’s high degree of decentralization, we remain resolute on improving our trust assumptions — as such, we are placing heavy investments in moving towards a completely trustless system based on zero knowledge proofs.
In just the last 90-days alone, Wormhole has transmitted over 300k messages. Wormhole has handled some of the recent volatile periods in DeFi with ease, facilitating 44k messages in just one day. Our tried and tested permissionless protocol has gained the trust of some of the most reputable developers in the space.
Finally, we recognize that Wormhole has earned some press for the hack in February of this year —we believe Wormhole is stronger for it. Wormhole, for instance, has the most generous bug bounty programs in crypto—over $10 million and counting— including 5 quality audits (e.g., Neodyme, Kudelski, Ottersec) of its full codebase (audits by Certik, Trail of Bits, etc. underway). Wormhole will continue along both of these fronts so as to uphold high standards of security for its users and protocols across supported ecosystems.
Venus will soon integrate with Pyth to provide high-quality price data to its price feeds and ensure timely and precise liquidations. Because Pyth on BNB involves streaming prices from Pythnet via Wormhole, that integration would already create a downstream integration between Venus and Wormhole. With this dependency in place, it makes sense to use Wormhole for other elements of Venus’ cross-chain goals, including cross-chain borrow-lend. Besides removing the need for a different set of bridge trust assumptions, Wormhole integration could also streamline future maintenance of the oracle mechanism, as the the fundamental interoperability requirements would govern both the oracle and the cross-chain messaging.
We look forward to engaging with the Venus community on our proposal.
- Wormhole Foundation