Proof #3 — A Bounded Autonomous Buyer With External Discovery
Status
COMPLETE — 28 August 2026.
Atinamos directly observed one bounded autonomous buyer complete the strict sequence:
human supplies task + budget + risk policy
-> live external Coinbase/x402 Bazaar discovery
-> exact-route non-paying contract preflight
-> Atinamos evidence lookup after discovery
-> buyer-owned policy evaluation
-> autonomous seller selection
-> bounded x402 payment
-> seller fulfilment
-> exact result validation
-> task completed
The successful final run did not receive a seller name or endpoint from the human. The buyer independently discovered Keyronne JSON Repair as the externally ranked first candidate, found qualifying previously published Atinamos evidence, selected it under the unchanged policy, paid 0.001 USDC on Base mainnet, received the repaired JSON, and validated the semantic result exactly.
This is not a claim that an unrelated external buyer has independently discovered and purchased an Atinamos service. External market adoption remains a separate milestone.
The question
Can a buyer receive only a task, a budget and a risk policy, then independently:
- discover paid services from an external marketplace;
- compare the externally ranked candidates;
- query independent Atinamos evidence;
- apply its own procurement policy;
- choose or reject a seller without a human supplying the endpoint;
- make one bounded x402 payment if allowed;
- validate the returned result?
That sequence is Atinamos Proof #3.
Pre-registered discovery criteria
The seller-neutral discovery rules were published separately before the final paid run:
Proof #3 discovery search criteria
The important controls were:
- search the complete Coinbase/x402 Bazaar with
curatedOnly=false; - search for paid machine services capable of repairing or validating-and-repairing malformed JSON;
- do not purchase during discovery;
- do not favour a provider or brand;
- do not use Atinamos evidence or another reputation layer to create the marketplace ranking;
- rank only by marketplace task fit, machine-contract clarity and price;
- return at most eight candidates;
- copy executable route details from marketplace metadata rather than inventing them.
Atinamos evidence is queried only after external discovery.
Initial buyer task
The buyer task remained deliberately small and frozen throughout the experiment.
Input:
{foo: 'bar', broken: true,}
Required exact semantic result:
{
"foo": "bar",
"broken": true
}
The small task keeps output validation objective and service cost low.
Pre-defined buyer policy
The policy remained unchanged through the final successful run:
- maximum spend: 0.02 USDC;
- Base mainnet only (
eip155:8453); - Base USDC only (
0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913); - x402 v2 only;
exactpayment scheme only;- published Atinamos evidence required;
- at least one successful paid fulfilment observation required;
- zero failed paid fulfilments allowed;
- evidence no older than 30 days;
- at most one paid retry;
- HTTPS public seller target only;
- redirects disabled on paid invocation;
- executable invocation URL bound to the exact externally discovered service route.
If every candidate fails policy, the correct action is do not buy.
Why the earlier evidence-gated purchase was not enough
On 18 August 2026 a separate buyer queried Atinamos evidence, applied policy, paid 0.25 USDC for Render Check and consumed the result. That proved evidence-gated buying, but the seller endpoint had been supplied directly to the buyer.
Proof #3 required seller-neutral discovery before evidence and payment.
Implementation
The public buyer implementation is on the Atinamos-Agent feature/proof3-autonomous-buyer branch.
Core files:
agent/autonomous_buyer.py
agent/aws_bazaar_discovery.py
agent/x402_payment_firewall.py
tools/proof3_autonomous_buyer.py
The final regression/safety suite passed 19/19 tests on Ubuntu before the final paid execution.
Tests establish control behaviour. They are not themselves proof that the live autonomous sequence happened.
Attempt 1 — discovery succeeded, wrapper parser failed
The first Ubuntu dry-run reached Coinbase/x402 Bazaar and returned eight ranked JSON-repair candidates. The wrapper then failed before evidence lookup because the model response contained explanatory prose plus a fenced JSON object and the parser locked onto malformed task text instead of the discovery object.
No evidence lookup, seller selection or payment occurred.
The parser was changed only to extract an object matching the expected discovery schema. The task, marketplace universe, policy and success criteria were not changed.
Attempt 2 — successful autonomous no-purchase
The corrected dry-run independently discovered eight candidates. At that moment none of their exact routes was present in the published Atinamos evidence corpus.
Under require_known_evidence=true, every candidate was ineligible and the buyer correctly recorded:
selected = null
purchase_allowed = false
payment = null
proof3_complete = false
This was a valid autonomous procurement decision, but it did not complete the paid milestone.
Separate evidence-acquisition intervention
The buyer policy was not weakened to force a purchase. Instead, Atinamos Verification tested the entire frozen eight-candidate set under one provider-neutral verification experiment.
The original buyer task remained frozen. Evidence acquisition used a separate, harder medium malformed JSON fixture so that seller evidence was based on more than the tiny buyer example.
Frozen candidate manifest:
config/proof3-json-repair-candidates-2026-08-28.json
Medium fixture:
config/proof3-json-repair-medium-fixture-v1.json
The fixture contained nested objects and arrays with repeated unquoted keys, single-quoted strings and trailing commas. Every candidate was required to produce the same exact semantic target; only the provider-specific request wrapper differed according to the marketplace contract.
Paid verification results
| Candidate | Observation | Payment |
|---|---|---|
| Keyronne | settled, fulfilled, exact semantic result valid | 0.001 USDC |
| AgentProof | TLS/transport failure before payment | none |
| FenixFoundry / agent-reader | settled, fulfilled, exact semantic result valid | 0.003 USDC |
| Hermes Commerce | settled and fulfilled HTTP flow, but semantic output invalid | 0.010 USDC |
| API Acre | settled, fulfilled, exact semantic result valid | 0.005 USDC |
| BitBooth | live challenge requested 0.005 USDC versus frozen advertised 0.001; verifier cap blocked payment | none |
| toolbelt402 | expected x402 challenge route returned HTTP 404 at verification time | none |
| NetIntel | expected x402 challenge route returned HTTP 404 at verification time | none |
Observed verification spend was 0.019 USDC. Three candidates produced settled, semantically valid fulfilments under the common test. Hermes demonstrates why payment settlement is not proof of useful fulfilment: payment settled, but the returned result failed the objective semantic criterion.
The BitBooth observation is evidence of price drift at verification time, not a claim of fraud. The 404 observations describe the exact tested routes at that time, not a permanent judgement about the providers.
Persistence and publication of evidence
The eight verification attempts were persisted to the Verification database as runs 15–22 with full artifacts 1–8. A read-back confirmed all eight artifacts were present.
Eight compact public evidence records were then exported to docs/evidence/ and published before the final buyer run.
The public buyer-facing /v1/trust API subsequently reported:
| Provider | Known | Paid tests | Successful fulfilments | Failed paid fulfilments |
|---|---|---|---|---|
| Keyronne | true | 1 | 1 | 0 |
| FenixFoundry | true | 1 | 1 | 0 |
| Hermes | true | 1 | 0 | 1 |
| API Acre | true | 1 | 1 | 0 |
That meant the unchanged buyer policy could accept Keyronne, FenixFoundry or API Acre if they were rediscovered on the exact verified route, while Hermes remained ineligible.
Route-identity failure discovered during rerun
One fresh dry-run exposed a separate discovery-integrity problem: the LLM-mediated discovery layer returned altered invocation paths for several candidates, for example changing Keyronne /json-repair to /json_repair and FenixFoundry /repair-json to /repair/json.
Read-only route checks showed the verified forms returned x402 HTTP 402 challenges while the altered forms returned 404/405.
The buyer correctly refused to bind evidence from one route to a different text route. No underscore/hyphen alias rule was introduced.
The discovery implementation was hardened instead:
- endpoint strings must be copied character-for-character from marketplace metadata;
- every returned invocation route receives a non-paying live preflight;
- redirects remain disabled;
- only a route returning the expected x402 402 challenge survives as an executable candidate;
- rejected routes remain visible in the receipt.
This produced a separate engineering finding: machine-service identity includes the executable route; URL transcription is not cosmetic in autonomous commerce.
Post-evidence dry-run
After route-fidelity hardening, a fresh live Bazaar discovery returned the correct Keyronne route and the buyer independently found qualifying public Atinamos evidence.
The buyer recorded Keyronne as eligible, selected the externally ranked first eligible candidate and set:
purchase_allowed = true
selected = Keyronne JSON Repair
No payment was sent during that dry-run.
First paid run — seller succeeded, buyer validator failed
The first live execution independently rediscovered and selected Keyronne and successfully paid 0.001 USDC. Settlement succeeded and the seller returned HTTP 200 with the exact repaired semantic object under a response field named value.
The Proof #3 wrapper nevertheless recorded proof3_complete=false because its result validator understood data, repaired_string and a top-level object but did not yet recognise the value response envelope.
That run is retained as a buyer-side implementation-validation failure after successful seller payment and fulfilment. It is not counted as a seller failure.
The result validator was then narrowly corrected to recognise the observed value envelope and made stricter: the extracted repaired object must equal the expected object exactly. Regression tests were added, and the full relevant suite passed 19/19.
Final live execution — Proof #3 completed
A completely fresh execute-mode run was then performed from the Ubuntu buyer host.
The buyer again independently searched Coinbase/x402 Bazaar. Keyronne JSON Repair was externally ranked first at 0.001 USDC and was returned on the exact route:
https://keyronne.com/api/json-repair
The non-paying route preflight returned HTTP 402. The buyer then queried Atinamos /v1/trust and observed one successful paid fulfilment, zero failed paid fulfilments and sufficiently fresh evidence. Under the unchanged policy Keyronne was marked eligible and purchase_allowed=true.
The live payment firewall independently rechecked the actual seller challenge and accepted only:
x402 version: 2
scheme: exact
network: eip155:8453
asset: Base USDC
amount: 1000 microunits = 0.001 USDC
The buyer paid the dynamically supplied seller recipient and received HTTP 200.
Settlement response:
success = true
transaction = 0x241358fc7223a80fd2803bb49438a47da684ab01b49afc5a0a99736c74fdffca
network = eip155:8453
Seller result:
{
"repairs": [
"quoted unquoted object key",
"converted single-quoted string to double quotes",
"removed trailing comma"
],
"value": {
"broken": true,
"foo": "bar"
}
}
The buyer extracted the value envelope and performed exact equality against the pre-defined expected data:
reason = exact repaired data matched
valid = true
proof3_complete = true
What Proof #3 now supports
The observed evidence supports the bounded claim that an Atinamos-operated buyer can:
receive task + budget + risk policy
-> independently discover external paid machine services
-> reject malformed/non-executable discovered routes before payment
-> query independently published Atinamos evidence
-> apply an unchanged buyer-owned procurement policy
-> choose a seller without a human naming it
-> independently verify live x402 terms
-> make a bounded payment
-> consume the seller output
-> validate the result objectively
-> complete the task
The evidence also shows two safe no-purchase/rejection behaviours: lack of qualifying evidence prevents purchase, and an executable-route mismatch prevents evidence from being silently transferred to a different endpoint.
Separate Atinamos discoverability finding
A read-only Bazaar check performed during the experiment found Atinamos Render Check indexed and discoverable, with marketplace usage signals, but Atinamos JSON Validate / Repair was not indexed in Bazaar at the time of the check.
No listing or metadata was changed during Proof #3. Fixing discovery of the newer Atinamos Shop service is deliberately treated as follow-up work so it could not influence the seller-neutral experiment.
Current claim
Proof #3 is complete. On 28 August 2026 an Atinamos-operated bounded buyer independently discovered paid JSON-repair services through Coinbase/x402 Bazaar, queried previously published Atinamos evidence, applied its unchanged procurement policy, autonomously selected Keyronne, paid 0.001 USDC over x402 on Base mainnet, consumed the result and validated the exact repaired data. The human did not name or pre-select the seller.
This is a controlled autonomous-buyer proof. It is not evidence that an unrelated external buyer has independently discovered or purchased an Atinamos service in the wild; that market-adoption milestone remains open.