Free USTA receipt signature check
Verify a USTA Agent Market buyer receipt against its published key.
Observed 2026-08-12: we fetched 7 primary sources for this offer and recorded a dated note for each. 6 limitations are published below, including the things we could not check. Coverage is stated on this page, never implied.
POST one Ed25519 buyer-result receipt envelope and get a bounded signature-and-expiry inspection. This is not a settlement, replay or delivery check.
In plain words: this free endpoint checks one narrow cryptographic claim. It tells you whether an Ed25519 buyer-result receipt was signed under the public key configured by the USTA Agent Market, then reports whether the signed expiry is current, expired, or unreadable. It rejects a tampered envelope and a receipt signed under a different key. It does not inspect a chain, payment provider, merchant account, delivery, or one-time-use ledger, and does not prove Base/USDC settlement.
The problem this exists for
A copied receipt envelope can be altered or signed under an unrelated key. A buyer needs a free check against this service's pinned public key without receiving any signing secret.
What you receive
A read-only JSON inspection of one USTA Agent Market Ed25519 receipt envelope: INVALID_OR_UNTRUSTED, VALID_CURRENT, VALID_EXPIRED, or VALID_EXPIRY_UNKNOWN, plus the signed tool name and whether a transaction binding is present.
Who this is for
Buyers holding an Ed25519 buyer-result receipt issued by the USTA Agent Market who need to check its signature against the service's published key.
How it works
- Fetch the service's public receipt key, then POST exactly one complete receipt envelope to /receipts/verify; never submit a private key or provider secret.
- The verifier checks the Ed25519 signature and embedded public key, then interprets the signed expiry when it is readable.
- Receive INVALID_OR_UNTRUSTED, VALID_CURRENT, VALID_EXPIRED or VALID_EXPIRY_UNKNOWN, plus the tool name and transaction-binding presence when signed into the payload.
What each verdict means
- PASS — The complete Ed25519 envelope verifies against this service's configured public key. Expiry is reported separately as current, expired, or unreadable.
- FAIL — The envelope is malformed, its signed bytes were altered, its signature is invalid, or its embedded key does not match this service's pinned public key.
- UNKNOWN — The verifier endpoint or configured verification key cannot be read. The service never converts an unavailable dependency into a valid receipt.
This contract is fail-closed. An input we cannot read returns UNKNOWN and stops there; UNKNOWN is never rounded up to PASS to keep a job moving, and it authorises nothing.
Readiness check — PASS
The question below was asked and answered, and the answer was yes.
Can the served read-only endpoint verify this service's Ed25519 receipt envelope, reject tampering and wrong keys, and report expiry without moving funds?
- On 2026-08-13 America/Phoenix, the implemented POST /receipts/verify route and its receipt inspection tests accepted a valid service receipt and rejected altered bytes and an unrelated key.
- The response keeps signature authenticity, expiry and transaction-binding presence as separate fields.
- The endpoint is read-only, takes at most 65,536 request bytes, and never signs, settles, spends, captures or sends anything.
Limits we publish against ourselves
- This verifies only Ed25519 buyer-result receipt envelopes issued by the USTA Agent Market against its currently configured public key.
- A valid signature does not prove Base/USDC settlement, payment authorization, finality, delivery, job quality or entitlement to release anything.
- The endpoint reports whether the signed payload contains a transaction binding but never reads a chain or payment provider.
- The endpoint does not maintain or consult a replay or one-time-consumption ledger.
- A receipt with no readable signed expiry remains cryptographically valid with status VALID_EXPIRY_UNKNOWN; it is not presented as current.
- The service does not verify counterparty identity, beneficial ownership, tax treatment or legal entitlement.
Boundaries
- Legal — This is technical evidence, not a legal opinion, not an arbitration ruling, and not a representation that release is legally required.
- Money — Verification is read-only. It never initiates, signs, settles, refunds, captures, or otherwise moves funds.
- Claims — A VALID_* result means only that this service's pinned Ed25519 key verifies the envelope. It does not prove settlement, non-replay, delivery or entitlement.
Signature authenticity does not prove Base/USDC settlement, non-replay, payment finality, delivery, quality or entitlement. The endpoint performs none of those checks.
Price
FREE — $0. This verifier has no checkout, payment challenge, account requirement, or sales form.
The implemented POST endpoint has no x402 challenge, checkout, account requirement, or sales form.
Sources we fetched on 2026-08-12
| Source | Kind | Fetch result | Fetched | What it said |
|---|---|---|---|---|
| https://github.com/x402-foundation/x402/blob/main/specs/extensions/extension-o | OFFICIAL PROTOCOL SPEC | FETCHED_2XX | 2026-08-12 | The normative x402 extension separates signature verification from signer authorization, makes the transaction field optional, and permits a chain check only when a transaction reference is present. |
| https://docs.x402.org/core-concepts/http-402 | OFFICIAL PROTOCOL DOCUMENTATION | FETCHED_2XX | 2026-08-12 | x402 v2 carries SettlementResponse in PAYMENT-RESPONSE; exact and upto commonly settle immediately, while batch settlement can redeem later. |
| https://docs.x402.org/core-concepts/client-server | OFFICIAL PROTOCOL DOCUMENTATION | FETCHED_2XX | 2026-08-12 | The server flow separates payment verification from settlement and documents duplicate-settlement protection for direct Solana settlement. |
| https://docs.stripe.com/payments/payment-intents/verifying-status | OFFICIAL PROVIDER DOCUMENTATION | FETCHED_2XX | 2026-08-12 | Stripe documents independent PaymentIntent retrieval, succeeded status, and signed payment_intent.succeeded webhooks for server-side fulfillment decisions. |
| https://docs.stripe.com/webhooks | OFFICIAL PROVIDER DOCUMENTATION | FETCHED_2XX | 2026-08-12 | Stripe documents signature verification and timestamp tolerance for replay mitigation, and notes that retried events receive a new signature and timestamp. |
| https://docs.stripe.com/reports/balance-transaction-types | OFFICIAL PROVIDER DOCUMENTATION | FETCHED_2XX | 2026-08-12 | Stripe distinguishes pending from available balance transactions and documents later payment failure refunds and reversals. |
| https://docs.stripe.com/api/charges/object | OFFICIAL API REFERENCE | FETCHED_2XX | 2026-08-12 | The Charge object links a receipt URL to a balance transaction, while paid can include authorization for later capture; exact status and capture fields must therefore be checked separately. |
Verify a USTA Agent Market buyer receipt for free
POST one JSON object to the endpoint below. The body must contain exactly one receipt field whose value is the complete Ed25519 receipt envelope returned by this service.
Endpoint: https://agents.ustechautomations.com/receipts/verify
Method: POST
Pinned key: https://agents.ustechautomations.com/.well-known/receipt-key.json
Machine resources: machine discovery card · authoritative x402 price and tool catalog
JSON example: {"receipt":{"version":2,"algorithm":"Ed25519","key_id":"ed25519:...","public_key":"...","payload":{},"signature":"..."}}
The response status is VALID_CURRENT, VALID_EXPIRED, VALID_EXPIRY_UNKNOWN, or INVALID_OR_UNTRUSTED. It also exposes the signed tool name when available and whether a transaction binding is present.
Scope: USTA Agent Market Ed25519 buyer-result receipts only. Signature authenticity does not prove Base/USDC settlement. Maximum request body: 65,536 bytes.