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 poisoning protection: Outbound transfer screening and transaction history warnings
• Address book: Recognize your counterparties with human-readable aliases
• 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.

Address poisoning protection

In an address poisoning attack, a scammer:

1. Sends a tiny transaction to your wallet from an address that looks nearly identical to one you regularly send to (matching first and last characters)
2. Hopes you copy that lookalike address from your transaction history when making your next transfer

The dashboard protects you on both sides of this attack.

Outbound: transfer screening

When you create a transfer in the dashboard, the destination address is screened at the confirmation step:

• A red warning appears when the destination closely resembles an address the wallet has sent to before — the signature of an address poisoning attempt. The warning names the resembled address so you can compare.
• A yellow notice appears when the wallet has never sent to the destination before, prompting a first-time check.

Screening is advisory: it never blocks the transfer. To enforce blocking, combine it with a TransactionRecipientWhitelist policy.

Lookalike detection covers EVM networks, Tron, Stellar, XRP Ledger, Bitcoin, Solana, and TON. The first-time-counterparty check runs on every network.

Inbound: transaction history warnings

In transaction history, any address that is not one of your organization’s wallets and not in your address book is marked with a red warning icon. Hovering it shows the full address and a reminder to be careful when copying — so a poisoned deposit’s sender stands out instead of blending in with your real counterparties.

Truncated addresses in the dashboard also display characters from the middle of the address, selected at hash-based positions. An attacker can cheaply match an address’s visible start and end, but not these unpredictable middle characters, so lookalikes remain distinguishable even in truncated form.

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. Known addresses display as their alias, and everything else is flagged.

Using the address book

The address book helps you manage blockchain addresses with human-readable aliases. Beyond convenience, it powers the inbound warnings above: aliased addresses are recognized, everything else is flagged.

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

Create policies

Step-by-step policy creation in the dashboard

Manage users and roles

Invite users and assign roles

Use the address book

Create and manage address aliases

Chainalysis integration

Set up AML/KYT transaction screening