Exchange Deposits
Centralized exchange deposit addresses are a top-three attack surface in crypto. Phishing pages clone exchange UIs and substitute attacker-controlled addresses. Malware swaps copied addresses at paste time. Support impersonators DM users with “deposit addresses”. Every major exchange has lost customer funds to some variant of this attack, even though the exchange itself was never compromised. Notareum gives exchanges a way to publish deposit addresses as signed.nota files that wallets verify before a transaction is signed, closing the attack surface at the wallet layer.
The problem
A user wants to deposit USDC to an exchange. The legitimate flow is:- User navigates to the exchange deposit page.
- Exchange displays a deposit address (often per-user, rotated periodically).
- User copies the address into their wallet.
- User sends funds.
The Notareum flow
The wallet trusts only two things: the exchange’s signing key and the on-chain record. It does not trust the page, the clipboard, the messaging channel, or the browser.Exchange-side implementation
Exchanges typically operate a single institutional signing key (HSM-backed) that signs all deposit address.nota files. The underlying deposit address is derived per user via HD wallets or allocated from a warm pool; the .nota wraps whatever scheme the exchange uses.
Wallet-side verification
Depositing to CoolExchange (verified institutional) User: bob@coolexchange Expires: 2026-04-23 14:30 UTC
Delivery channels
The.nota file is payload, not transport. Exchanges can deliver via:
- QR code on the deposit page. Wallets scan and import directly.
- Deep link like
notareum://deposit?nota=<b64>. Wallets register the URI scheme. - Push via WalletConnect v2 sessions.
- Email or SMS as attachments (the file is small).
Rotation and expiry
Exchanges rotate deposit addresses for privacy and accounting. Each rotation issues a new.nota:
- Short-lived (
validUntil< 24h) for per-transaction addresses. - Long-lived (rolling 30 days) for reusable user addresses.
- Revocation via
NotaRegistry.revokeResourceon compromise.
.nota.
Travel Rule compliance
The.nota file is a natural carrier for Travel Rule originator/beneficiary data between exchanges. When Exchange A sends to Exchange B, the payment request .nota can include a travelRule block:
Withdrawal allowlists
The inverse flow works too. A user submits a signed.nota of their personal withdrawal address; the exchange stores the resourceId as an allowlist entry. Any withdrawal request must resolve to an allowlisted resourceId. Because the binding is cryptographic, the exchange can offer “no-confirmation-email” withdrawals to addresses verified through Notareum.
Integration patterns
- Wallets require verified issuer identity before accepting
.notaimports. - Exchanges publish a single institutional issuer
.notaand a public directory of their operating subsidiaries. - Block explorers tag known exchange deposit addresses with the issuing exchange identity.
- Custodians use the same pattern for cold-wallet receive flows.

