Methodology

The question

Each profile answers one question for one configuration of a product: which crypto tasks can it perform, and what can it do without asking you? Products often behave differently through an app, an API, a CLI, an MCP connection or an SDK, so every answer belongs to a named configuration, never to a brand as a whole.

The first reader is someone deciding whether to give an agent access to a wallet. Developer infrastructure sits in a separate Builder tools view so it isn’t read as a consumer recommendation.

Claims and evidence

Every statement in the index is a claim about one field of one configuration: access, tasks, authority, custody and signing, approval, limits or revocation. Each claim records its support (yes, no, conditional, unknown or not applicable), its evidence status, the condition under which it holds, its limitations, the exact source sections behind it and the date it was checked.

Documented

Backed by scoped technical documentation, source code, pricing pages or terms.

Reported

Backed only by marketing, founder posts or community reports.

Unknown

The reviewed sources don’t settle it. Unknown never means no, zero, or proof that something is absent.

Conflicted

Sources disagree. Both stay cited and visible.

Not reviewed

No claim was recorded for that field in this snapshot.

Neither documented nor reported evidence proves that a product works. A model’s answer can point toward a source but is never evidence. Technical detail overrides broad marketing only for the matching version and configuration. Publication dates and retrieval dates are kept separately, an audit covers only its stated scope and version, and there are no “verified safe” badges.

Documentation, not tests

This release is built from public documentation and source code. Nothing was installed, connected, signed or traded. Every configuration records last_tested_at: null and is labelled Not hands-on tested.

Reading the documentation doesn’t establish that onboarding works, that a product is available where you are, or that a transaction will succeed. Any future testing needs a separately approved, reproducible protocol that tells read-only, simulation, testnet and mainnet results apart, and never infers a pass.

Autonomy stages

Authority is recorded per task and per configuration, as one or more stages, each with the condition under which it applies.

Stage 5 means only that a task can execute without someone approving each action. It does not mean the agent is limited, operating within limits, or safe, so the limits for the same configuration are always shown beside it.

A threshold can put one task at stage 5 below the threshold and stage 4 above it; both appear, each with its condition. Stages aren’t cumulative quality ratings. There is no brand-wide maximum, no composite score and no “safest” product. Custody and unattended scheduling are separate dimensions.

Limits, custody, approval

Limits

Status (documented enforcement, claimed, none or unknown), amount and asset, time window, recipient, contract and chain scope, the enforcement layer (onchain, wallet provider, backend, local code, prompt only or unknown), who can change the limits, and paths excluded from them. “None” needs affirmative evidence; silence is unknown.

Custody and signing

Who controls the keys, who signs, the wallet type and the custody class (custodial, self-custodial, shared control, configuration-dependent or unknown). Recovery and export appear only when evidenced. “Non-custodial” marketing alone isn’t enough.

Approval

Who approves, at which step, and who signs afterward. Delegating authority once is different from approving every action.

Revocation

Who can revoke, how, the scope, and the documented effect on pending and future actions.

Access

Availability, account and region prerequisites, supported chains, and required plans or fees. Nothing is called free when required costs are unknown.

How filters match

Task, chain and approval filters match only claims that are documented with support yes or conditional. Unknown, reported, conflicted and documented-no claims never match, and systems whose profiles are incomplete are left out of filter results and counts, even when some calibration claims are already recorded. Search covers names, configurations, setup requirements and documented tasks; without a task, chain or approval filter it also lists systems not yet profiled, labelled as such, including matches in the other view.

Every selected filter must hold for the same task in the same configuration. With a task and a chain selected, only that task’s own documented chain list counts; if the task has none, its chains are unknown and it doesn’t match, even when the configuration’s access lists that chain. With an approval stage selected, the stage must be recorded for a documented task, and for the same task that matches any selected task or chain. A chain on its own matches the configuration’s documented access chains or any documented task’s chains. Chains are matched by network id, so one network appears once in the list whatever name a source gives it. Conditional matches keep their conditions in the table.

The default view lists agent apps and connectors. Developer infrastructure lives in the Builder tools view.

Task pages apply the same rule to one task at a time: a configuration is listed only when its own documentation records that task as documented yes or conditional. Every other profiled configuration is named underneath with what its documentation does record, so an unknown stays visible as unknown.

Scope and exclusions

Covered: the systems listed under Coverage, each through one or more named configurations, as documented on the snapshot date.

Not covered: hands-on behaviour, uptime, regional availability, onboarding, pricing beyond what the documentation states, overall security posture, token prices, yields or returns. This site has no accounts, wallet connections, trading or per-visitor tracking; the aggregate page counts it keeps are described under Privacy.

Neutrality and advice

Inclusion isn’t endorsement. Systems are grouped by class and listed alphabetically within it. There are no rankings, scores, sponsored placements or affiliate links. If sponsorship is ever offered, it stays labelled and outside the evidence: it never changes findings, order or inclusion (see Sponsor).

Nothing here is financial, investment or security advice. Read the current documentation yourself before giving any agent access to funds.

Snapshot and corrections

This is a dated snapshot, not live monitoring. Products change, and a claim is only as current as its check date. Dates move only when a claim is actually re-checked. Known errors are corrected rather than left standing, and conflicted or withdrawn claims don’t match affirmative filters.

The dataset

Every page is generated from one JSON file, /data/index.json. Its structure:

Snapshot

schema_version, dataset_as_of, products[], sources[]

Product

id, name, official_url, product_type, setup_requirement, profile_status, modes[]

Configuration

id, surface, configuration, version_or_commit, claims[], last_reviewed_at, last_tested_at (always null)

Claim

id, field, value, support, condition, evidence_status, source_ids[], checked_at, limitations

Source

id, url, publisher, kind, locator, summary, retrieved_at, published_or_updated_at, version_or_commit

Dates are ISO 8601; timestamps are UTC. A missing optional field means it wasn’t reviewed.

Coverage

10 systems tracked in this snapshot, 6 profiled. Systems whose profiles are incomplete are named without a profile page and excluded from capability filters; any calibration claims already recorded for them stay in the dataset.