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
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.
SDK integration
For full transaction control, use the Dfns SDK with viem or ethers.js. See complete examples:
