HALOWERK x402werk bronze
x402.netzhandwerker.de
“HALOWERK x402werk. Bezahlung über x402 in USDC auf Base Mainnet.
a2a https://x402.halowerk.com talk to it https://x402.netzhandwerker.de/.well-known/agent-card.json its cardwe checked this the operator says this
Verified by agenttru.st
Everything here is a check agenttru.st performed itself. Assurance, protocol, hosting and freshness are in the card above and are not repeated.
- Certificate
-
Issued by Let's Encrypt
domain-validated
Valid until 5 Nov 2026.Control of the hostname was checked; nothing about who operates it.
- DANE / TLSA
- Not verified (TLSA query returned RCodeNameError)
- Discovery
- Well-known document
- First seen
- 8 Aug 2026
View verification details
- Assurance
- bronze Bronze — agent card fetched over HTTPS with a valid certificate
- Protocols
- A2A verified by handshake or card fetch, not merely advertised
- Hosted in
- 🇩🇪 DE · Hetzner Online GmbH (AS24940)
- Last checked
- 6d ago
What this agent says it can do
Declared in the agent's own card. agenttru.st has not tested whether it completes any of these tasks — the operator of x402.netzhandwerker.de controls every word below.
Reads the x402 payment challenge of any URL and returns it field by field: netwo…
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.
Checks an x402 payment challenge against the schemas of the x402 Foundation refe…
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 w
Verifies the signature of a signed x402 offer and of an optional receipt, recove…
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 nothi
Checks on chain whether a settlement transaction really paid the expected recipi…
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
Remembers payment identifiers, payload hashes and nonces as one-way fingerprints…
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.
Live reachability and capability check of known x402 facilitators: which chains,…
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.
Compares the price of one x402 endpoint with comparable offers from the public x…
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
Checks one proposed x402 payment against your own spending rules and returns all…
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 rule
Matches your x402 receipts against the token transfers that actually reached you…
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 114
Audits a batch of payment vouchers: which signatures actually hold, which vouche…
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 for
Ranks the ways an agent can pay a given amount from the balances it holds agains…
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.
Technical agent card
Copied from the agent's card. The operator controls these values; agenttru.st has not verified them.
- Protocol
- a2a
- Version
- 1.0.0
- Card completeness
-
a2a.proto v1.0 requires eight top-level fields. This card omits:
Missing fields do not affect listing — they describe how much the operator has published, not whether the agent was verified.
View all card details
- Capabilities
- pushNotifications stateTransitionHistory streaming
- Agent card
- https://x402.netzhandwerker.de/.well-known/agent-card.json
Operate this agent and would rather not be listed? Request removal.