Leading up to Malda’s mainnet launch, we will be unveiling bits of our tokenomics! In Part 1: The Foundation, the core pillars supporting Malda are explored in-depth. You will find out about the revenue structure to support Malda’s longevity, everything “global” about Global Pools as well a new Stability Module feature which bolsters Malda’s economic security while rewarding users.

This is just the beginning, however it is important to note that there are certain details we cannot disclose publicly prior to TGE. With that in mind, expect future releases to cover staking mechanism, governance, Malda Points and more!

Malda is the first Unified Lending protocol delivering a chain-abstracted lending experience across Mainnet and L2s, where all liquidity is truly unified in global pool and secured by zkProofs.

The benefits from Malda’s unified liquidity lending mechanisms are manifold:

• Better UX and lower total gas costs (without the need for additional protocols e.g. bridging) for users

• Maximize returns for lenders by programmatically moving liquidity across chains where demand is highest

• Global liquidity reduces fragmentation and helps create an efficient market rate for borrowing and lending

• Extends yield opportunities for tokens across chains

• Improved capital efficiency for arbitrageurs who can instantly borrow on any chain

Malda facilitates lenders and borrowers to interact with each other, taking a spread on the borrow fee for the provided service.

The average spread is expected to be ~15%. The spread is set on a per asset basis. The goal is to offer competitive rates which may require adjustments to the spreads in the future to stay in line with the market.

Additional revenue sources may include:

• OEV (Oracle Extracted Value) revenue

• Liquidation fee from liquidations

• Trading fees on POL (Protocol Owned Liquidity)

$MALDA is going to be the real yield token of Malda, distributing revenue to stakers and the treasury. The exact ratios will be determined based on the financial performance of the protocol to balance long-term sustainability of the protocol, which drives long-term value accrual of $MALDA, with attractiveness for stakers.

The interest rate is dynamically determined per asset based on its global utilization rate (assets in lending pool vs assets borrowed).

The interest rate curve utilizes two slopes - one until the target utilization is reached and a steeper slope afterwards. A target utilization rate below 100% is set to keep idle liquidity in the pool which enables a % of TVL to be withdrawn at any time. The steeper slope above that threshold incentivizes borrowers to pay back their debt and increase the idle liquidity.

The borrow rate is determined by three factors:

• Base Rate: A fixed, baseline interest rate independent of utilization.

• Utilization-based Rate (Slope 1): Applies when the utilization rate is below the target utilization rate.

• Utilization-Based Rate (Slope 2): Applies when the utilization rate is above the target, introducing a steeper curve.

$Rborrow ​=Rbase​+(M1​ × min(U,Utarget​))+max(M2 ​× (U−Utarget​),0)$

Where:

• Rbase: Base Interest Rate

• M1: Multiplier for utilization below target (Slope 1)

• M2: Multiplier for utilization above target (Slope 2)

• U: Utilization Rate

• Utarget: The target utilization rate for the asset

Utilization Rate Formula:

$U=Total Supply÷Total Borrowed Assets​$

The supply APR (Rsupply) is calculated from the interest paid by borrowers, adjusted for a reserve factor, and distributed proportionally among suppliers. The calculation is as follows:

$Rsupply​=([(1+Rborrow​)1/Blocks Per Year- 1] × Total Borrowed × (1−Rreserve​)) ÷ Total Supply$

To convert the supply rate into annualized APY:

$Rsupply(APY)​=(1+Rsupply​)Blocks Per Year−1$

The reserve factor is set on a per asset basis, based on standard parameters on the market:

• Stablecoins: ~10%

• Bluechips: ~5-15%

• Others: ~20%

Let’s assume the following parameters for Malda’s USDC market:

• Base rate (Rbase) = 2%

• Target utilization rate (Utarget) = 80%

• Multiplier 1 (M1)) = 10%

• Multiplier 2 (M2) = 25%

• Reserve factor (Rreserve) = 10%

• Total supply = 1,000,000 USDC

• Total borrowed = 700,000 USDC

• Blocks per year = 2,102,400

Step 1: Calculate Utilization Rate (U) in %:

$U =700,000÷ 1,000,000= 70$

Since U<Utarget​, we only use the first slope (M1) in %:

$Rborrow=2 + (10 × 70)=2 +2 = 9$

Malda utilizes global liquidations. Liquidators can pay back debt on any chain, including multiple chains, to liquidate a liquidatable borrowing position.

A position becomes liquidatable when it falls below the health factor of 1.

The health factor is calculated with the following formula:

$Health Factor =(Total Collateral Value * Weighted Average Liquidation Threshold)÷Total Borrow Value$

The liquidation threshold is set per collateral asset based on its associated risks, determined by liquidity, trading volume, market cap, and other factors. The higher the asset risk, the lower the liquidation threshold, providing a bigger buffer before a position becomes undercollateralized.

Anyone can liquidate a liquidatable position. This turns liquidations into a competitive market which ensures timely execution. A liquidator can repay up to 50% of the borrower’s debt. The liquidator receives a fixed percentage fee (liquidation fee) for their service, set per collateral asset based on its liquidity. For example, stablecoins and bluechips might see a liquidation fee around 5%, while more exotic tokens come with a liquidation fee of up to 10%.

Malda takes an average ~20-30% protocol fee on liquidation bonus earned by the liquidator based on asset class and risk parameters. Malda also takes 80% of OEV captured by liquidators for liquidations done through API3.

The stability module is expected to go live couple of months after mainnet.

The stability module enables lenders to voluntarily deposit into a stability pool. Stability pools are isolated on a per asset basis (e.g. USDC stability pool covers bad debt affecting USDC lenders). Stability providers opt in to take on initial bad debt incurred on Malda. For the higher risk, they’re rewarded with higher supply APYs.

Lenders without borrowings can opt into the stability vault by depositing their receipt tokens (e.g. mUSDC) into the stability pool. If bad debt occurs for a borrowed asset (e.g. USDC) within the protocol, stability providers are slashed first, proportionally to their stake in the mUSDC stability pool. The required amount of mUSDC is burned to make the system whole. At first, the slashing will be done manually by the security council for bad debt above a pre-determined threshold, which will be replaced by an automatic trigger in the future.

Example:

Someone borrows 1,000 USDC. Due to collateral failure, only 900 USDC can be paid back, leaving a hole of 100 USDC that lenders cannot withdraw. Now, 100 mUSDC in the stability pool would be burned (lenders in the stability pool split the loss proportionally), resetting total protocol bad debt at 0 (normal lenders do not take on any bad debt).

If the stability pool is insufficient, the remaining bad debt is socialized across normal lenders.

The stability vault is subject to a 20-day withdrawal period, ensuring stability and preventing malicious behavior from stability providers.

For the higher risk, stability providers receive a larger share of the interest paid by borrowers. This bonus is determined by market dynamics. Malda optimizes for coverage as a percentage of total borrows via the following formula:

$boost=target boost*(1+c*(current coverage÷ targetcoverage−1))$

with 0<c<1, determining the boost curve

The target boost is dynamically set, ensuring effectiveness and efficiency. The target boost is gradually increased when the coverage is below the target coverage and decreased when it’s above.

$new target boost=target boost*((1-k*current coverage-target coverage)÷target coverage)$

\with k:, adjustment speed

The adjustment is capped at a max percentage per period and the boost cannot turn negative. This is going to be set on a per asset basis.

To allow users to borrow assets on any chain, Malda makes use of a 2-layered rebalancing system that matches demand and liquidity across chains while reducing costs.

The rebalancing module continuously monitors borrow activity on Malda and other money markets, chains’ inflows and outflows, and additional metrics to forecast future borrow demand per chain to rebalance token balances across chains.

The expected borrow demand for a token on a chain is forecasted based on a linear regression of the borrow demand over the last 7 days.

Slope m is calculated as follows:

$m = (SUM(x-xmean) * (y-ymean))÷SUM(x-xmean)2$

Then, the intercept b is calculated:

$b = ymean - m*xmean$

Lastly, the borrow demand for the next day is forecasted:

$Expected borrow demand = b + m*x$

with x=8

If forecasts are shown to be inaccurate, other formulas will be used to minimize the observed delta.

Additional signals include deviations in general borrow demand on other money markets or outliers of chain inflows/outflows.

Based on that, each chain is assigned a weight defined as:

$expected chain weighti=expected borrow demandi÷ SUMexpected borrow demandi$

The available liquidity is then allocated according to the calculated chain weights. A rebalancing is triggered when:

$expected chain.weighti÷current chain.weighti>1.2$

This acts as an initial benchmark which will be adjusted in the future based on real-world data, optimizing for profit. The liquidity is taken from chains with expected access liquidity. The system moves liquidity in a way that minimizes:

$SUM |expected chain.weighti-current chain.weighti|$

Liquidity is bridged using Across and Everclear. Aside from bridging fees, points/token rewards will be used to create strong relationships with solvers.

In case of a token providing an official burn-and-mint bridge, Malda can make use of it for protocol health.

In t he case of borrowing demand exceeding the available liquidity on a chain, the borrower is prompted with a choice

• Pay the bridging fee

• Wait until the next intent-based via Across or Everclear

As we get closer to Malda’s mainnet, we’ll be ramping up the exciting alpha like this tokenomics overview! Want to stay ahead of the curve? Make sure to subscribe to the Malda Alpha Newsletter where we will be releasing alpha like this to subscribers first!

Leading up to Malda’s mainnet launch, we will be unveiling bits of our tokenomics! In Part 1: The Foundation, the core pillars supporting Malda are explored in-depth. You will find out about the revenue structure to support Malda’s longevity, everything “global” about Global Pools as well a new Stability Module feature which bolsters Malda’s economic security while rewarding users.

This is just the beginning, however it is important to note that there are certain details we cannot disclose publicly prior to TGE. With that in mind, expect future releases to cover staking mechanism, governance, Malda Points and more!

Malda is the first Unified Lending protocol delivering a chain-abstracted lending experience across Mainnet and L2s, where all liquidity is truly unified in global pool and secured by zkProofs.

The benefits from Malda’s unified liquidity lending mechanisms are manifold:

• Better UX and lower total gas costs (without the need for additional protocols e.g. bridging) for users

• Maximize returns for lenders by programmatically moving liquidity across chains where demand is highest

• Global liquidity reduces fragmentation and helps create an efficient market rate for borrowing and lending

• Extends yield opportunities for tokens across chains

• Improved capital efficiency for arbitrageurs who can instantly borrow on any chain

Malda facilitates lenders and borrowers to interact with each other, taking a spread on the borrow fee for the provided service.

The average spread is expected to be ~15%. The spread is set on a per asset basis. The goal is to offer competitive rates which may require adjustments to the spreads in the future to stay in line with the market.

Additional revenue sources may include:

• OEV (Oracle Extracted Value) revenue

• Liquidation fee from liquidations

• Trading fees on POL (Protocol Owned Liquidity)

$MALDA is going to be the real yield token of Malda, distributing revenue to stakers and the treasury. The exact ratios will be determined based on the financial performance of the protocol to balance long-term sustainability of the protocol, which drives long-term value accrual of $MALDA, with attractiveness for stakers.

The interest rate is dynamically determined per asset based on its global utilization rate (assets in lending pool vs assets borrowed).

The interest rate curve utilizes two slopes - one until the target utilization is reached and a steeper slope afterwards. A target utilization rate below 100% is set to keep idle liquidity in the pool which enables a % of TVL to be withdrawn at any time. The steeper slope above that threshold incentivizes borrowers to pay back their debt and increase the idle liquidity.

The borrow rate is determined by three factors:

• Base Rate: A fixed, baseline interest rate independent of utilization.

• Utilization-based Rate (Slope 1): Applies when the utilization rate is below the target utilization rate.

• Utilization-Based Rate (Slope 2): Applies when the utilization rate is above the target, introducing a steeper curve.

$Rborrow ​=Rbase​+(M1​ × min(U,Utarget​))+max(M2 ​× (U−Utarget​),0)$

Where:

• Rbase: Base Interest Rate

• M1: Multiplier for utilization below target (Slope 1)

• M2: Multiplier for utilization above target (Slope 2)

• U: Utilization Rate

• Utarget: The target utilization rate for the asset

Utilization Rate Formula:

$U=Total Supply÷Total Borrowed Assets​$

The supply APR (Rsupply) is calculated from the interest paid by borrowers, adjusted for a reserve factor, and distributed proportionally among suppliers. The calculation is as follows:

$Rsupply​=([(1+Rborrow​)1/Blocks Per Year- 1] × Total Borrowed × (1−Rreserve​)) ÷ Total Supply$

To convert the supply rate into annualized APY:

$Rsupply(APY)​=(1+Rsupply​)Blocks Per Year−1$

The reserve factor is set on a per asset basis, based on standard parameters on the market:

• Stablecoins: ~10%

• Bluechips: ~5-15%

• Others: ~20%

Let’s assume the following parameters for Malda’s USDC market:

• Base rate (Rbase) = 2%

• Target utilization rate (Utarget) = 80%

• Multiplier 1 (M1)) = 10%

• Multiplier 2 (M2) = 25%

• Reserve factor (Rreserve) = 10%

• Total supply = 1,000,000 USDC

• Total borrowed = 700,000 USDC

• Blocks per year = 2,102,400

Step 1: Calculate Utilization Rate (U) in %:

$U =700,000÷ 1,000,000= 70$

Since U<Utarget​, we only use the first slope (M1) in %:

$Rborrow=2 + (10 × 70)=2 +2 = 9$

Malda utilizes global liquidations. Liquidators can pay back debt on any chain, including multiple chains, to liquidate a liquidatable borrowing position.

A position becomes liquidatable when it falls below the health factor of 1.

The health factor is calculated with the following formula:

$Health Factor =(Total Collateral Value * Weighted Average Liquidation Threshold)÷Total Borrow Value$

The liquidation threshold is set per collateral asset based on its associated risks, determined by liquidity, trading volume, market cap, and other factors. The higher the asset risk, the lower the liquidation threshold, providing a bigger buffer before a position becomes undercollateralized.

Anyone can liquidate a liquidatable position. This turns liquidations into a competitive market which ensures timely execution. A liquidator can repay up to 50% of the borrower’s debt. The liquidator receives a fixed percentage fee (liquidation fee) for their service, set per collateral asset based on its liquidity. For example, stablecoins and bluechips might see a liquidation fee around 5%, while more exotic tokens come with a liquidation fee of up to 10%.

Malda takes an average ~20-30% protocol fee on liquidation bonus earned by the liquidator based on asset class and risk parameters. Malda also takes 80% of OEV captured by liquidators for liquidations done through API3.

The stability module is expected to go live couple of months after mainnet.

The stability module enables lenders to voluntarily deposit into a stability pool. Stability pools are isolated on a per asset basis (e.g. USDC stability pool covers bad debt affecting USDC lenders). Stability providers opt in to take on initial bad debt incurred on Malda. For the higher risk, they’re rewarded with higher supply APYs.

Lenders without borrowings can opt into the stability vault by depositing their receipt tokens (e.g. mUSDC) into the stability pool. If bad debt occurs for a borrowed asset (e.g. USDC) within the protocol, stability providers are slashed first, proportionally to their stake in the mUSDC stability pool. The required amount of mUSDC is burned to make the system whole. At first, the slashing will be done manually by the security council for bad debt above a pre-determined threshold, which will be replaced by an automatic trigger in the future.

Example:

Someone borrows 1,000 USDC. Due to collateral failure, only 900 USDC can be paid back, leaving a hole of 100 USDC that lenders cannot withdraw. Now, 100 mUSDC in the stability pool would be burned (lenders in the stability pool split the loss proportionally), resetting total protocol bad debt at 0 (normal lenders do not take on any bad debt).

If the stability pool is insufficient, the remaining bad debt is socialized across normal lenders.

The stability vault is subject to a 20-day withdrawal period, ensuring stability and preventing malicious behavior from stability providers.

For the higher risk, stability providers receive a larger share of the interest paid by borrowers. This bonus is determined by market dynamics. Malda optimizes for coverage as a percentage of total borrows via the following formula:

$boost=target boost*(1+c*(current coverage÷ targetcoverage−1))$

with 0<c<1, determining the boost curve

The target boost is dynamically set, ensuring effectiveness and efficiency. The target boost is gradually increased when the coverage is below the target coverage and decreased when it’s above.

$new target boost=target boost*((1-k*current coverage-target coverage)÷target coverage)$

\with k:, adjustment speed

The adjustment is capped at a max percentage per period and the boost cannot turn negative. This is going to be set on a per asset basis.

To allow users to borrow assets on any chain, Malda makes use of a 2-layered rebalancing system that matches demand and liquidity across chains while reducing costs.

The rebalancing module continuously monitors borrow activity on Malda and other money markets, chains’ inflows and outflows, and additional metrics to forecast future borrow demand per chain to rebalance token balances across chains.

The expected borrow demand for a token on a chain is forecasted based on a linear regression of the borrow demand over the last 7 days.

Slope m is calculated as follows:

$m = (SUM(x-xmean) * (y-ymean))÷SUM(x-xmean)2$

Then, the intercept b is calculated:

$b = ymean - m*xmean$

Lastly, the borrow demand for the next day is forecasted:

$Expected borrow demand = b + m*x$

with x=8

If forecasts are shown to be inaccurate, other formulas will be used to minimize the observed delta.

Additional signals include deviations in general borrow demand on other money markets or outliers of chain inflows/outflows.

Based on that, each chain is assigned a weight defined as:

$expected chain weighti=expected borrow demandi÷ SUMexpected borrow demandi$

The available liquidity is then allocated according to the calculated chain weights. A rebalancing is triggered when:

$expected chain.weighti÷current chain.weighti>1.2$

This acts as an initial benchmark which will be adjusted in the future based on real-world data, optimizing for profit. The liquidity is taken from chains with expected access liquidity. The system moves liquidity in a way that minimizes:

$SUM |expected chain.weighti-current chain.weighti|$

Liquidity is bridged using Across and Everclear. Aside from bridging fees, points/token rewards will be used to create strong relationships with solvers.

In case of a token providing an official burn-and-mint bridge, Malda can make use of it for protocol health.

In t he case of borrowing demand exceeding the available liquidity on a chain, the borrower is prompted with a choice

• Pay the bridging fee

• Wait until the next intent-based via Across or Everclear

As we get closer to Malda’s mainnet, we’ll be ramping up the exciting alpha like this tokenomics overview! Want to stay ahead of the curve? Make sure to subscribe to the Malda Alpha Newsletter where we will be releasing alpha like this to subscribers first!