The data

Everything on this site is generated from /data/index.json (80 KB), served byte for byte as recorded. It covers 10 systems: 6 profiled systems with 7 configurations, and 4 systems not yet profiled.

SHA-256 of this snapshot: cd278dff89e10f8b62b37ac195d6bdb97d94789ddc9b2236e24e2091ffed84e7

It is a static file. There is no query API, no MCP server and no live endpoint for this index.

What a claim means

Each configuration (modes[]) holds claims about one field each: access, tasks, authority, custody, approval, limits, revocation.

support: yes, no, conditional, unknown or not_applicable. Task items can carry their own support, which overrides the claim’s.
evidence_status: documented (technical docs, source code, pricing or terms), reported (marketing or community only), conflicted or unknown.
condition: When the claim holds. conditional support means conditions apply; keep them with the claim.
limitations: What the claim does not establish. Report them alongside it.
source_ids, checked_at: The sources behind the claim, listed in sources[] with retrieval dates, and the date the claim was checked.

Unknown never means no. An empty chain_ids list means a task’s chains were not reviewed, not that it supports none. A missing field means not reviewed. Approval stages run 0 to 5 per task; integrator_defined is its own value, never a number, and an explicit unknown stage is recorded on purpose.

Matching like this site

Use only products whose profile_status is documented and that have at least one mode. Anything else, including a pending product that already carries calibration claims, is not profiled and never matches.
A task counts only when its tasks claim is documented with support yes or conditional, and the task item’s own support (falling back to the claim’s) is yes or conditional. An item-level evidence_status, when present, must also be documented.
Match inside one mode. A task, a chain and an approval stage must all hold for the same task item in the same configuration.
For a task with a chain, use only that item’s own chain_ids. Never fill an empty list from the access claim’s chains.
An approval stage counts only when a documented yes/conditional authority claim records it for that same task. unknown stages never match.
A chain on its own matches the access claim’s documented chains or any documented task’s own chains.
Whenever you report stage 5, report the same mode’s limits claim with it, including every excluded path and limitation.

Task ids in this snapshot: read_balance (Check a wallet balance), prepare_transaction (Prepare a transaction), execute_transaction (Carry out a transaction), pay_for_service (Pay for a service). Each task page applies this rule and links to the same filter in the comparison.

What this is not

This is a dated documentation snapshot. Nothing was installed, connected, signed or traded; every configuration records last_tested_at: null. The site doesn’t execute wallet actions, doesn’t run or install an MCP server, doesn’t monitor products live and doesn’t recommend, rank or score anything. Products change after checked_at; read their current documentation before acting.

Other files

/feed.xml: Atom feed of web updates. Works without email.
/llms.txt: An optional plain-text index of these pages for language-model tools. It’s a convenience only and doesn’t affect search ranking.
/sitemap.xml: Every public page.

Citing a claim

Quote the claim’s id, its checked_at date and the source URL it cites, and keep its condition and limitations with it. Profile pages anchor every claim at /tools/{product id}/#claim-{claim id}.

For agents and developers