How is Falcon fft faster than scp, rsync or cloud CLIs?

Those tools run over TCP, which treats every lost packet as congestion and cuts its speed. On long, lossy paths that caps throughput far below the link. Falcon fft measures what the path can actually carry and paces to it, recovering losses without slowing down. Measured at 300 ms RTT with 2% loss: 8.4 Gbps versus 0.006 Gbps for default TCP.

Yes. Every packet is encrypted with AES-256-GCM using session keys from a forward-secret Noise handshake, the shared secret never crosses the network, and every file is verified end to end with BLAKE3.

Peer-to-peer · Encrypted · Verified

Move huge files across the world at the speed of the link.

Falcon fft fills 1, 10 and 25+ Gbps links across continents, satellites and lossy networks, where scp, rsync and cloud CLIs crawl. One command, no servers, no open ports.

Request early access See the benchmarks

Linux · macOS · Windows

sender: us-central → receiver: 100 ms away

$ fft send plates_v012.tar fft:eyJ2Ijox…
Connected · AES-256-GCM · 8 parallel flows
Path: 100 ms RTT · 1.0% packet loss
 0%
✔ 10.7 GB in 7.0 s · 12.2 Gbps
✔ BLAKE3 verified end to end

15.9 Gbps

Clean cloud link, encrypted

12.2 Gbps

100 ms RTT with 1% packet loss

11×

Faster than tuned TCP BBR at 300 ms / 2% loss

310 MB

Flat memory for a 100 GB transfer

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, tells random loss apart from real congestion, 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 and 25+ Gbps pipes a single TCP stream can't fill
Both ends behind NAT, with no IT ticket to open ports

300 ms RTT, 2% packet loss Goodput in Gbps, measured on Google Cloud

Falcon fft8.4

TCP BBR ×8, tuned0.74

TCP CUBIC ×8, default0.006

TCP measured with iperf3, 8 parallel streams, unencrypted. Falcon fft encrypted, single command.

Measured, not modeled

Two Google Cloud c3-standard-8 VMs, WAN conditions emulated with Linux tc netem, 10 GiB files, AES-256-GCM on, and every transfer verified end to end.

Network condition	Falcon fft	Default TCP (CUBIC)	Tuned TCP BBR ×8
Clean cloud network	15.9 Gbps	—	20–21 Gbps
100 ms RTT, 1% loss	12.2 Gbps	0.019 Gbps	15–18 Gbps
300 ms RTT, 2% loss	8.4 Gbps	0.006 Gbps	0.74 Gbps
100 ms RTT, 1 Gbps bottleneck	0.90 Gbps	0.019 Gbps	0.89 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)

Tuned TCP BBR needs kernel changes on both ends and runs unencrypted here; with 8 streams it can beat Falcon fft on a clean or moderately lossy short path. Falcon fft pulls ahead as distance and loss grow, and stays at full speed through 10–20% random packet loss in emulation, where loss-based protocols collapse.

~1.8

CPU-seconds per GB sent

~2.5

CPU-seconds per GB received, including decryption, verification and writing

Packets dropped by the receiving NIC, in every run

≤310 MB

Peak memory per side, whatever the file size

Everything a big transfer needs

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.

Zero-config peer to peer

Peers find each other over the public BitTorrent DHT and punch through ordinary NAT routers. No relay, no server, nothing to host or trust.

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.

Disk-aware

When the receiving disk is slower than the network, fft paces to the disk instead of wasting bandwidth on packets it would drop.

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 gently on stable links, 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
SHAREABLE P2P TRANSFER TICKET:
fft:eyJ2Ijox…
```
Share the ticket over chat or email, or agree on a room name.
2
Sender sends
```
$ fft send ./project fft:eyJ2Ijox… -r
```
Files or whole directory trees. Peers connect directly, even behind NAT.
3
Verified on arrival
```
Integrity Status: PASSED (100% MATCH)
BATCH TRANSFER COMPLETE
```
Every 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 8.4 Gbps, against 0.006 Gbps for default TCP.

Do I need to open firewall ports or run a server?

No. Peers find each other through the public BitTorrent DHT and connect directly, including from behind ordinary home and office routers. 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 yet; a port forward on one side solves that.

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?

Above a few Gbps it's usually the disks. One cloud SSD writes about 410 MB/s, or 3.3 Gbps. Falcon fft paces to the slower of the network and the disk, so you get the most 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