LiquidSat Security Model: Bitcoin-Native and Non-Custodial

Security as an Architectural Choice

Most Bitcoin lending systems fail not because of bugs, but because of structural risk assumptions:

LiquidSat's security model is built to avoid these assumptions entirely.

• Trusting custodians
• Relying on wrapped assets
• Depending on discretionary intervention
• Centralizing price authority

Custodial Lending: Centralized Risk

Custodial Bitcoin lending platforms require users to transfer BTC to a centralized entity.

This introduces:

History has shown that even well-capitalized custodians can fail under stress. LiquidSat does not custody Bitcoin or capital at any point.

• Counterparty risk
• Rehypothecation risk
• Opaque balance sheets
• Discretionary control over withdrawals and liquidations

Wrapped Bitcoin and Bridge Risk

Wrapped BTC systems replace native Bitcoin with synthetic representations issued on other chains.

This model introduces:

Even when collateralized, wrapped assets rely on off-chain trust assumptions. LiquidSat does not issue wrapped BTC or use bridge custody.

• Bridge exploits
• Custodian key risk
• Delayed or frozen redemptions
• Dependency on external governance

Bitcoin-Native Collateral Guarantees

LiquidSat secures Bitcoin collateral directly on the Bitcoin network using native execution conditions.

Security properties of this approach:

• Bitcoin remains on Bitcoin at all times
• Collateral conditions cannot be altered after creation
• No external system can seize or redirect funds
• Collateral behavior is enforced by the protocol, not by operational policy

Deterministic Outcomes, Not Discretion

A core risk in many lending platforms is human intervention during stress events.

LiquidSat avoids this by:

This ensures predictability for both borrowers and lenders, even during market volatility.

• Defining all settlement paths in advance
• Removing discretionary approvals
• Enforcing outcomes automatically when conditions are met

Oracle Risk and Price Integrity

Price feeds are one of the most common failure points in collateralized systems.

LiquidSat mitigates oracle risk through:

No single oracle can:

Oracle inputs are treated as signals, not authorities.

• Multiple independent price sources
• Predefined tolerance thresholds
• Trigger liquidation
• Halt settlement
• Manipulate outcomes

Failure Isolation and Containment

LiquidSat is designed to isolate failures rather than propagate them.

Examples:

This reduces systemic risk and prevents platform-wide failures.

• A single agreement failure does not affect others
• Oracle anomalies do not cascade across positions
• Liquidity pools are isolated by terms and risk profiles

No Rehypothecation, No Hidden Leverage

Collateral locked on LiquidSat:

This eliminates hidden leverage and ensures that exposure is always explicit.

• Cannot be reused
• Cannot be pledged elsewhere
• Cannot be leveraged beyond defined terms

Security Without Governance Dependency

LiquidSat's security model does not rely on:

The system is designed to function predictably without intervention, even in adverse conditions.

• Emergency governance actions
• Manual liquidations
• Trusted operators

What Security Means for Users

Security by Design, Not Promises

LiquidSat does not attempt to "insure away" risk through guarantees or intermediaries.

Instead, it reduces risk by removing trust assumptions entirely and enforcing outcomes at the protocol level.

Learn More

For readers who want to go deeper into execution details, threat models, and protocol mechanics, refer to the technical documentation:

• Explore the LiquidSat GitBook