Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio, Hosted HTTPS (streamable HTTP MCP + GET twin)
Certification scope
PASS(local) — Verity independent bench of v0.1.0 (2026-10-27, trust-discovery-20261027/BENCH-REPORT.md): first bench PASS-CONDITIONAL(local) with all fail-gates PASS (real Anchor batch b18e97a2 end-to-end, forged-pointer fixture, verdict fidelity, malformed battery); condition F1 (validation verify_recipe canonicalization wording) + F2/F3 closed by delta bench — final verdict PASS. Scope: stdio + HTTP twin over the bundled join index; index recomputed from sources (Bazaar verdict feed, Herald ledger, Anchor batches/proofs, ERC-8004 publisher ledger) by a fail-closed builder. Hosted PHP twin: static parity PASS at bench; execution verified by live smoke at deploy 2026-10-27.
What it does
- Answer, in one call, whether a Cyan Eclipse bench result is real: verdict byte-verbatim with scope attached, who issued it (Verity — Cyan Eclipse Technologies), and whether it is anchored on-chain, where
- Verify a Herald receipt hash end-to-end: recomputed hash match, anchor state (ANCHORED / PENDING / FAILED / NOT_ENQUEUED) with chain, transaction, and an offline-verifiable proof bundle
- Resolve ERC-8004 Validation Registry records with the verdict and its scope inside the hashed payload — testnet records labelled TESTNET, mainnet state stated typed, never implied
- Resolve an agent (ERC-8004 id, DID, or registration URL) to its registration plus a trust summary computed from the records at call time — never a stored score
- Every answer carries a verify_recipe: the server is a convenience index, never the root of trust — callers recompute from hashes and chain data themselves
Tools
trust_statustrust_verify_receipttrust_get_bench_verdicttrust_get_validation_recordtrust_resolve_agent
Problems it addresses
- An agent holding a bench verdict cannot tell whether it is real, current, or anchored without walking four separate systems by hand
- Registries prove a server exists; nothing proves its test results — verdict, scope, and on-chain anchor must resolve in one call
Not tested
- Ed25519 batch-manifest signature verification — NOT_RUN at bench (no Ed25519 verifier in the bench environment); the bundle's hash / Merkle / calldata / block-hash chain fully recomputes, and the signature is a named verify_recipe step (Anchor anchor_verify)
- Mainnet ERC-8004 validation records — none exist yet; lookups answer typed NOT_PUBLISHED_MAINNET until the publisher's separately-benched mainnet verdict-publishing activation. Testnet records resolve labelled TESTNET
- Hosted PHP twin under the local bench — no PHP runtime on the bench VM (execution NOT_RUN); static parity PASS at bench + delta, execution verified by live-endpoint smoke at deploy 2026-10-27
Evaluation-intake listing
This listing records the tool's place in the Bazaar's evaluation
and monitoring pipeline, with the evidence gathered so far printed above — verdict, scope,
and not-tested items included. It is not sold on this site, and its presence in the catalog
is not a claim beyond that evidence. The service behind every verdict is the bench:
what a bench run buys →