Skip to content

Best Practices for Policies in Fordefi

This page guides administrators in designing secure, efficient, and maintainable transaction policy structures.

Fordefi’s policy engine behaves like a structure of ordered firewall rules—with whitelist/blacklist-style logic—pinging from top (most specific) to bottom (default fallback).

The “Default Transaction Policy Action” acts as the final, catch-all rule. It is always present and unchangeable (except for the default action - more on that below), so ensuring unhandled transactions still follow safe governance.

How Fordefi’s Policy Engine works

Fordefi’s Policy Engine uses ordered rule evaluation. Policies consist of an ordered list of rules and the Policy Engine evaluates each new transaction by finding the first matching rule in the policy, top-down. The first rule that matches is applied, with later rules being skipped.

Types of rule actions

A rule is paired with an action. The action can be one of the following:

  • Allow: Auto-approve the transaction.
  • Block: Immediately halt the transaction.
  • Require Approval: Send to approvers before execution.

Default Rule

This rule is built-in to Fordefi by default and remains ever present at the bottom of all the custom rules.

  • Conditions are fixed to Any.
  • Admins cannot move or delete it.

It is recommended to adjust its action to a more restrictive one (for example, require approval or block), rather than leave permissive, by default.

Best Practice Methodology

Start with a safe baseline

Set a restrictive Default Action: Change from Allow all to either Require approval or Block.

This ensures fallback safety.

Use specific rules first

Prioritize granular, targeted exemptions at the top of the list.

These might include:

  • Trusted contracts (through) Fordefi’s DApp directory whitelist) — for example, allow USDC trades on Uniswap V3 without approval.
  • Frequent interactions that are business-critical and low risk.
  • Rules based on Initiator, Origin vault, Transaction Type, Recipient, Asset, Max Amount, and optionally Periodic Limits.

Tier by amount: small to large

Example structure:

  • Rules for small amounts—allow auto-approve (for example, ≤ $1000)
  • Medium amounts—require two approvers (for example, ≤ $1M)
  • High amounts—require a higher authority or blocking

This “tiered” approach optimizes throughput while scaling security overhead.

Define a safe baseline approval policy

For high-risk or large-value transactions, configure Require Approval with at least three approvers in your organizagtion quorum, ideally high-ranking admins.

This prevents single-point-of-failure risk and enforces multi-signature governance.

Policy design checklist

  • Define default action: Set fallback to Require Approval orBlock rather than Allow.
  • Add precise Allow rules: Whitelist trusted DApps through the DApp directory to streamline operations.
  • Tier small transactions: Auto-allow minimal amounts (for example, micro-transactions) to reduce friction.
  • Scale denial or approval: For increasing amounts, add rules requiring more approvers or blocking.
  • Set approval structure: Default to at least three approvers or quorum of senior admins for sensitive rules.
  • Review order: Confirm rule priority: most specific at top → broadest → default.
  • Leverage meta conditions: Use conditions like vault origin, asset types, transaction type, periodic limits.
  • Simplicity outside: Keep rules clear and understandable; avoid generic or overly complicated conditions.
  • Regular review: Audit policies periodically to tune controls and avoid drift.

Behind the Firewall Analogy

Think of your Fordefi policy list as a firewall rule table:

  • Top rules: highly specific, trusted, low-risk flows (“allow this explicitly”)
  • Middle rules: guardrails (“require multi-approval” or block risk)
  • Bottom rule: default deny or skeptical posture (“everything else needs scrutiny”)

The rationale behind this approach is that a layered logic ensures operational efficiency for routine processes while keeping the guard rails tight for sensitive operations.

Summary and recommendations

  • Secure by default: Always start with a restrictive default.
  • Make common actions easy: Use specific allow-list rules for trusted workflows.
  • Empower with tiering: Scale approval requirements with transaction risk level.
  • Operational integrity: Ensure high-value transactions require quorum.
  • Maintain order: Correct priority ordering is crucial.
  • Regularly Review: Audit and refine policies as your organizational risk posture evolves.
Previous page
Next page