Proof of control of a self-hosted wallet

Prove who controls an address.

Send a counterparty a link. They sign a challenge with any wallet, a hardware device, or a pasted signature. You get a verifiable certificate that the key was controlled — anchored on-chain. No screenshots, no Satoshi test.

Create a verification requestSee what it proves

Built for FATF R16 / EU TFR / MiCA. The signer never needs an account.

How it works

Three steps. The counterparty does one of them, and needs no account to do it.

STEP 01

Create & send a link

Pick a chain, add your reference, get a link (or QR) to send however you like.

STEP 02

They sign the message

The counterparty signs plain text with any wallet. Never a transaction, never a seed phrase.

STEP 03

You get a certificate

Verified on the right chain, certified, and anchored on-chain to fix the time it existed.

How the proof is built

The signature is verified, hashed into a certificate, folded into a merkle root, and anchored — first on Polygon, then Bitcoin.

The claim
Challenge
nonce 8f3c…
Signature
0x9a7f…e21b
Verify
eip191 ✓
Certificate
SHA-256 leaf
The anchor
Merkle root
0x41f8…6d20
Polygon
block 71,204,883
Bitcoin
block 958,544 · OTS
Anchored
proof fixed in time

What it proves — and what it does not

This is part of the product, not the fine print. We are precise about the claim.

Proved, trustlessly

  • This address produced this signature over this challenge.
  • The signer held the private key at the time of signing.
  • The certificate hash existed at the on-chain anchor time.

Not proved

  • The identity of the signer.
  • That control is exclusive, or that the key was not shared or coerced.
  • That the signer is your customer — identity binding is your KYC.

The full statement, the per-chain cryptography and how to verify it yourself are on the proof semantics page.

Why this exists

Several regimes require verifying control of a self-hosted wallet by technical means — not a screenshot.

FATF Recommendation 16

The “travel rule” expects obliged entities to verify control of self-hosted wallets by technical means.

EU Transfer of Funds

Regulation (EU) 2023/1113 requires verifying that a self-hosted wallet is controlled by the customer.

MiCA

Self-hosted-wallet checks under MiCA need a repeatable, evidenced method — not a screenshot.

API and webhooks

Run verifications from your own onboarding or withdrawal flow, without opening the dashboard.

Included in the Pro and Business plans.
  • One call creates a request and returns the signing link to send to your counterparty.
  • Webhooks tell your system when the counterparty signs and when the certificate is anchored, so nothing has to poll.
  • Every webhook is signed with HMAC-SHA256. Certificates come back as a JSON proof packet or a PDF.
API documentationSee plans
Create a request
curl https://basignet.com/api/v1/requests \
  -H "Authorization: Bearer $SIGNET_KEY" \
  -d '{"chain":"tron","reference":"KYC-0412","anchor":true}'

→ { "status": "pending",
    "signingUrl": "https://basignet.com/s/q0tHA2…" }
Webhook your server receives
POST /webhooks/signet
Signet-Signature: t=1759312345,v1=5f2c…

{ "type": "request.verified",
  "data": { "request": { "status": "verified",
    "certificate": { "address": "TNeiUD…", "sigType": "tronv2" } } } }

Works with any wallet

Message signing on every major chain. Hardware and offline signing via paste — no wallet integration required.

Ethereum
EIP-191 · 1271
Polygon
EIP-191 · 1271
Base
EIP-191 · 1271
Arbitrum One
EIP-191 · 1271
Optimism
EIP-191 · 1271
BNB Chain
EIP-191 · 1271
Avalanche
EIP-191 · 1271
Gnosis
EIP-191 · 1271
Linea
EIP-191 · 1271
Scroll
EIP-191 · 1271
zkSync Era
EIP-191 · 1271
Polygon zkEVM
EIP-191 · 1271
Celo
EIP-191 · 1271
Bitcoin
BIP-137 · 322
Litecoin
BIP-137
Dogecoin
BIP-137
Zcash (transparent)
BIP-137
Solana
ed25519
Polkadot
sr25519 · ed25519
Kusama
sr25519 · ed25519
TRON
signMessageV2

EIP-191 signatures verify on any EVM network out of the box — this is a curated set, not a limit.