ln-church-agent

The Value of "Not a Verdict" LN Church read models do not decide for the agent. They preserve observed memory: what was seen, what was paid, what failed, what receipt shape appeared, what protocol role was observed, and what verification cost was reported. This is not a recommendation or verdict; it is a reusable observation record that helps the local runtime avoid re-verifying everything. Final payment authority remains local.

Your agent will hit a 402 paywall in the wild.

Will it inspect, decide, pay, recover, verify, and continue — or freeze?

ln-church-agent is a buyer-side HTTP 402 runtime and agent-commerce surface inspector for autonomous agents.

In the broader agentic commerce stack, ln-church-agent acts as the buyer-side component of an observability and trust-evidence layer for HTTP 402-compatible paid actions.

It helps agents inspect paid-action surfaces, distinguish executable payment rails from higher-order commerce protocols, and prove paid execution across L402, x402, and supported MPP charge shapes when a concrete HTTP 402-compatible challenge, supported credential path, and verifiable receipt path are present

In v1.9.0+, the inspect layer explicitly classifies emerging agent-commerce surfaces such as OKX Agent Payments Protocol (APP), Google AP2, and ACP without executing payment logic. These protocols are treated as observable commerce / authorization patterns unless they expose a concrete HTTP 402-compatible settlement path.

Core Doctrine

Do not spend even one LLM token on what the agent should not need to reason about.

ln-church-agent moves payment plumbing out of the model's reasoning loop and into a deterministic buyer-side runtime.

The SDK handles mechanical HTTP 402 concerns such as:

• payment-rail inspection,
• challenge parsing,
• policy checks,
• payment execution,
• HATEOAS recovery,
• receipt verification,
• evidence capture.

The LLM remains responsible for the higher-level economic decisions:

• whether the counterparty should be trusted,
• whether payment is justified,
• whether the expected outcome was delivered,
• and whether the endpoint should be reused.

Don't Trust, Verify. But Don't Re-Verify Everything.

The SDK is designed for verification reuse: agents can inspect and verify live payment flows when necessary, but they should reuse observed memory, receipts, and read models when repeated full verification would waste context, liquidity, or reasoning budget.

What it does

Most payment SDKs help agents pay.
ln-church-agent helps agents complete the whole paid-action loop:

Probe → Inspect → Decide → Pay → Execute → Verify → Trace

It is designed for agents that must:

• Inspect HTTP 402 challenges before committing funds.
• Choose between L402, x402, MPP, or safe-stop paths based on local policy.
• Execute paid actions through policy-aware runtime controls (budgets, trust).
• Recover through HATEOAS-style next actions if a flow is interrupted.
• Verify receipts and semantic outcomes after payment.
• Report trace evidence to a public sandbox or local observer.
• Record goal-conditioned attempts and their outcomes for future optimization.

🧠 What this runtime is

• Generic Buyer-Side Runtime: A pure client-side execution engine that keeps your AI agent's reasoning loop clean by abstracting away the HTTP 402 negotiation layer.
• Agent Commerce Surface Inspector: Classifies emerging commerce and authorization layers such as OKX APP, AP2, ACP, and UCP separately from executable settlement rails.
• Open-Web 402 Interoperability: Natively supports Base64URL JSON headers, CAIP-2 network routing, and multi-chain execution out of the box.
• Reference Sandbox Support: Optionally integrates with the LN Church observation network for public benchmarking, trace reporting, and discovery workflows.
• Stable Interface: An unchanging developer API surface that safely

... View full README on GitHub