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.
What each key source can and cannot do. The ElGamal key encrypts and decrypts confidential balances; the XRPL account key signs. The rows follow the signer’s ownKeySource type, which has two variants, and rows that are not built say so.
| key source | decrypt own balance | prove + sign confidential | public transactions | exists today |
|---|---|---|---|---|
Generated demo seed, faucet-fundedderived-from-master-seed | yes The ElGamal secret is derived from the master seed, so the signer rebuilds it from the seed alone. docs/reviews/REVIEW-012-RULING-keygen-2026-08-18.md; signer/src/keygen.rs | yes One seed gives both the ElGamal secret and the XRPL account key. signer/src/keygen.rs; signer/src/onboarding.rs | yes An ordinary XRPL account. Public transactions are unaffected. signer/src/xrpl.rs | built signer/src/onboarding.rs |
Existing Devnet seed, pastedderived-from-master-seed | yes Same as a generated seed: the derivation does not depend on where the seed came from. signer/src/keygen.rs | conditional Only if the master key controls the account. With a regular key or a signer list, spending authority may sit elsewhere, so the signer warns; with lsfDisableMaster it refuses. signer/src/session.rs (REFUSED_MASTER_KEY_DISABLED); issue #11; REVIEW-012 condition 2 | yes An ordinary XRPL account. signer/src/xrpl.rs | built signer/src/onboarding.rs |
Standalone ElGamal keystandalone | yes A separate ElGamal secret kept in the profile: two secrets to keep instead of one. signer/src/onboarding.rs:279; signer/src/holder.rs:48 | conditional The ElGamal key decrypts and proves but does not sign; the account key is a separate secret. A custody platform ends up here, and who then holds the ElGamal key is an open question (E-117). CLAIMS.md E-117; signer/src/holder.rs | yes Unaffected: the ElGamal key plays no part in public transactions. signer/src/xrpl.rs | built signer/src/holder.rs — KeySource::Standalone |
| Browser wallet extension | no Decrypting needs the ElGamal secret, which is derived from the master seed, and a wallet exists to keep the seed in. None of the three wallets examined on 2026-08-28 (Xaman, GemWallet, Crossmark) decrypts for a page or gives it a key. A wallet that derived the key and decrypted internally could; none examined does (E-329). REVIEW-012 (derivation from master seed); ADR-0003 D2 | no A Send, a ConvertBack and the first Convert, which registers the key, need the ElGamal secret as well as the account key; a MergeInbox or a later Convert needs only the account key (TASK ZERO §3; R-8). These wallets supply only the account key, so a page cannot assemble the first three through them, and without the first Convert there is no position. A wallet that held the ElGamal key and built the proofs itself could; none examined does (E-329). ADR-0003 D2; signer/src/keygen.rs | yes 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) | not built not built, for the reasons in this row |
Custody platform (simulated)standalone | conditional Only with a standalone ElGamal key, held by something other than the custody platform, or if the platform itself ran the derivation inside its own boundary, which would need the derivation published as a standard (issue #10). Outside the platform the account cannot derive its key, because that needs the seed, and a custody platform never releases the seed. REVIEW-012; CLAIMS.md E-117 | conditional The external signer can sign. Holding only public data, it cannot apply a policy to the amount, because the transaction carries a proof, not a value: a rule like 'two approvers above $1M' has nothing to read. docs/research/CUSTODY-2026-08-28.md; CLAIMS.md P-4 | yes Public transactions carry plain amounts, so approval policies work as usual. docs/research/CUSTODY-2026-08-28.md | not built Simulation: an external-signer stub. No MPC, no HSM, no integration. |
The master seed becomes a permanent decryption credential. Anyone who ever holds it can decrypt every confidential balance this account has held, past and future. XLS-96 has no key rotation and no key recovery (P-10), so this cannot be undone.
The derivation is specified only in this repository and is not a published standard. A holder with their seed but without this repository cannot reconstruct their key. Issue #10 tracks this.
Required by the key-derivation ruling, REVIEW-012 condition 2.
P-4No key source hides identities. The sender and receiver of every confidential transaction are public.P-9A holder is never private from the issuer. The issuer can always decrypt.P-10No key source supports rotation or recovery. XLS-96 supports neither.P-11No key source hides who transacts, when, or how often. Only amounts are hidden.F-1A newly created confidential balance is publicly identifiable as exactly zero.F-24Retiring a position in tranches publishes each tranche size.P-5None of this is secure, audited, non-custodial or production-ready, and the custody mode is a simulation.