Skip to main content

Economic Patterns

Per-request economics require infrastructure that legacy rails cannot provide.

The Granularity Problem​

Traditional payment rails have minimum viable transaction sizes:

RailMinimum PracticalLatency
Credit Card$0.50-1.002-3 seconds
ACH$1.00+1-3 days
Wire$25.00+Hours
PayPal$0.35+Seconds

Lightning Network:

RailMinimum PracticalLatency
Lightning$0.001Milliseconds

This is not an incremental improvement. It is a categorical difference.

Request-Level Economics​

When settlement cost approaches zero and latency approaches zero, new patterns become viable:

Pay-per-Request APIs​

Instead of monthly subscriptions with usage limits:

POST /api/analyze
Settlement: 21 sats ($0.02)
Response: { analysis: "..." }

No accounts. No overages. No reconciliation.

Agent Budgets​

Autonomous agents can operate with bounded budgets:

Agent Budget: 10,000 sats
Each action: 10-100 sats
Total actions: 100-1000

The budget is a hard constraint, not an estimate.

Metered Compute​

Compute resources can be priced at actual usage:

CPU-second: 1 sat
GPU-second: 10 sats
Storage-MB-month: 0.1 sats

No minimum commitments. No reserved capacity.

Why This Matters for Software​

Software operates at scales incompatible with human-oriented payment rails:

  • An API might serve 1M requests/day
  • An agent might take 10,000 actions/task
  • A mesh network might have 100,000 nodes

These cannot each have accounts, invoices, and reconciliation processes. They need settlement as a primitive.

The Settlement Layer​

Lightning Enable provides this settlement layer. Not payment processing. Not financial services. Just the infrastructure that makes request-level economics possible.

Further Reading​