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

Vinny Fiano
ynniv@ynniv.com
npub12akj8hpakgzk6gygf9rzlm343nulpue3pgkx8jmvyeayh86cfrus4x6fdh

TL;DR

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 participant must execute at least one on-chain transaction, creating a scalability bottleneck as Bitcoin’s block space is limited.

Additionally, Lightning’s current architecture assumes participants can maintain high availability for channel management and have reliable internet for gossip synchronization. This excludes those in developing regions with intermittent connectivity and those who need simple, phone-based payment solutions. Even wealthy participants may prefer the simplicity of delegated channel management while maintaining cryptographic control of their funds.

Existing solutions to this problem involve custodial services that sacrifice Bitcoin’s core property of cryptographic verifiability. Depositors must trust operators to maintain reserves and process withdrawals honestly. Chaumian Ecash systems provide privacy but require participants to trust mints with custody of funds without transparent reserve requirements.

We propose a new layer 3 protocol that enables Lightning wallets through validated outputs: a Lightning protocol extension that describes new commitment transaction outputs which are subject to negotiated validation rules. Depositors will control funds through cryptographic keys without managing channels, while operators are constrained by protocol rules enforced at the Lightning channel level and monitored by other channel partners. Vaults are addressed using a multisig between channel partners. Security deposits and penalties when presented with pre-images for signed invoices that were never credited prevent operators from pocketing payments intended for vaults. Consensus rules allow operators to establish recurring maintenance fees, making profitability commonly achievable.

The system achieves:

1.1 Design Notes

2. Validated Outputs Extension

2.1 Overview

Bitcoin Deposits uses a new Lightning Network protocol extension called Validated Outputs that manages additional channel outputs which are subject to negotiated validation rules. 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)  │  - Private key controlled deposits
│                     │  - Multisig attestation
│                     │  - Security deposits and recovery protocol
├─────────────────────┤
│      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. Multisig Coordination: Both peers must cooperate for vault payment processing

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

2.4 Cross-Vault Auditing Network

In the Bitcoin Deposits protocol, auditing is handled through a natural network of cross-vault relationships rather than dedicated auditor entities. Operators should spread their vault operations across 4-6 different channel partners, and aim for each vault to be audited by the channel partners from the their other vaults.

Cross-Auditing Structure:

Auditing Functions:

Network Benefits:

3. Deposits

3.1 Overview

A core mechanic of Bitcoin Deposits is multisig invoice attestation This prevents operators from acting without oversight. If payments are not credited, evidence of payment results in loss of security deposits.

3.2 Vault Creation and Addressing

Vault Creation: A vault is created using a MuSig2 aggregated public key derived from both channel peers:

vault_address = MuSig2.KeyAgg(
    derive_key(operator_key, vault_id),
    derive_key(partner_key, vault_id)
)

3.3 Payment Processing

Invoice Generation: The vault operator creates an invoice with metadata identifying the target deposit. The channel partner verifies there are security deposits exceeding the high-water mark of recent invoice amounts. If the invoice is well formed and properly secured, both parties use MuSig2 to attest validity of the invoice.

Payment Receptino The operator chooses to place payment balances on the correct deposit. If they choose to keep the funds, it is up to the depositor to reveal proof of payment.

Preventing Payment Theft When a signed invoice has been paid, the payer will know the payment secret. They can share this secret with the depositor, who can broadcast both the invoice and the secret to all nodes associated with the deposit. An honest channel partner, seeing proof of payment without a corresponding credit, is required to force close the channel. The high-water payment security funds are used to make the depositor whole.

4. Validation Rules

4.1 Core Validation Functions

The Bitcoin Deposits validator implements validation with full deposit state visibility. Validation rules are deterministic and agreed upon by all channel participants.

4.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:

5. Security Model

5.1 Trust-Minimized Operation

This protocol is trust-minimized, not fully trustless. However, the MuSig2 addressing and multi-vault architecture significantly reduce trust requirements by preventing the most common attack vectors.

Primary Attack Vectors:

  1. Operator-Channel Partner Collusion: Both parties cooperate to steal vault funds
  2. Operator Payment Pocketing: The operator receives a payment but doesn’t credit the deposit
  3. Recovery Party Failure: Recovery party doesn’t properly reintegrate deposits after force close
  4. Fake Invoice Generation: Operator creates invalid invoices to steal individual payments

Trust Minimization Through:

Organic Trust: The protocol creates organic trust through structural incentives rather than pure reputation:

5.2 Multi-Vault Architecture for Collusion Prevention

Recommended Vault Network Structure: Operators should maintain 4-6 vaults with different channel partners, creating a robust cross-auditing network:

Operator A with Channel Partners B, C, D, E, F
├── Vault A-B (audited by partners C, D, E, F)
├── Vault A-C (audited by partners B, D, E, F)
├─ [...]

Security Deposit Alignment: Each operator’s security deposit per vault equals:

Security Deposit = 100% of vault value ÷ number of other vaults

For 5 total vaults: Security deposit = 25% of vault value For 6 total vaults: Security deposit = 20% of vault value

Cross-Auditing Network Effect: This structure creates powerful economic incentives against collusion:

Economic Balance:

5.3 Attack Vector Analysis

1. Operator-Channel Partner Collusion

2. Operator Payment Thft

3. Recovery Party Failure

4. Fake Invoice Generation

5.4 Reputation-Value Matching

The key insight of Bitcoin Deposits is that deposit sizes should match operator reputation value, enhanced by structural security:

Anonymous Operators:

Community-Known Operators:

Corporate Operators:

Depositors naturally distribute their holdings based on this hierarchy:

5.5 Cross-Vault Monitoring

Auditing peers report objective metrics about vaults:

Reporting Structure:

Network Transparency:

5.6 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 Process:

When a force close occurs, the validated output transfers vault funds and security deposits to a simple multisig controlled by the operator’s channel partners from their other vaults. This initiates a structured recovery process that distinguishes between honest operational failures and dishonest behavior.

Stage 1: Initial Force Close Output

Stage 2: Protocol Compliance Verification Channel partners verify force close circumstances through objective audit data:

Verification Activities:

Network Coordination:

Stage 3: Resolution Based on Protocol Compliance

Compliant Operator Path:

Non-Compliant Operator Path:

Stage 4: Deterministic Assignment (Non-Compliant Case)

If operator violated protocol rules, a commit-reveal process selects new operators:

Commit-Reveal Selection:

  1. Commit Phase: Each recovery participant specifies themselves, a substitute, or abstention
  2. Reveal Phase: Partners reveal selections after all commits received
  3. Entropy Combination: Use revealed selections + future block hash for final randomness
  4. Assignment: Deterministically select recovery operator(s) from qualified candidate pool
  5. Fund Transfer: Multisig releases funds to selected operator(s)

Time-Based Degradation for Assignment:

Recovery Operator Expectations:

Key Properties:

5.7 Vault-Initiated Transfers

Vaults can transfer deposits to other vaults for operational efficiency:

Transfer Process:
1. Origin vault identifies need to transfer deposits:
   - Channel capacity constraints
   - Planned channel closure
   - Liquidity rebalancing

2. Verify destination vault compatibility:
   - Supports Bitcoin Deposits protocol
   - Has acceptable reputation
   - Has sufficient capacity and reserves

3. Create keysend payment to destination vault with metadata:
   - Deposit details (public key, current fee structures, connection details)

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

5. If payment fails, no state change occurs

This enables vaults to:

Depositors discover transfers through:

Depositor-initiated rebalancing:

  1. Open new deposit at preferred vault
  2. Authorize payment from old vault to themselves
  3. Receive payment at new vault deposit

5.8 Operational Flexibility

The protocol’s design enables flexible deployment models:

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

Progressive Reputation Building: New operators can enter the market and build reputation over time:

  1. Start with small deposits from risk-tolerant depositors
  2. Establish multi-vault architecture early
  3. Build metrics through consistent operation
  4. Attract larger deposits as reputation solidifies
  5. Eventually compete with established operators

Infrastructure Specialization: Different entities can focus on their strengths:

Depositor Privacy: Depositors need only share:

Connection Privacy: Standard privacy tools enhance operational security:

6. Implementation Requirements

6.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.

MuSig2 Support:

6.2 Vault Operator Expectations

Multi-Vault Network Management:

Operational Expectations:

6.3 Channel Partner Expectations

Vault Infrastructure Support:

Cross-Auditing Responsibilities:

Network Participation:

6.4 Other-channel Partner Expectations

6.4 Independent Auditor Expectations

6.5 Client Expectations

Nostr Wallet Connect Integration:

7. Protocol Analysis

7.1 Universal Applicability

Bitcoin Deposits serves depositors across the entire economic spectrum:

High-Value Depositors:

Medium-Value Depositors:

Low-Value Depositors:

7.2 Risk Management Through Network Effects

Vault Network Distribution: The protocol naturally encourages risk management through network effects:

Operator Selection Criteria:

Network Health Indicators:

Dynamic Rebalancing:

Systemic Resilience:

7.3 Economic Incentive Alignment

The protocol creates sustainable economics for all participants:

For Operators:

For Channel Partners:

For Auditors:

For Depositors:

7.4 Trust Model

The protocol operates on a progressive trust model that adapts to depositor needs:

Cryptographic guarantees:

Web of Trust guarantees:

Economic guarantees:

Social guarantees:

7.6 Why Not Existing Solutions?

Why not Cashu/Fedimint (Ecash)?

Why not Ark?

Why not Spark/Statechains?

Why not Liquid?

Why not Channel Factories?

Why not Hosted Channels?

Why not Lightning Addresses with LSPs?

Why not Simple Custody?

7.6 Deployment Strategy

Bitcoin Deposits enables organic growth through market dynamics:

Bootstrap Phase:

Growth Phase:

Maturity Phase:

7.7 Future Considerations

  1. Privacy Enhancements: Balance transparency vs. operator needs while maintaining multisig security
  2. Cross-Implementation Support: Ensure broad compatibility of MuSig2 coordination
  3. Protocol Governance: Upgrade mechanisms as ecosystem evolves
  4. Tokenization options: Guaranteed full reserve ecash. Recovery is an issue

8. Conclusion

Bitcoin Deposits provides a trust-minimized path to Lightning Network access for all depositors, regardless of their technical capability, connectivity, or wealth. The introduction of MuSig2 keys for vault payments significantly strengthens the security model by preventing operators from selectively honoring payments. The addition of multi-vault architectures with cross-auditing creates organic trust through mutual accountability, making collusion economically irrational. By acknowledging that different depositors have different needs and risk tolerances, the protocol enables a market-based approach where deposit sizes naturally match operator reputation values and architectural robustness.

The key innovation is not in preventing all possible theft but in creating transparent mechanisms for reputation building, structural accountability, and risk assessment, while cryptographically preventing the most common attack vectors and economically disincentivizing collusion. Depositors can make informed decisions about which operators to trust with what amounts, while market dynamics ensure that good operators thrive and bad operators fail.

This pragmatic approach enables:

The protocol succeeds by providing infrastructure that meets people where they are. Whether someone has $10 or $10 million, intermittent connectivity or fiber internet, technical expertise or none at all—Bitcoin Deposits provides an appropriate solution that maintains the core principle of cryptographic verifiability while acknowledging the realities of human trust networks.

The combination of MuSig2 addressing and organic multi-vault architectures transforms Bitcoin Deposits from a purely reputation-based system to one with strong cryptographic guarantees and structural incentives for honest behavior. This makes the protocol suitable for peoples across the entire economic spectrum, from small-amount testers to large-scale adopters.

Bitcoin Deposits is evolution, not revolution. It builds on Lightning’s success while addressing its adoption barriers. By creating space for operators at all reputation levels to serve peoples with all risk tolerances, by providing cryptographic protection against the most common attack vectors, and by fostering organic trust through cross-vault accountability, we enable the Lightning Network to truly become the payment layer for the world.

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