Security best practices

Protect your organization with roles, policies, address book, and spam filtering.

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

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.

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: give users only the roles they need for their responsibilities.

Don’t assign ManagedFullAdminAccess to everyone. Create custom roles instead.

See 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

Use wallet tags to scope policies to specific wallets. Tag treasury wallets with treasury and filter policies accordingly.

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

When using exchange integrations, withdrawals to Dfns wallets may need to be whitelisted in the exchange’s address book (e.g., Kraken, Coinbase Prime).

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.

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

Create separate service accounts for different automation tasks, each with minimal required permissions. Service accounts can be configured as policy approvers if needed, but keep automation and approval authority separate by default.

Using the address book

The 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

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

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

Use both together: Address Book for awareness and easy identification, policies for enforcement.

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)

Testnet tokens are typically not verified. This is expected behavior.

Incoming transaction screening with Chainalysis

For additional protection, integrate Chainalysis KYT 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

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

Monitoring transactions

• Check the “Verified” column in transaction history
• Enable 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

Before deploying new policies in production, test them on a testnet to ensure they work as expected.

Next steps

Creating policies

Step-by-step policy creation in the dashboard

Managing users and roles

Invite users and assign roles

Using the address book

Create and manage address aliases

Chainalysis integration

Set up AML/KYT transaction screening