Transaction Management 2.0

Dfns has upgraded its transaction management system to address a common failure point in blockchain platforms at scale: unreliable transaction execution caused by weak resource management.

This release adds explicit nonce control, transaction cancellation, and transaction speed-up, and lays the groundwork for a broader transaction resource management framework. Since our first release (read: Transaction Management 1.0), the goal has always been to reduce transaction failures, make transaction execution predictable under concurrency, and provide clear, reliable recovery paths when things go wrong.

The challenge of unmanaged transaction resources

Blockchain transactions consume ordered and scarce resources. On Ethereum and EVM networks, that resource is called the “nonce.” On Bitcoin, it is “UTXOs.” Across all chains, fees and balances also matter.

For obtaining nonces, most platforms still rely on RPC calls like eth_getTransactionCount at build time. That approach fails in production for well-known reasons: 

• concurrent requests reuse the same nonce
• RPC nodes lag the mempool and return stale values
• different clients and providers apply inconsistent mempool semantics

The result is familiar: stuck transactions, cascading failures, and blocked wallets. With this upgrade, we wanted to move nonce and transaction control out of RPC guesswork and into deterministic infrastructure.

Deterministic nonce management

To prevent transaction failures before they happen, Dfns now provides an orchestration layer for EVM nonce management and transaction sequencing.

Instead of querying external nodes for the next available nonce, Dfns manages a dedicated database to reserve and allocate nonces atomically across concurrent requests. By internalizing the nonce lifecycle, Dfns ensures that once a nonce is assigned to a transaction, it is no longer eligible for reuse. This ensures that every transaction is constructed and serialized in the correct order, even under high volume.

If a transaction fails or is explicitly replaced, the system automatically handles the state update. This removes the reliance on inconsistent RPC behavior and makes transaction sequencing entirely observable and deterministic.

Transaction cancellation and speed-up

While better sequencing prevents most issues, network conditions still fluctuate. Dfns now provides customers with direct, explicit control over pending transactions to handle these scenarios:

• Transaction Cancellation (Ethereum/EVM): Dfns supports replacing a pending transaction with a higher-gas "no-op" (a self-transfer with zero value). This effectively unblocks a wallet if a transaction is malformed or no longer desired.
• Transaction Speed-up (Ethereum/EVM + Bitcoin): Dfns allows for rebroadcasting the same transaction with higher fees to improve the probability of inclusion during periods of high network congestion.

These capabilities are exposed through dedicated API endpoints, providing an immediate recovery mechanism when fee markets misbehave.

A full transaction lifecycle management system

Reliable execution requires treating transactions as resource-constrained operations, not just signed payloads sent to a network. Dfns has built a full Transaction Lifecycle Management system where every transaction explicitly declares the resources it needs before it is ever broadcast. Currently, this includes:

• EVM transactions reserve a specific nonce to ensure strict sequencing.
• EVM fee-sponsored transactions reserving multiple nonces to coordinate between sponsors and smart accounts.

Over time, this model will extend to other chains and execution environments, including account-based networks with different sequencing rules, parallel execution models, and fee mechanisms. Resources are locked before broadcast and are only released once the transaction is confirmed, cancelled, or clearly identified as failed. Transactions that cannot possibly succeed are stopped early, before they enter the execution pipeline. 

Most importantly, this approach treats transaction execution as a first-class system concern, not a side effect of signing and broadcasting. It is a foundational step toward blockchain transaction pipelines that behave like modern financial infrastructure: controlled, deterministic, and resilient.

Get started on Dfns today: app.dfns.io