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.
| 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 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:
| 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 |
B2B payments
For business payments and vendor disbursements:
| Policy | Configuration |
|---|
| Vendor whitelisting | TransactionRecipientWhitelist with approved vendor addresses |
| Tiered approvals | Multiple TransactionAmountLimit policies: 10K(1approver),50K (2 approvers), $100K+ (3 approvers) |
| AML screening | ChainalysisTransactionPrescreening 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.
| 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.
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:
- Send tiny transactions from addresses that look nearly identical to legitimate ones (e.g.,
0x1234...5678 vs 0x1234...5679)
- 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:
- Go to
Activity in the dashboard to see pending approvals
- Review the transaction details, including recipient address and amount
- Verify the recipient is in your address book or is otherwise expected
- 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 permissions | 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