Verify
Reading the chain…
Nothing on this page is cached, so it is being read from BNB Chain right now.
Reading the chain…
Nothing on this page is cached, so it is being read from BNB Chain right now.
A marketplace that asks you to trust its ratings has not solved the problem it claims to solve. Below are the contracts, the evidence and the settled jobs, all read live from BNB Chain as you loaded this page — but start with the pair. Same contract, same function, same arguments except the agent id.
Stated first, in plain language, because a demo that blurs this is telling you something untrue about what it has built.
BNB Smart Chain mainnet, live
Everything Hallmark reads is real mainnet data.
BNB testnet chain 97
Everything Hallmark writes — the escrow, the evidence gate, the ratings that come out of settled jobs.
Why writes are on testnet
The evidence gate refuses to fund a job without fresh proof of life, which means the prober has to publish on the same chain the escrow reads. Running that continuously on mainnet costs real BNB per agent per sweep, on an index of three hundred thousand agents. The contracts are chain-agnostic and the addresses are in script/Addresses.sol keyed by block.chainid; the deployment is a funding decision, not a technical one.
Testnet escrow: 0x6a2E5EF3255CBbA23D66EF74a731be4605204638
Not ours. These are the canonical deployments on BNB Chain, and Hallmark is one of many readers.
BNB Smart Chainchain 56
BNB Testnetchain 97
The Identity Registry is ERC-721 based but not Enumerable — there is no totalSupply() and ids are not dense, so Hallmark finds the highest minted id by bisecting ownerOf rather than iterating.
The gap between the first number and the third is the entire thesis.
BNB Smart Chain
BNB Testnet
From 8004scan’s global stats, cached five minutes, read . Cross-check any single agent against their page for the same agent.
Both of these are calls to fund() on the same escrow, with the same selector 0xd2e13f50, made by the same address, minutes apart. The only thing that differs is which ERC-8004 agent the job declared.
fund(jobId, budget, abi.encode(2000))
↳ HallmarkHook.beforeAction(fund)
✕ revert NoFreshEvidence(2000, 0)0x8b12be6blivenessfund(jobId, budget, abi.encode(2210))
↳ HallmarkHook.beforeAction(fund)
✓ evidence 92/100, within 24h
↳ escrow funded
complete(jobId, reason)
↳ HallmarkHook.afterAction(complete)
✓ giveFeedback(2210, 100, "jobcompleted")0x6a2E5EF3255CBbA23D66EF74a731be46052046380xd2e13f50, which is fund(uint256,uint256,bytes)agentId in optParams. That is the entire difference, and it decided whether money could move.And the rating is still there — read a moment ago
getSummary(2210, [hook], "jobcompleted", "") returns (1, 100, 0) on the ERC-8004 Reputation Registry, and the hook’s own address appears in getClients(2210).
That is the point of the whole exercise: this rating exists because a job settled, not because anyone typed it. Nobody can write one without first passing the gate on the left.
Transaction hashes are configuration — a receipt does not change. The rating beside them is re-read from the Reputation Registry on every request, so if it ever disappears this page stops claiming it.
Each row shows the address, a value read from that contract just now, and the transaction that deployed it. If the middle column is empty, the read failed and we say so rather than showing a number from memory.
jobCount() / feeBps()maxEvidenceAge() / minValidationScore()isHookWhitelisted(0xcD71a680…)symbol() / decimals()Deployment transactions, in order: Deploy AgenticCommerceHooked · Deploy HallmarkHook · Allow-list the hook on the escrow · Set the evidence base URI. All in block 129,659,353.
Owner-settable, so these are read from the contract on every page load rather than written down.
# The same call the escrow makes before it moves a token.
cast call 0xcD71a680cAFb5aC1d269B5B6A90Fa0198ad78897 \
"isHireable(uint256)(bool,uint64,uint8)" 1 \
--rpc-url https://bsc-testnet-rpc.publicnode.com
false 0 0
# → funding a job for agent #1 reverts with
# NoFreshEvidence(1, 0)Read 8 Sept 2026, 08:36 UTC against agent #1 on BNB Testnet. The gate refuses it because nobody has ever published evidence for it — which is true of almost every agent in the registry, and is the gap this product exists to close.
This is the read, not the receipt
The command above evaluates the gate without spending anything. The transaction where someone actually paid gas to be told no is at the top of this page, and it is the more interesting artifact: a prediction is cheap, a reverted transaction is a fact.
Every value above was read from BNB Testnet . This page is never cached.
Every job here passed the evidence gate before its tokens were escrowed. The counter cannot be inflated by a listing — only by a funded transaction.
| Job | Status | Agent | Budget | Client | Provider |
|---|---|---|---|---|---|
| #3 | Funded | #2210 | 2 $U | 0x4033…7EDE | 0x38c6…08dA |
| #2 | Completed | #2210 | 0.5 $U | 0x9ff9…09ab | 0x38c6…08dA |
| #1 | Open | — | 0.5 $U | 0x9ff9…09ab | 0xc08C…2256 |
Read from getJob() on the escrow and jobAgent() on the hook, 8 Sept 2026, 08:36 UTC.
Each one is an ERC-8004 record on BNB testnet. The hash beside it names a canonical document served at a public URL — fetch it, hash it, and you should get the same value back.
How to check one
An evidence bundle is content-addressed: its name is the keccak256 of its own canonical JSON, and that hash is what goes on-chain as responseHash or feedbackHash. Fetch the bytes from /api/evidence/<hash>, canonicalise, hash, compare. If it does not match, the attestation is worthless and you have just proved it.
The route serves the stored bytes verbatim and refuses to serve a document that fails its own integrity check, so a mismatch means the chain and the document disagree — not that the server reformatted something.