Rule Fields Reference

5 min

every rule in the policy engine is built from a set of fields that together define exactly when a rule applies and what happens when it does this reference covers each field, what it accepts, and how it affects rule matching field names each policy rule is defined by the following fields all fields except rule name and frequency actions are optional filters, leaving a field blank means “any value is permitted ” \field\ \options / values\ \description\ rule name free text a unique, descriptive identifier for the rule no two rules may share identical parameters vaults individual vaults, vault groups (core vaults, exchanges, gas vaults, vault groups) the source vault(s) from which a transaction may be initiated selecting a vault group applies the rule to all vaults in that group, including any added in the future action transfer, trade, on ramp, off ramp, mint, burn, contract call, view the type of operation the rule governs each action type can have its own independent set of policies creators individual users (by name/email) the users permitted to initiate (create) a transaction under this rule a creator does not need to be a signer signers individual users (by name/email) the users are eligible to approve a transaction under this rule approval thresholds and mandatory signers are configured in frequency actions counterparty contacts, contact groups, core vaults, dapps, exchanges, gas vaults, vault groups the permitted destination(s) for a transaction only transactions directed to a listed counterparty will match this rule asset any supported asset (1inch, aave, btc, eth, usdc, usdt, etc ) the specific asset the rule applies to leave blank for all assets chain alephium, aptos, arbitrum, avalanche c chain, base, bitcoin, ethereum, polygon, solana, tron, and more the blockchain network the rule applies to leave blank for all chains spend denomination native, fiat the currency unit in which spend limits and thresholds are expressed native = the asset’s native unit; fiat = usd equivalent action types primevault supports the following transaction action types, each configurable with independent policies action description transfer a standard onchain asset transfer from a vault to a counterparty address trade a swap executed within primevault’s platform (e g , usdt → usdc, usdt → eth) governed separately from transfers on ramp fiat to crypto on ramp transactions if no on ramp policy is configured, these transactions pass through by default define a policy to apply limits or approval requirements off ramp crypto to fiat transactions where crypto leaves the vault before fiat is delivered by a third party off ramp limits are strongly recommended given this two step exposure mint / burn token issuance (mint) and token destruction (burn) operations for supported assets contract call defi smart contract interactions (e g , staking, lending, dex interactions) integrated with primevault view read only access to vault data users assigned as creators under a view policy can see vault activity but cannot initiate or approve any transaction frequency actions frequency actions define the spend limits and approval requirements that apply within a given time window you can configure up to 5 frequency tiers per rule time windows per transaction limit applies to each individual transaction daily cumulative limit resets every 24 hours weekly cumulative limit resets every 7 days monthly cumulative limit resets each calendar month quarterly cumulative limit resets each quarter action type (within frequency) for each frequency tier you can configure one of two action types you can configure as many as you want let say 200 you need 2 approval 300 you need 3 approval and 400 block additional approval it gives the flexibility to add minimum number of approval required for transaction to go through as well as define the mandatory approvers block unconditionally reject any transaction that meets or exceeds the specified amount example per transaction amount ≥ $100 require 2 approvals, with akansh as mandatory amount ≥ $200 block entirely this means transactions between $100–$199 require 2 approvals (including robert), while anything $200+ is auto blocked multiple actions can be stacked within a single frequency tier in increasing order of amount, allowing fine grained tiered control