Self-hosted wallet strategy

Self-hosted wallet verification confirms that:

• in case of withdrawals, the customer controls the destination address before you proceed with a withdrawal, or
• in case of deposits, the customer controls the origin address before you release funds to them.

Regulations such as MiCA require transaction value based controls for transactions involving non-custodial wallets.

1. Collect the intended withdrawal details (asset, amount, destination wallet).
2. Decide whether the withdrawal qualifies for a self-hosted wallet check based on your policy.
3. Run the verification flow before you move funds, and store the result alongside the pending transaction.
4. Continue with the post-transaction or pre-transaction Travel Rule workflow once ownership is confirmed, or escalate if verification fails.

When receiving a deposit without a Travel Rule message, you can apply (depending on your internal AML policies) the following logic:

1. If the deposit is above an internally defined threshold (for example, amount or risk score), ask the customer for the origin of the funds: a. Sent from another exchange - the customer can also enter the sender's name and exchange; use the backfilling workflow to capture the missing data. b. Sent from their self-hosted wallet.
2. If they claim it was sent from their self-hosted wallet, run the verification flow before you release the funds.

• Cryptographic signature proofs – Customers sign an off-chain message with their private key. CryptoSwift verifies signatures for Bitcoin, Solana, EVM-compatible networks following CAIP-122 and more.
• Micro transactions (Satoshi Test) – Customers send a small deposit from the destination wallet within a 48-hour window. CryptoSwift monitors supported blockchains (Bitcoin, Ethereum, Dash, Litecoin, Dogecoin and more) and flags success automatically.
• Wallet videos and screenshots – Customers upload evidence from their wallet application for manual review.
• Self-declaration – Customers tick a checkbox declaring ownership. It is the least secure option but useful as a fallback when stronger evidence is unavailable.

You can find a detailed list of supported blockchains per verification method here

Wallet verification can include additional customer steps after the ownership check. CryptoSwift currently supports a combined Source of Funds / Source of Wealth document request as part of the same widget workflow. The additional step has its own review status, independent from the wallet ownership result, so your policy should decide whether both results must be accepted before funds are released or a withdrawal proceeds.

See Additional Steps for the request format, status lifecycle, widget sequence, evidence endpoints, and manual review behavior.

• Wallet verification widget – Embed a configurable web component or redirect to a hosted flow with minimal engineering effort. Ideal when you want a managed UX and rapid rollout.
• Wallet verification API – Orchestrate verification completely within your app, combining your own UI with CryptoSwift endpoints for maximum flexibility. Useful for mobile-first or highly customised experiences.

• Store verification results with transaction metadata so auditors can confirm when proofs were obtained.
• Reuse successful verifications according to your risk policy (for example, accept the same wallet for 12 months unless risk scores change).
• Ensure webhook events are routed to the systems that update withdrawal status—verification outcomes arrive alongside Travel Rule notifications.

• Wallet verification widget
• Wallet verification API
• Additional steps
• Compliance workflows

• Custodial vs self-hosted wallets
• CryptoSwift Compliance Documentation