Security Best Practices

Getting started safely

Before creating wallets or processing transactions, configure the following foundational security controls.

Initial policies

Tip: The following three policies are the minimum recommended configuration for any organization. They reduce the risk of user error and prevent a compromised administrator from escalating privileges or locking out other administrators.

Policy	Purpose
Permission assignment	Requires approval before granting permissions to any user. Prevents a compromised admin from creating users with elevated access.
Permission modification	Requires approval before modifying permission sets. Prevents privilege escalation of existing roles.
Policy modification	Requires approval before changing policies, ensuring security controls remain enforced.

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

Initial role setup

Follow the principle of least privilege; that is, grant users only the permissions required to perform their responsibilities.

Warning: Do not assign ManagedFullAdminAccess broadly. Create custom roles instead and assign administrative access sparingly.

See role templates for recommended configurations.

Policy templates by use case

Treasury management

For internal teams managing company wallets with multi-signature approval workflows:

Policy	Purpose
Large transaction approval	TransactionAmountLimit of USD 100,000 with a 2-of-3 approver quorum
Recipient whitelisting	TransactionRecipientWhitelist for treasury, exchange, and vendor addresses
Daily spending cap	TransactionAmountVelocity set to USD 500,000 per 24 hours
Transaction frequency limit	TransactionCountVelocity set to 50 transactions per 24 hours

Note: Use wallet tags to scope policies to specific wallets. For example, tag treasury wallets with treasury and apply policies selectively.

Exchange and trading operations

For high-volume workflows that integrate with exchanges:

Policy	Configuration
Withdrawal velocity	TransactionAmountVelocity tuned to expected daily volume
Exchange whitelisting	TransactionRecipientWhitelist configured with exchange deposit addresses
High-value approvals	TransactionAmountLimit applied above operational thresholds

Note: When using exchange integrations, withdrawals to IBM Digital Asset Haven wallets may need to be whitelisted in the exchange’s address book (for example, Kraken and Coinbase Prime).

B2B payments

For vendor payments and business disbursements:

Policy	Configuration
Vendor whitelisting	TransactionRecipientWhitelist with approved vendor addresses
Tiered approvals	Multiple TransactionAmountLimit policies: USD 10,000 (1 approver), USD 50,000 (2 approvers), USD 100,000+ (3 approvers)
AML screening	ChainalysisTransactionPrescreening for outbound payments

Role templates

Create these roles in Settings > Permissions and assign them based on user responsibilities.

Admin

This role provides full organizational control. It should be assigned sparingly.

You may use ManagedFullAdminAccess for this role. The list of permitted actions is maintained by IBM Digital Asset Haven and includes all available permissions.

Approver

This role reviews and approves transactions but cannot initiate them.

Policy	Purpose
Policies:Approvals:Approve	Approve or reject pending transactions
Policies:Approvals:Read	View pending approval requests
Wallets:Read	View wallet details and balances
Wallets:Transfers:Read, Wallets:Transactions:Read	View transaction details

Operator

This role handles day-to-day transaction execution.

Policy	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

This role provides view-only access for compliance and audit purposes.

Policy	Purpose
Wallets:Read	View all wallets
Wallets:Transfers:Read, Wallets:Transactions:Read	View all transfers
Policies:Read, Policies:Approvals:Read	View policies and approval history
Auth:Logs:Read	View audit logs

Service account (automation)

This role is used for server-to-server API integrations. For more information, See service accounts guide.

Policy	Purpose
Wallets:Read	Query wallet balances
Wallets:Transfers:Create, Wallets:Transactions:Read	Initiate automated transfers
Wallets:Transactions:Create	View policies and approval history
Auth:Logs:Read	Execute smart contract calls

Note: Create separate service accounts for different automation tasks, and grant only the minimum required permissions to each.

Using the address book

The address book allows you to manage blockchain addresses using human-readable aliases. In addition to improving usability, it provides important protection against address poisoning attacks.

Address poisoning protection

In transaction history views, the dashboard displays warnings when interacting with addresses that are not in your address book. This helps protect against address poisoning attacks, in which attackers:

• Send small transactions from addresses that closely resemble legitimate ones (for example, 0x1234…5678 versus 0x1234…5679)
• Rely on users copying the incorrect address from transaction history during future transfers

Warning: Always verify recipient addresses carefully. Attackers exploit the tendency to copy addresses without checking every character.

As best practice, add any address you expect to reuse to the address book immediately after its first legitimate transaction.

Address book management best practices

Follow these recommendations to keep your address book accurate and effective:

• Use clear naming conventions: Include the vendor or partner name, business purpose, and network (for example, acmecorp-payroll-eth).
• Add descriptions: Document the business relationship or account purpose for each address.
• Review regularly: Remove entries that are no longer in use.
• Update promptly: Add new addresses as soon as new business relationships are established.

Address book versus policy-based whitelisting

The address book and recipient whitelist policies serve different but complementary purposes:

• Address book: Provides visual identification and warnings within the user interface. It does not block transactions.
• TransactionRecipientWhitelist policy: Enforces controls by blocking transactions to non-whitelisted addresses or requiring approval.

Note: Use both features together: the address book for visibility and ease of recognition, and policies for enforcement.

Handling spam and scam tokens

Blockchain wallets may receive unsolicited tokens through airdrops or spam campaigns. These tokens can clutter wallet views and, in some cases, attempt to deceive users. IBM Digital Asset Haven provides verification and filtering tools to help reduce exposure to these risks.

Verified assets and transactions

Each wallet page includes filtering options to display only verified assets and transactions.

• Assets section
  • Enable Only show verified assets.
  • The Verified column indicates whether a token is verified by IBM Digital Asset Haven.
• Transaction history
  • Enable Only show verified assets.
  • The Verified column indicates the transaction’s verification status.

Meaning of Verified

• IBM Digital Asset Haven maintains a curated list of verified tokens and smart contracts across supported networks
• Verified indicates the token is a known, legitimate asset.
• Not verified indicates the asset is not included in IBM Digital Asset Haven’s verified list

Note: Not verified does not imply that an asset is malicious. It indicates that the asset should be handled with caution.

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

Transaction screening with Chainalysis

For additional protection, you can integrate Chainalysis to automatically screen blockchain transactions:

• ChainalysisTransactionPrescreening: Screens outbound transactions before signing.
• ChainalysisTransactionScreening: Flags incoming transactions associated with high-risk or sanctioned addresses.

These screenings help detect potential compliance or security issues earlier in the transaction lifecycle.

Day-to-day security operations

Reviewing pending approvals

When a policy requires approval, follow these steps:

1. Navigate to Activity in the dashboard to view pending approvals.
2. Review transaction details, including the recipient address and amount.
3. Confirm that the recipient address is expected and, when possible, present in the address book.
4. Approve or reject the request.

Note: A user who initiates a transaction cannot approve that transaction unless the initiatorCanApprove option is explicitly enabled in the policy.

Monitoring transactions

Use the following tools to maintain operational visibility:

• Review the Verified column in transaction history.
• Enable webhooks for real-time notifications.
• Export transaction records for compliance and audit purposes using Wallet > Export.

Ongoing security hygiene

Regular security reviews help reduce risk and identify configuration drift.

Task	Recommended frequency
Review user roles and permissions	Quarterly
Audit address book entries	Monthly
Review policy configurations	Quarterly
Test new policies on testnets	Before production deployment
Review audit logs	As needed

Note: Always test new or modified policies on a testnet before deploying them to production environments.