{"protocolVersion":"0.3.0","name":"HALOWERK x402werk","description":"HALOWERK x402werk. Bezahlung über x402 in USDC auf Base Mainnet.","url":"https://x402.halowerk.com","version":"1.0.0","preferredTransport":"JSONRPC","capabilities":{"streaming":false,"pushNotifications":false,"stateTransitionHistory":false},"defaultInputModes":["application/json"],"defaultOutputModes":["application/json"],"skills":[{"id":"parse_402_offer","name":"Reads the x402 payment challenge of any URL and returns it field by field: network, asset, exact amount in units and in human form, recipient, and every gap a paying agent should know about.","description":"Fetches the 402 challenge of a foreign endpoint without paying anything — no payment header, no signature, no settlement — or parses a challenge you already hold. Returns x402_version, every accepts entry with scheme, network, resolved network name and chain id, asset, symbol, decimals and the amount both in raw units and in human form, plus the resource block and any expiry. amount_human is computed with the decimals of that token, resolved from a known-asset table or read from the chain; where decimals cannot be established it stays null and is listed in unavailable_fields rather than assuming six. parse_warnings names concrete gaps such as a missing description or missing inputSchema, a non-CAIP-2 network, a bridged instead of canonical asset, or an amount sent as a JSON number. It does not judge the service, does not pay, does not verify signatures and does not check whether the seller delivers. Answers for a URL are cached for 60 seconds; age_ms states the age of the fetched challenge.","tags":["x402","402 challenge","payment required","offer parser","accepts","agent payments"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"validate_requirements","name":"Checks an x402 payment challenge against the schemas of the x402 Foundation reference implementation and names every deviation with field, expectation, finding and the schema clause that rejected it.","description":"Validates a 402 challenge — fetched from a URL without paying, or supplied directly — against PaymentRequiredV1Schema and PaymentRequiredV2Schema of the installed @x402/core reference implementation. Reports the detected version and how it was detected, every error with field, expected, found and spec_ref naming package, version, schema and field path, whether the network is valid CAIP-2, whether the asset is a known and canonical token address or a bridged variant, whether the declared inputSchema compiles as a JSON Schema, which protocol extensions are declared and which of them are known, and whether v1-only and v2-only clients could each act on this offer. price_sane flags amounts whose magnitude typically comes from a wrong decimal place; its thresholds are stated in the answer and it is reported as null wherever the asset is not a known stablecoin, since without a price feed that question cannot be answered honestly. This endpoint judges conformance only. It does not rate the service, does not say whether a price is fair, does not pay and does not verify signatures — signatures are Nr. 85.","tags":["x402","validation","conformance","payment requirements","caip-2","spec check"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"verify_offer_receipt","name":"Verifies the signature of a signed x402 offer and of an optional receipt, recovers the signer, and says whether that signer is actually the address the offer wants to be paid to.","description":"Cryptographic verification of the offer-receipt extension of x402. Accepts a signed offer in eip712, jws or eip191 form — either bundled as {format, payload, signature} or as payload plus a separate signature — and an optional signed receipt. Recovers the signer, compares it with the payTo of the offer, compares receipt and offer field by field and names every divergence with the value on each side, checks whether the offer has expired and whether the receipt timestamps are plausible against stated tolerances. The answer states plainly that recovering a signer proves nothing on its own: every well-formed ECDSA signature yields some address, so signer_matches_pay_to is the deciding field, and a valid signature from the wrong address is worthless. For jws the signer is a key identifier and not an EVM address, so signer_matches_pay_to is reported as null rather than guessed. If the verification method cannot be determined or a jws public key is missing, the call ends unverifiable with charged=false and nothing is billed. Nothing is fetched, nothing is paid, no chain is read — whether a settlement actually happened on chain is Nr. 86.","tags":["x402","signed offer","signed receipt","eip-712","eip-191","jws","signature verification"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"verify_settlement","name":"Checks on chain whether a settlement transaction really paid the expected recipient the expected amount of the expected token, reads it from the transfer events, and states separately whether the transaction is confirmed and whether it is final.","description":"Reads the receipt of a transaction on Ethereum, Base, Base Sepolia, OP Mainnet, Arbitrum One, Polygon PoS or Avalanche C-Chain and compares it with what you expected to be paid. The comparison runs against the ERC-20 transfer events in the receipt, not against the transaction recipient, because in a token payment the transaction recipient is the token contract and never the seller. Returns every transfer event with sender, recipient, token, raw amount and human amount computed with that token decimals, the sum actually received by the expected recipient, underpaid_by and overpaid_by separately, the block number, the confirmation count, and a finality block read from the chain rather than estimated. Native coin payments are covered too when no token asset is expected. The verdict is bestaetigt, abweichung, nicht_gefunden or nicht_final; a correct but not yet finalized payment is reported as nicht_final rather than as confirmed. It does not pay, does not settle, does not sign and does not judge the counterparty.","tags":["x402","settlement","payment verification","erc20 transfer","finality","receipt check"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"replay_guard","name":"Remembers payment identifiers, payload hashes and nonces as one-way fingerprints and tells you whether this one has been seen before, when, how often, and whether that sighting lies inside your window.","description":"A stateful duplicate check for agents that settle x402 payments. Supply any of payment_id, payload_hash and nonce; each is hashed with SHA-256 before storage, so the service keeps fingerprints and timestamps and never the values themselves, never a payload, never an address. The answer states for every supplied identifier whether it was seen before, when it was first and last seen, how often, and whether the first sighting falls inside window_seconds. The recommendation is ablehnen only for a repeated payment_id or nonce inside the window, since both are unique by definition; a repeated payload_hash alone yields pruefen, because buying the same query twice is legitimate. Every threshold behind the recommendation is stated in the answer. Fingerprints expire 24 hours after the last sighting. Set record to false to ask without writing, so a repeated check does not create the duplicate it reports. This endpoint does not verify payments, does not look at any chain and does not block anything by itself.","tags":["x402","replay protection","duplicate detection","nonce reuse","idempotency","payment id"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"facilitator_health","name":"Live reachability and capability check of known x402 facilitators: which chains, assets and schemes each one accepts right now, and how fast it answers.","description":"Asks every known facilitator what it supports and measures how long that answer takes. Reachability, supported chains, supported assets, supported schemes and the current response time are measured live on every call. Limits, and they are the important part: error rate over 24 hours, uptime over 7 days and latency percentiles CANNOT be delivered. They require a series of own measurements every few minutes, and this service keeps no such series - a single call cannot produce a p95. Those fields stay null and are named in unavailable_fields instead of being computed from one sample and presented as a distribution. Nothing is ever paid: only the public capability endpoint is called, never /verify with a crafted payment and never /settle. Facilitators operated by this service are marked is_own true.","tags":["x402werk"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"price_benchmark","name":"Compares the price of one x402 endpoint with comparable offers from the public x402 Bazaar catalogue and states median, quartiles and where the price sits — with the reason each offer counts as comparable.","description":"Reads the public x402 Bazaar catalogue and finds offers comparable to yours, either from a resource_url whose 402 challenge is fetched without paying, or from a category and description you supply. Every comparable offer is listed with its price, its provider host, a similarity score and the terms both sides share, so comparability is justified rather than asserted; the formula, its weights and the inclusion threshold are stated in the answer. Prices are aggregated as median, p25 and p75 over comparable offers denominated in a known stablecoin, and position says whether your price sits below, at or above that range against stated thresholds. Below five comparable offers no position is given at all and the caveat says why. Offers denominated in other assets are counted but kept out of the price distribution, because converting them would require a price feed this service does not consult. The catalogue sample, its size against the full catalogue and its fetch time are named in every answer. This endpoint gives no pricing advice, calls no price fair or unfair and never suggests what to charge.","tags":["x402","price benchmark","bazaar","comparable endpoints","median price","pricing context"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"spend_policy","name":"Checks one proposed x402 payment against your own spending rules and returns allow, reject or review with every rule listed separately, each with its limit and the actual value.","description":"A stateless rule check for agents that pay for x402 endpoints. You supply the proposed payment, your policy and the amounts already spent this hour and this day; this endpoint keeps no ledger of its own and returns your counters unchanged. Every configured rule — max_per_call, max_per_hour, max_per_day, allowed_chains, allowed_assets, allowed_recipients, blocked_recipients, require_schema — is reported individually as erfuellt, verletzt, nicht_pruefbar or nicht_gesetzt, together with the limit and the actual value, so a rejection can be acted on. Amounts are compared exactly in the smallest unit of the token, using decimals resolved from a known-asset table or read from the chain; where decimals cannot be established the amount rules are reported as nicht_pruefbar and the decision becomes pruefen rather than a guess. risk_flags mark an unverifiable recipient, a missing input schema, a bridged instead of canonical token, an unusual or test chain and an amount above a fixed, stated threshold. Where two rules contradict each other the stricter one applies and the conflict is named. This endpoint does not pay, does not hold a budget, does not learn from previous calls and gives no advice on whether a price is fair.","tags":["x402","spend policy","budget check","agent payments","allowlist","rate limit"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"x402_reconcile","name":"Matches your x402 receipts against the token transfers that actually reached your address on chain, and lists every receipt without a payment and every payment without a receipt.","description":"Reads all incoming ERC-20 transfers of one token to one address within a block or time window and matches them against the receipts you supply. Matching runs first over the transaction hash, which is the strongest link, and otherwise over amount plus payer plus a stated time tolerance; the method used is named for every single match, so a weak match is never mistaken for a strong one. The answer lists matched pairs, receipts without a payment, payments without a receipt, amount mismatches with expected, found and difference, and duplicate receipts sharing a transaction hash or payment identifier. Totals are given for both sides with their difference, plus coverage_pct and the window actually used, including the block range and how timestamps were resolved to blocks. Unmatched items are never quietly dropped — they are the point of the exercise. Block timestamps are read from the chain for up to sixty distinct blocks; beyond that the timestamp of a payment stays null and says so. The window is limited to 114000 blocks per call because public RPC providers cap log queries; a larger request is rejected instead of silently truncated.","tags":["x402","reconciliation","receipts","onchain payments","accounting","missing payments"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"channel_audit","name":"Audits a batch of payment vouchers: which signatures actually hold, which voucher id appears twice, what the sums add up to, and whether the claimed total exceeds what was deposited.","description":"Checks vouchers of a payment channel by computation only - nothing is ever claimed, redeemed or refunded. Signatures are verified cryptographically against the address each voucher claims to be signed by, in EIP-712 form when the typed data is supplied, otherwise as a plain message signature. Double spending is the expensive case and is checked in full: every voucher id occurring more than once is reported with all its occurrences and whether the duplicates agree on the amount. Sums are added up and compared against the deposit when one is given. Limits: the on-chain channel state is only read when channel_contract is supplied AND the contract answers the common getter shape - there is no single standard for payment channels, so deposited and claimed stay null for contracts this service cannot read, and the voucher arithmetic is then reported on its own. A voucher whose signed content is not supplied cannot be verified: valid stays null with the reason, never false, because unverifiable is not the same as forged.","tags":["x402werk"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]},{"id":"payment_route","name":"Ranks the ways an agent can pay a given amount from the balances it holds against what a seller accepts, with every cost brought into USD and swaps or bridges marked as what they are.","description":"Takes what the caller holds and what the seller accepts and works out which combinations can settle the amount. All costs are brought into USD, otherwise no comparison is possible: gas on the source chain plus, where needed, the cost of a swap or a bridge. Routes that require a swap or a bridge are marked explicitly - they often look cheaper on paper and are slower and riskier in practice. Every assumption is named in assumptions; nothing is folded in silently. Limits: gas costs are ORDERS OF MAGNITUDE from a static table, not live gas prices, and that is stated in assumptions - a live gas oracle per chain is not part of this endpoint. reliability_score is NOT filled: it was meant to come from the measurement series of the facilitator monitor, and that series does not exist, so the field stays null rather than carrying a number with nothing behind it. No recommendation is forced: the ranking is by total cost, and best_by_time and best_by_cost are given separately so the caller decides.","tags":["x402werk"],"examples":[],"inputModes":["application/json"],"outputModes":["application/json"]}],"payment":{"protocol":"x402","network":"eip155:8453","asset":"USDC","recipient":"0x2880EdfFF13100677Bf97A3CBdF3Bc34771C4E5E","manifest":"https://x402.halowerk.com/.well-known/x402"}}