Discovery 1.7.5 labels MPP EVM/Base challenges as tempo:8453

[seancrecord]

@agentcash/discovery@1.7.5 parses an MPP evm/charge challenge on Base as network: "tempo:8453". It also omits the six-decimal precision when the EVM request puts decimals in methodDetails.

Reporting here because apps/scan/package.json pins this package and the linked package repository (merit-systems/agentcash-discovery) returns 404. Please transfer if there is a better public tracker.

Reproduced with an unsigned GET of https://scvd.store/api/buy/context_anchor on September 17. The challenge declares method="evm", intent="charge", methodDetails.chainId=8453, and Base USDC. No payment was submitted. A deterministic reproduction needs no network or wallet:

npm install --ignore-scripts @agentcash/discovery@1.7.5

import { checkEndpointSchema } from '@agentcash/discovery';
const request = Buffer.from(JSON.stringify({
  amount: '1000000',
  currency: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
  methodDetails: { chainId: 8453, decimals: 6, credentialTypes: ['authorization'] },
  recipient: '0xDD350976B8cfFc65938C0464d39A2C78BE079bd0',
})).toString('base64url');
const header = `Payment id="fixture", realm="example.com", method="evm", intent="charge", request="${request}"`;
globalThis.fetch = async (url, init) => {
  if (String(url).endsWith('/anchor') && init?.method === 'GET') {
    return new Response('{}', { status: 402, headers: { 'WWW-Authenticate': header } });
  }
  return new Response(null, { status: 404 });
};
const result = await checkEndpointSchema({ url: 'https://example.com/anchor', probe: true });
console.log(JSON.stringify(result, null, 2));

The returned MPP option contains:

{"protocol":"mpp","paymentMethod":"evm","intent":"charge","network":"tempo:8453","amount":"1000000"}

Expected: preserve the EVM/Base identity (for example eip155:8453, consistent with the chain identifier), or mark an unsupported method explicitly. It should not be relabelled as a Tempo network. For supported EVM requests, preserve methodDetails.decimals=6 as well.

The published bundle's extractPaymentOptions unconditionally formats network as tempo:${chainId} and only reads request.decimals. This appears independent of SCVD's OpenAPI metadata. Separately, our current x-payment-info.protocols lists only x402; adding an MPP descriptor on our side is still needed and is not claimed as fixed by this report.

This blocks our MPPScan qualification. Does the current registration path support evm/charge on Base, or should this method be explicitly treated as unsupported for now?

[seancrecord]

SCVD's separate static-metadata gap is now fixed and deployed in release #791. At 2026-09-18T02:40:27.078Z, @agentcash/discovery@1.7.5 read both x402 and mpp from the live Context Anchor OpenAPI operation, with 1 USD, required summary input and no endpoint warnings.

The runtime parser issue reported here still reproduces after that correction: unpaid probe mode returns paymentMethod: "evm", network: "tempo:8453", and no decimals, while the actual challenge declares Base chainId 8453 and methodDetails.decimals 6. No payment was sent. The existing isolated reproduction remains applicable; the static descriptor change does not resolve the network mapping.

[seancrecord]

Still reproducible on our side as of today (September 18, 18:08 UTC): @agentcash/discovery@1.7.5 reports evm/charge as tempo:8453, with no decimals, while the live challenge declares Base chainId 8453 and six decimals. This was an unpaid probe.

Note our 402 envelope's resource.url now names the exact requested URL including the query string, which the mppx x402 reader requires; if your parser compares that field, the bare-path assumption no longer holds for doors with required inputs. Live readback of /api/buy/context_anchor?summary=directory-followup-2026-09-18 preserved that full URL in the x402 envelope. The resource-URL change shipped in #804; it does not fix the separate network-mapping issue reported here.

[seancrecord]

New hosted-scanner evidence, September 19: SCVD's free registration on MPPScan succeeded, and the public server page now displays the resources.

The hosted registration probe reported “Paid endpoint did not return payment options in the 402 response” and “Paid endpoint is missing an input schema” across 36 paid endpoints. The earlier local @agentcash/discovery@1.7.5 static read did see the MPP descriptor and Context Anchor's required summary input. A fresh unpaid GET https://scvd.store/api/buy/context_anchor still returns HTTP 402 with WWW-Authenticate: Payment, method="evm", intent="charge", and a decoded request containing methodDetails.chainId: 8453 and methodDetails.decimals: 6.

Is the hosted probe using the same parser/version and supporting this evm/charge method? We have not established whether these warnings share the cause reported above. Registration completed despite them; no payment was made. Separately, the two literal path templates /almanac/{slug} and /open-for-business/{week} returned 404 and were excluded, which we are recording as incomplete template coverage rather than changing their responses to pretend an unspecified resource exists.