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.

This is a simulation

No custody platform is integrated behind this page: no MPC, no HSM, no Harmonize. It models a key-source shape, a standalone ElGamal key plus an external signer, to show which flows survive and which break.

Two findings

1. The derived key does not work with custodial key management

The ElGamal secret is derived from the master seed, and a custody platform never releases the seed. So the account cannot derive its own ElGamal key or read its own confidential balance outside the platform. A platform that ran the derivation inside its own boundary would change that; it would need the derivation published as a standard, and it is not (issue #10).

A standalone ElGamal key gets around this, but then something outside the custody platform holds a permanent decryption key. Who that should be is an open question in this project (CLAIMS.md E-117).

2. Approval policies cannot read a confidential amount

An approval workflow that holds only public data sees a proof, not a value, so a rule like “two approvers above $1M” has nothing to check. This is structural, not an integration detail: confidentiality and amount-based approval policies pull against each other. The ways out each cost something: give the policy engine the ElGamal secret, and it becomes another party that reads every balance; accept the holder’s statement of the amount, and the policy rests on the holder’s honesty; or prove the bound in zero knowledge, which this project has neither built nor costed.

Which flows survive, and which break

Each flow lists what it needs, and the verdict is computed from what a custody-shaped key source has.

Note 1: Only with a standalone ElGamal key, held outside the custody platform (E-117).

survives: Send a public XRPL payment

breaks: Onboard with the ruled derived key

Structural in this simulation: a custody platform never releases seed material, so the account cannot derive its own ElGamal key outside the platform. A platform that ran the derivation inside its own boundary would change this, and that needs the derivation published (issue #10).

survives: Onboard with a standalone ElGamal key (note 1)

survives: Read own confidential balance (note 1)

survives: Send a confidential amount (note 1)

breaks: Send confidentially, under an amount-capped approval policy (note 1)

Structural: the transaction carries a proof, not a value, so a rule like 'two approvers above $1M' has no amount to read. It is hidden from this simulation's policy engine too, which holds only public data.

survives: Send confidentially, under a destination-allowlist policy (note 1)

survives: Retire a position in tranches (note 1)

Each tranche size and its timing is public: the amount is plaintext on every ConvertBack (CLAIMS.md F-24).

The two findings, drawn

1. Where the ElGamal key can come from

The custody platform

holds the seed and signs; never releases the seed

outside the platform

Derived key: breaks

deriving it needs the seed

Standalone key: survives

but something outside the platform then holds a permanent key to its balances

2. What an approval policy can read

An approval workflow

holds only public data

reads the confidential transaction

It reads a proof, not an amount

a rule like 'two approvers above $1M' has nothing to check

The simulation's two findings. A platform that ran the derivation inside its own boundary would change the first; that needs the derivation published as a standard (issue #10), and it is not.