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

# Security best practices

> Protect your Dfns organization with roles, policies, address books, spam filtering, credential rotation, and secure deployment configuration.

Dfns provides multiple layers of security to protect your organization. This guide covers best practices for:

* **Roles**: Control who can do what
* **Policies**: Enforce rules on transactions and sensitive operations
* **Address book**: Protect against address poisoning attacks
* **Verified assets**: Filter out spam tokens and suspicious transactions

## Getting started safely

Before creating wallets or processing transactions, set up these foundational security controls.

### Initial policies

<Tip>
  The following three policies are the minimum recommended setup for any organization. They reduce the risk of errors and make sure a compromised admin cannot lock you out or escalate privileges unnoticed.
</Tip>

| Policy                      | Purpose                                                                                                                               |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Permission Assignment**   | Require approval before granting permissions to any user. Prevents a compromised admin from creating fake users with elevated access. |
| **Permission Modification** | Require approval before changing permission sets. Prevents escalation of existing roles.                                              |
| **Policy Modification**     | Require approval before changing policies. Ensures your security rules stay in place.                                                 |

To create these policies, go to `Org > Policies` and click **New Policy**. Select the appropriate activity type and configure approval groups to require at least a 1-out-of-2 quorum.

### Initial role setup

Follow the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege): give users only the roles they need for their responsibilities.

<Warning>
  Don't assign `ManagedFullAdminAccess` to everyone. Create custom roles instead.
</Warning>

See [role templates](#role-templates) below for recommended configurations.

## Policy templates by use case

### Treasury management

For internal teams managing company wallets with multi-signature approvals:

| Policy                      | Configuration                                                                       |
| --------------------------- | ----------------------------------------------------------------------------------- |
| Large transaction approval  | `TransactionAmountLimit` at \$100,000 USD with 2-of-3 approver quorum               |
| Recipient whitelisting      | `TransactionRecipientWhitelist` with known treasury, exchange, and vendor addresses |
| Daily spending cap          | `TransactionAmountVelocity` at \$500,000 USD per 24 hours                           |
| Transaction frequency limit | `TransactionCountVelocity` at 50 transactions per 24 hours                          |

<Tip>
  Use [wallet tags](/core-concepts/policies#using-wallet-tags) to scope policies to specific wallets. Tag treasury wallets with `treasury` and filter policies accordingly.
</Tip>

### Exchange/trading operations

For high-volume operations with exchange integrations:

| Policy                | Configuration                                                        |
| --------------------- | -------------------------------------------------------------------- |
| Withdrawal velocity   | `TransactionAmountVelocity` tuned to expected daily volume           |
| Exchange whitelisting | `TransactionRecipientWhitelist` with your exchange deposit addresses |
| High-value approval   | `TransactionAmountLimit` for withdrawals above operational threshold |

<Note>
  When using [exchange integrations](/features/exchanges), withdrawals to Dfns wallets may need to be whitelisted in the exchange's address book (e.g., [Kraken](/integrations/exchanges/kraken), [Coinbase Prime](/integrations/exchanges/coinbase-prime)).
</Note>

### B2B payments

For business payments and vendor disbursements:

| Policy              | Configuration                                                                                            |
| ------------------- | -------------------------------------------------------------------------------------------------------- |
| Vendor whitelisting | `TransactionRecipientWhitelist` with approved vendor addresses                                           |
| Tiered approvals    | Multiple `TransactionAmountLimit` policies: $10K (1 approver), $50K (2 approvers), \$100K+ (3 approvers) |
| AML screening       | `ChainalysisTransactionPrescreening` to screen outbound payments                                         |

## Role templates

Create these roles in `Settings > Permissions` and assign them to users based on their responsibilities.

### Admin

Full organizational control. Assign sparingly. You can use `ManagedFullAdminAccess` for this role. The list of whitelisted actions is maintained by Dfns and contains all permissions.

### Approver

Reviews and approves transactions. Cannot initiate them.

| Permission                                            | Purpose                                |
| ----------------------------------------------------- | -------------------------------------- |
| `Policies:Approvals:Approve`                          | Approve or reject pending transactions |
| `Policies:Approvals:Read`                             | View pending approvals                 |
| `Wallets:Read`                                        | View wallet details and balances       |
| `Wallets:Transfers:Read`, `Wallets:Transactions:Read` | View transaction details               |

### Operator

Day-to-day transaction operations.

| Permission                                                 | Purpose                      |
| ---------------------------------------------------------- | ---------------------------- |
| `Wallets:Read`                                             | View wallets                 |
| `Wallets:Transfers:Create`, `Wallets:Transfers:Read`       | Create and view transfers    |
| `Wallets:Transactions:Create`, `Wallets:Transactions:Read` | Create and view transactions |

### Read-only auditor

View-only access for compliance and audit purposes.

| Permission                                            | Purpose                            |
| ----------------------------------------------------- | ---------------------------------- |
| `Wallets:Read`                                        | View all wallets                   |
| `Wallets:Transfers:Read`, `Wallets:Transactions:Read` | View all transactions              |
| `Policies:Read`, `Policies:Approvals:Read`            | View policies and approval history |
| `Auth:Logs:Read`                                      | View audit logs                    |

### Service account (automation)

For server-to-server API integrations. See [service accounts guide](/guides/developers/service-account).

| Permission                    | Purpose                      |
| ----------------------------- | ---------------------------- |
| `Wallets:Read`                | Query wallet balances        |
| `Wallets:Transfers:Create`    | Initiate automated transfers |
| `Wallets:Transactions:Create` | Execute smart contract calls |

<Tip>
  Create separate service accounts for different automation tasks, each with minimal required permissions. Service accounts can be [configured as policy approvers](/core-concepts/policies#service-account-approvers) if needed, but keep automation and approval authority separate by default.
</Tip>

## Using the address book

The [address book](/guides/address-book) helps you manage blockchain addresses with human-readable aliases. Beyond convenience, it provides critical protection against address poisoning attacks.

### Address poisoning protection

In transaction history, the dashboard shows warnings for addresses not in your address book. This protects against "address poisoning" attacks where scammers:

1. Send tiny transactions from addresses that look nearly identical to legitimate ones (e.g., `0x1234...5678` vs `0x1234...5679`)
2. Hope you copy the wrong address when making your next transfer

<Warning>
  **Always verify addresses carefully.** Scammers exploit the fact that users often copy addresses from transaction history without checking every character.
</Warning>

**Best practice:** Add all addresses you regularly interact with to the address book immediately after your first transaction.

### Address book management

* **Use clear naming conventions**: Include vendor/partner name, purpose, and network (e.g., "acmecorp-payroll")
* **Add descriptions**: Note the business relationship or account purpose
* **Review regularly**: Remove aliases for addresses no longer in use
* **Update promptly**: Add new addresses as soon as you establish new business relationships

### Address book vs policy whitelisting

These are complementary features:

* **Address Book**: Visual convenience and warnings. Helps you recognize addresses in the UI. Does not block transactions.
* **TransactionRecipientWhitelist policy**: Enforcement. Blocks transactions to non-whitelisted addresses (or requires approval).

<Tip>
  Use both together: Address Book for awareness and easy identification, policies for enforcement.
</Tip>

## Handling spam and scam tokens

Blockchain addresses can receive unsolicited tokens (airdrops, spam, scam tokens). Dfns provides tools to filter these out.

### Verified assets and transactions

On each wallet page, use the filtering toggles to focus on legitimate assets:

**Assets section:**

* Toggle: "Only show verified assets"
* The "Verified" column indicates which tokens are verified by Dfns

**History section:**

* Toggle: "Only show verified transactions"
* The "Verified" column shows transaction verification status

### What "verified" means

* Dfns maintains a list of verified tokens and contracts across supported networks
* **Verified**: Token is a known legitimate asset
* **Not verified**: Token is not in Dfns's verified list (doesn't necessarily mean malicious, but warrants caution)

<Note>
  Testnet tokens are typically not verified. This is expected behavior.
</Note>

### Incoming transaction screening with Chainalysis

For additional protection, integrate [Chainalysis KYT](/integrations/aml-kyt/chainalysis) to automatically screen transactions:

* **`ChainalysisTransactionPrescreening`**: Screen outbound transactions before signing
* **`ChainalysisTransactionScreening`**: Flag incoming transactions from suspicious addresses

## Day-to-day security operations

### Reviewing pending approvals

When policies trigger approval requests:

1. Go to `Activity` in the dashboard to see pending approvals
2. Review the transaction details, including recipient address and amount
3. Verify the recipient is in your address book or is otherwise expected
4. Approve or reject the request

<Info>
  The person who initiated a transaction cannot approve it themselves (unless `initiatorCanApprove` is enabled on the policy).
</Info>

### Monitoring transactions

* Check the "Verified" column in transaction history
* Enable [webhooks](/guides/developers/webhooks) for real-time notifications
* Export transaction history for compliance records (`Wallet > Export`)

### Regular security hygiene

| Task                          | Frequency                    |
| ----------------------------- | ---------------------------- |
| Review user roles             | Quarterly                    |
| Audit address book entries    | Monthly                      |
| Review policy configurations  | Quarterly                    |
| Test new policies on testnets | Before production deployment |
| Review audit logs             | As needed                    |

<Tip>
  Before deploying new policies in production, test them on a [testnet](/guides/network-testnets) to ensure they work as expected.
</Tip>

## Next steps

<CardGroup cols={2}>
  <Card title="Create policies" icon="shield" href="/guides/create-policies">
    Step-by-step policy creation in the dashboard
  </Card>

  <Card title="Manage users and roles" icon="users" href="/guides/users-and-roles">
    Invite users and assign roles
  </Card>

  <Card title="Use the address book" icon="address-book" href="/guides/address-book">
    Create and manage address aliases
  </Card>

  <Card title="Chainalysis integration" icon="magnifying-glass" href="/integrations/aml-kyt/chainalysis">
    Set up AML/KYT transaction screening
  </Card>
</CardGroup>