Bitcoin Deposits: A Layer 3 Protocol for Trust-Minimized Lightning Wallets

Vinny Fiano
ynniv@ynniv.com
npub12akj8hpakgzk6gygf9rzlm343nulpue3pgkx8jmvyeayh86cfrus4x6fdh

Abstract

We present Bitcoin Deposits, a Layer 3 protocol utilizing Proof of Over-Reserves that enables users to maintain Lightning wallets without requiring on-chain Bitcoin transactions or channel management. This protocol introduces validated outputs—a new Lightning extension that allows commitment transactions to include outputs subject to agreed-upon validation rules, enforcing protocol compliance at the consensus layer. Through cryptographic authentication, mandatory over-reserve requirements, metrics-based auditor monitoring, and deterministic validation rules, the system creates economic incentives for honest behavior while providing instant Lightning access. Integration with Nostr Wallet Connect enables users to access deposits from any compatible wallet interface. We rely on objective performance metrics and neutral party intervention for recovery scenarios, creating a trust-minimized (but not fully trustless) system that bridges the gap between custodial services and self-custody for users below the UTXO line.

1. Introduction

The Lightning Network has demonstrated the viability of off-chain Bitcoin transactions, achieving sub-second settlement times with minimal fees. However, adoption remains constrained by the complexity of channel management and the requirement for on-chain transactions to establish payment channels. Each new Lightning user must execute at least one on-chain transaction, creating a scalability bottleneck as Bitcoin’s block space is limited.

Critically, millions of potential Bitcoin users exist “below the UTXO line”—their total holdings are worth less than the on-chain fees required to establish self-custody. The ‘UTXO line’ represents the economic threshold where transaction fees exceed the practical value of creating a UTXO. When fees are $50, anyone with less than $500-1000 faces prohibitive costs.</span> When transaction fees spike to $50 or more, users with $100 in savings face an impossible choice: pay 50% of their wealth in fees or remain on custodial services. This economic reality locks out the very populations that would benefit most from Bitcoin’s financial inclusion.

Additionally, Lightning’s current architecture assumes users can maintain high availability for channel management and have reliable internet for gossip synchronization. This excludes users in developing regions with intermittent connectivity and those who need simple, phone-based payment solutions.

Existing solutions to this problem involve custodial services that sacrifice Bitcoin’s core property of trustlessness. Users must trust operators to maintain reserves and process withdrawals honestly. Chaumian Ecash systems like Cashu provide privacy but require users to trust mints with custody of funds.

We propose a new layer 3 protocol that enables Lightning wallets through validated outputs—a Lightning protocol extension that allows commitment transactions to include outputs subject to agreed-upon validation rules. Users control deposits through cryptographic keys without managing channels, while operators are constrained by protocol rules enforced at the Lightning channel level and monitored by auditors. The system achieves:

2. Validated Outputs Extension

2.1 Overview

Bitcoin Deposits requires a new Lightning Network protocol extension called “validated outputs” that enables commitment transactions to include additional outputs subject to validation rules agreed upon by channel partners. This mechanism provides cryptographic enforcement of Layer 3 protocols at the Lightning consensus layer.

2.2 Protocol Layers

┌─────────────────────┐
│      Layer 3        │  Bitcoin Deposits Protocol
│  (Deposit Wallets)  │  - Deposit management
│                     │  - Payment authorization
├─────────────────────┤
│      Layer 2        │  Lightning Network + Validated Outputs
│ (Payment Channels)  │  - Validation framework
│                     │  - Commitment transactions
├─────────────────────┤
│      Layer 1        │  Bitcoin Blockchain
│    (Settlement)     │  - Proof of Work
│                     │  - UTXO model
└─────────────────────┘

2.3 Protocol Integration

The validated outputs extension requires:

  1. Feature Negotiation: New feature bit option_validated_outputs
  2. Channel Messages: Extended to support validator negotiation
  3. Update Protocol: New message types for validated output operations
  4. Commitment Structure: Validated outputs included deterministically
  5. Auditor Requirements: Deposit auditors must approve of vault operators

Both channel partners must validate all outputs before signing commitments, ensuring consensus on protocol rules.

2.4 Auditors

In the Bitcoin Deposits protocol, “auditors” serve a dual purpose:

  1. Watchtower role: Monitor for outdated commitment transactions
  2. Monitoring role: Validate and monitor vault operator behavior

Auditors are peers that validate commitment transactions but cannot reject them. Instead, they:

Critically, auditors can be operated by various entities:

Each deposit specifies a set of acceptable auditors, while the channel state tracks which auditors are currently participating. This creates a two-layer system: deposits express auditor preferences, and channels enforce auditor participation.

3. Validation Rules

3.1 Core Validation Functions

The Bitcoin Deposits validator implements validation with full deposit state visibility

3.2 Maintenance Fee Implementation

Maintenance fees are enforced through block-based timing mechanisms similar to HTLC timeout periods

Fee Application Examples:

Timing Mechanism: Fees are calculated and applied during commitment transaction creation, ensuring deterministic timing. The block-based approach provides:

4. Security Model

4.1 Trust-Minimized Operation

Important: This protocol is trust-minimized, but not fully trustless. Operators retain the ability to steal funds through various mechanisms:

The protocol minimizes trust requirements through:

The system is designed for amounts where these protections provide adequate security—typically $5-200 per deposit. Users can further reduce risk by distributing funds across multiple vaults.

4.2 Auditor Monitoring

Reputation System Framework:

Storage and Query:

Key Insight: This is not a social reputation system—auditors report objective metrics that can be independently verified. Users don’t need to interpret complex scores; wallets can provide simple interfaces showing vault health.

4.3 Recovery Mechanisms

Cooperative Channel Close:

  1. All deposits must be transferred to other vaults or withdrawn
  2. Validated output must be removed (zero balance)
  3. Standard Lightning cooperative close proceeds

Force Close Recovery:

  1. Validated output appears in commitment transaction
  2. Vault funds and security deposit transfer to neutral party
  3. Neutral party coordinates re-homing of deposits
  4. Balances obtained via auditor records or channel counterparty

Recovery Guarantee: Users’ funds are protected through the combination of:

Bootstrap Strategy: Initial neutral parties may include:

4.4 Atomic Vault Transfers

Deposits transfer between vaults using atomic Lightning payments:

Transfer Process:
1. Verify destination vault meets requirements:
   - Supports Bitcoin Deposits protocol
   - Has acceptable auditor approval
   - Has sufficient capacity and reserves

2. Create Lightning payment to destination vault with metadata:
   - Transfer amount
   - Deposit public key
   - Authorization signature

3. Upon payment confirmation:
   - Destination vault adds deposit with transferred balance
   - Origin vault zeros the deposit balance
   - Both vaults update their validated outputs

4. If payment fails, no state change occurs (atomicity preserved)

4.5 Operational Flexibility

The protocol’s design enables flexible deployment models:

Geographic Distribution: Vault operators can serve users globally without geographic restrictions. The Lightning Network’s onion routing naturally provides payment privacy.

Pseudonymous Operation: Both vault operators and auditors can build reputation using persistent cryptographic identities rather than real-world identities. This allows new entrants to establish trust through consistent good behavior.

User Privacy: Users need only share:

Connection Privacy: Standard privacy tools enhance operational security:

5. Implementation Requirements

5.1 Lightning Node Requirements

Message Flow Integration: Validated output messages integrate with existing Lightning message flow during commitment transaction updates. Both channel partners must validate all outputs before signing new commitments, ensuring consensus on protocol rules.

5.2 Vault Operator Requirements

5.3 Auditor Requirements

5.4 Client Requirements

Nostr Wallet Connect Integration:

6. Protocol Analysis

6.1 Target Use Cases

Bitcoin Deposits specifically targets users and scenarios poorly served by existing solutions:

Below UTXO Line Users:

Low Availability Users:

Specific Applications:

6.2 Risk Management Through Diversification

Users can significantly reduce trust requirements through smart deposit management:

Multiple Small Deposits:

Dynamic Rebalancing:

Availability Benefits:

This approach transforms the trust model: instead of trusting one operator with $100, trust ten operators with $10 each—significantly reducing the incentive for theft while improving availability.

6.3 Progressive Trust Model

The protocol enables natural progression as users’ needs evolve:

Trust                               Complexity
Level                               Level
  |                                 |
  |   Raw Lightning                 | High
  |   (Full control)                |
  |                                 |
  |   Phoenix/Breez                 |
  |   (Self-custody)                |
  |                                 |
  |   Community Vault               |
  |   ($100s, community auditors)   |
  |                                 |
  |   Corp-Audited Vault            |
  |   ($100s, corporate auditor)    |
  |                                 |
  |   Exchange Balance              | Low
  |   (Full Custody, zero control)  |
  |                                 |
  v                                 v

Users can move between models based on:

6.4 Trust Model

The protocol operates on a trust-minimized model appropriate for its use cases:

For coffee-money amounts ($5-$200):

Cryptographic guarantees:

Economic and social guarantees:

6.5 Privacy Implications

Current privacy characteristics support flexible deployment:

What operators see:

What remains private:

Deployment flexibility:

6.6 Comparison with Existing Solutions

Vs. Phoenix/Breez (Self-Custodial Lightning):

Vs. Custodial Services:

6.7 Deployment Strategy

Bitcoin Deposits is designed for progressive deployment, starting with low-risk use cases and expanding as the ecosystem matures:

Phase 1: Nostr Zaps (Months 1-6)

Phase 2: Remittances & Tips (Months 6-12)

Phase 3: General Purpose (Year 2+)

Success Metrics:

6.8 Open Questions and Future Work

  1. Reputation System: Concrete implementation needed
  2. Neutral Party System: Selection and incentive mechanisms
  3. Maintenance Fee Timing: When and how fees are applied
  4. Economic Analysis: Fee structures and viability
  5. Privacy Enhancements: Potential cryptographic solutions
  6. Version Migration: Upgrade mechanisms for the protocol

7. Conclusion

Bitcoin Deposits addresses a critical gap in Bitcoin’s infrastructure: serving users below the UTXO line and those with limited connectivity. By providing a trust-minimized alternative to fully custodial services, the protocol enables millions of potential users to access Lightning payments without the burden of channel management or on-chain fees.

The key insight is matching security models to use cases. For coffee-money amounts, Proof of Over-Reserves with metrics-based auditing provides an acceptable risk/reward tradeoff—similar to how users trust payment apps or transit cards with small balances. This pragmatic approach enables:

The protocol succeeds not by replacing self-custodial Lightning but by providing a bridge for users who would otherwise remain on centralized exchanges. Starting with Nostr zaps demonstrates the model with minimal risk, while the flexible deployment model allows operators to serve users globally. The metrics-based trust system enables participants to establish credibility through consistent good behavior rather than regulatory compliance.

Bitcoin Deposits represents a practical step toward the Lightning Network’s goal of bringing Bitcoin payments to billions of users. By acknowledging that different users have different needs, and that perfect trustlessness isn’t required for every use case, we can build systems that serve real users today while maintaining Bitcoin’s core values of cryptographic verifiability and user sovereignty.

Future development will focus on implementation across Lightning nodes, privacy enhancements, and ecosystem growth. The protocol is designed to evolve as the Lightning Network matures, always providing users with the best tradeoff between security and usability for their specific needs.

Bitcoin Deposits: A Layer 3 Protocol for Trust-Minimized Lightning Wallets -