The wallet register method
How is the wallet register built?
30 wallets are on the register. 23 make a custody claim in their marketing, and each claim is tested against the binding document. 26 name a company in their terms, and 95 sub-service clauses are recorded across them. 8 have a primary-source incident recorded. No score is published on this register.
Documents last checked Reviewed by CryptoGuardz Register Desk, editorial desk
A wallet does not hold your coins, which is what makes it easy to write about badly. The question worth asking is not whether the keys are yours. It is what else is in the app, who the counterparty is for each of those things, and what the binding document says when the marketing and the help centre disagree with each other.
What goes on the register
A self-custody wallet is included where it is distributed to retail users, holds keys on the user’s device by default, and publishes terms that could be retrieved. There are 30 entries, ordered by how far the binding document falls short of the product it binds.
What custody means in a terms document
Three separate things are recorded, and the register never lets one stand in for another.
The first is the marketing claim: the words the company uses about custody on the pages a prospective user reads, quoted with the URL and the date. 23 of the 30 make a custody claim in their marketing. The count is computed from the language in the recorded quote and not from the presence of a quote, because an earlier version counted any marketing sentence and turned a slogan about security into a custody claim nobody had made.
The second is the position the binding document takes, quoted from the terms themselves. Marketing copy is not a contract term. A sentence on a product page saying the company never holds your keys binds nobody, and where the terms say something narrower, weaker or nothing at all, the entry prints both and says which one you would be arguing from.
The third is what the help centre describes as actually happening, which is frequently a third position. Where a cloud backup or social recovery option changes who holds key material, that is recorded as a change of custody with the company’s own documentation quoted for it, and never on reputation. 3 of the 30 entries record such a mechanism.
Why the sub-service terms are read
The swap, the staking product, the fiat on-ramp, the bridge, the marketplace and the default node provider are separate services, each with a counterparty, each governed by terms a user never opens and often never sees named. 95 such clauses are recorded across 29 of the 30 wallets, covering 6 kinds of service: swap, on-ramp, staking, node-provider, bridge, nft-marketplace.
They are counted as recorded clauses rather than as distinct companies. Two clauses can name the same counterparty and still be two separate things that counterparty is permitted to do. Where the terms identify the counterparty only as a third party, that is what the entry records, because the inability to name who you are dealing with is the finding.
186 further clauses are quoted across the register on interface termination, address blocking, geographic restriction, data sharing, liability limitation, unilateral amendment and arbitration. A power over an address is tracked in two separate columns: whether the wallet claims one itself, and whether it discloses that somebody else in the stack has one. 0 of the 30 claim the power and 1 disclose that a third party holds one.
What is not measured
No code has been audited and no binary has been reverse engineered. Nothing here establishes that a wallet does what its documents say, only what its documents say. A wallet that describes itself accurately and behaves otherwise would read well on this register, and that is a limit of a documentary method rather than a finding about any entry.
Nothing here measures security, key-generation quality, supply-chain risk, phishing exposure or the safety of any chain, token or Dapp the wallet reaches. No entry counts user reviews, app-store ratings or download volume, and no entry records a recommendation.
Where a column reads no, check whether a search for the opposite is recorded on the entry. On this register a denial published in the terms and an absence of any clause on the point are different findings, and the entry names which one it found.
Why there is no score
There is no score on the wallet register and there is not going to be one until there is something to compute. With 30 entries and no measured quantity anywhere in the dataset, a score would be a weighting of things nobody has agreed how to weigh. A liability cap, an unnamed swap counterparty and a cloud backup that moves key material are three different risks to three different users, and flattening them into one number would tell a reader less than the three rows already do.
A score is a claim that the things being compared differ along one measured dimension by a stated amount. Nothing in this register supports that claim, so a number here would be a measurement nobody made, dressed as one somebody did. The register publishes the fields instead and lets a reader weigh them, which is the part a single figure removes.
No Review, Rating or AggregateRating markup is emitted on any page in this section either, because none of those describes what is on the page.
How an absent value is written
| Token | What it means | On this register |
|---|---|---|
| Not measured | The measurement is in scope and we have not made it yet. The gap is ours. | Used for anything requiring a code audit or a running device, which this method does not do. |
| Not applicable | The concept does not fit this kind of entity at all. Reserved for a type mismatch, never for a count of zero. | Reserved for a field that cannot apply to a self-custody wallet, such as a reserve attestation. |
| Not disclosed | The company publishes nothing on the point. The gap is theirs and it is a finding about them. | Used where the terms are silent, including where no company name appears in the binding document at all. |
| No data | We looked and either nothing exists or nothing would load. The gap is in the record. | Used where a document or help-centre page could not be retrieved on the date recorded. |
Corrections
If an entry about a wallet is wrong, send the primary source that corrects it to the address on the contact page. A correction needs the document, not a request: a link to the clause, the register row or the page that shows the recorded value is not what it was on the date we read it.
Corrections are published with their date at corrections, and the original value stays visible rather than being edited away. A change to what an entry records about a company is logged at the change log on the day it is made. A register whose history can be rewritten quietly is not a register.
Commercial disclosure
CryptoGuardz holds commercial affiliate relationships with 3 of the 24 operators on the casino register, named in full at the disclosure page and named again on every page that carries one of them. Being paid through them is the intended model rather than a description of the current build: no outbound link here carries affiliate tracking yet. No wallet on this register is a commercial partner, no page in this section carries an affiliate link, and no wallet publisher has been given sight of an entry before publication. No commercial relationship is an input to anything computed on this site, and the build rejects a data file that tries to set a derived value by hand.
The data
Every field is published as a CSV with its columns and its known gaps at the data page, and the entries are at the wallet register.