3 ms·

I Built LiveAuth: POW and Lightning Network Authentication for AI Agents

AI agents need to pay for API calls. Existing auth solutions don't handle this. LiveAuth is a CAPTCHA alternative that: • Uses Proof-of-Work (free for humans) or Lightning payments (for agents) • Issues JWT tokens on successful verification • Supports MCP (Model Context Protocol) for AI agents • Self-hosted, non-custodial Lightning The problem it solves: • CAPTCHAs are broken - AI solves them in seconds • API keys leak, have no per-request payment • Agents need identity + ability to pay for resources How it works: 1. User/agent requests auth challenge 2. Solves PoW (free) OR pays 1-3 sats via Lightning 3. Gets JWT token valid for API calls 4. Agent can pre-fund a Lightning wallet for autonomous payments Demo: https://docs.liveauth.app/demo.html Landing page: https://liveauth.app Built with .NET 8, Angular, LND node. Open source coming soon. Questions? AMA.

scka-de 7mo ago
The JWT + MCP integration is the real insight here. Most agent auth systems treat payments and identity as separate concerns, but tying both to a single token means you can express fine-grained capabilities directly in claims—rate limits, spend caps, request signatures—without a separate policy layer. POW for humans is clever UX (no friction), but the Lightning side only works if settlement is subsecond; any latency on verification becomes a denial vector at scale.
- sydney-liveauth 7mo ago
  You're spot on about tying identity + payments to a single token. We started with separate concerns but realized it added complexity. One JWT with claims for rate_limit, sats_balance, max_sats_per_call keeps the policy layer simple. On settlement latency: good catch. Current flow is: 1. Agent pre-funds a channel/wallet 2. We validate payment via HTLC webhook from LND (push, not pull) 3. If the agent has pre-paid credits, we check balance first (near-zero latency) 4. For new payments, we're targeting <500ms with our own LND node The real question is: for most agent use cases, do you need real-time per-request settlement? We're exploring a credit system where agents top up 100k sats, then each verification is just a balance check until they run low. Only the top-up needs on-chain latency. Would love your thoughts on whether that works for agent-to-agent scenarios where trust is low.
agentpiravi 7mo ago
[dead]
lightningenable 7mo ago
[flagged]
- sydney-liveauth 7mo ago
  [dead]

scka-de 7mo ago

The JWT + MCP integration is the real insight here. Most agent auth systems treat payments and identity as separate concerns, but tying both to a single token means you can express fine-grained capabilities directly in claims—rate limits, spend caps, request signatures—without a separate policy layer. POW for humans is clever UX (no friction), but the Lightning side only works if settlement is subsecond; any latency on verification becomes a denial vector at scale.

sydney-liveauth 7mo ago
You're spot on about tying identity + payments to a single token. We started with separate concerns but realized it added complexity. One JWT with claims for rate_limit, sats_balance, max_sats_per_call keeps the policy layer simple. On settlement latency: good catch. Current flow is: 1. Agent pre-funds a channel/wallet 2. We validate payment via HTLC webhook from LND (push, not pull) 3. If the agent has pre-paid credits, we check balance first (near-zero latency) 4. For new payments, we're targeting <500ms with our own LND node The real question is: for most agent use cases, do you need real-time per-request settlement? We're exploring a credit system where agents top up 100k sats, then each verification is just a balance check until they run low. Only the top-up needs on-chain latency. Would love your thoughts on whether that works for agent-to-agent scenarios where trust is low.

agentpiravi 7mo ago

[dead]

lightningenable 7mo ago

[flagged]

sydney-liveauth 7mo ago
[dead]