feat: Auditable Shielded Pools by ganymedio · Pull Request #3 · MoveIndustries/MIP

ganymedio · 2026-07-08T19:14:45Z

Not to be merged until we have input from legal and leadership. BD is speaking with them.

musitdev

Mostly we have to see if we can make auditor permissionless.

musitdev · 2026-07-09T15:59:43Z

+
+## Summary
+
+This MIP specifies **Shielded Zones**, a design for private token transfers on Movement, together with the cryptographic primitive stack it requires. Value is held in **a single on-chain shielded pool** that supports any number of fungible assets — all sharing one commitment tree, so the anonymity set spans every asset. Every private transfer has an *audit scope*: one or more approved auditors, chosen per transfer, that can decrypt it. That per-transfer audit scope is what a **Shielded Zone** is — not a place funds live.


In the initial concept, auditor is defined by the node operator and is permissionless. We force having at least one auditor per transfer. For one asset several operators can define different auditors. It's the operator responsibility to respect the law. This point has to be validated with the layer, but it works like that in Tempo zone.
The user decide which operator he use for his transfer.
To summary:

User : KYC

Auditor: permissionless

The user chooses his auditor to do the transfer.

Good ideas, implemented all of the above.

musitdev · 2026-07-09T16:11:36Z

+
+The relayer performs one additional, mandatory task: it attaches **auditor data** — an encryption of the transfer's `(receiver, amount)` to at least one auditor — and proves on-chain that the auditor's ciphertext faithfully encrypts the same values the transfer moves. The operator and the relayer are the same party: the auditing institution operates (or facilitates) the relayer, so it is necessarily the entity that names the auditors and constructs their data.
+
+As in a Tempo Zone, that institution can observe all transaction information. Unlike a Tempo Zone, funds are not confined to a zone: a sender may pay any receiver, and a **Shielded Zone** here is only the **audit scope** (which auditors participate), chosen per transfer by the relayer.


I think we should remove all reference to tempo. Here it's a little different. The institution can observe all Tx that goes through his relayer. Tx relayed by other relayer won't be auditable by the institution. We can speak about auditable zone.

Removed Tempo references, changed concept to auditor zones.

musitdev · 2026-07-13T07:03:13Z

+### Out of scope
+
+- **Off-chain operator ledgers / rollups.** This design executes and verifies transfers **on-chain**. A separate off-chain "zone ledger" model is explicitly not proposed here.
+- **Legal accreditation of auditors.** The on-chain approved-auditor set and its admin control are specified here; how an auditor is vetted as a legitimate legal entity off-chain, before its key is approved, is a policy matter outside this MIP.


Depend on if we open the auditor part.

Resolved by going permissionless; off-chain auditor vetting is now a policy matter, not protocol-enforced.

musitdev · 2026-07-13T07:04:16Z

+
+- **Off-chain operator ledgers / rollups.** This design executes and verifies transfers **on-chain**. A separate off-chain "zone ledger" model is explicitly not proposed here.
+- **Legal accreditation of auditors.** The on-chain approved-auditor set and its admin control are specified here; how an auditor is vetted as a legitimate legal entity off-chain, before its key is approved, is a policy matter outside this MIP.
+- **Relayer economics.** Fees, incentives, and gas-paymaster accounting are out of scope; only the cryptographic property that lets a relayer submit on a sender's behalf (proof + nullifier authorize, not the submitter's identity) is specified.


I think we should define some fee possibilities and the relayer decide the fee. It can be done in a v2.

Added as planned v2 work for now.

musitdev · 2026-07-13T07:07:28Z

+
+Every transfer therefore carries, for at least one auditor, a ciphertext of the transfer detail under the auditor's key, and the relayer proves on-chain that this ciphertext encrypts exactly the `(receiver, amount)` committed in the transfer. The relayer attaches this data because it is operated by the auditing institution itself: it selects the auditors and is trusted to observe the transaction in cleartext.
+
+The approved auditor(s) attached to a transfer are that transfer's **Shielded Zone** — its audit scope, and the only sense in which a "zone" exists here: not an environment funds enter, but the set of auditors under which the transfer is auditable. This is what the diagram's `Shielded Zone` box marks.


I would say auditor zone instead of Shielded zone .

musitdev · 2026-07-13T07:18:36Z

+public entry fun revoke_auditor(admin: &signer, auditor_pubkey: vector<u8>)
+```
+
+There is no zone object, no `zone_id`, and no per-institution registration. Revoking an auditor removes its key from the set; there is no separate enable/disable flag. The set is asset-agnostic: it applies to a transfer of any supported asset.


We need to validate first if we really need to declare the auditor.

Confirmed we don't. Removed the on-chain auditor declaration; the auditor key just travels in the transfer's binding.

One other point we should present it to the BD and legal so that they can validate our choices.

…hielded Pools - Auditor selection permissionless: remove ApprovedAuditors set, admin, approve/revoke; chain enforces only the faithful P9 binding, not an auditor allowlist - Remove Tempo references; describe the audit scope self-contained - Rename concept 'Shielded Zone' -> 'auditor zone'; retitle MIP and file to Auditable Shielded Pools - Defer relayer-set fees to v2 (scope note + Future Potential) - Drop the resolved auditor-approval-authority open question

musitdev

I've added one constrain on the user request so that the relayer must add the user selected auditor to the transfer.

musitdev · 2026-07-16T14:05:03Z

+**On-chain state.** There is no zone object, no `zone_id`, no per-institution registration, and no approved-auditor set. The auditor for a transfer appears only as the `auditor_pubkey` carried in that transfer's P9 binding, and the rule is asset-agnostic: it applies to a transfer of any supported asset.
+
+**Binding a transfer to its audit scope.** For each transfer the operator selects one or more auditors and attaches, per auditor, a P9 ciphertext and binding proof. The pool requires at least one and verifies that the binding proof ties the ciphertext to the transfer's recipient output commitment. A transfer with zero valid bindings is rejected.
+


One point we should add. It's the user that choose his auditor and select a relayer of the chosen auditor. Nothing guaranty that the relayer put the right auditor, so in request the user should add a sign of his chosen auditor key so that the contract can validate that the relayer have added at least the chosen auditor.

Good point, pushed an update. The sender now endorses its chosen auditor key(s) inside its own transfer proof (auditor_endorsement = Poseidon(sorted auditor_pubkeys)), and the pool requires every endorsed auditor to be present among the bindings ("at least the chosen auditor,"); the relayer may add its own mandated auditors but can't drop or substitute the sender's. I went with I used a proof-carried endorsement rather than a literal signature — a signature as a public input risks deanonymizing the sender, whereas the endorsement gives the same on-chain guarantee and is authorized by the spend, so the relayer can't forge it.

Sender pins its chosen auditor(s) via an endorsement carried in the transfer proof; the pool requires every endorsed auditor to appear among the bindings, so a relayer cannot drop or substitute the user's choice. Operators define the auditors they serve and own their legitimacy; the sender selects among that offering.

musitdev

An endorsement is fine. Now we can present it to the BD and legal.

ganymedio force-pushed the feat/shielded-zones branch from 1d71e2c to 3ff64fe Compare July 8, 2026 19:56

ganymedio changed the title ~~[mip-xxx] Shielded Zones — operator-run privacy pools and cryptographic primitives~~ [mip-xxx] Shielded Zones — operator-run privacy pools Jul 8, 2026

ganymedio changed the title ~~[mip-xxx] Shielded Zones — operator-run privacy pools~~ [mip-xxx] Shielded Zone Jul 8, 2026

ganymedio force-pushed the feat/shielded-zones branch from 3ff64fe to 618ed0c Compare July 8, 2026 20:31

ganymedio changed the title ~~[mip-xxx] Shielded Zone~~ [mip-xxx] Shielded Pools — private transfers with relayer-attached auditing Jul 8, 2026

ganymedio changed the title ~~[mip-xxx] Shielded Pools — private transfers with relayer-attached auditing~~ feat: Shielded Zones Jul 8, 2026

ganymedio force-pushed the feat/shielded-zones branch 11 times, most recently from 1bcf247 to a70149e Compare July 9, 2026 14:47

feat: Shielded Zones

dbd7ef2

ganymedio force-pushed the feat/shielded-zones branch from a70149e to dbd7ef2 Compare July 9, 2026 14:48

docs: single multi-asset pool (correct the one-pool-per-asset mislabel)

28e69da

musitdev reviewed Jul 13, 2026

View reviewed changes

ganymedio changed the title ~~feat: Shielded Zones~~ feat: Auditable Shielded Pools Jul 15, 2026

ganymedio requested a review from musitdev July 15, 2026 20:52

musitdev reviewed Jul 16, 2026

View reviewed changes

ganymedio requested a review from musitdev July 16, 2026 15:49

musitdev approved these changes Jul 16, 2026

View reviewed changes

ganymedio marked this pull request as ready for review July 16, 2026 16:54

Primata mentioned this pull request Jul 30, 2026

feat: Transaction Request URLs #5

Open


		## Summary

		This MIP specifies Shielded Zones, a design for private token transfers on Movement, together with the cryptographic primitive stack it requires. Value is held in a single on-chain shielded pool that supports any number of fungible assets — all sharing one commitment tree, so the anonymity set spans every asset. Every private transfer has an audit scope: one or more approved auditors, chosen per transfer, that can decrypt it. That per-transfer audit scope is what a Shielded Zone is — not a place funds live.


		The relayer performs one additional, mandatory task: it attaches auditor data — an encryption of the transfer's `(receiver, amount)` to at least one auditor — and proves on-chain that the auditor's ciphertext faithfully encrypts the same values the transfer moves. The operator and the relayer are the same party: the auditing institution operates (or facilitates) the relayer, so it is necessarily the entity that names the auditors and constructs their data.

		As in a Tempo Zone, that institution can observe all transaction information. Unlike a Tempo Zone, funds are not confined to a zone: a sender may pay any receiver, and a Shielded Zone here is only the audit scope (which auditors participate), chosen per transfer by the relayer.


		Every transfer therefore carries, for at least one auditor, a ciphertext of the transfer detail under the auditor's key, and the relayer proves on-chain that this ciphertext encrypts exactly the `(receiver, amount)` committed in the transfer. The relayer attaches this data because it is operated by the auditing institution itself: it selects the auditors and is trusted to observe the transaction in cleartext.

		The approved auditor(s) attached to a transfer are that transfer's Shielded Zone — its audit scope, and the only sense in which a "zone" exists here: not an environment funds enter, but the set of auditors under which the transfer is auditable. This is what the diagram's `Shielded Zone` box marks.

		On-chain state. There is no zone object, no `zone_id`, no per-institution registration, and no approved-auditor set. The auditor for a transfer appears only as the `auditor_pubkey` carried in that transfer's P9 binding, and the rule is asset-agnostic: it applies to a transfer of any supported asset.

		Binding a transfer to its audit scope. For each transfer the operator selects one or more auditors and attaches, per auditor, a P9 ciphertext and binding proof. The pool requires at least one and verifies that the binding proof ties the ciphertext to the transfer's recipient output commitment. A transfer with zero valid bindings is rejected.

Uh oh!

Conversation

ganymedio commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

musitdev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ganymedio Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

musitdev left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

musitdev left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ganymedio commented Jul 8, 2026 •

edited

Loading

ganymedio Jul 15, 2026 •

edited

Loading

musitdev left a comment •

edited

Loading