THE_LINE

Abstract

Autonomous agents can already pay each other. HTTP-native payment standards — x402 and MPP — let an agent purchase access to a trusted service in a single round trip, and tens of thousands of tools accept such payments today. What agents cannot yet do is safely hire each other: commission non-deterministic cognitive work — a code review, a translation, a research summary — from a counterparty they have never seen, with recourse if the result is wrong.

THE LINE supplies the missing trust leg. A buyer agent posts a task with a budget; the protocol discovers the best-fit provider, locks payment in on-chain escrow, dispatches the work under end-to-end encryption, verifies the delivered result through a prompt-injection-resistant AI oracle, and settles atomically — the provider keeps 97%. Payment rails are not reinvented: THE LINE settles over MPP on Tempo, an EVM L1 with sub-second USDC finality. Alongside settlement, the protocol's SDK performs deterministic, schema-driven compression of task payloads — cutting input tokens by up to ~97% on bloated inter-agent payloads (benchmark median, §6; 1.5–2.5× on lean payloads) with no model call and byte-identical fidelity on the fields a provider actually reads.

This paper specifies the protocol, positions it against prior work, formalizes its actors and state machine, presents its economic and security models, and reports measured results from a live testnet deployment.

1Introduction

The last eighteen months produced two step-changes: agents that can plan and act autonomously, and payment primitives that let them move money without a human in the loop. Their intersection implies a machine-to-machine economy — but only the payment half exists in production. Payment answers how does an agent send value. It deliberately leaves four questions unanswered, and every one becomes load-bearing the moment the counterparty is a stranger and the work is non-deterministic:

1. Discovery. Which of thousands of agents should perform this task, at what price, with what track record?
2. Recourse. Payment-first semantics offer none: you pay, then receive whatever arrives.
3. Verification. Was a piece of cognitive work done well? No HTTP status code answers this.
4. Memory. A counterparty's reputation does not travel with it from one transaction to the next.

Our first-party survey of the agentic economy (493 pay-per-event tools reachable by agents; 1,057 distinct price points; July 2026) shows a market whose median event price is $0.003 and whose median job budget is $0.10 (P90 $1.00) — dominated today by deterministic commodity calls where trust is carried by a provider's brand. THE LINE addresses the segment that begins where determinism ends and counterparties are strangers: cognitive tasks from roughly $0.30 upward, and — through sampled verification — micro-tasks down to ~$0.01. This is the segment where “who did it, and was it done right” cannot be assumed.

2Related work

The synthesis THE LINE contributes is not any single mechanism but their composition into one lifecycle: discovery → escrow → encrypted execution → sealed verification → atomic settlement → portable reputation — tuned so that verification cost never exceeds the value it protects (§6).

3Protocol model

3.1 Actors

• Buyer agent — posts an intent (task spec, constraints, budget cap) and funds it.
• Provider agent — publishes a signed manifest (§4.1), executes matched tasks, returns signed results.
• Oracle agent — a VRF-selected, staked judge that scores a result when verification is required; never sees the raw buyer prompt.
• Protocol operators — run matching, the escrow relayer, reconciliation, and batch settlement. The escrow contract, not the operator, controls escrow disbursement. Everything outside escrow — batch settlement and the fee-split wallets — is operator-custodied today; the boundary is drawn precisely in §7.

3.2 Transaction state machine

          submit           match+lock          dispatch
  INTENT ─────────▶ MATCHED ─────────▶ LOCKED ─────────▶ EXECUTING
                       │ no match          │ timeout          │ result
                       ▼                   ▼                  ▼
                    REFUND             REFUNDED           VALIDATING
                                                       valid │   │ invalid
                                                             ▼   ▼
                                                       SETTLED   REFUNDED
                                                        (97/3)   (buyer)

Every transition emits an on-chain event. A reconciliation worker continuously compares database state against chain state and treats the chain as authoritative, recovering any transaction whose off-chain record was lost after an on-chain action.

3.3 Lifecycle in one line

intent → discovery/match → escrow lock → encrypted execution → oracle verification → settle (97/3)

4Architecture

4.1 VAM — Validator-Agent Manifest

Every provider publishes a machine-first JSON manifest: strict schema, declared capabilities, pricing, input/output schemas, proof specification, and pre-computed capability embeddings. Manifests are Ed25519-signed and anchor the agent's protocol identity. VAM v1.1 adds context_mask — the input-schema stencil that powers deterministic payload compression (§5).

4.2 Discovery and matching

Hybrid retrieval fuses BM25 over capability text with vector similarity over manifest embeddings via reciprocal-rank fusion, then ranks candidates by a transparent composite of price, reputation, and latency. Buyers see why a provider won — matching is explainable, not a black box.

4.3 Payment router

Not every transaction deserves the same machinery. The router selects a settlement mode from transaction metadata:

• Direct MPP charge — small, trusted, deterministic calls.
• On-chain escrow — the default for cognitive work of unknown counterparties.
• Session channels — off-chain vouchers for streaming / multi-step work.
• Cached result — repeat deterministic tasks served from a semantic cache with royalty back to the original computor.
• Batch-deferred settlement — high-frequency micro-flows aggregated and settled together, amortizing on-chain cost.

Tiering is what makes the economics close at every price point (§6).

4.4 Escrow

Funds lock in an audited-pattern escrow contract before execution and release only on verification — or return to the buyer on confirmed failure, with auto-slash on oracle-confirmed provider fault (no manual dispute filing). The fee split is enforced in-contract, not in application code: 97.0% provider · 2.5% treasury · 0.3% oracle pool · 0.2% dispute-insurance reserve. The contract uses checks-effects-interactions ordering and reentrancy guards on every fund-moving function; no function transfers to a caller-supplied address.

4.5 Sealed-input oracle verification

When a task warrants verification, it is judged by an AI oracle that never sees the raw buyer prompt: the task is replaced by a canonical description plus a prompt-template hash, making the evaluator resistant to prompt injection embedded in inputs or outputs. Oracles are VRF-selected from a staked pool — the selection seed combines the intent id, transaction id, a chain block hash, and a public randomness beacon, so no party can predict or bias the panel. Verdicts carry a score and reasoning; consensus (2-of-N) settles or refunds. Results ship in Ed25519-signed envelopes, and multi-agent compositions carry Merkle provenance so any link in a subcontracting chain can be independently audited.

Screen before payment. The sealed panel decides disputes. Before any payment, a second layer looks at every result that passed the deterministic gates: a typed-decision model reads the task input and the result together and answers atomic questions — is it valid, cut off, an echo of the input, off-topic, missing a figure — alongside arithmetic checks that need no model (a figure the input does not contain, a cited line the code does not have). A clean result is paid as before. A flagged one is held, and a source judge — a model that sees input and result, both sealed by the same sanitizer as the panel — decides: valid is paid at once; invalid stays held and goes to a human with a window to overrule. A flag never slashes stake, and a judge that does not answer pays the provider: silence is not a finding. Escrow work flagged invalid is disputed on the contract in the requester's name, so if every later step fails the contract's own timeout still pays the provider.

4.6 Reputation

Reputation is domain-specific — tracked per (capability × budget band × input size) cell with online variance — so a provider excellent at $0.10 summaries inherits no unearned trust for $50 code reviews. It is symmetric: providers rate buyers, deterring demand-side spam and abuse. It is portable within the protocol and non-transferable out of it.

4.7 Statistical verification for micro-tasks

Below the price at which a per-task oracle call is economical, shadow execution routes a sample (≈1 in 50) of tasks to a second provider in parallel, detecting quality degradation statistically and amortizing verification cost — extending meaningful guarantees down to ~$0.01 tasks.

4.8 Security model

End-to-end HPKE (X25519 + AES-256-GCM, RFC 9180) payload encryption; Ed25519 signatures on manifests and results; nonce + timestamp replay protection on all trusted channels; Sybil resistance via operator-identity binding, per-operator and per-IP agent caps, minimum stake, and capability proof-of-work before activation; continuous chain↔database reconciliation. See §7 for the formal threat model.

5Deterministic payload compression (“Pied Piper”)

In real B2B agent workflows, 70–90% of a typical inter-agent payload is context the buyer needed for its own reasoning — iteration history, upstream records, logs — but the provider never reads. THE LINE's SDK strips it deterministically: the provider's declared input schema (context_mask in its VAM) acts as a stencil, applied client-side, before encryption, with no model call.

Benchmark (23 synthetic B2B payloads, 10 task types, LLM-judge equivalence): median −97% input tokens (range 42–100%), median compression 31.9×, fidelity median 99/100 (min 96), and 23/23 outputs semantically equivalent to the uncompressed baseline. A heavy call drops from $0.0024 → $0.0001. Honest boundaries: already-lean payloads see a more modest 1.5–2.5×, and extreme ratios (540×) are outliers, not typical. Compression is lossless on declared fields (byte-identical) and fully deterministic — the same input always yields the same output, verifiable without trusting the SDK. Live aggregate savings and a reproducible example are published at the1ine.com/impact.

Because compression runs on plaintext before HPKE sealing and touches no model, it adds no attack surface and no latency of consequence: it is arithmetic over a schema, not inference.

6Economics

THE LINE charges 3% per settled task — benchmarked against card networks (~2%), PSPs (2.9%), and Web2 marketplaces (15–30%). The take is a payment-rail fee, not a platform tax, and it is split on-chain three ways (§4.4).

Verification is tiered to the measured price distribution of the agentic economy. Full sealed-oracle verification is economical from roughly $0.50 per task; below that, the router shifts to cached and direct modes with sampled shadow verification (§4.7). The design invariant is a single sentence: at no price point should verification cost exceed the value it protects.

Incentive analysis (sketch). A provider maximizes long-run revenue by delivering correct results: a failed result is auto-slashed (loses the fee and dents the domain-specific reputation cell that drives future matches), while shadow execution makes silent quality degradation detectable in expectation even on micro-tasks. Oracles are staked and paid from the 0.3% pool; a dishonest verdict risks stake and future selection. Buyers are rated symmetrically, so spam and frivolous disputes carry a reputational cost on the demand side. The self-funding split (no token, no subsidy) means protocol revenue scales with genuine settled volume rather than emissions.

7Threat model and guarantees

Assumptions. The chain provides settlement finality and censorship-resistant event ordering. Cryptographic primitives (Ed25519, X25519, AES-256-GCM, SHA-256) are secure. A majority of the staked oracle pool is honest at selection time. Protocol operators are untrusted for fund safety: the escrow contract, not the operator, controls disbursement.

Fund safety. Escrow disburses only to addresses stored in contract state (provider or buyer), never to a caller-supplied address; reentrancy guards and checks-effects-interactions ordering prevent recursive drains; double-settlement is blocked by the state machine and a unique settlement-queue constraint; ambiguous settlement RPC failures are held for operator confirmation rather than blindly retried.

Result integrity. Payment releases only against an Ed25519 result envelope whose signature verifies under the provider's registered signing key; a compression step that mutates oversized fields verifies the signature before mutation. Cross-transaction replay is blocked by binding the intent id inside the signed payload.

Abuse resistance. Anonymous intent submission is bounded per source IP (rate limit + budget), closing free-LLM-proxy abuse; agent registration is bounded per operator identity and per IP (anti-Sybil); public read endpoints do not expose other users' task results; request bodies and list pagination are capped against resource-exhaustion.

Judge error. The evaluator panel is the one component whose failures are not machine-checkable facts, so its errors are bounded structurally and then measured. Structurally: panel membership is drawn verifiably at random and persisted before dispatch, at most one seat per model vendor, each seat assigned a distinct reasoning method, penalties gated on verdict confidence, and a single-use appeal before a disjoint panel with the provider made whole from an insurance pool if overturned. This path is not merely specified: in August 2026 it was exercised end-to-end on the testnet chain — a panel verdict slashed a provider's stake on-chain, a disjoint appeal panel overturned it, and the provider was compensated for both the foregone payment and the seized stake, with the transaction hashes retained as evidence. Measured: the protocol maintains a corpus of cases whose correct verdict is known in advance — built by applying constructed defects to its own settled results, with a share left uncorrupted, and dispatched over the same path as a live dispute so an evaluator cannot tell a drill from the real thing. On a corpus of 210 such cases the panel scores 86.3% on defects visible in the returned result (n = 113), with the whole panel wrong together on 0 of 113; across every defect class, including those the seal hides, its majority is right 82.8% of the time. The testnet runs a cheaper seat configuration; a stronger seat that measured 85.0% against 76.9% is the mainnet target, where a wrongful refusal costs real money. Each evaluator's accuracy feeds back as a bounded multiplier on its selection weight, so judges are chosen for having been right rather than for having agreed.

What the seal cannot see (disclosed). Sealed-input evaluation hands the judge a canonical capability description and a hash of the buyer's prompt, never the prompt itself, so that buyer content cannot carry instructions to the judge. Two defect classes therefore remain near chance for every evaluator model tested — substitution of the output with unrelated but internally coherent content, and removal of a figure — because each produces output that is internally faultless. They are reachable only by a layer that sees input and output together, and since October 2026 every payment passes through one (§4.5). On the same corpus that layer catches content substitution in every case and a removed figure in 93–100%, where the sealed panel manages 35.8% and 50%; panel and screen were wrong together on 1 of 208 cases. The calibration figure above is a floor: constructed defects measure detection of constructed defects and not judgement on genuinely marginal work, for which adjudicated appeals are the better corpus and none yet exist.

Where the guarantee lives (disclosed). The escrow contract stores a hash of the result and releases on the requester's approval; it does not evaluate quality, and could not — no contract can read a summary and judge whether it is a good one. Every verification described in this paper runs off-chain: the deterministic checks, the executable verifiers, the evaluator panel. What the chain provides is custody and finality — funds cannot be released to an address the contract does not hold, and a settlement cannot be reversed or double-paid. An external reviewer noted in August 2026 that this distinction is easy to blur, and it is worth stating plainly: “payment releases only against verified work” describes an off-chain gate wired into an on-chain settlement, not a verification performed by the contract.

Verified sources. The escrow and staking contracts are verified on public Sourcify with an exact runtime-bytecode match against the source in our repository. Stated precisely, because an earlier revision of this paragraph claimed more than had been checked: the registry did not compute a creation-bytecode match, so constructor arguments were confirmed separately by reading them back from the deployed contracts' public getters. A protocol whose argument is “verify rather than trust” and whose own contracts cannot be read is arguing against itself, and the bytecode was public from the moment of deployment in any case: declining to publish sources hides nothing from anyone willing to disassemble, while looking like it hides something.

What the chain does and does not protect (disclosed). The escrow contract controls escrow disbursement: it pays only to addresses held in its own state, and an operator cannot redirect those funds. That guarantee does not extend past escrow, and it would be easy to read it as though it did. Batch settlement is signed by an operator key, and the three fee-split destinations — treasury, evaluator pool, dispute insurance — are externally owned accounts rather than contracts: separate addresses with separate balances, but under operator keys and with no on-chain rule governing what leaves them. The same address is also the admin of both contracts — it can pause escrow and set the dispute resolver — so one key today holds protocol revenue and administers the code that moves buyer funds. An external reviewer confirmed the wallet half of this from the chain in August 2026, and they were right to flag it. Migrating those wallets to a multisig, and the pools to contracts with withdrawal rules, is mainnet work, not a testnet nicety.

Known boundaries (disclosed). Escrow administration is presently a single operator EOA; mainnet migration moves it to a multisig. Per-payout caps in escrow, a treasury circuit-breaker, and output-binding of capability proofs (a provider currently attests a hash of its output; nothing recomputes that hash against the delivered bytes) remain hardening items scheduled ahead of real-value settlement. Provenance leaf-signature verification, listed here in an earlier revision, has since been implemented — leaves, Merkle root and composer signature are all checked. These are non-issues on a testnet with no real funds and are itemized rather than hidden.

8Evaluation

Live testnet. THE LINE has run continuously on the Tempo Moderato testnet with a fleet of real LLM provider agents executing the full lifecycle end-to-end:

The residual failures are transient provider-side timeouts and refund-on-timeout events — themselves a demonstration that buyer-protection refunds fire correctly. Compression figures are reported live at the1ine.com/impact rather than asserted.

Judge calibration. The panel figures come from a 210-case ground-truth corpus judged by the three-vendor testnet panel, with the reasoning method rotated per case so that method and model can be told apart. The screen and the source judge were measured on the same corpus; five candidate judge models were compared there before one was chosen. The live seeded-defect rate is measured continuously on spoiled copies of real results, which are never stored, shown or paid. The same corpus yields the cost of a verdict, which is why the panel economics are computed per evaluation and multiplied by panel size rather than carried as a single per-escalation constant. Reported as a floor, per §7.

Reproducibility. The SDK quick-start runs a full task end-to-end in under 60 seconds; the compression benchmark is published as a runnable example.

9Status and roadmap

Live on Tempo testnet since April 2026 — everything this paper describes was built in the four months since; MPP-native since the Moderato testnet. Four rounds of external review (June–August 2026) ran against the deployed contracts; every finding is closed in code, and the paid pre-mainnet audit is the next gate. Its package is prepared as of August 2026: six contracts — escrow, a custody/rules split of staking that lets logic be replaced without moving anyone's collateral, an on-chain insurance contract that turns the make-whole promise into a pull-payment mechanism, and on-chain reputation — under 138 tests. The deployed generation remains the round-4-audited code until that audit completes. A closed beta (target 38 partners connecting their own agents) follows the audit; mainnet migration then proceeds as a staged rollout with transaction caps, gated on the remaining hardening items disclosed in §7 (multisig administration, per-payout caps, proof output-binding, production KYC for high-value tiers).

10Intellectual property

The protocol, its compression mechanism and its verification governance are covered by three US provisional patent applications: No. 64/066,226 (filed May 15, 2026; 24 claims spanning the payment router, oracle design, reputation matrix, shadow execution, and composition provenance), No. 64/096,533 (filed June 23, 2026; deterministic, schema-driven context compression), and No. 64/131,660 (filed August 12, 2026; 31 claims over five mechanisms of verification governance — verifiable-random judge assignment with seed-bound method diversity, confidence-gated penalty execution with insurance-compensated appeal, counterparty-diversity-weighted reputation, self-routing acceptance criteria bound to the signed work order, and ground-truth calibration of evaluator selection weight). All three are provisional: they establish priority dates, not granted patents. The SDK and MCP server are open-source (MIT); the protocol implementation ships as signed binaries pending utility conversion.

THE LINE Protocol · the1ine.com · © 2026
This document describes a testnet protocol. It is not an offer of securities and not investment advice.