> ## Documentation Index
> Fetch the complete documentation index at: https://lending.satsterminal.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Architecture
> How the protocol is built, and why each choice is deliberate.
# 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:
Not a bridge to Bitcoin. Not a wrapped representation. State settles into Bitcoin's security model, not alongside it.
Standard Solidity tooling, standard audit pipelines, standard wallet integrations. Nothing exotic for an integrator to learn.
Liquidations land in time. Borrowers can act on opportunity. The protocol's economic guarantees survive volatility.
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.
**You post collateral into a specific market and draw the loan asset against it,** up to that market's loan-to-value limit. Posted collateral is tracked as an internal balance against your address — nothing is sent back to your wallet for it. The borrowed asset is transferred directly to you, and your outstanding debt is tracked as borrow shares in the market contract; there is no debt token in your wallet to manage.
Interest accrues on your outstanding debt. You can repay any amount, any time. You can add collateral or repay debt to stay clear of the liquidation threshold.
If your health drops below threshold, your position is liquidatable by anyone, immediately. There is no grace period and no discretion.
**You monitor unhealthy positions and call the liquidation function.** Liquidations are permissionless, no whitelist, no auction.
You repay a portion of the borrower's debt and receive collateral at a discount that compensates you for execution and capital.
The liquidation path is the protocol's main defense against bad debt. It is deliberately simple, deliberately fast, and deliberately open to anyone who can run a bot.
***
## 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:
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 vote can pause your withdrawal, freeze a market, or change a position's terms.
The lending core does not upgrade. New capability ships as new markets and new layers, not as mutations of the base.
There is no aggregate liability. There is no surface to contaminate.
How each class of residual risk is identified, bounded, and disclosed.