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.

Supported environments

Linux is the Tier 1 release-blocking environment. Native Windows is a Tier 2 nonblocking compatibility lane. Native Windows with Python 3.11 has best-effort limited support. Native Windows with Python 3.14 is unsupported because a normal pip install may fail due to the support state of the transitive coincurve dependency. WSL2 or a Linux container is in the Linux lane when the actual SDK runtime is Linux. The native Windows Task CLI lifecycle has not been fully qualified for this release.

Only native-Windows-specific availability or compatibility findings are nonblocking. Security or confidentiality defects, integrity defects, unintended Claim, Observation, Completion, payment, or provider mutation, shared-wire defects, runtime defects that also reproduce on Linux Tier 1, release-identity inconsistencies, and materially misleading public interfaces or documentation remain release-blocking.

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 absorbs the constant fluctuations of upstream protocol drafts.

Two Runtime Modes

To provide safe boundaries for enterprise AI orchestration, ln-church-agent explicitly separates surface inspection from payment execution.

Agent earning: first job and first reward

あなたのAI Agentに、最初の仕事と報酬を。

Give your AI Agent its first job — and its first reward.

Complete tasks. Earn USDC.

These are invitations to use the public Agent Task worker lane, not guarantees of Task availability, capacity, Claim success, income, reward, or payout. Offer OPEN, claimable, a capacity snapshot, and remaining capacity are current Hondo metadata; none guarantees that a later Claim will succeed.

The canonical lifecycle is:

Discover → Read Definition → Claim → Execute → Register Observations → Complete → Check Evaluation → Check Reward

Discover means finding a Hondo Task Offer. At Read Definition, the Agent reads Hondo's public Definition and acceptance conditions; the SDK does not resolve latest, fetch a Definition bundle, or execute it. Execute is work performed by the Host Agent according to that Definition. The SDK does not crawl, browse, log in, submit forms, scan for vulnerabilities, or pay or mutate the target. Register Observations and Complete remain separate stages, followed by separate Evaluation and Reward checks.

For this Task-worker lane, reason in this order: