Self-Hosted Wallet
The following documentation provides an overview of self-hosted wallet verification and its role within Ospree’s compliance framework. It explains what self-hosted wallets are, why they matter from both a regulatory and operational perspective, and how institutions can apply controls to mitigate the risks associated with transfers involving these wallets. It also outlines the methodology behind Ospree’s approach and its alignment with relevant regulatory expectations.
For technical API details on wallet control verification, please refer to the following section
What Is a Self-Hosted Wallet?
A self-hosted wallet is a software or hardware wallet in which the user retains sole control of the private cryptographic keys used to access, manage, and transfer digital assets.
In regulatory materials, self-hosted wallets are also commonly referred to as unhosted wallets, non-custodial wallets, or private wallets. In each case, the defining characteristic is the same: no third-party institution holds the user’s assets or controls the wallet on the user’s behalf. FATF describes unhosted wallets as wallets in which the user maintains exclusive control of the access keys.
Self-Hosted vs. Hosted Wallets
The core distinction lies in the presence of an intermediary. Hosted wallets are managed by a third-party service provider or CASP that is responsible for enforcing anti-money laundering and counter-terrorist financing (AML/CFT) controls. By contrast, self-hosted wallets are controlled entirely by the user, enabling direct peer-to-peer transactions without the oversight of a regulated intermediary or other obliged entity. The table below provides a comparison of both.
Self-Hosted Wallet
Hosted (Custodial) Wallet
Basic model
Works like a personal safe or cash wallet, with the user controlling the assets directly
Works like a traditional bank account, with a provider holding and safeguarding the assets
Private key control
The user controls the private keys
The institution controls the private keys
Access and recovery
Access depends on the private key or seed phrase, with no central recovery option
Access is typically through username and password, and the provider may help recover access
Intermediary and support
No middleman and no customer support for wallet recovery
Involves a third-party provider and usually includes customer support
Identity and examples
Can often be created without identity verification; examples include MetaMask, Trust Wallet, Phantom, Ledger, and Trezor
Usually linked to an account with onboarding; examples include Coinbase, Kraken, and Binance
Why Self-Hosted Wallets Matter for Compliance
Self-hosted wallets are relevant from a compliance perspective because they may be created and used without customer due diligence at the wallet level. This can make it more difficult for regulated firms to identify the true counterparty to a transfer and assess associated risks, including money laundering, terrorist financing, sanctions evasion, and fraud.
FATF identifies peer-to-peer transfers involving unhosted wallets as a key vulnerability because these transfers can occur without the involvement of an AML/CFT-obliged intermediary. FATF also notes that such transfers may present higher risk, particularly when layered through multiple unhosted wallets or conducted across borders.
Common Verification Approaches
Regulators and industry guidance recognize that more than one method may be used to assess control of a self-hosted wallet. The appropriate method depends on the asset, jurisdiction, technical environment, and risk profile.
Verification Method
Description
Notes
Cryptographic message signing
The customer signs a specific message using the private key associated with the wallet address.
Strong evidence of control where technically supported.
Micro-transfer verification
The customer sends a small predefined amount of digital assets from the wallet.
Sometimes referred to as a “Satoshi Test.”
How Ospree’s Solution Works
Ospree uses CAIP-122 to support a secure and standardized wallet verification flow based on message signing. CAIP-122 extends the Sign-In with Ethereum model into a chain-agnostic Sign-In with X format, allowing the same verification method to work across multiple blockchain networks.
Through this process, a user can prove control of a wallet address at a specific point in time without exposing the private key or moving funds. The wallet signs a structured, human-readable message containing elements such as the domain, wallet address, nonce, and timestamp.
This approach is secure because the private key remains in the wallet and is never shared. The use of a nonce and timestamp helps prevent replay attacks, while the standardized format creates a reliable and auditable record of verification across supported blockchains.
Control, Not Ownership
In the blockchain environment, an address acts as the public identifier for funds, while a wallet is the underlying software or hardware that manages the private keys. In practical terms, an address is controlled by whoever currently holds its corresponding private key and can authorize transactions.
While the CAIP-122 standard allows us to cryptographically verify that a customer currently controls a wallet, and by extension the assets at that address, this cryptographic proof of control does not automatically equate to legal ownership. That is why we bind the proof to KYC and apply risk-based safeguards.
Ospree Step-by-Step Verification
Send Request
Ospree generates a secure challenge Ospree’s system instantly creates a unique, standardized CAIP-122 message for the customer to sign. To prevent fraud and replay attacks, this message is tightly controlled through:
a specific domain, proving the signature is intended exclusively for Ospree
a nonce, which is a one-time randomized value ensuring the message cannot be reused
strict timestamps, ensuring the request is fresh and has not expired
a clear statement, such as: “I confirm I control this address for Travel Rule verification”
Save Record
Creating the audit-ready record To turn this technical step into a meaningful compliance event, Ospree binds the cryptographic proof directly to the customer’s verified identity record. It then generates a permanent, audit-ready trail that includes:
the verified customer identifier and session context, such as MFA logs
the exact message payload and resulting signature
precise timestamps and the final verification outcome
any risk signals detected at the time of verification
Regulatory Guidance
European Banking Authority. (2024). Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under Regulation (EU) 2023/1113 ('Travel Rule Guidelines') (EBA/GL/2024/11).
European Parliament and the Council of the European Union. (2023). Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets and amending Directive (EU) 2015/849 (recast). Official Journal of the European Union, L 150/1.
Financial Action Task Force. (2026). Targeted report on stablecoins and unhosted wallets - Peer-to-peer transactions. FATF. https://www.fatf-gafi.org/content/fatf-gafi/en/publications/virtualassets/targeted-report-stablecoins-unhosted-wallets