Monad Direct UDP Separates Transaction Forwarding from Consensus Traffic

Monad Direct UDP Separates Transaction Forwarding from Consensus Traffic

September 16, 2026.

BitCtrl has completed Direct UDP deployment on its Monad testnet validator as part of the staged testnet rollout. Direct UDP adds a dedicated transport channel for transaction forwarding between nodes.

This is not an official general release. Deployment is currently staged on testnet, and BitCtrl's completion is not permission for other operators to begin.

Please do not proceed until Monad Foundation provides notice.

The change addresses a specific networking task: getting a transaction from one node to another without using the same transport path as consensus traffic. It does not replace MonadBFT or remove RaptorCast from block distribution. Instead, it gives point-to-point forwarding a path designed for that job.

For operators, this is a configuration migration with version, firewall, and peer-discovery requirements. For users, the intended benefit is more efficient transaction delivery behind the RPC endpoint, not a new transaction format or a promised increase in TPS.

Why Transaction Forwarding Needs a Different Path

A block proposal must reach many validators. RaptorCast is built for that one-to-many problem: it encodes a proposal into chunks and distributes them through a two-level broadcast structure. Redundancy helps recipients reconstruct the message despite missing packets or uncooperative peers.

Forwarding an individual transaction to a particular peer is a different task. The RaptorCast architecture guide describes the existing forwarding path as one hop, without receiver rebroadcast. Even there, it uses RaptorCast's transport machinery.

Direct UDP adds a dedicated unicast channel for that one-to-one exchange. RaptorCast continues doing the work it was designed for: distributing block proposals across the network.

The useful distinction is not simply UDP versus another protocol. RaptorCast already runs over UDP. The change is which transport mechanism handles transaction forwarding, and how much overhead that mechanism introduces.

What the Amplification Reduction Actually Means

The Direct UDP migration preview states that transaction traffic avoids the 2.5x amplification when both peers have Direct UDP enabled.

That is a meaningful improvement for the affected forwarding traffic, but it is not a claim that every node uses 2.5 times less bandwidth or that transaction throughput increases by the same factor. A node still exchanges block proposals, synchronization data, and other messages. The overall effect depends on its workload and the peers it communicates with.

The guide also states that enabled nodes remain compatible with peers that have not enabled the feature. Adoption can therefore be incremental, while the forwarding benefit depends on both ends supporting the new path.

AI-generated conceptual illustration, not a complete protocol topology. The sender in the lower panel represents a Monad node, not a browser sending raw UDP. Dedicated transport still shares the host and network infrastructure. The banner is also an editorial illustration.

A Separate Channel Is Not a Separate Physical Network

Separating transaction forwarding from consensus traffic gives the two workloads distinct transport paths. That is useful engineering, but it should not be mistaken for complete resource isolation.

Both paths can still share a machine, its network interface, CPU, and upstream connection. A saturated link or overloaded host remains an operational problem. Direct UDP reduces unnecessary forwarding overhead; it does not remove the need to monitor packet loss, peer connectivity, and host capacity.

For RPC and full-node operators, forwarding efficiency matters because those nodes help move submitted transactions toward validators. For validators, the change is relevant to how transaction intake coexists with consensus networking. Neither role should treat an open port as proof that the migration works end to end.

Requirements Before Enabling It

The supplied rollout preview specifies these prerequisites:

| Requirement | Operator check | | --- | --- | | Client version | Monad v0.16.2 or later for the supplied procedure |

| Existing transport | Authenticated UDP already enabled | | Direct UDP listener | UDP port 8002 by default | | Existing ports | TCP 8000 and authenticated UDP 8001 remain configured |

| Identity | Existing secp256k1 keystore used to sign the updated name record |

| Network access | Host and upstream firewall rules allow the configured UDP port |

The default port numbers are configurable. What matters is agreement between the actual listener, firewall policy, and the externally advertised signed record.

There is an important documentation caveat. At the time of review, the public Direct UDP page still listed v0.14.6, while the supplied rollout preview required v0.16.2 and used revised configuration fields. Do not combine commands from the two versions. Use the procedure confirmed for your installed client and the current Foundation rollout.

Both pages describe Direct UDP as opt-in, with a future release expected to require it. The procedure supports different node types, but technical applicability is not rollout authorization. The current deployment is staged on testnet, not an official general release or a mainnet rollout. Operators must wait for Monad Foundation notice before applying the procedure.

The Signed Peer Record Is the Critical Detail

This migration is more than adding a firewall rule.

Peers need to discover the new endpoint through the node's signed name record. The preview instructs operators to regenerate that record with the Direct UDP port and a strictly higher sequence number. Without increasing self_record_seq_num, the updated record will not propagate as intended.

The same preview also separates the advertised IP from the TCP port and introduces the Direct UDP bind field. Operators should apply the generated record consistently rather than copy example signatures, addresses, or sequence numbers.

A practical maintenance sequence is:

1. Verify the client version and existing authenticated UDP setup.
2. Back up the configuration and allow the required UDP port through the relevant firewalls.
3. Generate a new signed name record with the correct external address, ports, and incremented sequence number.
4. Apply the matching peer-discovery and network settings from the approved guide.
5. Run its configuration checks before restarting the consensus service.
6. Review startup logs, peer connectivity, and continuing block progression afterward.

Validators with downstream full nodes should also update the relevant peer records as those peers enable Direct UDP. Record changes must reflect the peer's real configuration, not an assumption that every node has already migrated.

BitCtrl Has Completed the Testnet Deployment

BitCtrl has applied Direct UDP to its testnet validator as part of this staged deployment. This is a testnet operations update, not a claim of mainnet activation or an official network-wide release.

The completed deployment gives BitCtrl a basis for observing the transport under testnet conditions. It does not establish a measured bandwidth reduction or performance gain; those require comparison under representative workloads. Other operators should continue to wait for their own rollout instructions from Monad Foundation.

What Operators Should Measure

The first question after a restart is whether the node remains healthy. The next is whether the intended forwarding path is actually in use with compatible peers.

Useful comparisons include transaction-forwarding traffic, packet loss, host network utilization, and any available transport-specific logs or counters. These should be assessed against comparable workloads. A quieter period after migration is not, by itself, evidence of a transport improvement.

For application teams, no wallet action is described in this node-operator migration. The work takes place behind their RPC connection. Any claim of faster inclusion or better application performance should be supported by measurement rather than inferred from the transport design alone.

Direct UDP is a focused improvement: use broadcast machinery where the network needs broadcast, and a dedicated point-to-point channel where it does not. Its value comes from removing avoidable work while keeping the existing consensus distribution system in place.

Sources

• Monad Foundation Direct UDP rollout preview
• RaptorCast architecture and transaction forwarding
• Public Direct UDP migration guide

The staged testnet scope and BitCtrl testnet completion are operator-confirmed. Technical details follow the linked documentation, which explicitly instructs operators to wait for Monad Foundation notice. No mainnet completion or measured performance results are claimed.