@chipi-stack/backend 14.12.1 → 14.12.2

package/dist/index.d.mts

@@ -535,9 +535,16 @@ declare class ChipiTreasury {
      * from their own server could see a quorum applied to a proposal but never
      * choose it.
      *
-     * IMPORTANT: a quorum can only RAISE `requiredApprovals` above the wallet's
-     * on-chain threshold. The chain is the hard floor, so a quorum set below it
-     * produces proposals that reach `APPROVED` here and then revert at execute.
+     * IMPORTANT: a quorum can only RAISE `requiredApprovals`, never lower it
+     * below the wallet's on-chain threshold. Set one below and it is SILENTLY
+     * RAISED at propose time, not rejected and not reverted: a `routineQuorum`
+     * of 1 on a 2-of-3 wallet is clamped to 2 and executes normally. The risk is
+     * a policy that reads 1 everywhere while the system uses 2.
+     *
+     * The server now rejects that outright so the stored value means what it
+     * says (server-side enforcement, live since 2026-08; no SDK upgrade
+     * needed). To genuinely lower the requirement, lower the on-chain
+     * threshold first with `propose_set_threshold` (48h timelock).
      *
      * Server-only: it needs a `sk_`.
      *
@@ -2057,9 +2064,14 @@ declare const TIMELOCK_SECONDS: {
     readonly REMOVE_GUARDIAN: 86400;
     readonly RECOVERY: 604800;
 };
-/** `DEFAULT_OP_EXPIRY_SECONDS` from `pending_ops.cairo:78`. After this
- * window from propose-time, the pending op auto-expires even if no one
- * calls cancel. UI should reflect this so users don't sit on a stale op. */
+/** `DEFAULT_OP_EXPIRY_SECONDS` from `pending_ops.cairo:78`. The window is
+ * measured from `valid_after`, not from propose time:
+ * `expires_at = now + timelock + DEFAULT_OP_EXPIRY_SECONDS`
+ * (governance/component.cairo). So a 48h op (add_owner, set_threshold) lives
+ * 16 days from propose and a 7d recovery lives 21. Read `get_pending_op` for
+ * the exact `expires_at` instead of adding 14d to the propose timestamp. The
+ * op auto-expires at that point even if no one calls cancel; UI should
+ * reflect it so users don't sit on a stale op. */
 declare const DEFAULT_OP_EXPIRY_SECONDS = 1209600;
 /** Owner role on-chain. ROLE_OWNER can sign OEs; ROLE_GUARDIAN can
  * only `initiate_recovery` (no general signing power). */

package/dist/index.d.ts

@@ -535,9 +535,16 @@ declare class ChipiTreasury {
      * from their own server could see a quorum applied to a proposal but never
      * choose it.
      *
-     * IMPORTANT: a quorum can only RAISE `requiredApprovals` above the wallet's
-     * on-chain threshold. The chain is the hard floor, so a quorum set below it
-     * produces proposals that reach `APPROVED` here and then revert at execute.
+     * IMPORTANT: a quorum can only RAISE `requiredApprovals`, never lower it
+     * below the wallet's on-chain threshold. Set one below and it is SILENTLY
+     * RAISED at propose time, not rejected and not reverted: a `routineQuorum`
+     * of 1 on a 2-of-3 wallet is clamped to 2 and executes normally. The risk is
+     * a policy that reads 1 everywhere while the system uses 2.
+     *
+     * The server now rejects that outright so the stored value means what it
+     * says (server-side enforcement, live since 2026-08; no SDK upgrade
+     * needed). To genuinely lower the requirement, lower the on-chain
+     * threshold first with `propose_set_threshold` (48h timelock).
      *
      * Server-only: it needs a `sk_`.
      *
@@ -2057,9 +2064,14 @@ declare const TIMELOCK_SECONDS: {
     readonly REMOVE_GUARDIAN: 86400;
     readonly RECOVERY: 604800;
 };
-/** `DEFAULT_OP_EXPIRY_SECONDS` from `pending_ops.cairo:78`. After this
- * window from propose-time, the pending op auto-expires even if no one
- * calls cancel. UI should reflect this so users don't sit on a stale op. */
+/** `DEFAULT_OP_EXPIRY_SECONDS` from `pending_ops.cairo:78`. The window is
+ * measured from `valid_after`, not from propose time:
+ * `expires_at = now + timelock + DEFAULT_OP_EXPIRY_SECONDS`
+ * (governance/component.cairo). So a 48h op (add_owner, set_threshold) lives
+ * 16 days from propose and a 7d recovery lives 21. Read `get_pending_op` for
+ * the exact `expires_at` instead of adding 14d to the propose timestamp. The
+ * op auto-expires at that point even if no one calls cancel; UI should
+ * reflect it so users don't sit on a stale op. */
 declare const DEFAULT_OP_EXPIRY_SECONDS = 1209600;
 /** Owner role on-chain. ROLE_OWNER can sign OEs; ROLE_GUARDIAN can
  * only `initiate_recovery` (no general signing power). */

package/dist/index.js

@@ -2920,9 +2920,16 @@ var ChipiTreasury = class {
    * from their own server could see a quorum applied to a proposal but never
    * choose it.
    *
-   * IMPORTANT: a quorum can only RAISE `requiredApprovals` above the wallet's
-   * on-chain threshold. The chain is the hard floor, so a quorum set below it
-   * produces proposals that reach `APPROVED` here and then revert at execute.
+   * IMPORTANT: a quorum can only RAISE `requiredApprovals`, never lower it
+   * below the wallet's on-chain threshold. Set one below and it is SILENTLY
+   * RAISED at propose time, not rejected and not reverted: a `routineQuorum`
+   * of 1 on a 2-of-3 wallet is clamped to 2 and executes normally. The risk is
+   * a policy that reads 1 everywhere while the system uses 2.
+   *
+   * The server now rejects that outright so the stored value means what it
+   * says (server-side enforcement, live since 2026-08; no SDK upgrade
+   * needed). To genuinely lower the requirement, lower the on-chain
+   * threshold first with `propose_set_threshold` (48h timelock).
    *
    * Server-only: it needs a `sk_`.
    *