@openzeppelin/compact-contracts 0.4.0-alpha.6 → 0.4.0

package/multisig/ProposalManager.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/ProposalManager.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/ProposalManager.compact)
 
 pragma language_version >= 0.26.0;
 
@@ -8,14 +8,15 @@ pragma language_version >= 0.26.0;
  * @description Token-agnostic proposal lifecycle management for multisig
  * governance contracts.
  *
- * Supports shielded and unshielded proposals through a unified
- * Recipient type with a RecipientKind tag. Typed helper circuits
- * provide safe construction of recipients without exposing the
- * internal Bytes<32> representation to consumers.
+ * Supports shielded and unshielded proposals through the `Recipient` type
+ * and its `RecipientKind` tag, declared in `RecipientTypes` and re-exported
+ * here. Typed helper circuits provide safe construction of recipients
+ * without exposing the internal Bytes<32> representation to consumers.
  *
  * @warning PROPOSALS ARE PUBLIC. `_proposals` is exported ledger state, so
- * every proposal's recipient address, token color, amount, and state is
- * readable off-chain, and `_nextProposalId` reveals how many have been created.
+ * every proposal's recipient address, token color, amount, expiry, and status
+ * is readable off-chain, and `_nextProposalId` reveals how many have been
+ * created.
  * This holds regardless of which treasury a consumer composes: pairing this
  * module with `ShieldedTreasuryStateless` still publishes the full intent of
  * every transfer, even though the transfer itself is shielded. The transfer is
@@ -30,18 +31,23 @@ pragma language_version >= 0.26.0;
  */
 module ProposalManager {
   import CompactStandardLibrary;
+  import "./RecipientTypes";
+
+  export { Recipient, RecipientKind };
 
   // ─── Types ──────────────────────────────────────────────────────
 
   /**
-   * @description Proposal lifecycle states, derived from `Proposal.state` by
-   * `getProposalStatus`. Not stored on the ledger.
-   *
-   * - `Inactive`: no proposal with that id exists.
-   * - `Active`: `state` is an expiry in the future.
-   * - `Executed`: `state` is `executedState()`.
-   * - `Cancelled`: `state` is `cancelledState()`.
-   * - `Expired`: `state` is an expiry at or before the current block time.
+   * @description Proposal lifecycle status. `Proposal.status` stores `Active`,
+   * `Executed`, or `Cancelled`; `getProposalStatus` derives the other two.
+   *
+   * - `Inactive`: no proposal with that id exists. Never stored.
+   * - `Active`: created and not retired. Stored. Executable only while the
+   *   block time is below `Proposal.expiry`.
+   * - `Executed`: `_markExecuted` ran. Stored, terminal.
+   * - `Cancelled`: `_cancelProposal` ran. Stored, terminal.
+   * - `Expired`: stored `Active` with an `expiry` at or before the current
+   *   block time. Never stored.
    */
   export enum ProposalStatus {
     Inactive,
@@ -52,69 +58,30 @@ module ProposalManager {
   }
 
   /**
-   * @description What a `Recipient`'s bytes are and which rail accepts them.
-   *
-   * - `ShieldedUser`: a Zswap coin public key. `toShieldedRecipient` only.
-   * - `UnshieldedUser`: a user address. `toUnshieldedRecipient` only.
-   * - `Contract`: a contract address. Accepted by both.
-   *
-   * @warning `toShieldedRecipient` rejects `UnshieldedUser` and
-   * `toUnshieldedRecipient` rejects `ShieldedUser`, both at execution rather
-   * than at creation. That mismatch is the hazard noted in `_createProposal`.
-   */
-  export enum RecipientKind {
-    ShieldedUser,
-    UnshieldedUser,
-    Contract
-  }
-
-  /**
-   * @description A transfer target.
-   *
-   * @warning `address` is raw 32 bytes. `kind` alone decides whether they are
-   * read as a Zswap coin public key, a user address, or a contract address.
-   */
-  export struct Recipient {
-    kind: RecipientKind,
-    address: Bytes<32>
-  }
-
-  /**
-   * @description A proposal. `state` holds both the lifecycle stage and the
-   * expiry in a single field:
+   * @description A proposal. `status` is the stored lifecycle stage and
+   * `expiry` is the deadline, as seconds since the Unix epoch. Reaching a
+   * terminal stage changes `status` only, so an executed or cancelled proposal
+   * keeps the deadline it was created with.
    *
-   * - `executedState()` (1): executed.
-   * - `cancelledState()` (2): cancelled.
-   * - any greater value: the expiry, as seconds since the Unix epoch. The
-   *   proposal is active while the block time is below it and expired
-   *   afterwards.
-   *
-   * `_createProposal` rejects an `expiry` in the reserved range, so a proposal
-   * that has not reached a terminal state always has `state` greater than
-   * `cancelledState()`. Note that `Expired` is NOT terminal: a lapsed proposal
-   * still carries its original deadline, which is what tells a reader when it
-   * lapsed.
-   *
-   * @warning In the deadline range, `state` marks when a proposal STOPS being
-   * executable, not when it starts: it is executable while `blockTime < state`
-   * and inert once `blockTime >= state`.
+   * @warning `expiry` marks when a proposal STOPS being executable, not when it
+   * starts: an `Active` proposal is executable while `blockTime < expiry` and
+   * inert once `blockTime >= expiry`.
    *
    * @notice This module implements no execution delay. `expiry` bounds how long
    * a proposal stays valid; it does not impose a minimum wait before it may be
    * executed. A consumer that needs a delay must compose one.
    *
-   * @notice Off-chain readers decode `state` themselves, applying the sentinel
-   * checks and the deadline comparison above. `_proposals` is exported ledger
-   * state and readable without a proof. `executedState` and
-   * `cancelledState` are pure, so a reader can obtain the sentinel values without
-   * hardcoding them. A state-reading accessor will be revisited once contract-to-contract
-   * interactions are available.
+   * @notice `_proposals` is exported ledger state and readable without a proof.
+   * An off-chain reader takes `status` as stored and, when it is `Active`,
+   * compares `expiry` with the current block time. A state-reading accessor
+   * will be revisited once contract-to-contract interactions are available.
    */
   export struct Proposal {
     to: Recipient,
     color: Bytes<32>,
     amount: Uint<128>,
-    state: Uint<64>
+    expiry: Uint<64>,
+    status: ProposalStatus
   }
 
   // ─── State ──────────────────────────────────────────────────────
@@ -136,43 +103,23 @@ module ProposalManager {
 
   /**
    * @description Proposals by id, keyed by the value `_nextProposalId` produced
-   * at creation. Each entry carries the recipient, token color, amount, and the
-   * overlaid lifecycle/expiry encoding documented on `Proposal`.
+   * at creation. Each entry carries the recipient, token color, amount, expiry,
+   * and lifecycle status documented on `Proposal`.
    * @type {Uint<64>} id - The proposal identifier, issued by `_nextProposalId`.
    * @type {Proposal} proposal - The proposal record.
    * @type {Map<id, proposal>}
    * @type {Map<Uint<64>, Proposal>} _proposals
    *
-   * @notice Entries are never deleted. Reaching a terminal state overwrites
-   * `state` in place so the map only grows, and no circuit here prunes it.
+   * @notice Entries are never deleted. Reaching a terminal stage overwrites
+   * `status` in place so the map only grows, and no circuit here prunes it.
    * A consumer that needs cleanup must compose its own.
    *
    * @notice Readable off-chain without a proof so integrators read this map
-   * directly rather than calling a circuit. Decoding `state` is the reader's
-   * job. See `Proposal`
+   * directly rather than calling a circuit. See `Proposal` for how `status`
+   * and `expiry` combine.
    */
   export ledger _proposals: Map<Uint<64>, Proposal>;
 
-  // ─── State Sentinels ────────────────────────────────────────────
-
-  /**
-   * @description The `Proposal.state` value marking a proposal as executed.
-   *
-   * @returns {Uint<64>} 1.
-   */
-  export pure circuit executedState(): Uint<64> {
-    return 1;
-  }
-
-  /**
-   * @description The `Proposal.state` value marking a proposal as cancelled.
-   *
-   * @returns {Uint<64>} 2.
-   */
-  export pure circuit cancelledState(): Uint<64> {
-    return 2;
-  }
-
   // ─── Recipient Helpers ──────────────────────────────────────────
 
   /**
@@ -278,8 +225,8 @@ module ProposalManager {
 
   /**
    * @description Asserts that a proposal exists and is still executable. The two
-   * checks are separate: a terminal `state` (executed or cancelled) fails the
-   * first, and a deadline that has passed fails the second, so the error message
+   * checks are separate: a `status` other than `Active` fails the first, and a
+   * deadline that has passed fails the second, so the error message
    * distinguishes the two.
    *
    * @notice Expiry is terminal, unlike a conflicting read. A tx rejected
@@ -290,10 +237,10 @@ module ProposalManager {
    * Requirements:
    *
    * - Proposal must exist.
-   * - Proposal must not be executed or cancelled.
+   * - Proposal `status` must be `Active`.
    * - Proposal must not have expired.
    *
-   * @constraints k=9, rows=129
+   * @constraints k=7, rows=103
    *
    * @param {Uint<64>} id - The proposal ID.
    *
@@ -302,13 +249,13 @@ module ProposalManager {
   export circuit assertProposalActive(id: Uint<64>): [] {
     assertProposalExists(id);
 
-    const state = _proposals.lookup(disclose(id)).state;
+    const proposal = _proposals.lookup(disclose(id));
     assert(
-      state > cancelledState(),
+      proposal.status == ProposalStatus.Active,
       "ProposalManager: proposal not active"
     );
     assert(
-      blockTimeLt(state),
+      blockTimeLt(proposal.expiry),
       "ProposalManager: proposal expired"
     );
   }
@@ -341,11 +288,6 @@ module ProposalManager {
    * reintroducing the immortal proposal this field exists to prevent. Consuming
    * contracts that need a bounded lifetime must impose their own cap.
    *
-   * @notice `expiry` is also rejected if it falls in the sentinel range, keeping
-   * the two domains `state` overlays disjoint. That check is enforced here rather
-   * than left to the future check, so disjointness holds for whatever block time
-   * the executing environment reports.
-   *
    * @notice Access control is NOT enforced here.
    * The consuming contract must gate this behind its own
    * authorization policy.
@@ -353,10 +295,9 @@ module ProposalManager {
    * Requirements:
    *
    * - `amount` must be greater than 0.
-   * - `expiry` must be greater than `cancelledState()`.
    * - `expiry` must be in the future.
    *
-   * @constraints k=10, rows=913
+   * @constraints k=10, rows=883
    *
    * @param {Recipient} to - The recipient (constructed via helper circuits).
    * @param {Bytes<32>} color - The token color.
@@ -373,10 +314,6 @@ module ProposalManager {
     expiry: Uint<64>
   ): Uint<64> {
     assert(amount > 0, "ProposalManager: zero amount");
-    assert(
-      expiry > cancelledState(),
-      "ProposalManager: expiry in reserved range"
-    );
     assert(
       blockTimeLt(disclose(expiry)),
       "ProposalManager: expiry not in the future"
@@ -391,7 +328,8 @@ module ProposalManager {
       to: to,
       color: color,
       amount: amount,
-      state: expiry
+      expiry: expiry,
+      status: ProposalStatus.Active
     }));
 
     return id;
@@ -420,7 +358,8 @@ module ProposalManager {
       to: proposal.to,
       color: proposal.color,
       amount: proposal.amount,
-      state: cancelledState()
+      expiry: proposal.expiry,
+      status: ProposalStatus.Cancelled
     });
   }
 
@@ -447,16 +386,17 @@ module ProposalManager {
       to: proposal.to,
       color: proposal.color,
       amount: proposal.amount,
-      state: executedState()
+      expiry: proposal.expiry,
+      status: ProposalStatus.Executed
     });
   }
 
   // ─── View ───────────────────────────────────────────────────────
 
   /**
-   * @description Returns the full proposal data. The returned `state` is the
-   * raw encoded field. See `Proposal` for how to read it, and prefer
-   * `getProposalStatus` when the lifecycle stage is what is wanted.
+   * @description Returns the full proposal data. The returned `status` is the
+   * stored stage, so an `Active` entry may already be past its `expiry`.
+   * Prefer `getProposalStatus` when the effective status is what is wanted.
    *
    * @param {Uint<64>} id - The proposal ID.
    *
@@ -504,9 +444,10 @@ module ProposalManager {
   }
 
   /**
-   * @description Derives the lifecycle status of a proposal from its `state`
-   * field and the current block time. Returns `Inactive` for an id that was
-   * never created rather than failing.
+   * @description Derives the effective lifecycle status of a proposal: the
+   * stored `status` unless it is `Active`, in which case `expiry` and the
+   * current block time decide between `Active` and `Expired`. Returns
+   * `Inactive` for an id that was never created rather than failing.
    *
    * @constraints k=9, rows=252
    *
@@ -519,14 +460,11 @@ module ProposalManager {
       return ProposalStatus.Inactive;
     }
 
-    const state = _proposals.lookup(disclose(id)).state;
-    if (state == executedState()) {
-      return ProposalStatus.Executed;
-    }
-    if (state == cancelledState()) {
-      return ProposalStatus.Cancelled;
+    const proposal = _proposals.lookup(disclose(id));
+    if (proposal.status != ProposalStatus.Active) {
+      return proposal.status;
     }
-    if (blockTimeLt(state)) {
+    if (blockTimeLt(proposal.expiry)) {
       return ProposalStatus.Active;
     }
     return ProposalStatus.Expired;

package/multisig/RecipientTypes.compact

@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: MIT
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/RecipientTypes.compact)
+
+pragma language_version >= 0.26.0;
+
+/**
+ * @module RecipientTypes
+ * @description The transfer-target types shared by the multisig modules.
+ *
+ * This module holds no ledger state. Importing a module allocates every
+ * ledger field it declares, so a contract that needs only the recipient
+ * types imports this module rather than `ProposalManager`, which would add
+ * a `_nextProposalId` and `_proposals` the contract never writes.
+ * `ProposalManager` re-exports both types and provides the typed helper
+ * circuits that build and route recipients.
+ */
+module RecipientTypes {
+  import CompactStandardLibrary;
+
+  /**
+   * @description What a `Recipient`'s bytes are and which rail accepts them.
+   *
+   * - `ShieldedUser`: a Zswap coin public key. `ProposalManager.toShieldedRecipient` only.
+   * - `UnshieldedUser`: a user address. `ProposalManager.toUnshieldedRecipient` only.
+   * - `Contract`: a contract address. Accepted by both.
+   *
+   * @warning `toShieldedRecipient` rejects `UnshieldedUser` and
+   * `toUnshieldedRecipient` rejects `ShieldedUser`, both at execution rather
+   * than at creation. That mismatch is the hazard noted in
+   * `ProposalManager._createProposal`.
+   */
+  export enum RecipientKind {
+    ShieldedUser,
+    UnshieldedUser,
+    Contract
+  }
+
+  /**
+   * @description A transfer target.
+   *
+   * @warning `address` is raw 32 bytes. `kind` alone decides whether they are
+   * read as a Zswap coin public key, a user address, or a contract address.
+   */
+  export struct Recipient {
+    kind: RecipientKind,
+    address: Bytes<32>
+  }
+}

package/multisig/Secp256k1EcdsaMultisig.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/Secp256k1EcdsaMultisig.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/Secp256k1EcdsaMultisig.compact)
 
 pragma language_version >= 0.26.0;
 

package/multisig/ShieldedTreasury.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/ShieldedTreasury.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/ShieldedTreasury.compact)
 
 pragma language_version >= 0.26.0;
 
@@ -82,13 +82,13 @@ module ShieldedTreasury {
    * The coin is then merged with any existing coin of the same color,
    * or inserted as a new entry if no coin of that color exists.
    *
-   * Zero-value deposits are permitted and are not always a no-op. On a color the
-   * treasury does not yet hold, a zero-value coin is inserted and occupies that
-   * color's single slot until a later deposit merges into it; if a coin of that
-   * color already exists, the zero merges into it via `mergeCoinImmediate` and
-   * the stored value is unchanged. They may serve as signaling mechanisms when
-   * events are supported. They are not useful as privacy decoys, this
-   * treasury's holdings are public (see the module header).
+   * @warning Every deposit of a color replaces the coin that `_send` reads for
+   * that color, so a deposit that lands first invalidates every `_send` of the
+   * same color still waiting to be applied. A consumer that exposes `_deposit`
+   * without access control lets any depositor delay authorized sends for as
+   * long as they keep depositing; the sends must then be re-proven. No funds are
+   * lost. A zero-value coin is rejected, so each deposit costs at least one unit
+   * of the token plus the transaction fee.
    *
    * @notice Access control is NOT enforced here.
    * The consuming contract must gate this behind its own
@@ -96,6 +96,7 @@ module ShieldedTreasury {
    *
    * Requirements:
    *
+   * - The coin's value must be non-zero.
    * - Deposit must not cause received total overflow.
    *
    * @param {ShieldedCoinInfo} coin - The incoming shielded coin descriptor.
@@ -103,6 +104,8 @@ module ShieldedTreasury {
    * @returns {[]} Empty tuple.
    */
   export circuit _deposit(coin: ShieldedCoinInfo): [] {
+    assert(coin.value != 0, "ShieldedTreasury: zero value");
+
     const currentReceived = getReceivedTotal(coin.color);
     assert(currentReceived <= Utils_UINT128_MAX() - coin.value, "ShieldedTreasury: overflow");
 
@@ -142,12 +145,16 @@ module ShieldedTreasury {
    * the retained change coin, and nothing at all when the send leaves no change,
    * so the sent coin's plaintext is disclosed beyond anything in public state.
    *
+   * @dev A self-addressed coin is auto-received by `sendShielded` but never recorded
+   * in _coins so it would be stranded. Therefore, this circuit rejects sends to self.
+   *
    * @notice Access control is NOT enforced here.
    * The consuming contract must gate this behind its own
    * authorization policy.
    *
    * Requirements:
    *
+   * - `recipient` must not be this contract's own address.
    * - A coin of the given `color` must exist in the treasury.
    * - The coin's value must be >= `amount`.
    * - Send must not cause sent total overflow.
@@ -163,6 +170,11 @@ module ShieldedTreasury {
     color: Bytes<32>,
     amount: Uint<128>
   ): ShieldedSendResult {
+    // `kernel.self()` stays outside the `||`: the compiler treats a ledger
+    // read behind a witness-conditioned branch as an undeclared disclosure
+    const self = kernel.self();
+    assert(recipient.is_left || recipient.right != self,
+           "ShieldedTreasury: self-send");
     assert(_coins.member(disclose(color)), "ShieldedTreasury: no balance");
 
     const coin = _coins.lookup(disclose(color));

package/multisig/ShieldedTreasuryStateless.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/ShieldedTreasuryStateless.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/ShieldedTreasuryStateless.compact)
 
 pragma language_version >= 0.26.0;
 
@@ -22,10 +22,16 @@ pragma language_version >= 0.26.0;
  * application time. Sufficiency is likewise enforced by `sendShielded` rather
  * than by an assert here.
  *
- * @notice "No ledger state" is not the same as "unobservable". A coin
- * commitment is a hash of the coin's data, so `sendShielded` can link a coin
- * receive to its later spend; `_send` declares that disclosure on the
- * consumer's behalf. Consumers that need to make the trade-off themselves
+ * @notice "No ledger state" is not the same as "unobservable". A coin's
+ * nullifier is a hash of the coin and this contract's address, and
+ * `sendShielded` derives the nonces of the sent coin and of the change from a
+ * public hash of the spent coin's nonce. Whoever knows a deposited coin can
+ * therefore find the spend that consumes it, recover the amount sent (on a
+ * partial spend the change commitment has the value as its only unknown),
+ * test candidate recipients against the sent coin's commitment, and repeat
+ * from the change coin for every later spend descending from it. `_send`
+ * declares the spent coin's disclosure on the consumer's behalf. Consumers
+ * that need to make the trade-off themselves
  * should note it is only declared here for convenience — it could be moved to
  * the caller. Separately, see `_send`'s warning about its return value, which
  * carries coin plaintext.

package/multisig/Signer.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/Signer.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/Signer.compact)
 
 pragma language_version >= 0.26.0;
 

package/multisig/UnshieldedTreasury.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/UnshieldedTreasury.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/UnshieldedTreasury.compact)
 
 pragma language_version >= 0.26.0;
 
@@ -61,6 +61,14 @@ module UnshieldedTreasury {
    * operation creates a zero-valued `_balances` entry, which
    * `getTokenBalance` reports the same as absence.
    *
+   * @warning Every non-zero deposit of a color rewrites the `_balances` entry
+   * that `_send` reads for that color, so a deposit that lands first
+   * invalidates every `_send` of the same color still waiting to be applied.
+   * A consumer that exposes `_deposit` without access control lets any
+   * depositor delay authorized sends for as long as they keep depositing; the
+   * sends must then be re-proven. No funds are lost. A zero-value deposit
+   * rewrites the entry with the same value and does not have this effect.
+   *
    * @notice Access control is NOT enforced here.
    * The consuming contract must gate this behind its own
    * authorization policy.
@@ -92,17 +100,16 @@ module UnshieldedTreasury {
   /**
    * @description Sends unshielded tokens from the treasury.
    *
-   * @warning Recipients are not validated. An unspendable recipient (such as a
-   * zero address) is accepted and permanently removes the funds from the
-   * contract. This is not a sanctioned burn — no unshielded equivalent of
-   * `shieldedBurnAddress` is exposed to contracts — so treat recipient
-   * validation as the consuming contract's responsibility.
+   * @warning Recipients other than this contract are not validated. An
+   * unspendable recipient (such as a zero address) is accepted and
+   * permanently removes the funds from the contract. This is not a
+   * sanctioned burn (no unshielded equivalent of `shieldedBurnAddress` is
+   * exposed to contracts), so treat recipient validation as the consuming
+   * contract's responsibility.
    *
-   * @warning Sending to this contract's own address zeroes the tracked balance
-   * while the funds stay held and spendable at the protocol level, after which
-   * `_send` will refuse to touch them. Recovery is only possible outside this
-   * module: a consumer may reconcile the exported `_balances`, or spend the
-   * funds through its own `sendUnshielded` call.
+   * @dev A self-addressed send is auto-received by `sendUnshielded` but
+   * still debited from `_balances`, so the funds would be stranded.
+   * Therefore, this circuit rejects sends to self.
    *
    * @notice Access control is NOT enforced here.
    * The consuming contract must gate this behind its own
@@ -110,6 +117,7 @@ module UnshieldedTreasury {
    *
    * Requirements:
    *
+   * - `recipient` must not be this contract's own address.
    * - The amount must be non-zero. The ledger rejects zero-value outputs.
    * - The treasury must hold sufficient balance for the given token color.
    *
@@ -124,6 +132,11 @@ module UnshieldedTreasury {
     color: Bytes<32>,
     amount: Uint<128>
   ): [] {
+    // `kernel.self()` stays outside the `||`: the compiler treats a ledger
+    // read behind a witness-conditioned branch as an undeclared disclosure
+    const self = kernel.self();
+    assert(!recipient.is_left || recipient.left != self,
+           "UnshieldedTreasury: self-send");
     assert(amount != 0, "UnshieldedTreasury: zero amount");
 
     const bal = getTokenBalance(color);

package/multisig/examples/ForwarderPrivateExample.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/examples/ForwarderPrivateExample.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/examples/ForwarderPrivateExample.compact)
 
 pragma language_version >= 0.26.0;
 
@@ -54,7 +54,8 @@ export circuit deposit(coin: ShieldedCoinInfo): [] {
  * @description Spends a previously-deposited shielded coin to the parent,
  * a coin public key. The caller proves knowledge of `(parent, opSecret)`
  * matching the stored commitment; the coin is sent as a shielded note, so the
- * parent stays hidden on-chain. If the input coin's value exceeds `value`,
+ * parent stays hidden from anyone who holds no deposited coin (see the
+ * `ForwarderPrivate` module notice). If the input coin's value exceeds `value`,
  * change is re-emitted back to the contract for future drains.
  *
  * The parent is a `ZswapCoinPublicKey`, never a `ContractAddress`: a shielded

package/multisig/examples/ForwarderShieldedExample.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/examples/ForwarderShieldedExample.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/examples/ForwarderShieldedExample.compact)
 
 pragma language_version >= 0.26.0;
 

package/multisig/examples/ForwarderUnshieldedExample.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/examples/ForwarderUnshieldedExample.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/examples/ForwarderUnshieldedExample.compact)
 
 pragma language_version >= 0.26.0;
 

package/multisig/examples/NativeShieldedTokenIssuerExample.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/examples/NativeShieldedTokenIssuerExample.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/examples/NativeShieldedTokenIssuerExample.compact)
 
 pragma language_version >= 0.26.0;
 

package/multisig/examples/ShieldedMultiSigV2Example.compact

@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: MIT
-// OpenZeppelin Compact Contracts v0.4.0-alpha.6 (multisig/examples/ShieldedMultiSigV2Example.compact)
+// OpenZeppelin Compact Contracts v0.4.0 (multisig/examples/ShieldedMultiSigV2Example.compact)
 
 pragma language_version >= 0.26.0;
 
@@ -42,7 +42,7 @@ export circuit deposit(coin: ShieldedCoinInfo): [] {
 }
 
 export circuit execute(
-  to: ShieldedMultiSigV2_Proposal_Recipient,
+  to: ShieldedMultiSigV2_Recipient,
   amount: Uint<128>,
   coin: QualifiedShieldedCoinInfo,
   pubkeys: Vector<2, Secp256k1Point>,