Skip to main content
Dfns provides multiple layers of security to protect your organization. This guide covers best practices for:
  • Permissions: 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.
PolicyPurpose
Permission AssignmentRequire approval before granting permissions to any user. Prevents a compromised admin from creating fake users with elevated access.
Permission ModificationRequire approval before changing permission sets. Prevents escalation of existing roles.
Policy ModificationRequire 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 permissions setup

Follow the principle of least privilege: give users only the permissions they need for their role.
Don’t assign ManagedFullAdminAccess to everyone. Create role-specific permissions instead.
See Permissions templates below for recommended role configurations.

Policy templates by use case

Treasury management

For internal teams managing company wallets with multi-signature approvals:
PolicyConfiguration
Large transaction approvalTransactionAmountLimit at $100,000 USD with 2-of-3 approver quorum
Recipient whitelistingTransactionRecipientWhitelist with known treasury, exchange, and vendor addresses
Daily spending capTransactionAmountVelocity at $500,000 USD per 24 hours
Transaction frequency limitTransactionCountVelocity 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:
PolicyConfiguration
Withdrawal velocityTransactionAmountVelocity tuned to expected daily volume
Exchange whitelistingTransactionRecipientWhitelist with your exchange deposit addresses
High-value approvalTransactionAmountLimit 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:
PolicyConfiguration
Vendor whitelistingTransactionRecipientWhitelist with approved vendor addresses
Tiered approvalsMultiple TransactionAmountLimit policies: 10K(1approver),10K (1 approver), 50K (2 approvers), $100K+ (3 approvers)
AML screeningChainalysisTransactionPrescreening to screen outbound payments

Permissions templates by role

Create these permissions 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.
PermissionPurpose
Policies:Approvals:ApproveApprove or reject pending transactions
Policies:Approvals:ReadView pending approvals
Wallets:ReadView wallet details and balances
Wallets:Transfers:Read, Wallets:Transactions:ReadView transaction details

Operator

Day-to-day transaction operations.
PermissionPurpose
Wallets:ReadView wallets
Wallets:Transfers:Create, Wallets:Transfers:ReadCreate and view transfers
Wallets:Transactions:Create, Wallets:Transactions:ReadCreate and view transactions

Read-only auditor

View-only access for compliance and audit purposes.
PermissionPurpose
Wallets:ReadView all wallets
Wallets:Transfers:Read, Wallets:Transactions:ReadView all transactions
Policies:Read, Policies:Approvals:ReadView policies and approval history
Auth:Logs:ReadView audit logs

Service account (automation)

For server-to-server API integrations. See service accounts guide.
PermissionPurpose
Wallets:ReadQuery wallet balances
Wallets:Transfers:CreateInitiate automated transfers
Wallets:Transactions:CreateExecute smart contract calls
Create separate service accounts for different automation tasks, each with minimal required permissions.

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

TaskFrequency
Review user permissionsQuarterly
Audit address book entriesMonthly
Review policy configurationsQuarterly
Test new policies on testnetsBefore production deployment
Review audit logsAs needed
Before deploying new policies in production, test them on a testnet to ensure they work as expected.

Next steps