ADR-006: Proof of Reserves via Encrypted Total Supply Counter
| Status | Proposed |
| Date | 2026-03-11 |
Context
Under MiCA (Art. 22, Art. 56), EMT issuers must periodically report the value of issued tokens and demonstrate that reserves cover all outstanding supply. In a standard ERC-20 this is trivial — totalSupply() is public. In privacy system, it is not: individual balances are ElGamal ciphertexts (and later UTXOs), and the total amount held across all users is not directly observable on-chain.
Since the total encrypted supply equals the total amount of public tokens that have been shielded minus the total amount that has been unshielded, one could just track all mints and burns to calculate total issuance. But tracking this via public counters would leak information about particular burns (and hence private offramps), which we want to avoid.
The system needs a mechanism to prove total encrypted supply to an authorized party (e.g., auditor, regulator, or reserve custodian) without exposing it publicly.
Proposal
Introduce an encrypted total supply counter stored on-chain as a single ElGamal ciphertext TS = (R_ts, C_ts) encrypted under a dedicated total_supply_key (a Grumpkin public key). This counter is updated homomorphically on every operation that changes the total amount held in the encrypted layer:
| Operation | Effect on total supply counter |
|---|---|
| Concealed burn (encrypted → nowhere) | TS -= Enc(amount, total_supply_key, r) |
| Public burn (Public → nowhere) | TS -= Enc(amount, total_supply_key, r) |
| Mint to public | TS += Enc(amount, total_supply_key, r) |
| Mint to concealed (if ever supported) | TS += Enc(amount, total_supply_key, r) |
The counter starts at the identity ciphertext (O, O) representing an encryption of zero.
On-chain mechanics
The contract stores:
mapping(address => (Point, Point)) public encryptedTotalSupply;
Point public totalSupplyKey;
On each mint/burn, the contract performs ElGamal homomorphic addition (or subtraction) on encryptedTotalSupply[token] using the amount and a fresh randomizer. For public-amount operations (mint to public, public burn, mint to concealed), the contract computes Enc(amount, TPK, r) on-chain — no circuit changes needed. For concealed burns, the amount is hidden, so a ZK circuit must output Enc(amount, TPK, r) as a public output for the contract to subtract from TS.
Key management
The total_supply_key is a Grumpkin keypair (tsk, TPK) where:
TPKis stored on-chain and used by the contract (and circuits, for private burns) to encrypt amounts into the counter.tskis held by the authorized party (e.g., the EMI compliance team).
The key holder can decrypt the total supply counter at any time: total_supply · G = C_ts - tsk · R_ts, then solve the discrete log. Since total supply is bounded by reasonable token economics (e.g., max 2^64), the discrete log solver handles this efficiently.
Verification flow (proof of reserves)
The keyholder generates a ZK proof attesting that a given total_supply agrees with encryptedTotalSupply at a given block. It does so on regulator request, as well as periodically publishing the current total supply on-chain together with the proof.
Private burns
When a user's funds are seized or burned via a compliance action (see AML Enforcement), the encrypted balance is zeroed out. If this is done without going through the public unshield path, the total supply counter must still be decremented. The burn circuit (or the contract logic for administrative burns) must include an encryption of the burned amount under totalSupplyKey so the counter remains consistent.
Consequences
What becomes easier:
- Reserve audits can be performed at any block height without user cooperation or enumeration of all accounts.
- MiCA Art. 22 / Art. 56 reporting of "value of issued tokens" and "size of reserve" becomes mechanically straightforward.
- The auditor gets a single number (total encrypted supply) rather than having to reconstruct it from per-user data.
What becomes harder:
- Every supply-changing operation (shield, unshield, burn, mint) now has an additional on-chain cost: one ElGamal encryption + one point addition on the counter. This is ~2 EC point operations, comparable to the existing conceal cost.
- Private burns require circuit changes to output an encryption under
totalSupplyKey. - Key management for
total_supply_keyadds operational complexity — key rotation, backup, and access control must be designed. - If the
tskis compromised, the attacker learns total supply (but not individual balances). If thetskis lost, the counter becomes undecryptable — though the system continues to function, the audit capability is lost until a new counter is initialized.