Problem
Add support for amount-tiered signature thresholds on send_asset, so the number of cosigner signatures required scales with the transaction's value (and optionally per-faucet).
Today the transaction_threshold is computed purely from which procedures the tx calls (per the cryptography audit). The amount field of a p2id send is opaque to the threshold logic — confirmed in P2idProposalMetadata, which carries only recipientId, faucetId, amount with no tier or limit field.
This means a treasury sending 1 USDC and a treasury sending 1,000,000 USDC require exactly the same number of signatures. There's no native way to express "small ops should be fast, large transfers should require unanimous review."
A multisig configured for the current model has to pick one of two unsatisfying defaults:
- Low send_asset threshold → small operational sends are fast, but the same threshold enables draining the treasury.
- High send_asset threshold → large transfers are properly gated, but every petty-cash send becomes a coordination event.
Amount-tiered thresholds resolve this trade-off and are table-stakes for production-grade multisigs targeting institutional treasuries — Safe (via Allowance / Spending Limit modules), Squads (Spending Limits), Fireblocks (policy engine), and BitGo (wallet policy) all ship this primitive.
Adding it to Miden multisig would unlock realistic treasury operations: small recurring spends approved quickly, mid-tier vendor payments requiring a majority, large capital allocations requiring unanimous consent — all under a single account, configurable per faucet.
Problem
Add support for amount-tiered signature thresholds on send_asset, so the number of cosigner signatures required scales with the transaction's value (and optionally per-faucet).
Today the transaction_threshold is computed purely from which procedures the tx calls (per the cryptography audit). The amount field of a p2id send is opaque to the threshold logic — confirmed in P2idProposalMetadata, which carries only recipientId, faucetId, amount with no tier or limit field.
This means a treasury sending 1 USDC and a treasury sending 1,000,000 USDC require exactly the same number of signatures. There's no native way to express "small ops should be fast, large transfers should require unanimous review."
A multisig configured for the current model has to pick one of two unsatisfying defaults:
Amount-tiered thresholds resolve this trade-off and are table-stakes for production-grade multisigs targeting institutional treasuries — Safe (via Allowance / Spending Limit modules), Squads (Spending Limits), Fireblocks (policy engine), and BitGo (wallet policy) all ship this primitive.
Adding it to Miden multisig would unlock realistic treasury operations: small recurring spends approved quickly, mid-tier vendor payments requiring a majority, large capital allocations requiring unanimous consent — all under a single account, configurable per faucet.