The Identity‑Intent Gap

Multi-model research swarm + Ramp Network codebase audit of wallet ownership verification at embeddable crypto on-ramps. 8 gather agents, 12 debate agents, 3 frontier model lineages. March 31, 2026.

01

On-ramps verify identity, not intent

$75B funneled to scam-related crypto addresses since 2020, despite increasingly stringent KYC
92.4%
of users who enter the deposit screen never advance to review (Ramp Network, week of Mar 23)
67%
review-to-completion rate. Once users commit, they follow through. The leak is upstream.

On-ramps verify who you are but not whether the destination wallet is yours. This identity-intent gap is the central finding across all three model lineages (Google Gemini, Kimi/Moonshot, Anthropic Opus). KYC proves identity. It does not prove wallet control. The $75B figure from the University of Texas study exists because every major attack vector exploits the gap between verified person and unverified destination.

02

Four layers, ranked by effectiveness

1

SDK Address Locking

lockWalletAddress userAddress pre-fill, HMAC-signed widget URLs. Host app sets destination programmatically. Deterministic prevention.

Deployed
2

KYC + Chain Analysis

Sumsub identity verification, Chainalysis KYT real-time screening, Reactor for cross-chain fund tracing. Identity + known-bad matching.

Deployed
3

Cryptographic Wallet Signing

EIP-191, BIP-137, Ed25519 via WalletConnect/Reown. Mathematical proof of private key possession. Only active for Ireland entity, transactions >990 EUR.

IE Only >990€
4

Behavioral Intelligence

Sardine: 4,800+ risk features, typing rhythm, device-holding angle. 93.75% dispute reduction for neobank clients. Detects RATs and coerced sessions.

Not deployed

The most effective mechanism is Tier 1: the SDK integration itself. When a wallet app embeds the on-ramp widget, the destination address is set by the host application, not typed by the user. This closes clipboard hijacking and social-engineered address swaps by removing user input entirely. Tier 3 is the gold standard but its deployment scope is narrow.

03

Jurisdictional divergence is the defining feature

Jurisdiction Mandate Threshold Methods Ramp Status
Switzerland FINMA Must prove "power of disposal" via technical means only 1,000 CHF (30-day agg.) Satoshi Test, AOPP, crypto signature Not covered
EU TFR Art. 14(5) Verify self-hosted address ownership €1,000 Technical means; "mere statement" rejected IE only, 990€
Singapore MAS PSN01 Verify unhosted wallet control SGD 1,500 Signature test, deposit test Not covered
UK FCA Risk-based approach €1,000 for EDD Satoshi test for higher-risk GB not gated
US FinCEN No federal mandate (rule withdrawn Aug 2024) N/A OFAC SDN screening only Compliant
FATF Collect info; does NOT mandate ownership proof USD/EUR 1,000 Defers to national implementation Compliant

All three model lineages agreed: regulation is the primary driver where mandates exist, but it is not universal. Switzerland is the gold standard. The US has no federal requirement. The direction of travel is toward stricter requirements globally. FATF's 2025 expansion and the AMLR timeline (July 2027) point toward convergence on the Swiss/EU model.

Key regulatory quote: Polish GIIF (Aug 2025 VASP training): "Mere client statement or recording is not proof of wallet ownership." Ramp Network currently sends checkbox_confirmation to Notabene as beneficiary proof for unhosted wallets.
04

9 gaps mapped to actual code

Full review of the ramp-instant monorepo: NestJS backend, React widget-2 frontend, DDD wallet-ownership domain, Travel Rule Notabene integration, and signature verification service.

1

Signing is Ireland-only and threshold-gated

wallet-ownership.aggregate.ts → isVerificationRequired()

Cryptographic verification only fires for EntityIe, amount >990 EUR, unhosted wallets. GB entity has Travel Rule but zero ownership gate. A UK user buying 5,000 EUR of crypto to an unverified wallet faces no challenge.

Critical
2

No replay protection in signing message

verification.api.tsx

Signed message is static plain text with wallet address. No nonce, no timestamp, no session ID, no domain separator. A captured signature is valid forever. Should use EIP-712 typed data with domainSeparator.

High
3

Checkbox proof sent to Notabene as ownership evidence

create-request.builder.ts

For unhosted wallets, Notabene receives { type: 'checkbox_confirmation', proof: 'checked' }. This is the "mere client statement" regulators explicitly reject. When user has signed, the actual signature should be sent instead.

High
4

Compliance check always approves

wallet-ownership-check-provider.ts

The instant compliance check records wallet type but never blocks. Transactions to UNKNOWN wallet types proceed without friction. Monitoring only, not gating.

Medium
5

US entity skips Travel Rule for non-hosted wallets

travel-rule.aggregate.ts → request()

Legally defensible (FinCEN rule withdrawn Aug 2024), but FIN-2025-NTC1 says operators "may require" certification. The DC AG Athena case shows liability risk of doing nothing.

Low
6

No behavioral biometrics in widget

widget-2 frontend

Zero Sardine, SEON, or ThreatMetrix integration. No device fingerprinting for fraud scoring. Behavioral signals detect RAT-controlled sessions that chain analysis cannot.

Medium
7

Manual fallback for non-EVM/BTC/SOL chains

wallet-ownership-verification.use-case.ts

Chains without automatic signing redirect to a support form with undefined SLA. Cosmos (amino), Polkadot (sr25519), and Tron all support message signing natively.

Medium
8

Satoshi test implemented but disabled

WALLET_OWNERSHIP_OFFRAMP_AS_SATOSHI_TEST_ENABLED = false

A completed offramp proves wallet control (user sent crypto FROM the address). FINMA explicitly accepts this method. The handler exists. The flag is off.

Medium
9

Notabene wallet lookup hardcoded to GB entity

notabene.provider.ts

All wallet ownership lookups use the GB VASP DID regardless of actual service entity. Per-entity VASP DIDs are already configured in TravelRuleProviderConfigService but not used.

Medium
05

How scammers exploit the identity-intent gap

Destination Redirection

Victim passes all KYC checks, then enters the scammer's wallet address in the payout field. The on-ramp has no mechanism to distinguish the victim's wallet from any other valid address.

Remote Access Tools

Scammer controls victim's device via AnyDesk or TeamViewer during the on-ramp flow. All device-based security checks pass because the victim's device is legitimate.

Address Poisoning

Dust transactions from vanity addresses matching the first and last 4 characters of the victim's real address. Victim copies the wrong address from transaction history.

Clipper Malware

Malicious software monitors the clipboard for strings matching crypto address patterns and silently replaces them with the attacker's address during copy-paste.

AI Deepfakes

AI-generated faces and motions bypass liveness detection (head movement, blinking) in automated KYC flows. Reported by Sardine and Sumsub security researchers.

93% of Athena Bitcoin ATM deposits originated from scams (DC Attorney General, Sept 2025). The on-ramp verified the victim, thereby facilitating their exploitation. This is the identity-intent gap in its purest form: perfect KYC, zero fraud prevention.
06

Where three AI lineages agree and disagree

Bull Angle: What's Working

Gemini Pro SDK locks + AOPP = deterministic defense. Sardine metrics not crypto-specific. Med-High
Kimi K2.5 SDK binding strongest. Chain analysis doesn't prove ownership. Missing bypass rates. 75%
Opus 4.6 SDK locking is the workhorse. Crypto ownership proofs are the gap. 7.5/10
3/3 agree: SDK address locking is the most effective deployed mechanism. Crypto proofs exist but aren't standard.

Bear Angle: Failures & Gaps

Gemini Pro "Security theater." System verifies victim, facilitates exploitation. DC AG 93% devastating. High
Kimi K2.5 Systemic failure. Negative correlation between KYC stringency and fraud prevention. 85%
Opus 4.6 Architectural flaw fatal, but missing counterfactual data tempers certainty. 75-80%
2-vs-1 split: Gemini/Kimi definitive. Opus notes possible invisible prevention of low-sophistication fraud.

Regulatory Angle

Gemini Pro Three regulatory postures. Swiss strictest. High fragmentation. High
Kimi K2.5 Partial support. Non-regulatory drivers in US (banking partners, insurance). High/Mod
Opus 4.6 Jurisdictional divergence is the defining feature. Direction: stricter globally. High
3/3 agree: regulation drives verification where mandates exist. Switzerland is the gold standard. US gap is notable.

Technical Angle

Gemini Pro EIP-712/SIWE + HMAC = deterministic gold standard. Behavioral tools are probabilistic. High
Kimi K2.5 Crypto + behavioral = two-factor paradigm. Production deployments confirm maturity. 90%
Opus 4.6 Tier 1 (crypto proof) + Tier 2 (SDK lock) > Tier 3 (detection alone). High
3/3 agree: cryptographic signing is the gold standard. Deterministic prevention beats probabilistic detection.
07

Ranked by effort vs. impact

# Action Effort Impact Reg. Risk
1 Enable offramp Satoshi test flag Trivial Medium Low
2 Add nonce/timestamp to signing message Small High Medium
3 Fix Notabene entity hardcode Small Medium Low
4 Extend signing to GB entity (risk-based) Medium High High
5 Upgrade Notabene proof from checkbox to signature Medium High High
6 Reject/flag UNKNOWN wallet type in compliance check Small Medium Medium
7 Add Cosmos/Polkadot/Tron signing support Medium Medium Low
8 Migrate to EIP-712 typed data signing Medium High Medium
9 Evaluate behavioral biometrics SDK (Sardine/SEON) Large High Low
Items 1-3 are quick wins. Flip the Satoshi test flag, add a nonce to the signing message, fix the Notabene entity hardcode. Combined: ~2-3 days of work for meaningful security and compliance improvement.
08

Both sides are right about different things

Bull Case
Embedded SDK flows with address locking ARE structurally safer than standalone on-ramps. The 67% review-to-completion rate proves the committed cohort converts. The technical toolkit (EIP-712, AOPP, SIWE) is production-ready. Regulatory convergence will force adoption.
Bear Case
$75B in scam outflows proves the system fails at scale. KYC verifies the victim, not the transaction. The strongest available tool (cryptographic signing) isn't deployed by default at any top-3 on-ramp. Banks blocking 40% of UK crypto transactions is the market's verdict.

Resolution: Both cases are correct about different things. Embedded SDK flows with address locking are structurally safer than standalone on-ramps (like crypto ATMs where 93% of deposits were scams). But the identity-intent gap remains real. Cryptographic ownership proofs are the missing piece. The infrastructure exists in the Ramp Network codebase. The deployment scope is the problem, not the technology.

09

What we still don't know

01

What are Ramp Network's actual third-party wallet fraud rates? No on-ramp publishes this data. Without it, we can't measure whether verification prevents fraud or merely creates compliance checkboxes.

02

Does enabling the Satoshi test flag affect offramp completion rates? The handler is tested and ready, but could the additional confirmation step introduce drop-off in legitimate flows?

03

How do fraud rates compare between SDK-locked wallet flows and manual-entry wallet flows? This counterfactual would quantify the real value of Tier 1 address locking.

04

Would EIP-712 typed data signing reduce user drop-off vs. current plain text signing? Structured signing shows human-readable fields in the wallet, which may build trust.

05

What's the false positive rate on Chainalysis KYT destination screening? If it's high, the monitoring-only compliance check might be the right call. If low, it should gate.

06

How does ERC-4337 account abstraction affect the signer-equals-owner assumption? Multi-sig and social recovery wallets break the model that the SignatureVerificationService relies on.

10

Research swarm architecture

8
Gather Agents

Gemini Flash + Grok Fast
4 angles × 2 models

1
Quality Gate

Opus orchestrator
Data sufficiency check

12
Debate Agents

Gemini Pro + Kimi K2.5 + Opus
4 angles × 3 lineages

4 research angles: Bull (what's working), Bear (failures and gaps), Regulatory (jurisdictional landscape), and Technical (mechanism assessment). Each angle gathered by 2 workhorse models with web search, then debated by 3 frontier models from different AI lineages to avoid monoculture bias.

No Phase 2.5 rebuttal was needed. All four angles showed strong 3/3 consensus or clear 2-vs-1 splits with identifiable reasoning differences. The only split (Bear angle: Opus vs. Gemini/Kimi) was on the strength of the counterfactual argument, not on the diagnosis itself.

Codebase audit: 3 parallel Explore agents read the full wallet-ownership DDD domain, Travel Rule Notabene integration, signature verification service, widget frontend flows, and SDK address locking implementation. Findings were mapped against research conclusions to produce actionable recommendations.