#bitcoin wallets for

Explorer V3

The following is a visual representation of the version 3 WalletMatrix schema. It contains cross-referenced and linked information describing the type of information to be included in each block as well as a rationale explaining what each one should be used for.

Select a link in the schema below and be taken to a full explanation of it on the right-hand side.


  " version [a] ": "3.0",

  "organisation": {

    "name": "Acme Co",

    "web": "https://acme.app/",

    "email": "media@acme.app",

    "location": "New Zealand",

    " established[b] ": "2017-01-01",

    "socials": [] [c] ,

    "soft": [] [d]


  "wallets" [e] : [


      " name [f] " : "acme model 1",

      " web [g] ": "https://shop.acme.com/products/acme-model-1",

      " uuid [h] ": "D48869A0-759E-45D1-ABDF-E5339DE38E70",

      "features": {

        " currencies [i] ": [],

        " wallet_types [j] ": [],

        " security [k] ": [],

        " privacy [l] ": [],

        " languages [m] ": [],

        " custodial [n] ": "N",

        " license [o] ": [],

        "multisig[p]": "N",

        "testnet[q]": "N",

        "batchtx[r]": "N",

        "fio[s]": "N",

        "form_factor[t]": "mobile",

        "custom_node[u]": "Y",

        "rbf[v]": "?",

        "psbt[w]": "?",

        "reproducible_builds[x]": "?",

        "hd[y]": "Y",

        "sna[z]": "Y",

        "fee_estimation[aa]": "?",

        "fee_control[ab]": "?",

        "hardware[ac]": [],

        "lightning[ad]": [],

        "refill[ae]": [],

        "validation[af]": "spv",

        "platforms[ag]": [


            "name": "ios",

            "github": "https://github.com/acme-wallets-inc",

            "download": "https://shop.acme.com/pages/acme-model-1",

            "language": "Golang"



        "coin_control[ah]": "?",

        "tx_labelling[ai]": "?"





[a]NOT TO BE MODIFIED. Used internally by WalletMatrix for import validation. Represents the version of the WalletMatrix schema in-use by this instance of matrix.json.

[b]The date at which the vendor/company was first active in the Bitcoin wallet space.

[c]An array of objects each of which representing  single social media account with x2 keys: "type" e.g. "linkedin" and "slug" e.g. "acmewallet".

[d]Each object can have one of two keys "data-retention-policy"  - the URL of an applicable web-page where data-retention policies live and "product-support" - an email address intended for support requests to be sent.

[e]An array of objects, each of which represents a wallet and its features. These data form the bulk of the data available for search and display within WalletMatrix. Multiple wallets may be included. This may be useful if for example a single github repo represents a codebase powering two different wallet apps such as a Desktop and Smartphone app.

[f]The name of the wallet as displayed in matrix search results.

[g]The main website of the wallet. Used when "name" is displayed as a link.

[h]NOT TO BE MODIFIED. A unique wallet identifier. Initially generated by and used internally by WalletMatrix. It may also be generated by vendors via the REST API if creating a wallet entry from scratch.

[i]An array of objects. Describes the full range of currencies and coins able to be managed or displayed in any UI. Comprises "type" and "ticker" keys where "type" is one of: "crypto", "stablecoin" or "fiat". Will be replaced with separate "coins" and "currencies" blocks in v4.

[j]An array of "internal" wallet-types. The kinds of accounts/wallets that can be setup within the app or device itself. Possible values are: "on-chain", "brd", "lightning", "single-address" and "watch-only"

[k]An array of security-related features. Acceptable values are:

* "fake-wallet": Provide an easy to access wallet with a minimal balance to palm-off onto attackers

* "pin-on-wallet": Wallet can be configured with a PIN in order to obtain access to any functionality

* "pin-on-tx": Wallet can be configured with a PIN in order to perform any payment

* "encrypted-password": For wallets using a PIN or password for access, these are encrypted at rest within the app/device

* "dust-protection": Provide a means for wallet users to consolidate minute UTXOs without sending them to a single address

* "scrambled-pin": For wallets offering a PIN entry - digits are ordered differently on each display.

* "2fa": Wallets offer MFA/2FA app or device authentication

* "keyless": Wallet does not use or store a private key. It uses some pattern that follows Shamir's secret sharing.

* "touch-id": The app or device allows users to configure fingerprint-only access.

* "login-countdown": Any PIN or login screen gives a limited time for a successful login to occur.

* "brick-pin": Allow users to type a specific PIN which bricks the app or device, rendering it useless to anyone.

* "face-id": The app or device allows users to configure access via facial recognition

"remote-wipe": Users can wipe the device of any PII or addresses from a remote location.

* "withdrawal-limit": Wallet imposes a limit on the amount of funds able to be sent from a wallet or account.

[l]An array of privacy-related features. Acceptable values are:

* "tor": Transactions can be sent and received over Tor either natively or through an approved add-on

* "coinjoin": The wallet provides a coin-join or coin-mixing feature

* "custom-node": See "custom_node". (The former will be deprecated)

* "offline": Transactions be sent or received "offline" e.g. via Satellite, Mesh Network or SMS

* "paynym": Provides customised BIP47 re-usable payment codes (Deprecated in v4)

* "vpn": Transactions be sent or received over a native VPN connection or one provided as a recommended addon.

* "no-signup": The wallet requires no email address, ID or other PII to be registered with a 3rd party. These data are never requested.

[m]An array of objects with a single key "iso6392" as a list of all the 2-char iso6392 language codes the wallet UI supports.

[n]Could any part of the wallet be considered to be custodial? (You can check using the WalletScrutiny tool) One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[o]An array of strings representing the software licsense(s) for all components of the wallet: Apache 2.0, AGPL 3.0, GPL 2.0, GPL 3.0, LGPL 2.1, LGPL 3.0, BSD 2 Clause, BSD 3 Clause, MPL 2.0, CDDL 1.0, EPL 2.0, MIT, MS-PL, MS-RL, Unlicense, Beerware.

[p]Does the wallet support base-chain multi-signature transactions? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[q]Does the wallet support testnet on the base-chain? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[r]Does the wallet support batch transactions? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[s]Does the wallet support components of the FIO protocol, in whole or in part? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[t]What is the eventual/target form-factor for the wallet?  One of "mobile", "hardware", "desktop", "wearable"

[u]Can users connect the wallet to a bitcoin node of their choosing? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[v]Does the wallet support RBF? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[w]Does the wallet support partially signed bitcoin transactions? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[x]Do wallet maintainers provide sufficient instruction to allow end-users and researchers to reproduce builds? Note: All android wallet versions are run through the WalletScrutiny service which clobbers the user-defined value. One of "Y","N","?","P". (Yes, No, Unknown, Planned).

[y]Does the wallet support hierarchical deterministic address generation? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[z]Dos the wallet support Segwit Native Addresses (Bech32)? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[aa]Does the wallet support an automated fee estimation feature? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[ab]Does the wallet permit users to manually control the fee is some way? One of "Y","N","?","P". (Yes, No, Unknown, Planned)

[ac]An array of strings representing hardware wallet features. Possible values are:

* "u2f"" The hardware device adheres to the universal 2nd factor standard

* "touch-screen": Device operation is achieved predominantly through a touch screen

* "desktop-app": Device users can connect the device to a desktop application provided either by the vendor or 3rd parties

* "secure-element": The device stores sensitive data such a private keys in a specially designed chip that is resistant to common side-channel attacks.

* "backup": The device provides some means to generate a data backup of accounts/wallets some form of removable storage for example.

* "mobile-app": Device users connect the device to a smartphone application provided either by the vendor or 3rd parties

* "camera": The device comprises a camera for use with QR codes for example.

* "ble": The device support the Bluetooth Low Energy standard for data-transmission.

* "air-gapped": The device contains no means of remote access through USB, BLE or WIfi. The primary means of transitioning signing is therefore through PSBT for example.

[ad]An array of strings representing lightning wallet features. Possible values are:

* "auto-liquidity": The wallet provides automatic incoming liquidity to aid opening a channel.

* "routing-node": The wallet can also be used as a Lightning Network routing node.

* "testnet": The wallet supports development while running on the Lightning Test Network.

* "pos": The device can double as a Point of Sale device.

* "custom-node": The wallet can be connected to a Lightning Node of the user's choosing.

* "lnurl": The wallet supports at least one of the 5 LNUrl features.

[ae]An array of strings representing the ways in which users can purchase bitcoin from within the wallet. Possible values are:

"apple-pay", "google-pay","debit-card","credit-card","wire-transfer","bank-transfer","fastbitcoins".

[af]The primary way in which the wallet validates transactions. One of:

* "spv": The device performs local and partial transaction  validation via SPV (Simple Payment Validation)

* "full": The wallet performs local full transaction validation of its own

* "neutrino": The device performs local and partial transaction validation via Neutrino

* "via-own-servers": The wallet performs full validation via a full-node hosted on servers that it or its maintainer runs

[ag]An array of objects, one for each complete wallet codebase that builds or provides for a single wallet implementation on a single operating system. "platforms" will be deprecated in v4 given that multiple wallets are now permitted.

"name": The name of the platform e.g. "ios". (Not used)

"github": The github.com repo URL for the codebase. Used for validation during import

"download": The play or app store URL were the wallet can be downloaded or purchased. Used to support clickable app-store icons

"language": The main programming language used in the codebase e.g "Java" (Not used)

[ah]Does the wallet give users the ability to choose which UTXOs should comprise a payment?  One of "Y","N","?","P". (Yes, No, Unknown, Planned).

[ai]Does the wallet provide a means for labelling transactions?  One of "Y","N","?","P". (Yes, No, Unknown, Planned).