Self-hosted wallet strategy

Connect ownership checks to your Travel Rule policies

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.

When to trigger verification

Common trigger points include first-time transactions, amounts above thresholds defined by the regulation or internally, or when analytics tools flag elevated risk. Align the trigger with your transaction monitoring policies so customers experience a consistent flow.

Where it fits in the workflow

Outgoing transactions (withdrawals)

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

Incoming transactions (deposits)

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

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.
If they claim it was sent from their self-hosted wallet, run the verification flow before you release the funds.

Verification methods supported by CryptoSwift

Cryptographic signature proofs – Customers sign an off-chain message with their private key. CryptoSwift verifies signatures for Bitcoin, Solana, and EVM-compatible networks following CAIP-122.
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 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.

Choose an integration approach

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.

Operational considerations

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.