Skip to main content

​
A protocol you can hold in your head.

Most lending protocols are large, governed, and upgradeable. They have to be. They accumulated complexity to paper over the limits of their original design. SatsTerminal Lending starts from the opposite premise: the smallest set of mechanisms that can correctly price and settle BTC-denominated credit, and nothing else. This page walks through that design layer by layer.

​
1. The settlement layer: Flashnet

SatsTerminal Lending settles to Bitcoin via Flashnet, a Bitcoin-native execution layer. The relevant properties for a lending protocol:

Native to Bitcoin

Not a bridge to Bitcoin. Not a wrapped representation. State settles into Bitcoin’s security model, not alongside it.

EVM-compatible execution

Standard Solidity tooling, standard audit pipelines, standard wallet integrations. Nothing exotic for an integrator to learn.

Sub-second finality

Liquidations land in time. Borrowers can act on opportunity. The protocol’s economic guarantees survive volatility.

Sovereign assets

Users hold the actual asset. No wrapped BTC. No bridge multisig holding redemption rights.
The point isn’t that Flashnet is the only environment in which BTC lending could be built. It’s that it’s the first environment in which it can be built without giving up the properties that made Bitcoin worth lending against in the first place.

​
2. The market model: isolated, not pooled

The single most consequential design decision in the protocol. In a pooled lending protocol (the original DeFi design), every listed asset shares one risk surface. A bad oracle on a small collateral type can, and historically has, drained the entire protocol. Risk parameters are set by governance, often slowly, often after the damage is done. In an isolated market model, every market is its own ring-fenced contract. A market is defined by:
  • A specific collateral asset
  • A specific loan asset
  • A specific oracle
  • A specific set of risk parameters (LTV, liquidation threshold, interest curve)
Lenders choose which markets to supply. A failure in one market is contained to that market. Other markets, and the protocol as a whole, are structurally untouched.
Risk isolation isn’t a feature. It’s the topology of the protocol. There is no shared pool to be drained.

​
3. The trust model: ungoverned by design

The protocol has no admin keys over user funds. There is no upgrade path that can change market behavior after deposits land. There is no governance vote that can pause withdrawals, change parameters retroactively, or seize collateral. This is a deliberate restriction on what the protocol is allowed to become. A protocol that can change its own rules under pressure is one whose risk model is fundamentally undefined, you are not just underwriting the code, you are underwriting whoever holds the keys. We have chosen not to give you that problem to solve.

​
4. Three roles, three views

The same protocol looks different depending on what you’re doing on it. Each view below is what the protocol does for that participant, mechanically.
You deposit the loan asset of a specific market. Your claim on the supply side is tracked as supply shares in the market contract — internal accounting, not an ERC-20 wrapper sent to your wallet.Borrowers in that market pay interest, which accrues to the supply side and increases the value of your shares over time.You can withdraw, proportional to your shares, as long as the market has free liquidity. Utilization determines the rate you earn and the speed at which you can exit. There is no governance lever in this loop.What you are exposed to: the collateral asset of this market, the oracle for that asset, and the soundness of the liquidation engine. Nothing else in the protocol can hurt you.

​
5. The oracle question

Every lending protocol’s risk reduces, eventually, to its oracle. We treat the oracle as a per-market choice, not a global parameter. Each market specifies its own price source. That source can be a battle-tested feed (e.g., Pyth/Chainlink-class providers), a TWAP from a deep on-chain venue, or, for highly conservative markets, a redundant combination of both. Markets with low-quality oracles are markets that lenders will not supply, and that is the correct outcome. The discipline imposed by isolated markets is what makes this work: a bad oracle hurts only the lenders who chose that market. The protocol does not socialize that loss.

​
6. What the core actually contains

The lending core is small, small enough that a reviewer can hold the full state machine in their head. It implements:
  • Supply / withdraw accounting
  • Borrow / repay accounting
  • Interest accrual against utilization
  • Liquidation at threshold
  • Per-market oracle integration
That’s the whole protocol. Everything else (market creation, integrations, front-ends, vault layers) sits outside the core and cannot break what’s inside it.
The minimal core is the security argument. Fewer moving parts, fewer surfaces, fewer ways to be wrong.

​
7. What we did not build

Equally important to the design:

No protocol-owned bridge

The protocol does not custody assets in a bridge. There is no wrapped-BTC issuer in the path. The protocol holds no redemption rights over user funds.

No governance over funds

No vote can pause your withdrawal, freeze a market, or change a position’s terms.

No upgrade path on the core

The lending core does not upgrade. New capability ships as new markets and new layers, not as mutations of the base.

No shared risk pool

There is no aggregate liability. There is no surface to contaminate.

Read the risk framework →

How each class of residual risk is identified, bounded, and disclosed.