What it is
Asset-liability management (ALM) is the practice of a protocol tracking and actively adjusting its assets (what it holds — collateral, reserves, yield-bearing positions) against its liabilities (what it owes — outstanding stablecoins, deposits, debt to users) so the two stay in balance. It's the same discipline banks and insurers use off-chain, applied on-chain to protocols like stablecoins, lending markets, and yield vaults where the protocol itself sits between depositors and the assets backing their claims.
How it works
- The protocol defines its liabilities precisely: every unit of a stablecoin in circulation, every deposit owed back to a lender, or every share of a vault represents a claim the protocol must be able to honor.
- On the asset side, the protocol holds a mix of collateral — this could be volatile crypto, yield-bearing positions, hedges via derivatives, or a mix of on-chain and off-chain instruments — chosen to back those liabilities.
- The protocol (via governance, an algorithm, or a designated risk team) continuously monitors the ratio of assets to liabilities, often expressed as a collateralization ratio or reserve ratio.
- When market moves threaten the ratio — say, collateral value drops relative to liabilities — the protocol triggers rebalancing actions: adjusting hedge positions, raising collateral requirements, pausing new issuance, or liquidating under-collateralized positions.
- Some designs actively hedge duration and volatility mismatches, for example holding derivatives positions specifically to offset the risk that the backing asset moves against the liability it's meant to cover.
- Reporting mechanisms (on-chain proof-of-reserves, attestations, dashboards) let users verify the asset side actually covers the liability side at any point in time, which is what keeps confidence in redemption intact.
Why designers use it
- Keeps a protocol solvent through market volatility by ensuring assets can always cover what's owed, rather than assuming static market conditions will hold.
- Builds user trust in stablecoins, lending pools, or vaults by making solvency verifiable rather than something users must simply take on faith.
- Allows a protocol to take on more sophisticated, higher-yielding, or more capital-efficient positions (hedged exposure, leverage) while still managing downside risk within defined limits.
- Provides an early-warning system: tracking the asset/liability ratio continuously lets a protocol react to stress before it becomes an insolvency event.
Failure modes
- Correlated collateral risk: if the assets backing liabilities are correlated with the liabilities themselves (e.g., a stablecoin backed partly by its own governance token), a market crash can hit both sides simultaneously and the buffer disappears exactly when it's needed.
- Hidden liquidity mismatch: assets may be technically sufficient on paper but locked in illiquid or long-duration positions, so the protocol can't actually meet a wave of redemptions even though its balance sheet looks solvent.
- Oracle or reporting lag: if the ratio is calculated from stale or manipulable price feeds, the protocol can believe it's healthy while actually under-collateralized.
- Discretionary rebalancing risk: if rebalancing depends on a human team or governance vote acting fast enough, a sudden market move can outpace the protocol's ability to react, turning a manageable dip into an insolvency.
- Opacity: without regular, verifiable reporting, users have no way to know the true asset/liability ratio, and a protocol can operate under-collateralized for a long time before anyone notices.
What to check before using it
- Look for regular, verifiable proof-of-reserves or on-chain attestations rather than relying on team statements about solvency.
- Check how correlated the backing assets are with the liabilities they cover — same-asset or same-ecosystem backing is a red flag for cascading failure.
- Assess the liquidity of the asset side: can it actually be converted to meet redemptions quickly, or is it locked in long-duration or illiquid positions?
- Verify what triggers rebalancing (automated rules vs. discretionary governance) and how fast that process can execute during a stress event.
- Confirm the oracle sources used to calculate the asset/liability ratio are robust to manipulation and update frequently enough to reflect real market conditions.