Introduction to DoubleZero: Learnings from a Team Q&A

During the first Solana Community Validator Call of 2025, we had the pleasure to host the team behind the DoubleZero protocol. Malbec Labs co-founders Mateo Ward & Andrew McConnell and Austin Federa, President of the DoubleZero Foundation, joined us to demonstrate how DoubleZero works and to answer questions from the call attendees.

What Is DoubleZero Network

The DoubleZero (DZ) protocol is a decentralized, high-performance network framework designed to optimize communication in distributed systems, particularly blockchains. It improves bandwidth, reduces latency, and eliminates jitter by aggregating and monetizing underutilized private fiber links to create a global, permissionless network.

If you are interested in a deep dive, read the DoubleZero whitepaper:

Current Status

DoubleZero is currently in testnet, present in 7 cities around the world where there is concentrated Solana stake: Singapore, Tokyo, Los Angeles, New York, London, Amsterdam, and Frankfurt. In each of those cities there is a DoubleZero device, which provides connectivity to the private bandwidth between each of those city pairs. It's also equipped with the FPGA technology that we demoed in Breakpoint. That FPGA technology is capable of supporting dedupe and signature verification of incoming transactions before they hit your network interface card of your validator.

The DoubleZero team has developed a software package that includes two main components that users will need to install to interface with the network. The first component is a CLI. It's similar in look and feel to the Solana CLI, and it uses the Solana devnet. The second component is a lightweight daemon that interfaces between the host OS and the physical DoubleZero network.

Building From Source

The DoubleZero software is currently packaged up and available in the DoubleZero app repo. The team recognizes that the community is going to want to build from source, and so they're actively working to open source their repo.

Connecting to the DoubleZero Network

In the next part of the call, Andrew McConnell demonstrated how to connect to the DoubleZero network before opening the floor for a Q&A session.

There is a bare metal server that would be hosting the validator software. Then, there is a device. This would be the switching infrastructure that's been deployed that composes the physical network that is DoubleZero.

On top of that, there are two components that are currently hosted in AWS but the DZ team is looking to decentralize and include as part of the network contributors package further down the roadmap.

The DZ daemon and the DZ CLI mentioned before are installed on your computer and this is how you effectively initiate a connection to DoubleZero.

There is a smart contract program and through the CLI you make a call into that smart contract providing your public IP address. Once you have been assigned the IP address and you sign the transaction from your devnet wallet with some $SOL, the system will attempt to create a connection.

The activator service is listening for pending activation events on-chain and when it sees a new contract created, it does some IP allocation and assignment of logical network resources that will ultimately need to be provisioned onto the network, like IP addresses and tunnel IDs.

In the next stage of the pipeline, the controller piece, which is the basis for our orchestration layer, is also looking for events of activated contracts, at which point it can take the information off the blockchain that was provisioned and begin rendering configuration that will ultimately be delivered to the device.

The final piece of the pipeline is that the agent that lives on the DZ device that's operated by a networking contributor is constantly asking for configuration updates from the controller, and then it pushes them down to the software running on the switch. At that point you now have a new interface created on your host OS and you have a tunnel connection through the internet to the nearest DZ device.

The DoubleZero Q&A Session

Once the demo was over, the DZ team invited the call participants to ask their questions about the protocol.

Question: Does running a device just require a physical device (or a bare metal server configured in a particular way), or does it also require physical infra?

Answer: Running a DZ device to contribute bandwidth to DZ requires connecting physical Arista devices built to protocol spec (bare metal will not work) to a point-point circuit (wavelength, L2, or L3). It can use existing network capacity, or the network contributor can light up dark fiber as a wavelength service and contribute it to the protocol.

Question: Given that DoubleZero does transaction introspection before it hits the validator for dedupe and signature verification, what kind of assurances are provided to users and validators that the transaction won't be dropped if it's incorrectly identified as duplicate.

Answer: There are a couple of mechanisms to demonstrate that the DoubleZero team is not unintentionally censoring transaction. The first one is statistics and publishing them publicly. The second one is publishing the code that backs the deduplication logic so it can be independently verified what constitutes a duplicate transaction or an improperly signed signature.

Question: When you described the DoubleZero device, you mentioned that there is an operator who runs it as a contributor. Can you talk about the persona of that operator, who is it that would run that?
And secondary, there is no physical connection between the validators and that device, right? This is tunneled?

Answer: Taking the first question, the intention behind the DoubleZero protocol is to invite a community of operators to build a network through contributing their unused or over-provisioned network assets into a sort of unified networking system. The DZ team is hoping to build with dozens and dozens of network contributors with spare capacity and work with them to create this expansive global decentralized network.

To address the second question, the DZ team envisions many styles of connectivity for the users of the network. The first one that seems to create the most coverage is a tunnel. The underlying technology is just inbuilt to the kernel using GRE tunneling. A GRE tunnel is created to the nearest DZ device and then a link local IP subnet is established between the two devices (the host and the nearest DZ device).

And then the DoubleZero team introduces routing, a routing protocol between the server, and a switch so that the IP reachability is announced to DoubleZero. That's how routing is controlled.

Question: DoubleZero is passing the bind address into the validator. How does that work? Is there a fallback option for the validator in case of an outage of the DZ network?

Answer: The DZ team has a fallback mechanism to the public internet. It's built in from day zero and as soon as you connect, there's documentation about how to fallback.

Question: When it comes to the dedup verification, how do you know what you guys are censoring or filtering? Can you provide some sort of cryptographic proof of what transactions you've received and what transactions you've removed?

Answer: The way the DZ team is thinking about the problem is to stream data and then present data on what's been dropped to the community.

There are many things that DZ can do now that you can't currently do on the public internet. It's very unlikely that a public ISP is monkeying with your traffic, but they do have the technology to do that. DoubleZero's design brings more of this to light. The assurances that you will have over DZ that no one in that link is monkeying with it is economic security. These are going to be links that have economic value behind them. There's all the normal crypto economic incentives to make sure that people aren't misbehaving.

Question: If you're far away from the nearest DZ device, at what point does it become not beneficial to join the DZ network because the additional latency of getting to that first access point is too far? Is there at some point going to be a disadvantage to not using DZ if everyone else is using it?

Answer: The reliability and the experience of being on DoubleZero is contingent on being near a DZ node, and that happens in two ways. First, the DZ team wants network contributors to be incentivized to bring the DZ network and operate DZ nodes in all the places where computers might pop up, especially computers with lots of stake.

Question: GRE has 24 bytes of overhead, does that cause packet fragmentation if we still target an MTU size of 1232 bytes?

Answer: Packet fragmentation will not occur for packets transiting the DZ network since the DZ network can handle jumbo frames. For packets transiting the public Internet inside DZ GRE tunnels, the DZ team does not expect packet fragmentation because even though the payload is targeted to 1232 bytes, the total packet size can be up to 1500 bytes which leaves us with plenty of room.

Question: How do I sign up for DZ testnet?

Answer: Fill out this Google form. Validators will be admitted on a rolling basis over the coming weeks.

Have thoughts or feedback? Join Chainflow on Discord or follow us on Twitter/X!