Building Self-Custodial Wallets in a Travel Rule World: UX Challenges

General
1

As someone who’s been building wallet infrastructure for five years, I can tell you: the Travel Rule is the biggest UX challenge we’ve faced since seed phrases.

When regulators announced enhanced due diligence for self-custodial withdrawals, our support tickets tripled. Users don’t understand why their “own money” suddenly requires proof of ownership. Let me walk through what this looks like from a wallet developer’s perspective.

The Current State: Friction Everywhere

Here’s a real user flow from March 2026:

  1. User buys ,000 USDC on Binance
  2. Tries to withdraw to their MetaMask address
  3. Binance flags it: “First-time withdrawal to self-custodial wallet, verification required”
  4. User must either:
    • Sign a message with their MetaMask private key to prove ownership
    • Complete a test transaction (Binance sends , user confirms receipt)
    • Wait 24-48 hours for manual review

If the amount is above €1,000, add:

  • Proof of address for wallet ownership
  • Screenshot showing wallet balance
  • Additional identity verification if the wallet has interacted with flagged addresses

This is a UX disaster. Most users don’t know how to sign messages with their private key. They don’t understand why they need to prove they own a wallet they just created. And the 24-48 hour hold? Completely kills the “instant” promise of crypto.

What Wallets Are Doing to Adapt

Account Abstraction (ERC-4337)

Smart contract wallets can automate compliance verification:

  • Generate ownership proofs automatically when requested by VASPs
  • Support multi-sig verification that satisfies regulatory frameworks
  • Embed compliance modules for selective disclosure

But gas costs are higher, adoption is still early, and most exchanges don’t support smart contract wallet deposits yet.

Whitelisting Systems

Some wallets now let users “register” addresses with exchanges in advance:

  • Submit proof of ownership once
  • Whitelist approved addresses
  • Future withdrawals to whitelisted addresses have reduced friction

Problem: 7-day waiting periods for new whitelisted addresses defeat the point of instant transfers.

Zero-Knowledge Proofs for Ownership

This is where I think we’re headed. Instead of revealing your transaction history to prove ownership, you generate a zkProof:

  • “I control the private key for address 0x123…”
  • “This wallet was created on [date]”
  • “This wallet has never interacted with sanctioned addresses”

The exchange verifies the proof cryptographically without seeing your full transaction history.

But: No standardization yet. Each VASP wants different proofs. There’s no universal “wallet ownership certificate.”

Design Principles for Compliance-Friendly Wallets

After 100+ user interviews, here’s what we’ve learned:

1. Hide complexity, not functionality
Users don’t care how ownership verification works—just that it’s fast. Auto-generate signed messages in the background.

2. Progressive disclosure
Don’t scare new users with compliance warnings upfront. Show verification requirements only when triggered.

3. Clear explanations in plain language
“Your exchange needs to verify you own this wallet for amounts above ,000” beats “Enhanced due diligence per FATF Travel Rule.”

4. One-tap verification flows
Reduce multi-step processes to single actions wherever possible. “Tap to verify ownership” instead of “Export private key, sign message, copy signature, paste into form.”

5. Educational content at the right moment
Explain why verification is required, not just what to do. Users accept friction better when they understand the rationale.

The Trade-Offs We’re Making

Every compliance feature we add creates tension:

  • Gas costs increase with smart contract wallets
  • Complexity grows with zkProof integration
  • Privacy decreases when linking wallets to identity
  • Decentralization suffers if verification requires centralized services

As wallet developers, we’re walking a tightrope: Make it compliant enough that VASPs accept it, but usable enough that normal people can actually use it.

My Ask to the Community

To regulators: Please standardize verification requirements. Every VASP implementing their own system creates chaos.

To VASPs: Work with wallet developers. We can build better verification flows if you tell us what you actually need (not just what the law requires).

To users: Be patient. This is messy right now, but we’re working on solutions that will make compliance invisible.

I think we can build wallets that are both compliant and user-friendly—but it requires collaboration, not adversarial finger-pointing.

What verification UX have you experienced? What worked, what was terrible?

For wallet devs: ERC-4337 Account Abstraction

2

Will, this is EXACTLY the kind of thing I think about when building UIs. The technical solution might work, but if users can’t figure out how to use it, it doesn’t matter.

A recent horror story from my side:

I was onboarding a new team member to our DeFi protocol’s testnet. She’s a designer, not a developer, but totally competent with Web2 apps. I told her: “Just withdraw some test USDC from Coinbase to your MetaMask.”

30 minutes later, she’s still stuck because Coinbase asked her to “sign a message to verify wallet ownership” and MetaMask’s signature UI looked like a hex dump of random characters. She thought it was a phishing attempt and closed the tab.

This is a UX failure at every level:

  • Coinbase didn’t explain why signing was required
  • MetaMask showed raw hex instead of human-readable message content
  • No clear “this is legitimate, not a scam” indicator
  • Zero guidance on what happens after signing

I ended up having to screen-share and walk her through it. If a designer at a Web3 company struggles with this, how are we expecting mainstream users to handle it?

What I’d love to see:

  • Wallet partnerships with VASPs: Pre-authorized signature flows where MetaMask + Coinbase have a trust relationship, so verification is one-tap
  • Human-readable message signing: Show “Coinbase is verifying you own this wallet” instead of “Sign: 0x4f776e6572736869705665726966696361…”
  • Progressive onboarding: First withdrawal is small amount, no verification. Second withdrawal, explain compliance. Third withdrawal, automate it.

Your point about “hide complexity, not functionality” is perfect. We need to learn from Web2 onboarding—nobody explains OAuth flows to users, but everyone can “Sign in with Google.”

Can we build “Sign in with Wallet” for compliance? Or is that too centralized?

3

Will, I appreciate the constructive framing here. Too often these conversations devolve into “regulation bad, freedom good” without acknowledging the real-world constraints. :clipboard:

What regulators actually want from wallet providers:

First, clarity: Wallet software developers are NOT VASPs under most current interpretations. You’re not holding customer funds or facilitating transactions—you’re providing tools.

The Travel Rule burden falls on VASPs (exchanges, custodians), not wallet apps. But VASPs are requiring proof from wallet users to satisfy their own compliance obligations, which creates the UX friction you’re describing.

What would help:

  1. Standardized proof formats
    Right now, Binance wants X, Kraken wants Y, Coinbase wants Z. If FATF or national regulators would publish a standard “wallet ownership attestation” format, everyone could implement it once.

  2. Safe harbor for good-faith compliance efforts
    Wallet developers shouldn’t face regulatory risk for building compliance features that later turn out to be “not quite right.” Regulators should encourage experimentation, not punish it.

  3. Recognition of zkProof systems
    If wallet developers build zero-knowledge ownership proofs that satisfy Travel Rule requirements, regulators need to explicitly approve them. Otherwise VASPs won’t accept them.

  4. Whitelisting = acceptable compliance
    Some jurisdictions are moving toward “if a user pre-registers a wallet with proof of ownership, future transactions to that wallet are low-risk.” This should be formalized globally.

Practical advice for wallet developers:

  • Engage with regulators early. Participate in sandboxes (UK FCA, Singapore MAS, Switzerland FINMA all have them).
  • Document your compliance features. When VASPs evaluate your wallet, they want to see proof you’ve thought about AML/CFT.
  • Build interoperability. If your wallet can export compliance attestations in multiple formats, it reduces friction for users.

The 7-day whitelisting wait is annoying, but from a regulatory perspective, it’s actually a reasonable balance: low ongoing friction (after initial setup) with time for fraud detection.

Not perfect, but better to be proactive than reactive. Regulators remember who engaged constructively when enforcement actions start.

4

Will, I want to push back on one aspect: third-party verification services introduce security risks that users don’t understand. :warning:

When you integrate a “compliance verification” service into your wallet to automate proof generation, you’re introducing a new attack surface:

Risk 1: Credential leakage
If the verification service gets hacked, attackers now have a database linking real-world identities to wallet addresses. This is a honeypot for targeted attacks.

Risk 2: Fake verification services
Phishing attacks will absolutely target these flows. Imagine a fake “Binance Wallet Verification” site that tricks users into signing malicious messages, not ownership proofs.

Risk 3: Centralization pressure
If “compliance-as-a-service” becomes the norm, a handful of KYC providers (Chainalysis, Elliptic, Onfido) become de facto gatekeepers for who can use crypto. That’s not decentralization.

Privacy-preserving alternatives:

Instead of centralized verification services, wallets should implement:

  1. Self-sovereign identity (SSI) standards
    W3C Verifiable Credentials let users control their own identity attestations. No central database.

  2. Decentralized attestation networks
    Use networks like BrightID or Proof of Humanity where identity verification is decentralized and privacy-preserving.

  3. Zero-knowledge credential systems
    Polygon ID, zkCred, and similar systems let users prove KYC compliance without revealing identity to verifiers.

The zkProof approach you mentioned is the right direction, but implementation matters. If the zkProof reveals your identity to the wallet developer or a third-party service, it’s not actually private—you’ve just moved the surveillance from VASPs to wallet providers.

Design principle: Users should control their own attestations and selectively disclose them only when required. No intermediaries. No databases. Just cryptographic proofs.

I know this is harder to build than integrating a third-party API, but it’s the only way to preserve the decentralization ethos of crypto while still achieving compliance.

Security is not a feature—it’s a process. And that process needs to include threat modeling for compliance integrations, not just smart contract vulnerabilities.

5

From the DeFi protocol side, I’m watching smart contract wallet adoption closely because it affects composability in ways most people don’t realize.

The problem:

When users switch from EOAs (externally owned accounts) to smart contract wallets for compliance features, it breaks DeFi integrations that assume is a simple address.

Real-world example:

We built a yield vault that uses to verify user signatures for gasless transactions. When users switched to Argent or Safe (smart contract wallets), those signatures stopped working because the contract, not the user’s key, was the signer.

Gas cost implications:

Every compliance verification embedded in a smart contract wallet adds computational overhead:

  • zkProof verification: ~200k-500k gas depending on proof complexity
  • Multi-sig coordination: ~50k-100k gas per additional signer
  • Compliance module checks: ~20k-50k gas per transaction

At current gas prices (~50 gwei), that’s - in extra costs per transaction just for compliance.

For yield farming, this kills small trades. If I’m trying to optimize worth of liquidity, I can’t afford in compliance gas fees. It only makes sense for institutional-size transactions.

What we need:

  1. L2 adoption for smart contract wallets
    Base, Arbitrum, Optimism have gas costs 100x lower. Compliance features become affordable.

  2. Standardized wallet interfaces
    ERC-6551 (token-bound accounts) and ERC-4337 (account abstraction) need widespread adoption so DeFi protocols can integrate once, not build separate flows for each wallet type.

  3. Batch transactions
    If wallets can bundle multiple actions (verification + swap + stake) into one transaction, we amortize gas costs.

My take:

Compliance-enabled wallets are coming whether we like it or not. DeFi protocols need to adapt by:

  • Supporting smart contract wallet interactions natively
  • Migrating to L2s where gas costs don’t kill UX
  • Building with account abstraction in mind from day one

Otherwise, we end up with a two-tier DeFi: EOAs for simple swaps, smart contract wallets for compliant institutional use. That fragmentation hurts liquidity and composability.