Operator design

What the operator isCopy Anchor Link

OpenZeppelin Confidential Tokens and Nethermind's Stellar Private Payments (SPP) both define compliance roles and leave them to whoever deploys them. The operator would run those roles for issuers and pool operators:

• auditor-key custody;
• scoped audit requests;
• selective-disclosure outputs, including tax export;
• allow and deny lists.

Confidential one-to-many payouts remain the first use case.

Where the demand comes fromCopy Anchor Link

The written record is narrower than some earlier research said. SDF's 2026-08-06 developer meeting notes, written by Kaan Kacar, contain:

• in his own voice: "Nobody is building that platform for you. Hint.";
• his paraphrase of Alessandro Voto, SDF's privacy product manager: "go be the operator — sanction lists, allow/deny lists, compliance hooks".

The notes also carry design guidance that this design follows: the auditor key "should sit unused inside an MPC or TEE custody setup … and only answer scoped requests when a regulator compels one".

Other asks quoted elsewhere came from video captions that could not be checked. There is no statement from SDF, OpenZeppelin or Nethermind that they will not build this themselves. Sources: docs/research/DEMAND-QUOTES.md.

Who takes partCopy Anchor Link

The design rule: no single party, Tally included, can decrypt an amount, prove a clawback or change a list on its own.

Auditor-key custodyCopy Anchor Link

The protocols fix several things:

• On OpenZeppelin Confidential Tokens, the auditor key is one Grumpkin scalar per auditor_id. The registry accepts any valid point with no proof of possession, and rotation overwrites the key in place.
• On SPP, the view key is one Baby JubJub scalar that cannot be rotated and must exist before the pool is deployed.
• Decryption is linear in the key in both systems.

Options comparedCopy Anchor Link

The chosen designCopy Anchor Link

• Custodians. The issuer's compliance function, Tally, and an independent custodian chosen by the issuer.
• Separation. The issuer's freeze and clawback signers must not hold a quorum of shares.
• Key generation. The key is generated jointly, and a proof of possession is published, because the registry checks none.
• Who opens a result. The requester combines the partial results. Custodians encrypt their contributions to the requester's key, so only the party entitled to a result sees it.
• Share upkeep. Shares are refreshed without changing the public key. Every historical key version is kept.

The weakest point. Clawback and auditor-side disclosure proofs need the whole key inside one proof. The design reassembles the key briefly inside an attested enclave, only for a logged, approved request, and publishes the attestation. Two alternatives, a collaborative prover or a circuit change, are open questions for SDF and OpenZeppelin.

Standing balance openings are as sensitive as the key, so they are held secret-shared among the same custodians.

Scoped audit requestsCopy Anchor Link

A request names:

• the issuer and contract;
• the requester and its disclosure key;
• a legal basis;
• the subjects (accounts or note keys);
• a ledger range;
• the data wanted;
• the output type;
• an expiry;
• a notification rule.

Scope is enforced cryptographically:

• Custodians compute their part only for events they resolve themselves from at least two archives.
• They never accept event data from the requester.
• Each contribution is bound to the request and the event.

Every request, approval, refusal, contribution and enclave session is written to a hash-chained log. Custodians countersign the log daily, and its head is anchored on Stellar daily.

Disclosure outputsCopy Anchor Link

The tax export is a verifiable transaction statement. It does no fiat valuation, no jurisdiction-specific tax calculation and no filing.

Allow and deny listsCopy Anchor Link

The two systems use different list models:

• OpenZeppelin: a yes/no policy call keyed by Stellar address. OpenZeppelin v0.9.0 ships no implementation.
• SPP: Merkle trees keyed by note public keys. The allowlist cannot delete, and the blocklist root must match exactly at proof time.

The design keeps one off-chain subject registry and projects it into each system:

• OpenZeppelin projection: a policy contract serving many tokens, signed two-of-three.
• SPP projection: Tally runs the pool's association-set contracts. Removal from an allowlist becomes a blocklist entry. Blocklist updates are batched on a published schedule, with an emergency path for sanctions hits.

What exists and what is missingCopy Anchor Link

The full threat table is on Threat model. The questions this design leaves open are on Open questions.