Self Hosted Wallet Verification

Proving ownership of a self hosted or non custodial wallet

What is self hosted wallet verification?

Self hosted wallet verification is a process in which a person proves ownership of a blockchain wallet address. This can be a requirement before transferring virtual assets from a VASP to a non-custodial wallet or self hosted wallet. By implementing self hosted wallet verification VASPs can have confidence that their users are sending assets from their centralized accounts to a wallet they own.

Notabene provides support for the following methods of wallet verification:

  • Cryptographic Signature Proofs
  • Micro Transactions (satoshi tests)
  • Wallet Screenshots
  • Self-Declaration

🇪🇺

Proof of ownership is required in the EU starting in 2025, read more here.

Signature Proofs

Signature proofs are a form of wallet ownership proof in which the user uses their private keys to sign an off-chain message which can then be verified using their blockchain address. This cryptographically proves that the user holds the private keys of the wallet where they intend to transfer funds.

The Notabene Javascript SDK performs the following steps to provide a smooth UX:

  1. Connect to the user wallet
  2. Prompt the message to be signed in the user wallet
  3. Retrieve and validate the signature
BlockchainWalletsAvailable in txCreateAvailable in Javascript SDK V1Available in Javascript SDK V2
BitcoinTrezor, Ledger, wallets that support user-supplied signatureLiveLiveWIP
EthereumTrezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed hereLiveLiveLive
PolygonTrezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed hereLiveLiveLive
OptimismTrezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed hereLiveLiveLive
ArbitrumTrezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed hereLiveLiveLive
All EVM ChainsTrezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed hereLiveLiveLive
SolanaTo be announced...LiveWIPWIP
TronTo be announced...LiveWIPWIP
RippleTo be announced...LiveWIPWIP
CardanoTo be announced...LiveWIPWIP

Signing a message with the Javascript SDK

Below is a video of an off-chain signature for a ETH address using Metamask software wallet see more demo videos here


Below is a video of a off-chain signature for a BTC address using Electrum software wallet (from version 1, version 2 video coming soon!):

Passing the proof to txCreate

The type must be one of the following: eip-191, eip-712, bip-137, or xpub.

Ethereum example (metamask):

"beneficiaryProof": {
    "proof": "0x3dd4a17a...ce4a2bcd1b",
    "attestation": "I certify that ETH account 0x896B....0b9b belonged to did:key:z6Mk...z2Zn on Thu, 12 Sep 2024 16:00:33 GMT",
    "address": "0x896B...0b9b",
    "type": "eip-191",
    "wallet_provider": "injected"
}

BTC example (user supplied signiture):

"beneficiaryProof": {
    "proof": "H3V8GXBy39Dz...tr3TSTkY=",
    "attestation": "I certify that BTC account 1442...dxhsQ belonged to did:key:z6Mk...z2Zn on Thu, 12 Sep 2024 18:24:34 GMT",
    "address": "1442...dxhsQ",
    "type": "bip-137",
    "wallet_provider": "manual"
}

Microtransactions (Satoshi Tests)

Notabene also supports micro transactions. A Satoshi test is a verification process that involves sending a specified amount of cryptocurrency from the destination address within a particular time window to confirm control of the wallets private keys.

BlockchainWalletsAvailable in txCreateAvailable in Javascript SDK
All blockchainsAny walletsLiveLive

Flow with Javascript SDK



Format of the proof object

"beneficiaryProof": {
    "type": "microtransfer",
    "proof": "{{txHash}}"
}

Screenshots

Notabene supports screenshots as a method of wallet proof ownership.

BlockchainWalletsAvailable in txCreateAvailable in Javascript SDK
All blockchainsAny walletLiveWIP

Flow with Javascript SDK

Format of the proof object

"beneficiaryProof": {
    "type": "screenshot",
    "proof": "upload_link"
}

Self-declaration (checkbox)

Notabene provides an option for checkbox attestation in which the user confirms they are indeed the owner of the self hosted wallet address.

BlockchainWalletsAvailable in txCreateAvailable in Javascript SDK
All blockchainsAny walletLiveLive

Self attesting the control using the Javascript SDK


Format of the proof object

"beneficiaryProof": {
    "type": "self-declaration",
    "did": "did:pkh:eip155:1:0xa437bEed902AF9338B7DEB23848e195d85019510",
    "address": "eip155:1:0xa437bEed902AF9338B7DEB23848e195d85019510",
    "attestation": "I hereby declare that the blockchain address 0xa437bEed902AF9338B7DEB23848e195d85019510 is under my own control and ownership.",
    "confirmed": true,
    "status": "verified"
},
"beneficiaryProof": {
    "type": "checkbox",
    "proof": "checked"
}

FAQ

Can I reuse signature proofs?

Yes! Signature proofs can be re-used for later transactions to the same destination address. Here is a video demonstrating.

What do I do for third-party transfers?

Currently only self declaration is supported for third party transfers. Notabene will collect the name of the beneficiary of the transfer and then provide a check-box to declare that the beneficiary is the owner of the destination address.

In Q4 2024, we plan to release a third-party signature flow.

Which of these proofs show up on chain?

Only micro transactions (satoshi tests) show up on chain. Cryptographic signatures will not show up on chain nor will screenshots and self-declaration proofs.

How do I know which assets are supported?

Micro Transactions, Self-declaration and screenshoots all support any asset. Support for cryptographic signature is not based on asset but is instead based on the blockchain of the asset and wallets technical capabilities. The table above has Notabene's current blockchain support for signature proofs.

How do I handle transactions involving multiple UTXOs?

For deposits coming from multiple UTXOs, if the client has verified 1 input address, then the other 3 input addresses can be considered verified. This is because the transaction itself serves as proof that all 4 inputs are controlled by the same person/entity (the client has to know the private keys to all 4 input addresses, otherwise the transaction won’t be accepted by the blockchain). So as long as one of the inputs is verified that should be sufficient as part of a risk based approach.