Documentation Index
Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
Use this file to discover all available pages before exploring further.
Dfns supports Ethereum and many EVM-compatible networks. This guide covers features common to all EVM chains.
Supported EVM networks
Dfns supports numerous EVM-compatible networks including:
| Network | Type |
|---|
| Ethereum | Mainnet |
| Polygon | Layer 2 |
| Arbitrum One | Layer 2 |
| Base | Layer 2 |
| Optimism | Layer 2 |
| Avalanche C-Chain | Layer 1 |
| BNB Smart Chain | Layer 1 |
| Fantom Opera | Layer 1 |
| Celo | Layer 1 |
Gas and fees
All EVM transactions require gas, paid in the network’s native token (ETH, MATIC, etc.).
Gas must always be paid in the native token, even when transferring other tokens. Ensure your wallet has sufficient native token balance before initiating any transaction.
Fee priority
Use the priority field in the Transfer Asset endpoint to control gas prices:
| Priority | Description |
|---|
Slow | Lower gas price, may take longer to confirm |
Standard | Current market gas price |
Fast | Higher gas price for faster confirmation |
Transfers
Use the Transfer Asset endpoint for all EVM transfers:
- Native tokens: Use
kind: Native with amount in wei (1 ETH = 10^18 wei)
- ERC-20 tokens: Use
kind: Erc20 with the token’s contract address
- ERC-721 NFTs: Use
kind: Erc721 with the NFT’s contract address and tokenId
- ERC-7984 confidential tokens: Use
kind: Erc7984 with the token’s contract address (see below)
Smart contract interactions
For complex smart contract interactions beyond simple transfers, use the Broadcast Transaction endpoint with kind: Transaction. For fee-sponsored smart contract calls, use kind: UserOperations with a fee sponsor.
Nonce management
On EVM networks, every transaction from an account must include a sequential nonce. Transactions execute in strict nonce order — if nonce 5 is pending, nonce 6 cannot confirm until 5 does. This makes the nonce a scarce, ordered resource that must be managed carefully under concurrency.
Deterministic nonce allocation
Dfns manages nonces through a dedicated orchestration layer instead of relying on RPC queries. Nonces are reserved and allocated atomically across concurrent requests in an internal database. Once a nonce is assigned to a transaction, it cannot be reused.
This guarantees that every transaction is constructed and serialized in the correct order, even under high volume. If a transaction fails or is replaced, the system handles the state update automatically.
Transaction resource reservation
Every EVM transaction in Dfns explicitly reserves the resources it needs before broadcast:
- Standard transactions reserve a specific nonce to ensure strict sequencing.
- Fee-sponsored transactions (
UserOperations) reserve multiple nonces to coordinate between fee sponsors and smart accounts.
Resources are locked before broadcast and released only once the transaction is confirmed, cancelled, or identified as failed. Transactions that cannot succeed are stopped early, before entering the execution pipeline.
Speed up and cancel
EVM transactions can be sped up or cancelled while they are pending in the mempool (status Broadcasted). Cancellation also works on aborted transactions (status Aborted) to burn the reserved nonce and unblock subsequent transactions.
Both operations use Ethereum’s nonce-based transaction replacement:
- Speed up: Creates a new transaction with the same parameters but higher gas fees (10% bump or current Fast fees, whichever is higher). The higher-fee transaction replaces the original in the mempool.
- Cancel: Creates a zero-value self-transfer with the same nonce and higher gas. When mined, it consumes the nonce and invalidates the original transaction.
Success is not guaranteed. If the original transaction confirms before the replacement is mined, the operation will fail. Network congestion and timing affect the outcome.
Confidential tokens (ERC-7984)
Dfns supports ERC-7984 confidential tokens powered by Zama’s FHE. These tokens encrypt balances and transfer amounts on-chain using Fully
Homomorphic Encryption — no one can see your holdings by inspecting the blockchain.
Delegate decrypt rights to Dfns
Because balances are encrypted, Dfns needs explicit permission from each wallet to decrypt and display them. Without delegation, balances appear as encrypted handles (eg. 0xe9d6af...) instead of plaintext
amounts.
To enable decryption, call delegateForUserDecryption on the Zama ACL contract from your Dfns wallet. This is a one-time transaction per wallet per token
contract.
| Parameter | Value |
|---|
delegate | The Dfns delegatee address (see below) |
contractAddress | The ERC-7984 token contract you want Dfns to read |
expirationDate | Unix timestamp for when the delegation expires |
0xf0Ffdc93b7E186bC2f8CB3dAA75D86d1930A433D on both Sepolia and Mainnet.
See the full working example in the Dfns TypeScript SDK: delegate-fhe-decrypt
Once the delegation transaction is confirmed, Dfns automatically decrypts balances and transfer amounts for that wallet and token.
Dfns delegatee addresses
| Environment | Delegatee Address |
|---|
| Sepolia | 0x1f4252accc541a7a37868e02031b85ea00245d73 |
| Mainnet | 0x1f4252accc541a7a37868e02031b85ea00245d73 |
SDK integration
For full transaction control, use the Dfns SDK with viem or ethers.js. See complete examples:
