Show HN: Velocity is a post-quantum transport protocol

I’ve been experimenting with a new transport layer called Velocity, built to explore how much performance we can unlock if we stop inheriting the historical weight of TLS and HTTPS.

Velocity’s goal is simple: build a clean, modern protocol that’s resistant to quantum attacks, supports hybrid key exchange, and minimizes handshake latency to near zero. The numbers have been surprising. In controlled bare-metal tests, Velocity’s pqq-supported handshake runs about 12,100× faster than TLS 1.3, while the fallback QUIC mode still performs several thousand times faster. Even the most security-hardened configuration (Velocity Fortress) stays well ahead of HTTPS in total handshake throughput.

The system is designed for active and passive threat resistance. Against passive surveillance, Velocity shortens ticket lifetimes and encrypts transcripts. For active MITM attempts, it binds handshakes to profiles, validates PQ signatures, and enforces ALPN consistency. Malicious clients that flood or replay requests are handled through retry tokens, proof-of-work hooks, and replay window tracking. Even in a scenario where a CA is compromised, Velocity cross-checks PQ extensions, logs certificate transparency events, and plans for mandatory PQ validation policies.

At the moment, Velocity terminates only its post-quantum UDP transport. Legacy HTTPS fallback still runs through a standard web server such as Caddy or Nginx. The roadmap aims to integrate first-class HTTPS and ACME automation directly into Velocity, making it a single binary that can serve static assets or reverse-proxy traffic across multiple domains, with automatic certificates and hot reloads.

Future stages focus on:

Unified TCP/UDP stack supporting HTTP/1.1, HTTP/2, and HTTP/3 alongside Velocity QUIC.

Built-in ACME automation for certificates and OCSP stapling.

Multi-tenant routing with host and path mapping in JSON, YAML, or TOML.

Observability and CLI parity with tools like Caddy — structured logs, metrics, safe defaults, and graceful reloads.

You can read the current docs here: https://projectvelocity.org

I’d appreciate thoughts from people running high-performance or self-hosted systems. The next step is integrating HTTPS support directly into the runtime so operators can deploy Velocity like they do Caddy or Nginx, without separate configuration or reverse proxies.

What parts of the HTTPS ecosystem do you think are worth keeping, and which should be rethought entirely if we were starting from scratch today?