# Security Model

LayerBTC inherits Bitcoin’s security guarantees and layers additional protections that match its modular architecture. This section presents (i) the formal threat model, (ii) the cryptographic primitives employed, (iii) independent-audit results, and (iv) mitigation and upgrade strategies.

### Threat Model

| Threat Class                | Targeted Layer           | Impact if Unmitigated                                         |
| --------------------------- | ------------------------ | ------------------------------------------------------------- |
| Key Compromise              | Vault & Assets           | Theft, asset freeze, loss of control                          |
| State Revocation            | Lightning++              | Channel funds stolen via outdated commitment                  |
| Protocol Downgrade / Replay | All RPC channels         | Forced use of weaker cipher-suites, replay of signed messages |
| Double-Mint / Inflation     | Assets Module            | Undercut asset supply integrity                               |
| DoS & Resource Exhaustion   | Service Layer            | Payment latency spikes, mint/transfer stalls                  |
| Supply-Chain Attack         | Dev-Hub templates & SDKs | Injection of back-doored dependencies                         |

***

### Cryptographic Foundations

* Schnorr Signatures (BIP-340) – Deterministic, linear-in-nonce signatures enable MuSig2 aggregation and PTLC adaptor keys.
* MuSig2 – Two-round multisignature protocol securing vault policies with low interactive overhead.
* Taproot Tweaks – Assets are committed in Taproot leaves, producing short proofs with native key-path spending for simple sends.
* Adaptor Signatures (PTLCs) – Route-blinded, asset-aware Lightning swaps with minimal value-correlation leaks.
* Noise\_KX Handshake – Authenticated gRPC streams between modules, binding channel keys to TLS certs and thwarting replay/downgrade.

### Mitigation Strategies

| Threat             | Primary Mitigation                             | Secondary Controls                                 |
| ------------------ | ---------------------------------------------- | -------------------------------------------------- |
| Key compromise     | Hierarchical MuSig2 + Shamir offline shards    | Time-delayed exits; watchtower sweep scripts       |
| State revocation   | Breach remedy transactions embedded by default | Third-party watchtowers monitor 24/7               |
| Replay / downgrade | Channel-binding tokens & nonce curtains        | Versioned protobuf schemas, HSTS for APIs          |
| Double-mint        | Single-use GenesisDescriptor signed by issuer  | Merkle indexers cross-validate supply in real time |
| DoS                | Adaptive token bucket per peer & gRPC stream   | Horizontal scaling via stateless micro-services    |
| Supply-chain       | Reproducible builds, sigstore attestations     | Template CI scans (SCA + fuzz) before merge        |

### Upgrade & Recovery Path

* Semantic Version Fences – Clients can interact only within a ±1 minor-version window; older nodes default to receive-only mode, never risking fund loss.
* Shadow Migrations – New cryptographic primitives introduced behind feature flags; dual-signing (old + new) for one release cycle ensures safe rollout.
* Emergency Revocation – A two-of-three multisig of core maintainers can publish a “freeze script” disabling new mints or channel opens in the rare event of critical exploit discovery—funds already on-chain remain spendable.

Through layered cryptography, conservative engineering, and transparent third-party review, LayerBTC delivers a security posture that matches Bitcoin’s own ethos: assume hostile networks, minimise trust, and keep the exit keys in the user’s hands.

<br>