aopp

Address Ownership Proof Protocol (AOPP)

• Name: Address Ownership Proof Protocol (AOPP)
• URL: https://gitlab.com/aopp/address-ownership-proof-protocol
• Category: self-hosted-wallet ownership-proof protocol / compliance interoperability standard
• Summary: AOPP is a narrow ownership-proof handshake for regulated withdrawal flows. It standardizes how a VASP asks a wallet to prove control of an address and receive the signed proof back. Useful because it turns a messy manual compliance step into a machine-readable callback flow, not because it is some broad wallet or identity layer.
• What it does:
  • Defines an aopp: URI scheme a VASP can present when it needs proof that a user controls a self-hosted wallet address
  • Standardizes request fields such as protocol version, challenge message, asset, address format, and callback URL
  • Lets an AOPP-compatible wallet choose an address, sign the VASP-supplied challenge, and POST the proof back to the VASP
  • Supports optional xpub_required account-level disclosure for services that want more than single-address proof
  • Replaces screenshots, manual message-copy flows, and other brittle ownership-check workarounds with a cleaner request-response path
• Key claims:
  • The canonical GitLab README says AOPP is meant to streamline and automate address-ownership proofs between self-hosted wallets and VASPs, especially for withdrawals
  • The same specification defines a concrete aopp: link format with v, msg, asset, format, and callback fields plus optional xpub_required, which is the clearest sign this is a protocol note rather than a wallet feature page
  • The README says the wallet returns JSON containing version, address, signature, and optionally xpub, so the standard covers proof delivery as well as the approval prompt
  • 21 Analytics’ explainer ties AOPP directly to AML / Travel Rule-style self-hosted-wallet verification requirements, which is where the protocol is actually operationally relevant
  • BitBox’s support article makes the privacy boundary clear: standard AOPP proves only the specific address used for the transaction, while optional xpub sharing broadens the verification scope materially
  • Trezor’s removal note is a useful reality check: AOPP can be implemented on top of ordinary sign-and-verify flows, and the controversy was about the compliance use case, not some novel cryptographic breakthrough
• Whitepaper: No canonical standalone AOPP whitepaper or litepaper surfaced in this pass. The clearest source of truth was the official GitLab specification, supplemented by first-party wallet-support materials and compliance explainers; see ../../whitepapers/aopp-primary-sources-2026-05-03.md.
• Sources:
  • https://gitlab.com/aopp/address-ownership-proof-protocol
  • https://gitlab.com/aopp/address-ownership-proof-protocol/-/raw/master/README.md
  • https://www.21analytics.co/what-is-aopp/
  • https://support.bitbox.swiss/en_US/1-other/what-is-aopp-crypto-ownership-proof
  • https://blog.trezor.io/a-decision-on-aopp-789540c2930b

Internal linkages

• Keep the budget tight.
• Best anchors: transaction-authorization-protocol, caip-222, and walletconnect-auth.

Control surface

• The leverage is in the request format, wallet support, optional xpub disclosure, callback trust, and the downstream VASP policy attached to a successful proof.

• Treat AOPP as a compliance-driven ownership-proof shim, not as a general wallet-authorization or identity standard.

• Last reviewed: 2026-05-26 UTC