Plannt. A Bitcoin-native access control layer for AI agents.

AI agents are the first credentialed principals on the internet that nobody trained the credential layer for. This paper argues that the right primitive for autonomous machines to authenticate and pay for HTTP services is L402 over Bitcoin Lightning, and that this is a deliberate single-rail choice with consequences worth defending.

00Abstract.

Every HTTP credential in production today assumes a human operator who provisioned it, a human who can rotate it, and a human who notices when the bill arrives. None of those assumptions hold once an autonomous agent is the principal. We propose, and Plannt implements, an alternative: a payment-native HTTP authentication scheme where the credential and the payment are the same cryptographic object. Each request generates a fresh Bitcoin Lightning invoice. The payment preimage becomes a single-use bearer credential. Verification is pure HMAC against a server-held root key. The result is a stateless, sessionless, capped-spend access control layer designed for machines from first principles.

01The threat model API keys were never designed for.

An API key is a long-lived symmetric secret. A person registers for an account, generates the credential, copies it into a config file, and rotates it on whatever cadence policy demands. Every part of that ritual depends on a human in the loop. A human scopes it. A human stores it. A human revokes it when something goes wrong. The credential carries no native payment semantics. Billing is bolted on out-of-band, settled against an invoice the credential itself can neither generate nor agree to.

Autonomous agents do not fit this shape. An agent that needs to call an inference API at 03:00 cannot wait for a person to approve the request, scope a token, or authorize a top-up. The agent must acquire access at runtime, on its own, with no standing relationship to the service and no shared infrastructure beyond the open internet.

The failure modes that follow are not hypothetical. They are the bulk of the incident reports filed against API platforms today:

• Static credentials leak. The same string that authenticates ends up in a Slack thread, a public repository, a baked Docker image. There is no cryptographic asymmetry. Once it is out, every downstream system trusts it equally.
• Static credentials have no spending cap. A leaked key can run a training loop for the entire billing cycle. Limits are dashboards, not invariants. Damage is uncapped until a human notices.
• Static credentials carry no payment metadata. The protocol cannot say what a request costs. The agent cannot consent to a price before the work is done. Settlement happens after the fact, against a bill the agent never saw and never agreed to. Machines should not need an accountant.

02The L402 specification.

L402 (originally LSAT, formalised as Lightning Labs' bLIP-26 proposal) is a payment-native HTTP authentication scheme. The protocol assumes nothing about the identity of the agent and everything about the cost of the work. The five-step lifecycle is short enough to fit in your head.

2.1Challenge.

The agent issues a normal HTTP request to a protected endpoint with no authentication header. The server generates a BOLT11 Lightning invoice via its Lightning node, mints a macaroon scoped to the invoice's payment hash, and responds with HTTP 402 Payment Required. Both artifacts return in the response body. The macaroon is a base64-encoded bearer token. The invoice is a standard BOLT11 string suitable for any Lightning wallet.

2.2Settlement.

The agent's Lightning wallet pays the invoice. On a healthy mainnet path, settlement is final in under a second. The wallet returns a 32-byte payment preimage. This is the cryptographic proof: the only way to obtain the preimage is to settle the invoice with the receiving node. Possession of the preimage is mathematically identical to possession of the payment.

2.3Verification.

The agent retries the original request with the header Authorization: L402 macaroon:preimage. The server recomputes HMAC(root_key, payment_hash) and compares the result against the macaroon's identifier. If they match, the payment is real, and the access is granted. The token is then marked spent, irreversibly.

The verification equation is the entire access decision:

    if HMAC(root_key, payment_hash) == macaroon_id
        AND token_not_yet_spent(preimage):
        access granted; mark_spent(preimage)
    else:
        401 invalid token

There is no database lookup for the access decision itself. The server holds a root key and a small in-memory record of recently spent preimages. Horizontal scaling is trivial because state is bounded by the spent-set TTL, not by the number of users.

03Why Bitcoin Lightning, specifically.

L402 is a payment-rail-agnostic protocol in its specification. In its practice, it requires three properties from whatever rail it sits on:

1. Final settlement in seconds. The retry must happen on the same TCP roundtrip horizon as the original request. If settlement takes minutes, the protocol is unusable for HTTP.
2. Per-request granularity at sub-cent cost. A 21-sat invoice must settle for a fraction of a US cent. If the fee for a single API call costs more than the call itself, the protocol is unusable for high-frequency machine traffic.
3. Permissionless transit end-to-end. No issuer, no acquirer, no chargeback layer, no compliance gate between the agent and the API. If the rail can refuse a payment, the rail is the auth, not the protocol.

Bitcoin Lightning is the only network in production today that delivers all three. Sats settle in under a second across well-routed paths. The base fee for a routed Lightning payment is typically zero plus a few millisats. The network operates without an issuer, an acquirer, a chargeback layer, or a compliance gate. The network is, in its protocol-level design, indifferent to who is paying whom.

3.1The properties Lightning shares with HTTP.

Lightning and HTTP are both stateless at the wire level, request-scoped at the application level, and identity-blind by default. The agent does not need an account to make a payment. The server does not need an account to receive one. The payment is the relationship. L402 is the protocol that makes this isomorphism visible to the application layer.

04Stateless verification, formally.

A claim worth making precisely: the L402 access decision can be made without any durable state besides the server-held root key. The argument:

Macaroon construction. When the server generates a macaroon at challenge time, the macaroon identifier is computed as HMAC(root_key, payment_hash). The payment hash is the SHA-256 of the eventual preimage. The macaroon and the invoice are bound together by this hash, but neither is bound to a user, a session, or a database row.

Verification. When the agent retries with the preimage, the server computes SHA-256(preimage) == payment_hash and then recomputes the macaroon identifier from the payment hash. If both checks pass, the agent has proven two things in one step: that the invoice was paid, and that the macaroon was legitimately issued by the server. The server does not need to remember what it issued. It needs only the root key to verify what it would have issued.

Spent-set discipline. To prevent replay, the server tracks preimages it has accepted within a short TTL window. This is the only state in the protocol, and it is local, ephemeral, and bounded. A replicated cache (Redis, an in-memory LRU, or a CRDT among server replicas) suffices. The protocol's correctness does not depend on this state being globally consistent across the entire fleet, only consistent for the request-handler that accepts the retry.

05The deliberate choice: not x402.

Other proposals exist for payment-native HTTP. The most prominent is x402, which makes the opposite bet from Plannt: payment-native HTTP, but on stablecoins, settled on an EVM-compatible chain. That is a legitimate design choice. It is not the one Plannt is making, and the difference is not cosmetic.

The operational consequences of choosing stablecoins as the rail include:

• Issuer risk. A stablecoin is a liability of an issuer. The issuer can freeze, blacklist, or recall. The credential is therefore subject to the issuer's policies. The same agent that holds the credential holds a relationship with the issuer, whether the agent or the protocol designer wanted that relationship or not.
• Settlement layer politics. EVM chains have governance, hard forks, MEV markets, and validator concentration. Any of those can interrupt settlement at exactly the moment an agent needs a request to clear.
• Gas. A per-request payment that costs more in gas than the underlying call is not viable for high-frequency traffic. Layer-2 solutions amortize this but reintroduce trust assumptions in the bridge layer.
• KYC gravity at the edges. The endpoints where stablecoins meet fiat are KYC-gated almost universally. An agent that runs only on stablecoins eventually meets a wallet that demands a passport scan.

Plannt is not multi-rail. Settlement is in sats. The unit of account and the credential share one trust assumption, because they are the same object. That property only survives on a payment network that is permissionless, programmable, and final. That network is Lightning.

This is a positioning choice. The agent-builder community is bifurcating along exactly this fault line. Plannt is the protocol-pure Bitcoin-native option for the half of that community that wants the credential and the money to share one trust surface, and that wants the trust surface to be the smallest one available.

06Properties of the resulting system.

The L402-over-Lightning design produces five emergent properties worth listing:

• Credentials are ephemeral. A token exists from the moment the invoice is paid until the moment it verifies. That window is typically under a second. There is nothing to leak that lasts long enough to be useful.
• Tokens are single-use. Verification marks the preimage spent. Replay returns 401. The replay window is zero. The idle window is zero.
• Every request is pre-paid. Spend is capped at the cost of one request. There is no billing cycle to run wild inside. There is no surprise invoice at the end of the month, because there is no end of the month.
• Verification is stateless. The server holds a root key and a bounded spent-set. Horizontal scaling is the default, not a feat. A second server instance is a copy of a binary plus the same root key.
• The protocol carries no user identity. The server never learns who paid. It learns that the payment settled. The agent is anonymous to the API operator unless it chooses to identify itself.

07Open questions and future work.

The protocol is in production at api.plannt.com and the implementation is open source. The list below is what we are actively working on or watching:

• Hosted Lightning wallet abstractions. Today, the strongest claim of the Plannt positioning is "single line of code." The reality of integration is closer to "single line of code plus a Lightning wallet that exposes the preimage." Closing that gap with a wallet abstraction that hides node management from the agent builder is the most useful next step.
• MCP server. Shipping May 2026 (see roadmap). A native Model Context Protocol server that exposes L402-gated endpoints as standard tool calls to any MCP-compatible agent runtime.
• CLI client. A single static binary that speaks L402 from the terminal. The fastest way to feel the protocol without writing an integration.
• Agent SDKs. Drop-in detection loops for Node.js and Python, so existing agent frameworks can wrap any HTTP client with L402 awareness with one import.
• Multi-endpoint capability scoping. Macaroons natively support caveats. A future version of the protocol can issue tokens that authorize a bundle of endpoints, or a quantity of inference, or a time window.
• Discoverability. The long-term goal is a permissionless network of L402-gated APIs that any agent can discover and pay for autonomously. That requires a discovery layer that is itself permissionless. We are watching the nostr-NIP space and the bLIP discussions for the right primitive.

08References and prior art.

• L402 / LSAT. Lightning Labs. The original specification proposed as bLIP-26.
• Macaroons. Birgisson, Politz, Erlingsson, Taly, Vrable, Lentczner. "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud." NDSS 2014. The original macaroon construction Plannt uses.
• BOLT11. Lightning Network Specifications. The invoice format Plannt's server emits in the 402 response body.
• HTTP 402. RFC 7231 §6.5.2. Reserved status code "Payment Required," now in active use after twenty-five years of dormancy.
• L402-on-Bitcoin discussion. bLIP-26 thread on the lightning/blips repository. Active as of writing.

This whitepaper is intended as a living document. The version above is v1.0. Issues and pull requests against the public repository are welcome at github.com/HashRails/plannt-api.