Fortary’s policy engine governs how your organization manages transaction approvals, policy change approvals, and user-level permissions. These settings define the rules your team operates under — how many signatures are required, who can approve what, and whether users may approve requests they initiated.
Fortary’s Policy controls are incredibly modular and customizable to meet most needs!
Policy engine settings are currently configured by the Fortary team on behalf of your organization. Self-service configuration will be available in a future release. Contact your Fortary account team to request changes to any of the settings described below.
Transaction Approval Thresholds
Every vault in your organization can have an independent approval threshold for transactions. This is the minimum number of distinct Approver signatures required before an Issuer can submit a transaction to the blockchain.
How It Works
The threshold is expressed as M-of-N: M approvals required from N users who hold the Approver role on that vault.
| Threshold | Behavior |
|---|
| 1-of-N | Any single approver can approve; first approval moves to Approved |
| 2-of-N | Two distinct approvers must independently approve |
| 3-of-N | Three distinct approvers must independently approve |
Custom Policy Restrictions on Transactions
The threshold of approvers can also be configured based on your custom setup. Specific threshold amounts, edge cases, or specific easying of restrictions can be set using:
- Transaction Type (Staking, Transfer, etc…)
- Token (BTC, ETH, AVAX, etc…)
- Amount ($50,000 or 0.5BTC)
- You can set this as a notional amount or a token amount
| Example Custom Policy Controls |
|---|
| If the tx amount is <= $100,000, it will require at least 2 approvals. |
| If the tx amount is > $100,000 and <= $3,000,000, it will require at least 3 approvals. |
| If the tx amount is > $3,000,000, it will require at least 4 approvals. |
| EXCEPT- When the transaction is an AVAX Validator Staking transaction, only require 1 approval |
Per-Vault Configuration
Different vaults can have different thresholds based on the value or risk profile of assets held. A typical configuration might look like:
| Vault Profile | Threshold |
|---|
| Low-value operational wallet | 1-of-N |
| Standard treasury | 2-of-N |
| High-value cold storage | 3-of-N |
An approver cannot approve the same transaction more than once. Each approval must come from a different user.
Policy Request Approval Thresholds
The approval threshold for policy requests (such as whitelisting a new address or removing one) is configured separately from transaction thresholds. This lets organizations apply stricter controls to policy changes than to day-to-day transactions — or vice versa, depending on operational needs.
| Setting | Description |
|---|
| Required approvers for policy requests | How many approvers must sign before a policy change takes effect |
| Per-vault configuration | Policy thresholds are also configured at the vault level |
Self-Approval Controls
By default, a user who holds both the Initiator and Approver roles can create a request and then approve it themselves. For organizations that require stricter segregation of duties, this behavior can be disabled.
| Setting | Behavior |
|---|
| Allow self-approval | Initiators may approve requests they created (default) |
| Disallow self-approval | An approver cannot count their own initiated request toward the threshold; a separate approver is always required |
DeFi Operator Policy Controls
Users with the DeFi Operator role can independently initiate and issue transactions to DeFi protocols via WalletConnect, without the standard M-of-N approval flow. Because of this independence, each DeFi operator operates within their own configurable policy envelope.
| Setting | Description |
|---|
| Per-transaction limit | Maximum value a DeFi operator can execute in a single transaction |
| Periodic spending limit | Maximum value a DeFi operator can execute within a rolling time window |
| Permitted protocols | Specific smart contracts or dApp connections the operator is authorized to use |
DeFi transactions bypass the standard approval workflow. DeFi has it’s own custom policy workflow to accommodate the speed of execution that is required of these tranasactions. It is important to configure appropriate spending limits for each DeFi operator and review their activity regularly.
Approval Expiry for Staking Transactions
Avalanche staking transactions have a time-sensitive launch window. If a staking transaction sits in Pending Review or Approved status and cannot be issued with at least 14 days remaining before the intended staking start date, it will be automatically marked Expired and cannot be issued.
Organizations running staking operations should ensure their approval workflows are configured to move quickly enough to avoid expiry.
Requesting a Configuration Change
To adjust any policy engine settings for your organization, contact the Fortary team with:
- The specific setting you want to change
- The vault(s) it applies to
- The desired new value (e.g., “increase transaction approval threshold from 1 to 2 on Vault X”)
Your Fortary account team will apply the change and confirm once it is active. 
