Devnet snapshot · signs nothing, holds no keys · this project is not secure, not audited, not production-ready (P-5)

W-CONF

What confidential Multi-Purpose Tokens (MPTs) on the XRP Ledger hide, and what they do not. A research project, shown on one snapshot of the Devnet.

The two keys, and which one a wallet holds

The master seed
what an XRPL wallet keeps
XRPL's own derivation
The account key
signs, while the master key controls the account; with a regular key or a signer list, signing authority may sit elsewhere
A browser wallet holds this one.
The master seed
the same seed
this project's derivation, not a published standard
The ElGamal key
reads the holder's balances; builds the proofs
None of the wallets examined on 2026-08-28 keeps it or gives it to a page.
Or a standalone ElGamal key, kept separately
Two secrets to keep instead of one.
A Send, a ConvertBack and the first Convert, which registers the key, need both keys; a MergeInbox or a later Convert needs only the account key. The wallets examined supply only the account key, so a page cannot assemble the first three through them.

A browser wallet cannot hold a confidential position

The three wallets examined (Xaman, GemWallet and Crossmark, on 2026-08-28) cannot, and the reasons are structural, not missing features. A wallet that kept the ElGamal key inside the extension and offered a prove-and-sign operation could; none of those examined does.

  1. A Send, a ConvertBack and the first Convert, which registers the key, need two secrets: the ElGamal secret, to decrypt the balance and build the proof, and the XRPL account key, to sign. A wallet supplies only the second. A MergeInbox or a later Convert needs only the account key, and neither opens nor spends a position (CLAIMS.md R-8).
  2. Under the ruled key generation, the ElGamal secret is derived from the master seed. A derived-key account has no other way to get it.
  3. A wallet extension exists in order not to release seed material. That is the product, not a gap in its API.

So a page cannot assemble those transactions through these wallets, and without the first Convert there is no position to hold. They are not refusing a permission; they hold nothing they are built to give a page.

What a wallet can do

yes
Ordinary XRPL transactions

Ordinary transactions are what a wallet is for. Per each vendor's docs on 2026-08-28, the GemWallet, Crossmark and Xaman APIs accept any transaction type to sign and submit.

gemwallet.app API reference; docs.crossmark.io; docs.xaman.dev (all read 2026-08-28)

yes
Prove control of an account

Enough to show that account’s observer view, which anyone with the address can read anyway.

What this page does not claim

Not determined: whether a given wallet build can serialise XLS-0096 transactions. The page-side SDKs examined on 2026-08-28 carry no codec, so serialisation happens inside the extension, or for Xaman in its backend, and none of them names the codec version (CLAIMS.md E-206). This is not why a wallet cannot hold a confidential position: the reasons above are structural, and this one could change with any release.

CLAIMS.md E-206.