Liquidity Layer on

Operate: Sanity checks

Mon, 01 Jan 0001 00:00:00 +0000

The operate function starts from performing few sanity checks. We are looking at this code:

Remember that this function handles all operations in one place:

supplyAmount > 0 -> we are doing a regular supply
supplyAmount < 0 -> we are withdrawing liquidity
borrowAmount > 0 -> we are doing a regular borrow
borrowAmount < 0 -> we are paying back borrowed assets

So we perform straightforward sanity checks in this order:

Operate: Setup memory variables

Mon, 01 Jan 0001 00:00:00 +0000

After we performed sanity checks, we want to set up memory variables which will help us later to perform various calculations during the function.

We are looking at this piece of code:

First, we initialize OperateMemoryVars. This is just a common pattern to group local variables inside one struct to prevent stack too deep errors.

Then we are introduced to variables memVar_ and memVar2_. This is a pattern heavily used across the Fluid codebase, where memVar_, memVar1_ … memVarN_ are temporary variables that are reused across calculations and assignments to avoid creating new ones, with the goal of reducing gas cost.

Operate: Dex callback

Mon, 01 Jan 0001 00:00:00 +0000

After setup of memory variables, we are looking at this piece of code, which we are going to skip and won’t analyze.

Why?

Because we are “only” analyzing T1 vaults in this guide, and this piece of code is only used for DEX vaults (T2, T3, T4).

To prove that to you, we are going to cheat a little bit and jump to the place in the code where T1 vaults (consumers of this liquidity) use this operate function. Note that T1 vaults will be analyzed later in this guide in separate Vault Protocol section.

Operate: Eth payment check

Mon, 01 Jan 0001 00:00:00 +0000

After the skipped DEX callback, we are looking at this piece of code:

If you remember, memVar2_ was calculated as deposit + payback amount, so its purpose was for this check, where we want to make sure the caller has sent enough native token:

memVar2_ > msg.value

But also not too much above the excess allowance limit:

msg.value > (memVar2_ * (FOUR_DECIMALS + memVar3_)) / FOUR_DECIMALS

Where:

memVar3_ = 100; // MAX_INPUT_AMOUNT_EXCESS = 1%
FOUR_DECIMALS = 1e4;

// 10100 / 10000 = 1.01

So this simply reverts if we sent 1% more native token than the combined deposit plus payback amount passed in the function call, to prevent the caller from accidentally passing more tokens than needed.

Operate: Send funds from sender

Mon, 01 Jan 0001 00:00:00 +0000

After the ETH payment check, we want to send funds from the caller to this liquidity layer.

This is the snippet of code we are looking at:

At first, we see that we want to transfer tokens only if memVar2_ is greater than zero, meaning deposit + payback != 0.

For ETH transfers, this is already handled in the previous section by setting it to zero, which is also noted by the comment, so no new transfer is needed.

Operate: Update exchange prices / utilization / ratios

Mon, 01 Jan 0001 00:00:00 +0000

Before we analyze, let’s quickly revisit some of the things we covered earlier here.

We previously brought exchange prices forward from the previous checkpoint to the current timestamp. During this action, we introduced the concept of supplyRatio and borrowRatio.

Remember that supplyRatio and borrowRatio always stay below 100% and represent the ratio between interest and interest-free supplying or borrowing.

if supplyInterestFree > supplyWithInterest
 supplyRatio = supplyWithInterest / supplyInterestFree
else
 supplyRatio = supplyInterestFree / supplyWithInterest

Operate: Send funds to sender

Mon, 01 Jan 0001 00:00:00 +0000

We are almost finished with this main operate function. As we finished all calculations, now we are only left to send funds to the user if he is using withdraw or borrow operation.

This is the code we are analyzing.

First, this whole branch of using o_.netTransfersOut can be skipped, as it is only used for DEXes, leaving us only the second branch to analyze.

The code is straightforward. We first store borrow and withdraw amounts to memory variables:

Operate: Emit event and return

Mon, 01 Jan 0001 00:00:00 +0000

Congratulations! We are done with the main operate function. The only last thing we want to do is emit an event and return values for supply and borrow exchange price:

Summary

Mon, 01 Jan 0001 00:00:00 +0000

To summarize, we understood how the main operate function from the liquidity layer works under the hood.

We learned that Fluid keeps liquidity in one contract, and although we gave examples with test users like Bob and Alice, we know that users of this liquidity are actually other protocols that use it through one interface and the operate function.

We also saw how interest can be divided into with-interest and interest-free groups, and how withdrawal and borrow limits can dictate how protocols use liquidity from this layer.