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:
- Connect to the user wallet
- Prompt the message to be signed in the user wallet
- Retrieve and validate the signature
Blockchain | Wallets | Available in txCreate | Available in Javascript SDK V1 | Available in Javascript SDK V2 |
---|---|---|---|---|
Bitcoin | Trezor, Ledger, wallets that support user-supplied signature | Live | Live | WIP |
Ethereum | Trezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed here | Live | Live | Live |
Polygon | Trezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed here | Live | Live | Live |
Optimism | Trezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed here | Live | Live | Live |
Arbitrum | Trezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed here | Live | Live | Live |
All EVM Chains | Trezor, Ledger, Metamask, TRUST Wallet, 200+ wallets listed here | Live | Live | Live |
Solana | To be announced... | Live | WIP | WIP |
Tron | To be announced... | Live | WIP | WIP |
Ripple | To be announced... | Live | WIP | WIP |
Cardano | To be announced... | Live | WIP | WIP |
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.
Blockchain | Wallets | Available in txCreate | Available in Javascript SDK |
---|---|---|---|
All blockchains | Any wallets | Live | Live |
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.
Blockchain | Wallets | Available in txCreate | Available in Javascript SDK |
---|---|---|---|
All blockchains | Any wallet | Live | WIP |
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.
Blockchain | Wallets | Available in txCreate | Available in Javascript SDK |
---|---|---|---|
All blockchains | Any wallet | Live | Live |
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.
Updated 5 days ago