Virtual Liquidity Balance and Transaction Flow
Last updated
Last updated
Users deposit funds by interfacing with the vault contract of the VLL. Once a user deposits their tokens into a vault on any supported network, their virtual balance is updated proportionately and they can spend their entire virtual balance on any supported network.
User's can claim/withdraw funds from the VLL to execute their desired transactions. Let's walk through an example transaction. Assume a user has a virtual USDC balance equal to 400. Given below is a table describing the state of the user deposits across networks constituting the user's virtual balance.
Ethereum
100
Base
200
Arbitrum
100
Let's assume a user wants to purchase an NFT on Base and the cost of the NFT is 350 USDC.
The user's balance on Base is 200 USDC and deficit is 150 USDC.
The user's desired transaction requirements can be expressed as an intent. The user's intent in the example given above is to spend 350 USDC from their VLL balance, i.e, the user needs 350 USDC on Base (the target network).
The user's desired output token amount must be less than or equal to the virtual liquidity balance for the given token. In the current example the user's balance is 400 and the target output amount is 350. Therefore the user's intent is valid.
When the user submits the intent the solver calculates the fees required to process the user's intent. The fees includes the fees required to pay for transaction gas fees along with solver fees.
The solver computes the user's deficit on the target network and generates the transaction calldata and signatures required by the user to claim/withdraw funds from the VLL contracts to execute their desired transaction.
The solver also includes a reclaim plan, which describes the networks where the solver reimburses itself for the funds lent to the user on the target network, the reclaim plan is described in detail in the section outlining the settlement process given below.
The user executes a claim function on the VLL paymaster contract for the deficit the user is missing on the target chain. In this example, the user's USDC deficit on Base is 150 USDC. The user borrows the 150 USDC from the paymaster here and the solver later reimburses itself from vaults on the networks where the user does have USDC virtual balance.
The user executes a withdraw function on the VLL vault on Base for the funds the user already has on base, which in this example is 200 USDC.
The user's transaction to purchase the NFT is bundled along with the transactions to withdraw and claim USDC from the VLL. These sub-transactions are bundled and executed atomically in the form of a user operation in a single transaction.
Once the user's transaction is executed the solver settlement process begins. In the solver computation step, along with the claim/withdraw signatures, the solver also computes the reclaim plan. In the example above the solver fronts 150 USDC to the user. Lets assume the solver needs 152 USDC to reimburse itself. The additional 2 USDC accounts for the gas fees for the user's transaction and the fees required by the solver. The solver may compute a reclaim plan as given below:
Ethereum - 100, Arbitrum - 52
The solver accounts for the user's balances on each individual network, as well as the gas price on each individual network when computing the withdrawal plan. Once the transaction is executed with the signatures from the solver (which encodes the provided reclaim plan), the solver can claim 100 USDC from the vault on ethereum and 52 USDC on the vault from Arbitrum to complete the transaction settlement.