4/5
## Understanding the Kink Borrowing Factor Model In decentralized finance (DeFi) and other resource-constrained web3 systems, managing the utilization of shared resources like liquidity pools is crucial. Protocols need mechanisms to ensure resources aren't over-utilized, which could lead to instability or poor user experience. The "kink" borrowing factor model provides an elegant economic solution to this challenge. This model dynamically adjusts the cost of borrowing (the borrowing factor or fee) based on the current level of resource usage. Its primary goal is to keep borrowing costs relatively low during periods of normal usage but to sharply increase them when usage exceeds a predetermined optimal level, thereby incentivizing users to maintain utilization around that target. **Key Components:** 1. **Usage Factor (u):** This represents the current proportion of a resource being utilized or borrowed. It's typically expressed as a value between 0 (0% usage) and 1 (100% usage). For example, if 50% of the liquidity in a pool is currently being borrowed, `u = 0.5`. 2. **Optimal Usage Factor (u_optimal):** This is a critical parameter set by the protocol, representing the target or ideal utilization level. It defines the threshold where the borrowing cost calculation changes behavior. A common example might be `u_optimal = 0.8` (or 80%). 3. **Borrowing Factor:** This is the cost incurred for borrowing the resource, often expressed as a rate per unit of time (e.g., "borrowing factor per second"). This factor is not fixed; it dynamically changes based on the current `Usage Factor (u)`. Other parameters, like a `Base borrowing factor`, might influence the starting point or initial slope, but the defining characteristic is its relationship with `u`. **How the Kink Model Works:** The relationship between the Usage Factor (`u`) and the Borrowing Factor is defined by a piecewise linear function. Imagine plotting this relationship on a graph: * The horizontal axis represents the Usage Factor (`u`) from 0 to 1. * The vertical axis represents the resulting Borrowing Factor (cost per second). The graph of this function has two distinct linear segments meeting at a specific point – the "kink". 1. **Segment 1: Below or At Optimal Usage (u ≤ u_optimal)** * When the current resource utilization is below or exactly at the optimal threshold (e.g., `u` is between 0 and 0.8), the borrowing factor increases as usage increases, but it does so along a line with a relatively gentle positive slope. * This means that within this normal operating range, borrowing becomes slightly more expensive as usage rises, but the increase is gradual and predictable. Costs remain relatively low. 2. **Segment 2: Above Optimal Usage (u > u_optimal)** * As soon as the Usage Factor surpasses the Optimal Usage Factor (e.g., `u` goes above 0.8), the relationship crosses the "kink" point. * From this point onwards, the borrowing factor continues to increase with usage, but now along a line with a significantly steeper positive slope. * This sharp change in slope means that for every additional percentage point increase in usage above the optimal level, the borrowing factor per second jumps up much more rapidly than before. **Economic Incentives and Implications:** The kink model acts as a powerful economic lever: * **Discouraging Over-utilization:** The rapidly escalating costs above `u_optimal` create a strong financial disincentive for pushing resource usage too high. Borrowing becomes prohibitively expensive in the high-usage zone. * **Promoting Stability:** By encouraging usage to hover around or below the `u_optimal` level, the model helps maintain protocol stability and ensures some capacity is usually available. * **User Behavior:** Users are economically motivated to monitor the usage factor. If usage approaches or exceeds `u_optimal`, borrowers may be incentivized to reduce their positions or refrain from opening new ones until usage drops back into the lower-cost range. Conversely, liquidity providers might be incentivized by higher potential returns (derived from higher borrowing fees) when usage is high, helping to bring `u` back down. In essence, the kink borrowing factor model uses transparent, predictable economic rules to guide user behavior towards a desired state of resource utilization, balancing the need for accessibility with the need for system health.
In decentralized finance (DeFi) and other resource-constrained web3 systems, managing the utilization of shared resources like liquidity pools is crucial. Protocols need mechanisms to ensure resources aren't over-utilized, which could lead to instability or poor user experience. The "kink" borrowing factor model provides an elegant economic solution to this challenge.
This model dynamically adjusts the cost of borrowing (the borrowing factor or fee) based on the current level of resource usage. Its primary goal is to keep borrowing costs relatively low during periods of normal usage but to sharply increase them when usage exceeds a predetermined optimal level, thereby incentivizing users to maintain utilization around that target.
Key Components:
Usage Factor (u): This represents the current proportion of a resource being utilized or borrowed. It's typically expressed as a value between 0 (0% usage) and 1 (100% usage). For example, if 50% of the liquidity in a pool is currently being borrowed, u = 0.5
.
Optimal Usage Factor (u_optimal): This is a critical parameter set by the protocol, representing the target or ideal utilization level. It defines the threshold where the borrowing cost calculation changes behavior. A common example might be u_optimal = 0.8
(or 80%).
Borrowing Factor: This is the cost incurred for borrowing the resource, often expressed as a rate per unit of time (e.g., "borrowing factor per second"). This factor is not fixed; it dynamically changes based on the current Usage Factor (u)
. Other parameters, like a Base borrowing factor
, might influence the starting point or initial slope, but the defining characteristic is its relationship with u
.
How the Kink Model Works:
The relationship between the Usage Factor (u
) and the Borrowing Factor is defined by a piecewise linear function. Imagine plotting this relationship on a graph:
The horizontal axis represents the Usage Factor (u
) from 0 to 1.
The vertical axis represents the resulting Borrowing Factor (cost per second).
The graph of this function has two distinct linear segments meeting at a specific point – the "kink".
Segment 1: Below or At Optimal Usage (u ≤ u_optimal)
When the current resource utilization is below or exactly at the optimal threshold (e.g., u
is between 0 and 0.8), the borrowing factor increases as usage increases, but it does so along a line with a relatively gentle positive slope.
This means that within this normal operating range, borrowing becomes slightly more expensive as usage rises, but the increase is gradual and predictable. Costs remain relatively low.
Segment 2: Above Optimal Usage (u > u_optimal)
As soon as the Usage Factor surpasses the Optimal Usage Factor (e.g., u
goes above 0.8), the relationship crosses the "kink" point.
From this point onwards, the borrowing factor continues to increase with usage, but now along a line with a significantly steeper positive slope.
This sharp change in slope means that for every additional percentage point increase in usage above the optimal level, the borrowing factor per second jumps up much more rapidly than before.
Economic Incentives and Implications:
The kink model acts as a powerful economic lever:
Discouraging Over-utilization: The rapidly escalating costs above u_optimal
create a strong financial disincentive for pushing resource usage too high. Borrowing becomes prohibitively expensive in the high-usage zone.
Promoting Stability: By encouraging usage to hover around or below the u_optimal
level, the model helps maintain protocol stability and ensures some capacity is usually available.
User Behavior: Users are economically motivated to monitor the usage factor. If usage approaches or exceeds u_optimal
, borrowers may be incentivized to reduce their positions or refrain from opening new ones until usage drops back into the lower-cost range. Conversely, liquidity providers might be incentivized by higher potential returns (derived from higher borrowing fees) when usage is high, helping to bring u
back down.
In essence, the kink borrowing factor model uses transparent, predictable economic rules to guide user behavior towards a desired state of resource utilization, balancing the need for accessibility with the need for system health.
A graphical exploration to Visualizing Kinked Borrowing Fees - Discover how a 'kink' model dynamically sets borrowing fees based on resource usage via a Desmos graph. Learn why costs increase gently below an optimal point but rapidly escalate beyond it to incentivize stability.
Previous lesson
Previous
Next lesson
Next
Give us feedback
Cyfrin Updraft has partnered with GMX to provide SSCD+ certifications vouchers to the first 25 students who demonstrate the completion of this course and are building on top of GMX. Join the GMX Discord server to redeem your coupon, or navigate to the docs to learn more!
Course Overview
About the course
Mechanics and contract architecture of the GMX protocol
Token pricing and fees
Liquidity: GM pools and GLV vaults
Math, funding rates, liquidation pricing, P&L calculations
Limit orders, take profit orders, stop loss, and stop market orders
Auto-cancel and auto-deleveraging
GLP, esGMX, GMX staking and delegation
DeFi Developer
$75,000 - $200,000 (avg. salary)
Smart Contract Engineer
$100,000 - $150,000 (avg. salary)
Web3 developer
$60,000 - $150,000 (avg. salary)
Web3 Developer Relations
$85,000 - $125,000 (avg. salary)
Smart Contract Auditor
$100,000 - $200,000 (avg. salary)
Security researcher
$49,999 - $120,000 (avg. salary)
Last updated on June 26, 2025
Duration: 8min
Duration: 1h 19min
Duration: 1h 24min
Duration: 16min
Duration: 11min
Duration: 11min
Duration: 6min
Course Overview
About the course
Mechanics and contract architecture of the GMX protocol
Token pricing and fees
Liquidity: GM pools and GLV vaults
Math, funding rates, liquidation pricing, P&L calculations
Limit orders, take profit orders, stop loss, and stop market orders
Auto-cancel and auto-deleveraging
GLP, esGMX, GMX staking and delegation
DeFi Developer
$75,000 - $200,000 (avg. salary)
Smart Contract Engineer
$100,000 - $150,000 (avg. salary)
Web3 developer
$60,000 - $150,000 (avg. salary)
Web3 Developer Relations
$85,000 - $125,000 (avg. salary)
Smart Contract Auditor
$100,000 - $200,000 (avg. salary)
Security researcher
$49,999 - $120,000 (avg. salary)
Last updated on June 26, 2025