Atinamos Verification
Core Principle You can pay to be tested. You cannot pay to be trusted.
Explore verification

Study 3 — x402engine Paid Screenshot Returned Contract-Invalid Artefact

Result

Classification: settled_fulfilment_contract_invalid

On 22 August 2026 Atinamos independently exercised the x402engine Web Screenshot service using a controlled request for https://example.com.

The payment settled successfully and the seller returned HTTP 200 with plausible page metadata. However, the primary screenshot artefact did not satisfy the provider's advertised output contract: the returned value could not be decoded as the expected base64 PNG.

Atinamos therefore recorded:

payment settlement observed = true
fulfilment observed          = true
output valid                 = false

A successful payment and HTTP 200 response are not, by themselves, proof that the purchased output matched the advertised contract.

What the seller was offering

At the time of this study, x402engine advertised Web Screenshot at $0.01. Its API documentation described the endpoint as:

“Capture a screenshot of any URL. Returns a base64-encoded image.”

Seller source: x402engine API documentation

The documented example response showed a screenshot field containing base64 beginning iVBORw0KG..., identified as a base64 PNG, alongside page metadata such as title and status code.

In buyer terms, the useful product was therefore a screenshot image of the requested public web page, delivered as base64-encoded PNG data.

Claim Atinamos tested

For a controlled request to screenshot https://example.com, the paid response should contain:

  • metadata corresponding to the requested page; and
  • a screenshot value that is valid base64 and decodes to a PNG image.

This is the seller proposition against which the output was evaluated.

Service tested

  • Provider: x402engine
  • Service: Web Screenshot
  • Method: GET
  • Controlled target: https://example.com
  • full_page: false
  • x402 version: 2
  • Network: Base mainnet (eip155:8453)
  • Payment scheme: exact
  • Price: 0.01 USDC

The live payment contract offered several networks. The recipe explicitly selected Base and imposed a 0.012 USDC maximum-spend cap.

What Atinamos tested against the offer

The verifier did not treat “HTTP 200” as the product. It tested the useful thing the seller said it was selling: a screenshot image in the documented representation.

The paid response was checked against three assertions:

  1. metadata.title == "Example Domain" — PASS
  2. metadata.statusCode == 200 — PASS
  3. screenshot must be valid base64 whose decoded bytes begin with the PNG signature 89504e470d0a1a0a — FAIL

The first two assertions established that the returned metadata referred to the controlled target page. The third tested the advertised screenshot artefact itself.

The returned screenshot string was 573 characters long, but strict base64 decoding failed. Because it could not be decoded as base64, it could not satisfy the documented base64-PNG output contract in this run.

Atinamos did not attempt to judge screenshot visual fidelity, dimensions or page completeness: the artefact failed the more fundamental advertised representation check first.

Settlement proof

The x402 payment response reported successful settlement. Atinamos then independently checked Base USDC transfer data and the verifier wallet balance.

Observed transfer:

  • amount: 0.01 USDC
  • recipient: 0x7dd5Be069f2d2eAd75eC7C3423B116fF043c2629
  • transaction: 0x362e2520619063c42fddbcb9dc0db62052e460fd8ba02daab1c56dcb3ea47e2b
  • Base block: 50306644

The on-chain transaction matched the transaction reported by the payment response.

Why Atinamos did not call this a success

The seller did fulfil the HTTP request in the narrow sense that it returned HTTP 200 and a JSON body. Two metadata fields also matched the controlled target.

But the primary purchased artefact was the screenshot image. The seller documentation said that image would be returned as base64, with its example identifying it as base64 PNG. The observed screenshot value did not decode as valid base64.

Marking the transaction successful merely because payment settled and HTTP 200 was returned would therefore ignore the thing the buyer had actually paid for.

This observation demonstrates three separate evidence layers:

payment succeeded → response arrived → advertised primary output format failed validation

What a future buyer should see

If a buyer agent considers the same screenshot service, Atinamos should not say “do not buy” or “untrusted.” It should report the evidence and the seller proposition that was tested:

Atinamos observed one paid verification on 22 August 2026. The service was advertised to capture a URL and return a base64-encoded screenshot image. 0.01 USDC settled and HTTP 200 fulfilment was returned, but the primary screenshot field did not satisfy the tested base64-PNG output contract. This is one timestamped observation. Apply your own risk policy.

The buyer can then choose to reject, require a fresh test, accept the risk or continue for other reasons.

What this does not prove

This single run does not prove that:

  • x402engine always returns a contract-invalid artefact;
  • the provider as a whole is unsafe or untrustworthy;
  • every input to the endpoint would produce the same result;
  • the exact alternate representation of the 573-character value is known from the retained evidence;
  • one failed observation should force every buyer to reject the service.

It proves only that the advertised Web Screenshot output contract was not satisfied in this specific paid observation.

Machine-readable evidence

GET /v1/trust?endpoint=https://x402engine.app/api/web/screenshot

The registry reports the settlement, fulfilment, failed output validation and classification. The buyer decides whether that evidence is sufficient to change its purchase decision.