A second agent, and it signs for itself
Scaffolded by the BNB Agent Studio CLI, deployed, carrying an ERC-8004 identity that same CLI minted — and quoting ERC-8183 work under a signature you can check without this site’s cooperation.
Ask it for a quote
One request, no wallet and no money. The agent prices from a clamp in its own configuration — the model never prices — and signs the result with the key that owns its identity.
It is asked: “Choose which PancakeSwap v3 WBNB/USDT pool range to provide liquidity to over the next 24 hours, and say why.”
The signed envelope
recorded earlier- negotiation hash
- 0xc367212f…25af8a0b
- provider_sig
- 0x4675ae2c…c2dbbe1c
- recovers to
- 0xdEaF…3e29
- verifying contract
- 0xa206…b0deour kernel
- chain
- 97
- price
- 0.1 0xc70B…5565
Taken Sep 7, 2026, 4:20 PM and recorded at vetting/identity/studio-negotiation.json. Every other reading on this site says how old it is; an envelope with no date reads as current.
- quote stands until
- Sep 7, 2026, 4:35 PM
- delivery estimated
- 600s
- evaluator
- uma_oov3
Signed over the negotiation hash as a hex string, EIP-191. That encoding is documented nowhere and recovering the other one returns a plausible wrong address, so it is stated rather than left to be discovered.
What the signature is checked against
PASSThree of these compare the agent’s envelope against addresses this repository recovered from deployed bytecode, before the scaffold existed. Two paths that never consulted each other arriving at the same values is the corroboration; either alone is a claim.
the signer holds the identity's key
PASSprovider_sig recovers to 0xdEaF…3e29, which is the wallet that owns the identity this agent publishes
eth_account.recover_message + vetting/identity/studio-local-run.json
the signature binds to the kernel we verified
PASSverifyingContract 0xa206…b0de is erc8183.JOB_ESCROW[97], whose selectors this repository recovered from deployed bytecode
packages/misquote/registry/erc8183.py::JOB_ESCROW
the quote is denominated in the kernel's own token
PASScurrency 0xc70B…5565 is erc8183.PAYMENT_TOKEN[97], read from the kernel
packages/misquote/registry/erc8183.py::PAYMENT_TOKEN
the chain matches the registered identity
PASSsigned for chain 97, which is the chain the CLI registered the identity on
the envelope, and vetting/identity/studio-local-run.json
notify_funded — verify a funded job on chain, deliver, and submit — has not been driven through this agent, and no job has been created against the quote below.The agent itself
misquoterouter-agent
ERC-8183 seller agent (misquoterouter-agent) — negotiate + notify_funded over A2A.
negotiateSend a data part {"skill": "negotiate", "task_description": "...", "terms": {"deliverables": "...", "quality_standards": "..."}} (both terms keys are REQUIRED) and receive a wallet-signed price quote (price, currency, negotiation_hash, provider_sig). Anchor the returned envelope on-chain via createJob + fund, then send the `notify_funded` skill with the job_id to request delivery.
notify_fundedAfter you fund the job on-chain, send {"skill": "notify_funded", "job_id": <int>} to tell the seller "I funded job X — please deliver". The seller verifies the funded job carries its signed quote and replies AT ONCE with {"status": "accepted"|"rejected", "job_id"}; delivery then runs in the background (work takes time). Do NOT wait on this call for the result — read the deliverable back from the CHAIN once the job reaches SUBMITTED (the `submit` tx carries the deliverable_url; ERC-8183 `get_deliverable_url`). The agent serves no job-query endpoint.
bag deploy takes bnb, aws or azure, and none of them has been used. Running the agent is not the native-citizenship proof; the CLI deploying it is.What it will charge, and who decided
- price
- 0.1
- clamped to
- 0 – 0.2
- quote valid
- 900s
The price is fixed in configuration and clamped to [min, max] before signing. The model never prices.
Public faces: A2A. The signer is a evm-local keystore the agent holds alone.
An identity the vendor's CLI minted
Distinct from the four we registered ourselves. Those were minted by scripts/register_identity.py; this one was not minted by anything in this repository.
ERC-8004 #2102
Owned by 0xdEaF…3e29 — the wallet the envelope above recovers to.
Its card publishes https://misquote-agent.onrender.com/.well-known/agent-card.json — a registration with no resolvable endpoint is a row, and assess() refuses one.
Read back independently: ownerOf(2102) is the scaffold wallet and the tokenURI is a data: URI whose services[] endpoint is the running agent. The CLI's own word was not taken for it.
From the CLI’s own audit log
- Sep 4, 2026, 10:34 AM8004_registerclichain 97submitted
- Sep 4, 2026, 10:34 AM8004_registerclichain 97confirmed#2102
The CLI, and what it turned out to offer
This work sat parked for a fortnight on “the vendor cannot be reached”. Half true — the install page does not resolve — and no reason at all that the package cannot be installed, which nobody had checked.
@bnbagent/studio-cli
bag erc8004ERC-8004 identity (register / show / resolve / update-endpoint / update-metadatabag erc8183ERC-8183 commerce (list / buy / status / submit / fetch / settle).bag x402x402 payment client helpers.bag deployDeploy the agent after explicitly selecting a provider (bnb|aws|azure);
The full dated probe, with status codes, is at vetting/identity/studio-probe.json.
What this does not prove
The half a judge will check. Kept in the shape the ledger uses — what it would have been, why it is not, and a path to check that against.
Agent Studio deployment
bag deploy --provider bnb|aws|azure — which is the native-citizenship claim the track is about.bag erc8004 register gave it identity 2102 on chapel; and its ERC-8183 task interface is live and signs — make studio-negotiate gets a quote back whose signature recovers to the wallet owning that identity, and whose verifying contract is the kernel this repository verified from bytecode. What has not happened is bag deploy: it takes bnb, aws or azure, and running the agent on a host we already operate is not the same claim as the CLI deploying it. /studio renders all of it, this entry included.vetting/identity/ — no studio-deploy.json
The Studio agent's x402 self-funding
studio.toml declares protocols = ["A2A"] and publishes one face. The scaffold's own comment in unifiedMain.ts names the file this would take — bag x402 trust <merchant> then bag recipe code x402-buyer, emitting the tools that spread into the work hook — and that file has never been generated. The LLM credit does top itself up from the Pieverse balance, which is a different mechanism and not this one.studio/misquoterouter/app/agent/src/ — no x402Buyer.ts
A delivery driven through this agent
notify_funded: a funded job verified on chain, worked, and submit mined by the agent itself.negotiate has been called and its signature checked four ways. The other half stops before the chain, and not for the reason recorded twice before it. It is not the money — chapel has no faucet and no market for the payment token, but on mainnet it costs about twenty cents. It is the deliverable storage: submit carries a deliverable_url, the agent is configured to write one to an S3 bucket, and no S3 credentials exist in its environment. A job funded against this agent today would never reach submit at all, and the budget would lock until the 192-hour expiry. The storage is the thing to fix first, before any registration.studio/misquoterouter/.studio/ — no DELIVERABLE_S3_ACCESS_KEY_ID
The escrow this agent quotes against is the same one a job was funded and reclaimed on, with real money on BSC mainnet.