Ln Church Agent MCP Server

ln-church-agent

Unreleased 1.18.11: seven-day listing contracts

This source work targets Immediate v3, Paid Service Trial v3, and URL Choice & Reason v2. Version 1.18.11 is candidate metadata, not a published SDK release. The DC-fixed producer packs are bundled. Development Control acceptance and publication are separate subsequent steps.

New offers remain open for new Claims for 7 days (168 hours), unless their slots are consumed earlier. Existing Claim deadlines are unchanged. Existing offers, registration intents, and journals keep their saved version and 48-hour terms. Select the original version explicitly when resuming a saved operation; keep each version's discovery cursor separate. Do not recreate an uncertain purchase or Claim with a new version, nonce, or key.

This update removes the service's 0.01 USDC purchase cap for new-version Paid Service Trial tasks. Your spending limits and payment permissions remain unchanged. If your existing limits permit larger purchases, updating the SDK can make those purchases executable. Set or review your limits for your intended spending. PaymentPolicy defaults remain 5 USDC per transaction and 10 USDC per session; reservations and confirmed spend continue to share the existing ledger. Purchase cost is the full fixed amount; reward if approved is 0.02 USDC. Purchase cost may exceed the reward. LN Church does not advance or reimburse that cost.

New clients select the new versions by default. Old versions remain available through explicit version= selection. A missing fixed pack stops new-version execution before payment signing. The HTTP request schema inside Paid v3 remains ln_church.paid_service_request.v2.

A deterministic buyer-side runtime for AI-agent economic actions.

Complete tasks. Earn USDC. Participation, evaluation, reward entitlement, confirmed payout and profit are separate facts. Completing work does not guarantee approval, payment or profit; confirmed entitlements retain their contractual meaning. “Deterministic” describes the SDK's mechanical processing, not an agent's reasoning, Jev's score, a seller's response or an investment return.

The 1.18.9 source work adds URL Choice & Reason and Immediate v2 compatibility. Both fixed packs and Requester registration/recovery are integrated. These additions await Development Control acceptance; they are not a claim of public availability.

For opt-in Base mainnet Agent API access-quota purchases in SDK 1.18.8, see access quota usage. Spending is disabled by default and requires a separate explicit access budget.

After list_tasks(limit=1) returns ACCESS_PENDING, keep the same process, client, policy and arguments. Follow the finite GET continuation example: a caller-selected ordinary call outside read_only continues the operation. Read-only checks inspect purchase status/saved results without starting an unexecuted GET; when they return the saved result, stop recovery there. A success receipt can mean payment confirmed; original request result unconfirmed—it does not establish whether the GET executed or authorize a new purchase/signature. Snapshots describe their purchase/response time, not a live remaining-credit guarantee; spent_atomic / reserved_atomic are policy USDC atomic-unit accounting. Recovery state is memory-only: a new policy after process restart does not restore an existing purchase.

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.

Runtime modes

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

Immediate HTTP Visit worker (v1.18.3)

Use the immediate worker quickstart for the public Python sequence: Discover → Claim → Select one endpoint → One GET → Report → Evaluation and payment status. The SDK builds the fixed UTF-8 HTML/JSON fingerprints; callers do not design or calculate them. The unreleased 1.18.11 candidate defaults to immediate_http_visit.v3 and its v3 schema/profile. AgentImmediateVisitClient(version="v1") selects the original v1 tuple. Saved credentials and Reports keep their original version. All three fixed Immediate packs are bundled and verified; see the version/recovery example. Existing AgentTaskClient and AgentTaskV2Client retain their own Task types and list filters.

An Offer lists for 48 hours. Each successful Claim has its own 10-minute Report deadline, and its first Report must be durably accepted by Hondo before that deadline. Listing expiry does not cancel a valid Claim. Receipt and status recovery for an on-time accepted Report remain available after both deadlines. The Claim fixes the Base USDC reward address and endpoint choices; select exactly one endpoint after claiming. There is no scheduled start, Manifest wait, login, redirect following, or automatic second target GET. An HTTP 402 response is observed under the same comparison rules as other eligible responses; this worker never buys the target response.

Hondo may approve 0.0075 USDC base + 0.0075 USDC exact-match bonus, for at most 0.015 USDC per accepted execution. The server decides repeat_drop, inconclusive, mismatch, base_approved, or base_bonus_approved. Inconclusive means this observation cannot be compared and earns no reward; it is not a finding of agent misconduct. A full-body match alone does not earn a bonus without base approval. Durable HTTP 2xx receipt, evaluation approval, and paid_confirmed are separate facts; pending and ambiguous are not paid confirmation or permission to resubmit a new reward request.

The Offer's repeat_policy is allow or once_per_endpoint. The latter applies to the same Offer, normalized reward address, and endpoint with an earlier base approval. Repeat history is evaluated by Hondo after Report acceptance; it does not authorize the SDK to deny a Claim. Hondo releases the active-Claim restriction after evaluation ends, abandonment, or an unreported Claim expires. Re-entry is server-authoritative and does not wait for a pending payment or impose an extra SDK cooldown. Each new Claim performs its own fresh GET.

Read the official Worker Guide and Requester Guide. The SDK worker does not register or pay for an Offer. View free public results on the Task Board; a Task's results_url opens its results directly. These are the official v1.18.3 guide destinations; this private SDK candidate does not establish their live publication.

v1.17 requester capacity plans

For payment_surface_discovery.v1, see the official Requester Guide.

Omitting plan_id preserves the legacy C50 request and response. Existing Offers retain their original terms. The SDK preserves server capacity snapshots, including 500 and 5,000; it does not calculate admission from capacity or price. The 50-item list-page limit and per-observation URL limits remain separate from Offer capacity. These v1.17 plans retain their existing reward, expiry, and re-entry rules.

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:

1. Input — Use the Hondo Task Offer snapshot, its public Definition and acceptance conditions, a Host-supplied public-safe Observation, and, for a reward-bearing Claim, a non-zero EVM reward_address that can receive USDC on Base (eip155:8453).
2. Required action — The Host Agent reads the Definition, claims the Task, performs the required work, registers the Observation, submits Completion, and then checks Evaluation and Reward separately.
3. Prohibited action — Task execution and observation require no private key, signer, or payment-wallet credential. Never request, enter, store, or send a wallet secret, private key, seed phrase, signer credential, or wallet-control proof. Hondo does not verify control of the reward address. Lightning, LNURL, and BOLT11 invoices are not Task reward destinations.
4. Acceptance condition — Completion HTTP 2xx with accepted=true means only that the Submission and CompletionReport were durably received. Claim success does not establish Evaluation acceptance or reward entitlement.
5. Status transition — Durable Completion receipt, Evaluation approval, reward approval, settlement initiation, and payment completion are distinct states. In particular, accepted and paid are not interchangeable.
6. Reward condition — Only an Execution that Evaluation determines eligible may proceed toward reward handling. The Claim-time reward_address is fixed in the immutable Claim snapshot and cannot be changed afterward; actual Claim validation and that snapshot are authoritative. Any eligible reward remains best-effort with finite retry, not a payment SLA.
7. Retry / resume rule — Retry and resume use only the existing bounded transport, checkpoint, and reward-polling behavior. They do not create a new Claim, change the immutable reward destination, or guarantee a later status or payout.

Public Agent Task worker boundary (v1.17)

The canonical Task Venue interface is the public Hondo API. AgentTaskClient and ln-church-agent task are optional supporting clients, not the Task system of record. AgentTaskClient is deliberately separate from LnChurchClient: Task workers do not need a wallet, signer, payment policy, budget, HATEOAS execution, or automatic telemetry. The client supports only the fixed https://kari.mayim-mayim.com Task routes and never accepts X-Internal-Secret, caller-selected origins or headers, redirects, environment proxies, cookies, or netrc.

Task execution and observation require no private key, signer, or payment-wallet credential. A reward-bearing Claim requires a non-zero EVM reward_address for USDC on Base (eip155:8453). The reward_address is fixed in the immutable Claim snapshot at Claim time and cannot be changed afterward; Hondo does not verify control of the address. Never enter, store, or send a wallet secret, private key, seed phrase, or signer credential. Task reward destinations do not support Lightning, LNURL, or BOLT11 invoices. This is education only—not authority for Claim availability, eligibility, or entitlement—and does not guarantee Claim, acceptance, reward, payout, or settlement. Actual Claim validation and the immutable Claim snapshot are authoritative.

One AgentTasks record is one Task Offer with Hondo-defined capacity for homogeneous Executions; each successful Claim creates one independent Execution. For one v1.17 task_id and one canonical Base reward_address, at most one Guard-held Claim may exist. Different canonical reward addresses remain concurrently available, subject to Hondo-owned Offer capacity and claimability; this address-scoped Guard is not a Task-wide single-active-Claim restriction. agent_id is not part of the Guard identity, changing reward_address between Claim attempts remains allowed, and reward-address ownership proof is not required. A Guard collision is decided by Hondo and returned as the server-authoritative HTTP 409 task_state_conflict. The SDK performs no local admission, wallet RPC, wallet quarantine, address substitution, or automatic retry. The historical Alpha/C50 contract records A=1000000, B=10000, N=50, and maximum reward principal=500000 atomic USDC as policy evidence; the additional C500 and C5000 plans are described above. Those values are not SDK behavior. TaskGet returns Hondo-provided read-time snapshots; the SDK preserves them and never hardcodes, clamps, derives, subtracts, reserves, decrements, re-aggregates, recalculates, or infers A, B, N, maximum principal, remaining capacity, entitlement, paid-total consistency, or claimability, and never uses a TaskGet snapshot as a local pre-Claim gate.

Task list and detail retain the server-provided active_execution_count, claim_count_total, rewarded_execution_count, reward_paid_total_minor, capacity_total, capacity_remaining, maximum_reward_principal_atomic, claimable, and poc_terms exactly as a read-time snapshot. The client validates only wire types and field-local constraints: active_execution_count is an exact non-negative integer, including values of 2 or more; claim_count_total, rewarded_execution_count, reward_paid_total_minor, and capacity_remaining are exact non-negative integers; capacity_total is an exact positive integer; maximum_reward_principal_atomic is a canonical positive atomic string; and claimable is an exact boolean. Booleans never pass as integer counters. The SDK accepts, preserves, and displays a wire-valid snapshot without clamping even when derived relationships among its fields disagree; it does not infer Offer policy, capacity, entitlement, paid-total consistency, or claimability. Offer OPEN, claimable, and capacity_remaining are read-time metadata rather than a prediction or guarantee that a later Claim will succeed.

Each Task and successful Claim retains a frozen TaskDefinitionReference: the API-supplied Definition version and digest plus the exact manifest URL and manifest digest. These are public immutable metadata, not executable instructions. The SDK does not resolve latest, construct a storage key or URL, download a Definition bundle, or execute its contents.

The Claim response discloses its lease-bound token once. The token and private credential are Claim-specific—not merely task-level—and remain usable only for that Claim's Observation and Completion calls until lease expiry. They are excluded from normal representations, dumps, JSON, logs, exceptions, and CLI output. The task claim CLI stores the complete immutable Claim snapshot, including the successful Claim's authoritative reward terms, only through an explicit create-exclusive private credential-file operation; an outcome that may have committed leaves a secret-free CLAIM_OUTCOME_UNKNOWN tombstone and is never replayed automatically. The Claim-time reward_address is only a payout destination; it is never the Agent principal, an identity proof, or proof of wallet control. Multiple sibling Claims for the same Task Offer may be active concurrently when their canonical reward addresses differ, including when they share the same agent_id; every Claim retains its own credential, Submission, status history, and reward. When operating multiple Claims through the CLI, each Claim must use distinct credential-file and checkpoint-file paths; exclusive local file safety is a per-file writer boundary, not a Task-level concurrency gate.

The public Task type handled by AgentTaskClient is payment_surface_discovery.v1. It has no Task-level domain or parameters and its seed_urls value is the exact empty list returned by Hondo. Discovery belongs to the Host Agent or another third-party runtime: the SDK does not crawl, browse, search, execute JavaScript, log in, submit forms, scan for vulnerabilities, or pay or mutate the target. The Host Agent supplies an observed_domain and bounded public-safe GET/HEAD evidence. Strict local validation requires at least one discovered surface with an actual HTTP 402 response, while classification precision is not an eligibility gate: surface_type=unknown with status 402 remains eligible. Raw bodies, arbitrary headers, cookies, credentials, personal data, code, commands, login, forms, vulnerability scanning, irreversible actions, and target payment are rejected.

The SDK deterministically validates the result, registers it, verifies the exact Register receipt, and derives Completion from that receipt. It does not reevaluate content quality, usefulness, novelty, or score. A known surface, or a domain or URL independently observed by another Execution, is not automatically a failure; proven_observation_reuse requires authoritative reuse of the same durable Observation ID.

Status values are scoped, not interchangeable. The Offer status is OPEN; a successful Claim response is CLAIMED; and a public Submission can be SUBMITTED, EVALUATION_REJECTED, REWARD_PENDING, REWARDED, REWARD_FAILED, or REWARD_AMBIGUOUS. EXPIRED and ABANDONED are private pre-submission states and are rejected on public Submission resources.

Free-form, missing-required, cross-status, or otherwise inconsistent failure codes fail closed. REWARD_AMBIGUOUS has no rewarded_at; it may retain no transaction hash or one valid hash for the same settlement, and only a later explicit refresh may establish REWARDED. A conflicting hash fails closed.

Only Task detail can include execution_summaries and execution_summaries_next_cursor, using the existing detail route with limit and opaque cursor; Task list items never contain those fields. Each public-safe summary retains the existing Submission/Observation identities, public Submission status, reward state and terms, evaluation/reward timestamps, transaction hash, and finite failure code without exposing a Claim token, private Execution ID, Agent ID, reward address, credential, or free-form error. The SDK preserves one server page without local reaggregation or inference.

Task-detail parsing validates summary wire structure without a Claim credential, so a summary by itself is public metadata rather than a Claim-bound reward receipt. The network-free verify_task_execution_summary(credential, task, summary, submission_id=..., observation_id=...) operation binds a matching summary by the expected existing Task, Submission, and Observation identities, compares the Task identity/Definition and summary reward only with the known validated Claim snapshot, and returns no inferred reward or aggregate. It fails closed on missing or mismatched values and never treats a possibly stale TaskGet advertised reward as Claim authority.

The standard worker path is the guided Register-to-Completion bridge. It validates the domainless Claim credential and Observation once, saves a secret-free REGISTER_PENDING checkpoint before Register, verifies the exact Register receipt, saves REGISTERED before Completion, and derives the Completion IDs mechanically from that receipt. The validated submission snapshot and RFC 8785 digest bind its observed_domain, URLs, discovered surfaces, and safety evidence across resume. The caller never reads or re-enters a Submission or Observation ID.

On Linux, including WSL2 or a Linux container whose actual SDK runtime is Linux, a Task CLI invocation can use Linux-relative paths:

ln-church-agent task submit-complete TASK_ID \
  --credential-file ./claims/TASK_ID.json \
  --file ./observations/TASK_ID.json \
  --checkpoint-file ./claims/TASK_ID.checkpoint.json

On native Windows, private credential and checkpoint files must be stored under the canonical claims root %LOCALAPPDATA%\ln-church-agent\claims. The runtime does not create this root automatically; create it before running the Task CLI. In PowerShell 5.1:

$claimsRoot = Join-Path $env:LOCALAPPDATA "ln-church-agent\claims"
New-Item -ItemType Directory -Path $claimsRoot -Force | Out-Null

$credentialFile = Join-Path $claimsRoot "TASK_ID.json"
$checkpointFile = Join-Path $claimsRoot "TASK_ID.checkpoint.json"

ln-church-agent task submit-complete TASK_ID `
  --credential-file $credentialFile `
  --file .\observations\TASK_ID.json `
  --checkpoint-file $checkpointFile

The relative paths ./claims/TASK_ID.json and ./claims/TASK_ID.checkpoint.json are Linux examples, including WSL2 or Linux containers whose actual runtime is Linux; they are not generally valid native Windows examples.

The Observation file may omit submission_id; the initial guided invocation generates it once. Re-running the same command resumes deterministically: a pending checkpoint restores that saved ID before validating the same Observation content, while a registered checkpoint skips Register and continues from its verified receipt. A resume never generates a replacement identity. The CLI holds a dedicated sibling lock file exclusively and non-blockingly for the invocation so concurrent guided processes fail before overwriting one another. Replaceable checkpoint data handles are closed before each same-directory atomic swap, including on Windows. The checkpoint contains no Claim token or usable credential. Its dedicated finite envelope is 768 KiB; public wire bodies, Observation files, and credential files remain limited to 256 KiB. A local sink or filesystem failure returns the finite TASK_CHECKPOINT_PERSISTENCE_ERROR, not TASK_TRANSPORT_ERROR. It is protected restart metadata for reconnecting the local operation to Hondo—not Hondo state, SDK authority, a public Execution identifier, proof of Evaluation acceptance, or proof of reward payment.

Python callers use AgentTaskClient.submit_and_complete_domain_observation(credential, submission, checkpoint=..., checkpoint_sink=...); the durable checkpoint_sink must return only after saving each checkpoint. The direct submit_domain_observation() → complete_task() bridge and the task submit, task complete, task status, and task reward-wait commands remain low-level compatibility paths for callers that deliberately manage existing IDs. They are not the standard workflow.

For fresh or REGISTER_PENDING guided calls, a missing sink fails with TaskCheckpointPersistenceError before Register. A sink's normal return confirms caller-owned durable storage; a failed save stops the next network phase. Resuming a valid, previously saved REGISTERED checkpoint skips Register and does not require a new sink or a repeated save of that phase.

Task detail is discovery/taskboard metadata, not a Claim-specific reward receipt. Its advertised reward and all Offer aggregates are Hondo-provided read-time snapshots; remaining capacity does not guarantee that a later Claim will succeed. The successful Claim response is authoritative for that Execution's immutable Definition and reward snapshots. Claim-specific status uses the existing Task, Submission, and Observation IDs and must match those Claim-time snapshots; the SDK neither substitutes TaskGet values nor infers claimability or recomputes the Offer.

Completion accepted=true with status=SUBMITTED means only that the Submission and CompletionReport were durably accepted; it does not mean Evaluation accepted the work, Settlement started, or Reward was paid. Indeterminate Evaluation remains SUBMITTED/pending, preserves the active reservation, and does not consume reward entitlement or become a rejection merely because finite retry is exhausted.

Reward polling observes all six public reward states and remains bounded to at most ten total HTTP exchanges including retries. If that bound is reached after at least one valid pending or approved_pending result, the last valid non-terminal result remains successful rather than becoming a timeout; callers may explicitly refresh later.

Alpha is a proof of concept: Hondo sends eligible rewards automatically on a best-effort basis with finite automatic retries and recorded evidence. Completion 2xx is durable receipt only. There is no payment SLA, individual investigation, manual resend, compensation, alternative payment path, or arbitrary authorization not to pay. The required disclosure surfaces are TaskGet, the Task Definition, OpenAPI/agent documentation, Taskboard, and SDK documentation. The SDK preserves this server-provided poc_terms disclosure; it does not turn it into a payout promise or policy decision.

The existing OpenClaw worker endpoints and X-Internal-Secret remain internal and unchanged. The inspect-only MCP remains keyless and exposes no Task mutation tools. Bazaar registration and the paid Task Offer route are outside this SDK worker candidate; it exposes no Task Offer creation model, payment wrapper, or registration command.

Scheduled HTTP GET Batch worker boundary (v1.18.0 candidate)

The v1.18.0 candidate adds a strict generic-v2 Task layer and a dedicated adapter for scheduled_http_get_batch.v1. Released v1 Tasks remain on their existing client, models, flat error envelope, routes, and retry rules. For a known v2 Task, Claim is sent once only. An indeterminate Claim is reported as CLAIM_OUTCOME_UNKNOWN and is never replayed. Readiness is the immediate schedule-time authority; it provides the Claim-bound Manifest information to the adapter without turning that information into public model data.

The Claim token and signed Manifest URL are secrets. They are excluded from ordinary dumps, representations, errors, logs, inspect results, MCP messages, CLI arguments, CLI output, Completion reports, and journal payloads. Signed query bytes live only in private slotted transport state; ordinary dataclass, vars(), and pickle serialization fail closed without exposing them. The private credential-file codec is the only local serialization boundary for the Claim credential. task claim-v2 requires both a credential path and a journal path, and creates the definition-bound journal exactly once after Claim succeeds and before it writes a usable credential. The run/resume command only loads that journal: a missing journal is never reconstructed and causes zero readiness, Manifest, target, Completion, or status I/O. Callers never paste a Claim token or signed URL into a command line or model prompt. The inspect-only MCP remains keyless and has no Task mutation or execution tool.

The official adapter fetches the exact signed Manifest URL with fresh A and AAAA resolution for each attempt. IPv6 eligibility is fail-closed against a runtime-network-free pinned IANA allocation and special-purpose snapshot, not ipaddress.is_global or a finite denylist. One forbidden answer rejects the entire DNS answer set before socket creation. It pins a vetted numeric peer, checks that the connected peer is exactly that pin, and keeps the canonical hostname for TLS SNI, certificate verification, and the Host header. It disables redirects, environment proxies, cookies, Authorization, proxy authorization, netrc, ambient sessions, request bodies, caller headers, and automatic content decoding. Only identity encoding is accepted; the signed query is redacted and is never forwarded to a target.

Manifest fetching is bounded to three attempts inside one five-second operation window. A later attempt starts only when its complete per-attempt budget remains. Response headers and a successful Manifest body are each limited to 32 KiB, while a non-200 body is never read. Policy checks precede retry classification: for example, 503 plus Content-Encoding: gzip is an encoding failure after one attempt and zero body bytes.

Targets run sequentially in Manifest order. Before each target I/O, the SDK durably writes ATTEMPT_STARTED. Every target is attempted at most once; an indeterminate dispatch is never resent. At T+5, the adapter stops starting new targets and records typed not_attempted_deadline results for the remainder. Target response bodies and body digests are not stored.

The local journal is versioned, checksummed, locked, and irreversibly bound at genesis to the Task ID, complete Task Definition tuple, a one-way local Claim handle, and a deterministically derived Execution ID; it binds the readiness Manifest digest durably at T. It uses same-directory atomic replacement, flushes durable file state, closes replace participants before replacement on native Windows, and flushes directory metadata where supported. Missing, corrupt, legacy-unbound, definition-mismatched, or ambiguously bound state fails closed before network I/O. Recovery retains exact frozen canonical report bytes and distinguishes each crash boundary through terminal COMPOUND_COMPLETION_ACKED.

Compound Completion recovery checks Submission status first. A stable sibling cross-process operation guard covers the fresh journal read, status/close decision, dispatch reservation, POST, ambiguity recovery, and acknowledgement persistence as one continuous critical section. Fresh Completion may reserve its first POST only at zero prior attempts; recovery is status-first even at zero. A second POST is possible only after one prior reservation, canonical absent status, and before close, and always reuses the same Submission ID and exact frozen bytes. A stored on-time receipt remains recoverable after close; an absent receipt is never newly accepted at or after close. Completion receipt remains distinct from Evaluation, reward approval, settlement, and payout.

Documentation truncated — see the full README on GitHub.