Permissionless Deployment
Anyone can deploy a Monolith stablecoin on any supported chain without permission in few minutes.
Redeemable
All Monolith stablecoins are redeemable for their underlying collateral.
Redemption Protection
Borrowers may avoid redemptions by paying a variable borrow rate.
Interest-Free Loans
Borrowers may avoid paying interest by allowing their loans to be redeemed.
Peg Stability Module
A temporary PSM may use an existing stablecoin to bootstrap supply.
Immutability deadline
All Monolith stablecoins either start immutable or become immutable within four years.
## Our Vision
Monolith aims to democratize access to decentralized stablecoins:
* **Low barrier to entry**: A user-friendly interface for creating a stablecoin in minutes.
* **Sound Economics**: A carefully-designed stablecoin protocol that maintains the peg no matter what.
* **Discoverability**: A list of user-created stablecoins for lenders and borrowers to find new opportunities.
* **Immutability**: Stability requires certainty. Immutability protects stablecoin users from human mistakes.
# Bad Debt Socialization
Source: https://docs.monolith.market/protocol/bad-debt-socialization
How irrecoverable losses are redistributed across borrowers when a loan is written off
# Bad Debt Socialization
## Overview
When a borrower’s position becomes undercollateralized, fully recovering the debt via normal liquidations may be impossible. In that rare case, the protocol “writes off” the position and socializes the loss across all remaining borrowers of the instance in order to prevent a bank run among `Coin` holders.
Write‑offs are guarded by strict conditions and are typically invoked automatically at the end of a liquidation. They may also be executed independent of liquidations via the `writeOff()` function.
## Mechanism
Bad debt identification and handling are governed by the `writeOff(borrower, to)` flow:
* Accrue and sync: Interest is accrued and the borrower’s internal accounting is synchronized.
* Price gate: The oracle must report a valid, sufficiently fresh price; otherwise socialization is disabled.
* Write off threshold: If `debt > 100 × collateralValue` at the oracle price, the collateral value is considered negligible and the position qualifies for write‑off.
* Three actions then occur atomically:
1. Delete borrower debt: The borrower’s entire outstanding debt is wiped.
2. Redistribute the wiped debt: The same amount of debt is added back to the system by increasing total free and total paid debt in proportion to their current sizes.
3. Transfer residual collateral: All of the borrower’s remaining collateral is sent to `to` (the liquidator/caller), and the borrower’s collateral balance is set to zero.
This function is called from liquidations via a safe external call (try/catch) so that liquidation success is not jeopardized if the write‑off preconditions are not met.
## Impact
Effects by stakeholder:
* Remaining borrowers (free and paid): Their total pool debt increases while their individual shares remain unchanged, so their computed debts rise proportionally. This fairly spreads the loss across active borrowers.
* Liquidator/caller: Receives the borrower’s remaining collateral as compensation for calling the `writeOff()` function.
* `Coin` holders/stakers: Re-collateralizes their holdings using collateral of other borrowers and avoids bank runs.
## Prevention
Preventing bad debt write‑offs starts with prudent instance configuration and healthy market structure:
* Conservative collateral factors and robust oracles limit the chance of undercollateralization.
* Timely liquidations reduce drift into the write‑off zone.
* The immutability deadline locks sensitive parameters after launch, removing configuration risk over time.
Related:
* [Liquidations](/protocol/liquidations)
* [Paid vs Free Debt](/protocol/paid-vs-free-debt)
# Immutability Deadline
Source: https://docs.monolith.market/protocol/immutability-deadline
Time‑locked switch that permanently disables sensitive controls, making an instance credibly neutral after launch.
# Immutability Deadline
## Overview
Each instance has an immutability deadline: a timestamp after which sensitive parameters and admin actions permanently lock. This turns the instance into a credibly‑neutral system with no ongoing configuration powers over protocol behavior.
## Why it exists
* Early flexibility: Gives operators the ability to finetune parameters after launch.
* Predictability: Once locked, users can rest assured that the rules will never change.
* Safety: Eliminates the possibility of human error, building Lindiness over time.
## How it’s set
* On deployment, the deadline is set to `deployTimestamp + timeUntilImmutability`.
* `timeUntilImmutability` is bounded (at most 4 years) and can be `0` for immediate immutability at launch.
* Before the deadline, the operator may call an early lock by calling `enableImmutabilityNow()` (irreversible, cannot be delayed or reopened later).
## What the deadline locks
After the deadline passes (or is enabled early), the following become permanently unavailable:
* Interest policy knobs:
* Half‑life of rate changes (exponential rate)
* Target free‑debt ratio band
* Redemption fee basis points
* PSM‑related mutability:
* The buy path (asset→coin) through the PSM wrapper
These gates ensure the instance’s monetary policy surface cannot be altered after the lock, and that exposure to the PSM asset can no longer increase.
## What remains adjustable (intentionally)
Only fee-related actions remain accessible by the operator:
* Operator/manager rotation
* Local reserve fee bps for the instance operator (bounded by a 10% cap)
* Pulling the instance operator fee
## Related
* [Interest Rate Controller](/protocol/interest-rate-controller)
* [Paid vs Free Debt](/protocol/paid-vs-free-debt)
# Interest Rate Controller
Source: https://docs.monolith.market/protocol/interest-rate-controller
How interest rates are determined and controlled
# Interest Rate Controller
## Overview
The Interest Rate Controller sets the borrow rate for each instance to keep the system balanced and liquid. It is designed to be:
* Predictable: changes follow smooth, time‑based curves rather than step functions.
* Objective: driven by a single measurable signal — the share of free (redeemable) debt in the system.
* Resilient: implemented as a shared, minimal, non‑upgradeable, external math contract with a failsafe in case of unexpected reverts.
## Why it exists (and what’s unique)
* Ensures exit liquidity: By targeting a healthy share of free debt, the controller helps keep redemption capacity available without constant governance.
* Enforces peg stability: The controller infers the market condition of the stablecoin through borrower choice and uses this signal to steer the peg to \$1.
* Aligns incentives: When free‑debt share is scarce, rates rise to encourage migration to free debt (or repayment). When it’s abundant, rates decay toward a low floor to make paid borrowing attractive again.
* Smooth policy, minimal complexity: Adjustments are exponential over time with an explicit floor, avoiding volatile jumps.
## How it works (high‑level)
* The controller observes the system’s free‑debt ratio `f` and compares it to a target band `[f_start, f_end]`.
* If `f < f_start`: the borrow rate increases over time (borrowers mostly choose paid; perceived redemption risk high; price likely ≤ \$1).
* If `f > f_end`: the borrow rate decays over time toward a minimum floor (borrowers mostly choose free; perceived redemption risk low; price likely ≥ \$1).
* If `f` is inside the band: the borrow rate remains constant (price near \$1).
This feedback loop lets borrowers’ mode choices (paid vs free) collectively steer the system toward a stable equilibrium while preserving exit liquidity and peg health.
## Peg maintenance (over/under/at‑peg signals)
* The controller does not read secondary‑market prices. Instead, it treats borrower mode choices as a crowd‑sourced “indirect oracle”: the resulting free‑debt ratio `f` reflects perceived redemption risk (and thus peg pressure) in a robust, manipulation‑resistant way.
* Interpreting `f` relative to the target band:
* `f < f_start` (too little redeemable collateral): most borrowers are choosing paid debt, which we treat as an indirect signal that perceived redemption risk is high. That typically corresponds to price pressure at or below \$1 where an arbitrage opportunity opens up between redemptions and the secondary market. The controller raises the borrow rate to discourage paid borrowing and encourage migration to free debt, expanding redeemability and helping lift the price toward \$1.
* `f > f_end` (abundant redeemable collateral): most borrowers are choosing free debt, signaling perceived redemption risk is low. That typically corresponds to price pressure at or above \$1 where there is no arbitrage opportunity between redemptions and the secondary market. The controller lets the rate drift toward a floor, making paid borrowing cheaper and drawing borrowers back to paid, while incentivizing new paid borrowers to come in and increase total supply.
* `f_start <= f <= f_end`: choices are mixed, signaling moderate perceived redemption risk. The coin is likely near \$1; the rate holds steady while redemptions and market participants keep the peg tight.
* Combined with redemptions (direct \$1 exits), this creates a self‑correcting system that keeps the stablecoin near its peg without constant governance or external market information.
## Under the hood: math (from InterestModel.sol)
Let:
* `r_old`: previous borrow rate (mantissa)
* `dt`: time elapsed
* `k`: exponential rate constant (`expRate`)
* `g = exp(-k * dt)`: exponential growth/decay factor
* `D`: total paid debt (principal that accrues interest)
Case 1 — Below target (increase):
* `r_new = r_old / g = r_old * exp(k * dt)`
* `I = D * (r_new - r_old) / (k * 365 days)`
Case 2 — Above target (decay toward a floor):
* `r_new = max(r_old * g, r_min)`
If the decay crosses the floor during `dt`, interest integrates piece‑wise: an exponential segment down to `r_min`, then a flat segment at `r_min`:
* `t_min = -ln(r_min / r_old) / k`
* `I = D * ((r_old - r_min) / k + r_min * (dt - t_min)) / (365 days)`
If the floor is not reached within `dt`:
* `I = D * (r_old - r_new) / (k * 365 days)`
Case 3 — Inside the band (hold):
* `r_new = r_old`
* `I = D * r_old * dt / (365 days)`
Notes:
* The implementation uses a single function `calculateInterest(...)` to return `r_new` and the interest `I` given `D, r_old, dt, k, f, f_start, f_end`.
* A minimum rate `r_min` prevents rates from decaying below a fixed floor (0.5% APR).
* The calculation is called externally from each `Lender` with try/catch, so if anything ever failed, accrual would safely skip instead of freezing funds.
## Inputs and outputs
Inputs per accrual step:
* `totalPaidDebt` (`D`)
* `lastBorrowRateMantissa` (`r_old`)
* `timeElapsed` (`dt`)
* `expRate` (`k`)
* `lastFreeDebtRatioBps` (`f`)
* `targetFreeDebtRatioStartBps`, `targetFreeDebtRatioEndBps` (band `[f_start, f_end]`)
Outputs:
* `currBorrowRate` (`r_new`)
* `interest` (`I`) accumulated over `dt`
See also: [InterestModel contract reference](/reference/InterestModel)
## Related
* [Paid vs Free Debt](/protocol/paid-vs-free-debt)
* [Redemptions](/protocol/redemptions)
# Liquidations
Source: https://docs.monolith.market/protocol/liquidations
How unhealthy positions are force-repaid
# Liquidations
## Overview
Liquidations close unsafe positions when a borrower’s debt exceeds their borrowing power at the current oracle price. Anyone can repay part of an unsafe borrower’s debt in `Coin` and seize collateral with a variable incentive. This keeps solvency intact and prevents bad debt.
## Triggers
Liquidations are enabled only when a valid, sufficiently fresh oracle price is available. A position becomes liquidatable when:
* Borrowing power \< debt at the current price, where borrowing power = price × collateral × collateralFactor.
* When liquidations are enabled. Liquidations are disabled when no valid price is provided by the feed.
## Process
High‑level flow (per `liquidate(borrower, repayAmount, minCollateralOut)`):
1. Accrue interest and update borrower’s internal accounting.
2. Read oracle price; require liquidations to be allowed.
3. Compute the maximum chunk that can be liquidated now:
* If the position is healthy, liquidation is not allowed.
* If unhealthy, the protocol allows liquidating up to 25% of the borrower's debt, but at least a minimum chunk size (10,000 `Coin`) when applicable.
4. Reduce the borrower’s debt by `repayAmount`.
5. Compute the liquidator’s collateral reward at the current price with an incentive (see Incentives below).
6. Cap the reward by the borrower’s remaining collateral and enforce `minCollateralOut` (slippage protection for the liquidator).
7. Transfer collateral to the liquidator; pull `repayAmount` of `Coin` from the liquidator and burn it.
8. If the position is undercollateralized, the protocol attempts a write‑off: delete remaining debt, redistribute it across the system’s borrowers, and hand the borrower’s remaining collateral to the liquidator.
## Incentives
The liquidation incentive scales with how far the position is beyond the collateral factor:
* 0% incentive when loan‑to‑value (LTV) is at or below the collateral factor.
* Up to 10% when LTV is 5 percentage points above the collateral factor.
* Linear between those points.
Collateral reward calculation (conceptually):
* collateralReward = repayAmount × (1 + incentiveBps/10,000) ÷ price
* Reward is capped so it cannot exceed the borrower’s available collateral.
This design pays more to liquidators as positions drift further into unsafe territory, incentivizing liquidators while minimizing loss to borrowers.
## Limits and safety valves
* Chunked liquidations: At most \~25% of a borrower’s debt can be liquidated per call (subject to the 10,000 `Coin` minimum). This ensures that the liquidation incentive is sufficient to attract liquidators.
* Oracle‑gated: If the oracle is stale/invalid, liquidations are temporarily disabled to avoid mispricing.
* Write‑off path: If a position is effectively irrecoverable (debt > 100× collateral value), remaining debt can be redistributed among borrowers, and the liquidator receives the borrower’s remaining collateral (negligible).
## Example
* Suppose a borrower has debt of 200,000 `Coin`, collateral value of 230,000 at the oracle price, and a collateral factor of 80% (borrowing power = 184,000). The position is undercollateralized (200,000 > 184,000).
* Maximum liquidatable chunk is 25% of debt = 50,000 `Coin` (greater than the 10,000 minimum).
* If the incentive computes to 8%, and the price implies 1 `Coin` buys \$1 of collateral value, then the liquidator who repays 50,000 `Coin` receives collateral worth 54,000 in value (capped by what’s available), transferred at the oracle price.
# Overview
Source: https://docs.monolith.market/protocol/overview
Deep dive into Monolith protocol mechanics, economics, and technical specifications
## Core Concepts