Fees & Economics 費用與經濟

Lightning Network Routing Fee Formula:

Total fee = base_fee + (amount * fee_rate)

Parameters:

base_fee:
  - Fixed fee charged per forward
  - Unit: millisatoshi (msat)
  - Typical: 0 - 1000 msat (0 - 1 sat)
  - Charged regardless of amount

fee_rate:
  - Proportional to forwarded amount
  - Unit: ppm (parts per million)
  - Typical: 1 - 5000 ppm (0.0001% - 0.5%)
  - 1 ppm = 1 sat per 1,000,000 sats forwarded

Calculation Example:
  base_fee = 1000 msat (1 sat)
  fee_rate = 100 ppm
  payment amount = 100,000 sats

  fee = 1000 + (100,000 * 100 / 1,000,000) msat
      = 1000 + 10,000 msat
      = 11,000 msat = 11 sats

Multi-hop Payment:
  A -> B -> C -> D
  Fee = fee(A->B) + fee(B->C) + fee(C->D)

Fee-related fields in channel_update message:

{
  "channel_flags": 0,
  "message_flags": 1,
  "cltv_expiry_delta": 40,
  "htlc_minimum_msat": 1000,
  "htlc_maximum_msat": 990000000,
  "fee_base_msat": 1000,
  "fee_proportional_millionths": 100
}

Important Parameters:

cltv_expiry_delta:
  - Timelock blocks added per hop
  - Affects payment's total timelock
  - Longer values safer but may be rejected

htlc_minimum_msat / htlc_maximum_msat:
  - Limits forwardable HTLC size
  - Protects channel from dust attacks
  - Controls liquidity usage

Liquidity-Based Fee Strategy:

Channel State:
  You <--[0.3 BTC]--+--[0.7 BTC]--> Counterparty

  Local balance: 0.3 BTC (30%)
  Remote balance: 0.7 BTC (70%)

Fee Adjustment Logic:

Outbound direction (You -> Counterparty):
  - Local balance low (30%)
  - Outbound capacity scarce
  - Set high fee to protect liquidity
  - Example: base=1000, rate=500ppm

Inbound direction (Counterparty -> You):
  - Remote balance high (70%)
  - Inbound capacity abundant
  - Set low fee to attract traffic
  - Example: base=0, rate=10ppm

Automated Fee Management Tools:
  - charge-lnd (LND)
  - clboss (CLN)
  - Various automation scripts

Dynamic Fee Formula Example:
fee_rate = base_rate * (1 + sensitivity * (0.5 - local_ratio))

  local_ratio = 0.3 -> fee rate increases
  local_ratio = 0.7 -> fee rate decreases
  local_ratio = 0.5 -> use base rate

Routing Node Profitability Analysis:

Revenue Source - Routing Fee Income:

  Assumptions:
    - Daily routing volume: 10 BTC
    - Average fee rate: 50 ppm
    - Average base fee: 1 sat
    - Daily payments: 1000

  Daily income = 10 * 1,000,000 * 50/1,000,000 + 1000
               = 500 + 1000 = 1500 sats/day
               = ~45,000 sats/month

Cost Structure:

  1. Channel Opening Cost
     - On-chain TX fee (~2000-10000 sats per channel)
     - Need multiple channels for effective routing

  2. Channel Closing Cost
     - On-chain fee for cooperative or force close

  3. Rebalancing Cost
     - Routing fees for circular payments
     - Submarine Swap fees

  4. Capital Opportunity Cost
     - Locked BTC cannot be used elsewhere
     - ~1-5% annualized (depending on risk preference)

  5. Operating Cost
     - Server/hardware
     - Time and effort

Profitability Condition:
  Routing income > Rebalancing + Capital + Operating costs

Most small routing nodes are actually operating at a loss!

Information Revealed by Fees:

Routing nodes can learn from fees:

  1. Payment Amount
     - Can be inferred from proportional fee

  2. Payment Direction
     - Knows fund flow direction

  3. Timing Patterns
     - When payments occur

Privacy Protection Measures:

  1. Onion Routing
     - Node doesn't know full path

  2. PTLCs (future)
     - Eliminates cross-hop correlation

  3. Add Random Fees
     - Obscures real amount (user-side)

  4. Route Blinding
     - Hides receiver location