Policies

Set programmable guardrails that automatically allow, block, or route sensitive actions through normal approval in your workspace. Policies evaluate every withdrawal and smart contract call against rules you define, so risky activity is stopped before it ever reaches the blockchain.

Overview

A policy is a set of rules that runs automatically whenever someone initiates a guarded action, such as requesting a withdrawal or calling a smart contract. Each rule describes a condition (for example, "withdrawal value over $10,000 to a non-whitelisted address") and an effect:

• Deny: block the action outright
• Allow: let the action skip the approval queue and proceed directly

Policies act as an always-on layer of defense that complements your signer approvals. Instead of relying on every approver to remember your treasury rules, you encode those rules once and let Fystack enforce them on every transaction.

How Policies Are Evaluated

When a guarded action runs, Fystack checks it against every active policy that targets the relevant wallet and applies a custody-safe decision model:

1. Deny always wins: if any rule matches with a Deny effect, the action is blocked, even if another rule would allow it.
2. Allow bypasses approval: if a rule matches with an Allow effect and nothing denies, the action skips the approval queue and proceeds.
3. No match: if no rule matches, the action continues through your normal approval flow.

Trigger Actions

Each rule applies to one trigger action, the type of operation it guards:

How to Create a Policy

Step 1: Open the Policies Page

In the left sidebar, open Policies, then click Create Policy.

Step 2: Name the Policy and Choose an Approval Group

Give the policy a clear Name that describes what it protects (for example, "Large withdrawal guard"). Then select the Approval Group that will review changes to this policy.

Every policy is tied to an approval group. This means a policy cannot be silently created or edited, any change must be reviewed and approved, the same way a withdrawal is.

Step 3: Target Specific Wallets (Optional)

By default, a policy applies to all wallets in the workspace. To scope it to a subset, select one or more wallets in the Wallets field. The policy's rules will only be evaluated for actions on those wallets.

Step 4: Add Rules

Add one or more rules to the policy. For each rule, choose the Trigger (Withdrawal or Contract Call), build the Condition, and pick the Effect (Allow or Deny).

The condition builder shows the fields available for the selected trigger, so you can construct expressions without memorizing field names. See Writing Rule Conditions below for examples.

Policies also programmable with JSON builder, which is useful for power users who want to copy/paste rules or use more complex logic than the UI supports.

Step 5: Submit for Approval

Click Create. Because every policy is approval-gated, the new policy is not active yet, it is submitted to its approval group as a Pending Approval request, along with all of its rules.

Step 6: Approve the Policy

A member of the assigned approval group opens the pending request, reviews the proposed policy and its rules, and approves it. Only then does the policy become Active and start guarding transactions.

Writing Rule Conditions

A condition is an expression that evaluates to true or false. When it is true, the rule's effect applies. Combine fields with and, or, and not, and compare values with operators like >, >=, ==, and !=.

Condition Fields

The fields available in the builder depend on the rule's trigger. Use the labels below when deciding which field belongs in a rule.

Available on Every Trigger

Withdrawal Fields

Withdrawal Activity Fields

Contract Call Fields

Example Conditions

Policy Statuses

Change History

Every change to a policy is recorded. The policy's History shows each revision with who proposed it, what changed (field by field), and whether it was approved or rejected. This gives you a complete audit trail of how your guardrails evolved over time.

Best Practices

• Start with Deny rules for your highest-risk scenarios (large transfers, unknown destinations) before adding convenience Allow rules
• Remember that Deny always wins, use this to set hard limits that no Allow rule can override
• Scope policies to specific wallets when different wallets have different risk profiles, rather than applying one broad policy everywhere
• Use Allow rules sparingly, they bypass your approval queue, so reserve them for low-value, clearly trusted patterns
• Validate every condition before submitting, and review the change in the approval step to confirm it behaves as intended
• Treat policy changes with the same care as withdrawals, the approval gate exists so no single person can weaken your controls unnoticed