Before reading the setup guide, please review the FAQ.
Setting up and configuring a FIBRE network requires two distinct efforts: investigating and selecting server locations and then configuring and connecting the nodes. For those who wish to become a FIBRE Network Operator (FNO), we strongly recommend you spend time carefully considering and researching the topology of your deployment, as this will be the primary limiting factor on relay performance. Ultimately, software and hardware level optimizations will not be able to overcome poorly-selected interconnects.
The physics of light through fiber imposes a fundamental limit on relay performance. The speed of light in a vacuum divided by the glass refractive index results in speeds of approximately 200km/ms. Your goal as a FNO is to approach this theoretical minimum.
To achieve this goal, you’ll want to select servers near large cable landing points. The Submarine Cable Map is an excellent reference for this phase of your planning. However, it’s important to note that proximity to a desirable submarine cable does not guarantee access. Hosting providers have peering relationships that vary widely. Even two hosting providers in the same datacenter will often have entirely different routes to the same destination. This is because BGP makes path selections based on policy, commercial agreements, and AS-level relationships rather than physical geography.
Additionally, some cables are privately owned and managed, making them inaccessible to the general public. A prime example is Meta’s Project Waterworth —a cable that runs from the US east coast to Brazil, South Africa, India, and Australia, before looping back to terminate on the US west coast. While the cable itself is very desirable to a FNO, unfortunately it is only accessible to Meta and its subsidiaries.
When investigating potential hosting providers, we recommend first focusing on those that have public Looking Glass tools. That way you can execute a traceroute between candidate providers to test performance before signing up. And while traceroute is a powerful tool, it can be misleading! It only reveals Layer 3 hops, which means entire classes of infrastructure are not surfaced. Use it as a guide, but treat the output as a partial sketch of the path. Also, do not forget to probe your route bidirectionally, as routing is asymmetric. The path packets from provider A -> B are likely entirely different from the path packets take from B -> A.
For large well established cities, you may also be able to identify potential datacenters by the buildings they are located in and the publicly documented peering relationships they have. If you can, identify hosting providers that maintain a presence in buildings that are also IXP points. This will give you access to the greatest number of potential routing paths and likely yield higher levels of reliability in routing performance over the lifetime of your FIBRE network. Tools like PeeringDB and DataCenterMaps are very useful at this stage of the process.
Sometimes, you may come across a single hosting provider who has availability across multiple cities in your target areas. Operationally this is ideal because it lowers the overhead of managing your infrastructure and makes for a more unified experience. But more importantly, these providers generally operate their own Autonomous Systems and establish strategic peering relationships to ensure optimal routing within their network of hosts. This offers more predictable paths than those you’d achieve by stitching together unrelated hosts from different providers, each of whom would route your traffic independently through their own upstream transit relationships.
The overhead required to run FIBRE is minimal relative to an unmodified version of Bitcoin Core. While bare metal is certainly the most desirable platform for predictable performance, an adequately resourced VPS should suffice, with the caveat that you may observe latency spikes due to virtualisation overhead, noisy neighbors, network interface poll frequency, and uncontrollable swap usage. It is recommended you disable swap space, at least for the bitcoind process.
FIBRE introduces some RPC commands and configuration options. Among these is the -addtrustedudpnode option, which connects a set of “trusted” FIBRE nodes. These nodes are considered trusted because data received from them is relayed before being fully validated. This is necessary because, due to the nature of FIBRE’s FEC encoding, there is no way to know whether individual packets are legitimate until the block has been fully reconstructed. This represents the fundamental tradeoff that FIBRE makes: sacrificing DoS resistance in exchange for lower latency.
Once you’ve set up your network, you must monitor it. Peering relationships change and once-performant routes can silently degrade. To that end, we’ve instrumented bitcoind with USDT tracepoints for benchmarking block propagation. At runtime, an eBPF-based exporter captures these metrics and feeds them to Prometheus while Promtail streams the node’s debug log into Loki. Both sources converge in a single Grafana dashboard, offering a real-time view of relay health. We strongly encourage you to use this tool.
Finally, to ensure the reliability of the data surfaced by these monitoring tools, it is important that your FIBRE nodes are time-synced. We recommend utilizing ntp with peering between neighboring nodes to establish a relative consensus, while anchoring each node to a reliable ntp server.