Line rate on bad networks
Measures the path's real capacity and keeps pacing at it through latency and loss. Losses are repaired within about a round trip while data keeps flowing.
Peer-to-peer · Encrypted · Verified
Move huge files across the world at the speed of the link.
Falcon fft fills links from 1 to 100 Gbps, across continents, satellites and lossy networks, where scp, rsync and cloud CLIs crawl. One command, no servers, no open ports.
Linux · macOS · Windows
$ fft send checkpoint.bin fft:eyJ2Ijox…
Connected · AES-256-GCM · 16 parallel flows
Path MTU 8896 · jumbo frames
✔ 107.4 GB in 11.0 s · 78.1 Gbps
✔ BLAKE3 verified end to end94 Gbps
Sustained on a 100 Gbps link, encrypted
11 s
100 GiB end to end, encrypted and verified
33–40 Gbps
100 ms RTT with 1% packet loss, encrypted
2,500×
Faster than default TCP at 300 ms / 2% loss
Your link is fast. TCP isn't.
Nearly every file tool runs over TCP, and TCP reads every lost packet as congestion and slows down. On a long path a little loss caps throughput far below what you pay for, no matter how big the pipe.
Falcon fft measures what the path can actually carry and paces to it. It recovers lost packets while the transfer keeps moving, holds its rate through heavy loss, and backs off only when the network really is full.
- Intercontinental and region-to-region links (100–300 ms)
- Satellite, cellular, Wi-Fi and congested peering
- 1, 10, 25 and 100 Gbps pipes a single TCP stream can't fill
- Both ends behind NAT, with no IT ticket to open ports
TCP measured with iperf3, 8 parallel streams, unencrypted. Falcon fft encrypted, single command.
Measured, not modeled
100 Gbps networking
Two Google Cloud n2-standard-80 VMs with 100 Gbps networking in one zone, 100 GiB per transfer,
16 parallel flows, AES-256-GCM on, every transfer BLAKE3-verified. Memory to memory: the receiver discards the data
instead of writing it, so the network path is measured, not the disks.
| Packet size | Sustained | 100 GiB end to end |
|---|---|---|
| Jumbo frames (MTU 8896): private links, VPCs, data centers | 91–94 Gbps | 76–78 Gbps · 11.0–11.3 s |
| Standard 1500-byte packets: internet-sized | 37–41 Gbps | 35–37 Gbps · 23.5–24.2 s |
Ranges cover repeated runs; sustained rates were measured on two different VM pairs. "Sustained" is the steady transfer rate; "end to end" includes connection setup and the ramp to full speed. fft finds the largest packet size the path allows on its own. At 76 Gbps encrypted, the sender used about 13 of its 80 vCPUs and the receiver about 7.
Long, lossy paths
The same two n2-standard-80 VMs, with WAN conditions emulated by Linux tc netem: standard 1500-byte
packets, 16 flows, AES-256-GCM on, memory to memory, every transfer verified end to end. 50 GiB per transfer (5 GiB and
2 GiB on the rate-limited paths); ranges cover repeated runs.
| Network condition | Falcon fft | Default TCP (CUBIC) | Tuned TCP BBR ×8 |
|---|---|---|---|
| 100 ms RTT, 1% loss | 33–40 Gbps | 0.024–0.034 Gbps | 17.7–19.8 Gbps |
| 300 ms RTT, 2% loss | 17.0–18.5 Gbps | 0.007 Gbps | 4.9–5.0 Gbps |
| 100 ms RTT, 1 Gbps bottleneck | 0.90 Gbps | 0.92 Gbps | 0.91 Gbps |
| 500 Mbps link, 80 ms RTT, 10% loss | 0.39–0.40 Gbps | 0.004 Gbps | 0.44–0.45 Gbps |
| NAT-to-NAT, no open ports* | 14.9 Gbps | n/a | n/a |
| 100 GiB disk to disk, 100 ms, 1% loss* | 4 min 25 s | Limited by the test VM's SSD (~410 MB/s) | |
TCP was measured with iperf3 on the same VMs and packet size, 8 parallel streams, unencrypted. Tuned TCP BBR needs kernel
changes on both ends; with 8 streams it can beat Falcon fft on a clean short path, and it matches it at a 1 Gbps bottleneck
and on a 500 Mbps link with 10% random loss. Falcon fft pulls ahead as distance and loss grow. Default TCP, which most
tools use, collapses on every lossy path.
*Earlier runs on two Google Cloud c3-standard-8 VMs (~23 Gbps network, 10 GiB unless noted).
~13
vCPUs of 80 to send at 76 Gbps, encrypted
~7
vCPUs of 80 to receive, decrypt and verify it
0
Packets dropped by the receiving NIC, in every run
≤310 MB
Peak memory per side, whatever the file size
Everything a big transfer needs
Zero-config peer to peer
Peers find each other over a public peer-discovery network and punch through ordinary NAT routers, with nothing to host. Prefer to keep discovery in-house? Run your own private rendezvous service; it never sees file data.
Encrypted by default
AES-256-GCM on every packet with keys from a forward-secret Noise handshake. Forged or injected packets never reach your disk.
Verified end to end
Every file is BLAKE3-verified, computed as the data streams, so there's no extra pass over a 100 GB file at either end.
Resume anything
Interrupted? Run the same command again. Only missing or corrupted blocks are sent, even across NAT-to-NAT connections.
Light on the machine
Constant memory whatever the file size, page-cache-friendly disk I/O, and hardware-accelerated crypto, so the machine stays usable at full speed.
Bound by your hardware, not the protocol
On fast links it is the disks, not the protocol, that set the ceiling. fft runs at whatever your hardware can sustain.
Linux, macOS, Windows
One self-contained binary per platform, using each OS's fast paths: kernel batching, NIC offloads and SIMD hashing.
Plays nice with the network
Backs off on real congestion, probes for more throughput gently, and slows right down if the receiver stops answering. Fast without being a bad neighbor.
Three steps, no infrastructure
-
1
Receiver gets a ticket
$ fft recv --output ./incoming fft:eyJ2Ijox…Share the ticket over chat or email, or agree on a room name.
-
2
Sender sends
$ fft send ./project fft:eyJ2Ijox… -rFiles or whole directory trees. Peers connect directly, even behind NAT.
-
3
Verified on arrival
Integrity Status: PASSED (100% MATCH) BATCH TRANSFER COMPLETEEvery byte is checked end to end. Interrupted? Run it again to resume.
Built for people who move terabytes
Media & entertainment
Camera originals, VFX plates and deliverables between studios, vendors and continents.
AI & research
Datasets, checkpoints and simulation output between cloud regions and on-premises clusters.
Remote & field sites
Getting data home over satellite, cellular and congested links that TCP can't fill.
Backup & replication
Large archives to a second site, with resume and verification built in.
Frequently asked questions
How is it faster than scp, rsync or cloud CLIs?
Those tools run over TCP, which treats every lost packet as congestion and slows down. On long, lossy paths that caps throughput far below the link. Falcon fft paces to what the path can carry and recovers losses without slowing down. At 300 ms RTT with 2% loss we measured 17–18.5 Gbps, against 0.007 Gbps for default TCP.
Do I need to open firewall ports or run a server?
No. Peers find each other through a public peer-discovery network and connect directly, including from behind ordinary home and office routers. Organizations that want discovery kept in-house can run their own private rendezvous service instead; it only introduces the two peers and never sees file data, which is encrypted end to end. For LANs, private links and cloud VPCs there's a direct mode as well. Some strict carrier-grade or enterprise NATs can't be traversed peer to peer yet; for those, run one side on a reachable host, such as a cloud VM or DMZ server, with access limited to your peers.
Is my data secure?
Every packet is encrypted with AES-256-GCM using session keys from a forward-secret Noise Protocol handshake. The shared secret never crosses the network, receivers accept only senders holding it, and every file is verified end to end with BLAKE3.
How does it compare with Aspera or Signiant?
Like them, Falcon fft is built for fast transfer over long, lossy links. It's peer to peer and serverless: there's no transfer server or cloud service to deploy, and both ends can sit behind NAT.
What limits the speed in practice?
Usually the disks. fft has sustained 94 Gbps over 100 Gbps cloud networking, far more than most storage can write: one cloud SSD writes about 410 MB/s, or 3.3 Gbps. fft runs at whatever your hardware can sustain.
Which platforms are supported?
Linux, macOS and Windows, as one self-contained binary per platform with no runtime dependencies.
Ready to stop waiting on transfers?
Falcon fft is in early access. Tell us about your network and data, and we'll set up a trial on your own links.
Request early access