How RFC 18 Lets DoubleZero Match Traffic to the Right Links

Edge feeds need speed. Unicast needs bandwidth. RFC 18 lets DoubleZero's network give each what it needs, onchain. 

Why This Matters

DoubleZero is a physical network assembled from links contributed by many operators. Those links are not uniform. They differ in latency, in bandwidth, and in what they are good for: a short low-latency metro hop is a different resource from a thin, high-latency intercontinental long-haul. A network that routes everything down a single lowest-latency topology sends every service over the same fast paths, leaves the rest underused, and gives operators no way to say that a given link is meant for a particular kind of traffic.

DoubleZero Edge is what makes this concrete. Edge delivers market-data feeds across the network as IP multicast, and multicast has a property that decides how you want to use your links:

> A multicast feed crosses each link on its distribution tree exactly once. 

> The network replicates a packet only where the tree branches toward different receivers, so any given link carries a single copy of the feed regardless of how many subscribers sit downstream. > The load a feed places on a link is its own bitrate, not that bitrate multiplied by subscriber count.

Two things then follow:

Edge is latency-sensitive, so it wants the lowest-latency paths the network can offer. As a feed needs only one copy per link, it is light and it scales to many subscribers without adding load. 

Unicast is different. Tenant VRFs can move real volume, so unicast prioritizes capacity, and each tenant has its own requirements. One shared topology cannot serve both well, because a latency-sensitive feed and heavy unicast end up competing for the same links. 

The goal is to keep the low-latency paths clear for Edge and put unicast where its bandwidth needs and each tenant's requirements fit. That is what RFC 18 makes possible.

What is RFC 18?

IS-IS Flexible Algorithm (IETF RFC 9350) lets one network compute several routing topologies at once, each with its own metric and its own include/exclude rules over which links it uses. BGP color communities are the steering mechanism: a route tagged with a color resolves its next hop through the matching topology. Both are established, carrier-grade tools.

What RFC 18 changes is where the definitions live. A set of onchain accounts (TopologyInfo PDAs on DoubleZero's Solana program, plus new fields on link and tenant accounts) is the source of truth for which topologies exist, what constrains them, and how they map to flex-algo numbers and BGP colors. 

A Rust CLI reads and writes those accounts. A Go controller reads current onchain state and compiles it, deterministically, into Arista EOS configuration, then pushes that to the physical switches. Solana (topology accounts) → Rust CLI → Go controller → Arista EOS (IS-IS flex-algo, BGP color)

DoubleZero Edge multicast runs on IS-IS algo 0, the latency-optimized topology, so it takes the lowest-latency path to every receiver, one copy per link. 

What RFC 18 controls is the unicast side: which links unicast is allowed to use. Heavy unicast sharing a premium low-latency link adds congestion, latency, and jitter to the Edge feed on it, so the model is to keep the low-latency paths clear for Edge and steer unicast onto the links that suit its bandwidth and each tenant's requirements. Multicast keeps the fast paths; unicast is the traffic you move.

The foundation is deployed on mainnet-beta today. The differentiated placement it enables, matching each class of traffic to the links that suit it, is the next layer being built on top of it.

How It Was Built: From Lab to Production

1. Lab first, on real hardware. Before any production code, the feature was validated on physical Arista switches (7280CR3A and 7130LBR) in our lab. Containerized EOS does not fully reproduce flex-algo forwarding behavior, so a container-only test would have reported green while the real feature was broken.
2. RFC, then build. Malbec Labs designs in the open. The work started as RFC 18, a ~720-line document covering the onchain account model, controller behavior, the live-migration strategy, multicast interactions, and explicit non-goals. It was reviewed and merged before implementation began.
3. Build it, then throw it away. The first implementation was four PRs, roughly 16,700 lines. Review was direct: the PR boundaries were wrong and the diff was too large to review well. It was discarded and rebuilt as five focused PRs, sequenced program → CLI → SDKs → controller → migration and tests. Five merged in five consecutive days. When implementation is AI-assisted, discarding working code for cleaner, reviewable boundaries is an easier decision. Reviewability beat sunk cost.
4. Migration, on a live network. RFC 18 changed the account schema for every link and interface on a live, decentralized network. You cannot run a flag-day upgrade when participants are independent and distributed. The fix was a migration tool that upgrades accounts in deployment-order-aware batches, behind feature flags, with rollback safety at each step. The sequence: deploy the updated Solana program, run the migration, then update the controller. The network kept running throughout.

What Makes This New:

None of the pieces are new on their own:

- IS-IS Flexible Algorithm is deployed by carriers today

- BGP color communities for traffic steering are standard in service-provider networks

- Solana programs are widely deployed

- Arista EOS supports flex-algo natively

What we have not seen in production elsewhere, to our knowledge, is a live network whose link classifications are defined onchain and compiled, deterministically, into the running configuration of physical switches. The individual pieces are standard. Wiring them so that a public ledger is the authoritative source of truth for a production global network's topology is the new part.

AI-assisted, expert-directed, and shipped through guardrails.

RFC 18 was implemented by one network engineer, working with Claude Code. That engineer is not a career Solana, Go, or TypeScript developer. The build spanned a Solana program and CLI in Rust, SDK support in Rust, Go, and Python, a Go controller with template rendering, migration tooling, and an end-to-end test suite.

What AI did not do was make the hard part go away. The irreplaceable contribution was human: the mental mode on Arista hardware, the ability to diagnose failures that cross from onchain account layout to physical switch forwarding, and the judgment to know whether a given bug lived in the SDK, the controller, or the network.

It shipped safely because it went through the same controls as any production change at Malbec Labs:

- Peer review on every PR. The first attempt was discarded because of review.

- High-quality CI gating every merge.

- A staged path to production: physical lab hardware, then devnet, then testnet, then mainnet-beta.

The three bugs that mattered are the evidence. A TypeScript SDK deserializer read a stray byte from a pre-migration account layout, interpreted it as a huge length, and spun into a ~590,000-iteration loop. A Go controller template rendered ‘set extcommunity color color 1’, a duplicated keyword that passed unit tests but produced invalid switch configuring mismatch between the CLI and the onchain program only appeared in the full end-to-end run. Each was caught by review or by a testing layer before it could affect production. AI widens how much one expert can build; the review and testing pipeline is what makes it safe to ship.

As implementation gets cheaper, an engineer's judgment matters more, not less. The constraint is no longer writing the code. It is understanding the system well enough to know what to build, how it fails, and when the machine is wrong.

What Comes Next

RFC 18 is the foundation, not the finished capability. It gives DoubleZero named topologies and the machinery to classify links and decide what runs where.

The next steps build on it directly. Links can be selected automatically by bandwidth and type, so a topology is composed from exactly the links a service needs, and specific tenants or Edge feeds can be assigned to the topology that fits their requirements. The onchain fields for this, link.bandwidth and link.link_type, are already live. Over a longer horizon, the same onchain mechanism could extend topology governance beyond the Foundation to more participants.

Edge keeps the fast paths clear. Everything else gets the links that suit it. That's what RFC 18 was built to do.

Read RFC 18: github.com/malbeclabs/doublezero/blob/main/rfcs/rfc18-link-classification-flex-algo.md

Malbec Labs: malbeclabs.com   |   DoubleZero: doublezero.xyz