> ## Documentation Index
> Fetch the complete documentation index at: https://help.primevault.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rule Fields Reference

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.*

> [!NOTE]
>
> Multiple actions can be stacked within a single frequency tier in increasing order of amount, allowing fine-grained tiered control.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.