---
title: "flightofthefox"
url: "https://radix.wiki/community/flightofthefox"
version: "1.1.0"
updated: 2026-08-18
last_verified: 2026-08-18
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# flightofthefox

| flightofthefox |  |
| --- | --- |
| Type | Software developer (pseudonymous) |
| Known for | Lead developer of [hyperscale-rs](/contents/tech/research/hyperscale-rs), the production candidate for [Xi’an](/contents/tech/releases/radix-mainnet-xian) |
| Also | Primary developer of [Proven Network](/ecosystem/proven-network) |
| GitHub | [@flightofthefox](https://github.com/flightofthefox) (account created 17 February 2022) |
| X | [@flightofthefox](https://x.com/flightofthefox) |
| Public commit record | 1,692 to [proven-node](https://github.com/proven-network/proven-node), 345 to [proven-2pc](https://github.com/proven-network/proven-2pc), 2,895 to [hyperscale-rs](https://github.com/hyperscalers/hyperscale-rs), 293 to [hyperscale-vm](https://github.com/hyperscalers/hyperscale-vm) (18 August 2026) |
| Language | Rust |
| Funding | $300,000 USD-equivalent over six milestones proposed in the [Xi’an RFC](https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280); Milestone 1 paid directly by the [Radix Foundation](/ecosystem/radix-foundation) |
| Telegram | [t.me/hyperscale_rs](https://t.me/hyperscale_rs) |
| Category | [Community](/community) |

**flightofthefox** is the pseudonymous developer who writes [hyperscale-rs](/contents/tech/research/hyperscale-rs), the Rust implementation of the Hyperscale consensus protocol that is the leading candidate to deliver [Xi’an](/contents/tech/releases/radix-mainnet-xian) – the sharded consensus layer intended to make [Radix](/ecosystem) linearly scalable. He is also the near-sole author of [Proven Network](/ecosystem/proven-network), the TEE-based companion network he built before turning to consensus. As of 18 August 2026 the [public contributor record](https://github.com/hyperscalers/hyperscale-rs/graphs/contributors) credits him with 2,895 of the 2,978 commits on hyperscale-rs, and every one of the 293 commits on its execution engine. The one other substantial contributor, [kaldeberger](https://github.com/kaldeberger), wrote 68 commits of continuous-integration and deployment tooling between 15 December 2025 and 31 January 2026 and has committed nothing to the repository since; the remaining handful of contributors have three commits or fewer each.

That concentration is the point of the entry. With the [Radix Foundation](/ecosystem/radix-foundation) in maintenance mode since April 2026, the network’s scalability roadmap rests on a codebase written almost entirely by one person who has never published a legal name. This article covers the public work only; no attempt is made here to identify the individual behind the handle, and none of the sources below do so either.

## Proven Network (2024–2025)

The GitHub account dates from [17 February 2022](https://api.github.com/users/flightofthefox), but the first substantial public work under it is [Proven Network](/ecosystem/proven-network), whose [GitHub organisation](https://github.com/proven-network) was created in mid-2024. Proven is an off-ledger auditable compute, storage and messaging layer for Radix applications: user code runs in [trusted execution environments with remote attestation](https://docs.proven.network/the-trust-model-and-cryptography) so that neither the operator nor the hardware owner can tamper with it, with identity supplied by Radix Persona and [ROLA](/developers/frontend/03-rola-authentication) rather than separate key management. Its documentation is unusually direct about what it is not: Proven [explicitly does not aim to be decentralized, permissionless or censorship-resistant](https://docs.proven.network/the-trust-model-and-cryptography), on the reasoning that the ledger underneath already is.

Across sixteen public repositories – the node itself, a WebAssembly runtime forked from Deno, TypeScript SDKs for key-value, SQL, session and crypto access inside the runtime, and an AWS Nitro Enclaves attestation binding – the work is essentially one person’s: [1,692 commits to proven-node](https://github.com/proven-network/proven-node/graphs/contributors) and no other contributor on the repository. Public commits to proven-node stop on **4 November 2025**, and no mainnet or testnet launch has been announced.

## The turn to consensus (August–December 2025)

Between the last Proven commits and the first Hyperscale ones sits [proven-2pc](https://github.com/proven-network/proven-2pc), created on 29 August 2025 and described in one line as a “transactional consistency experimental playground”. It took 345 commits, all his, and stopped on 14 November 2025. Three weeks later, on **7 December 2025**, the [hyperscale-rs](https://github.com/hyperscalers/hyperscale-rs) repository was created; on 30 December he forked [radixdlt-scrypto](https://github.com/radixdlt/radixdlt-scrypto), the engine he would spend the following year integrating and then replacing.

The sequence is public; the causal reading is not his. It is worth noting that Hyperscale’s own atomic-commitment design [opens by rejecting the two-phase-commit comparison outright](/contents/tech/research/hyperscale-rs) – no coordinator, no votes on the outcome, no blocking participant – so whatever the experiment settled, it did not settle on 2PC.

A third artefact from this period sits outside both organisations. [jellyfish-verkle-tree](https://github.com/flightofthefox/jellyfish-verkle-tree), written over two days in March 2026, grafts verkle-tree proof aggregation onto the storage design of the Jellyfish Merkle Tree: Pedersen vector commitments on the Bandersnatch curve, 544-byte IPA openings, and Dankrad Feist multipoint aggregation yielding a 576-byte constant-size cryptographic proof, with the same [Quint](https://quint-lang.org/) specifications he uses on the consensus stack. Constant-size state proofs matter for light clients reading a sharded ledger, but the experiment is not wired in: hyperscale-rs ships its own plain `hyperscale-jmt` crate, and no reference to the verkle work appears in that repository as of August 2026.

## hyperscale-rs and the Xi’an proposal

On 20 April 2026 he posted an [RFC to deliver Xi’an](https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) to the governance forum, offering hyperscale-rs as “a production-ready, linearly scalable, post-quantum-ready implementation of Radix” on an eighteen-month schedule with a twelve-month support window, for $300,000 USD-equivalent paid in XRD across six milestones plus a 50M XRD bonus at mainnet, with milestone sign-off by the [Radix Accountability Council](/ecosystem/radix-accountability-council) and no exit fee if the work is stopped at any boundary. The RFC also committed the codebase to Apache 2.0 on acceptance; the licence [landed on 7 August 2026](https://github.com/hyperscalers/hyperscale-rs/commit/91db7add4a917d8bf382b6b2a250577983e57cff) as a dual MIT-or-Apache grant, going further than promised. [Milestone 1](/contents/tech/research/hyperscale-rs) – validator lifecycle, dynamic topology and the staking model – was reported [complete on the same day](https://t.me/hyperscale_rs/10474). The RFC’s “post-quantum-ready” claim acquired a concrete referent on **16 August 2026**, when hyperscale-rs gained [transaction signing and verification under ML-DSA-65](https://github.com/hyperscalers/hyperscale-rs/commit/aa1adef93009a751e176ae3435b0c7ef5485d8d9) – the lattice signature scheme standardised by NIST as [FIPS 204](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) – along with a test scenario exercising a virtual ML-DSA-65 account.

He is candid about the structural problem with all of it. The proposal calls the scope “ridiculously ambitious for one human” and puts three options for key-man risk to the community – fund a second person, buy key-man insurance, or accept the single point of failure because payments are milestone-gated – while stating his own preference plainly: that documentation and design discussion stay public so that _“we have to get to a world where multiple entities have a stake (and the knowledge to) maintain the network”_. Until April 2026 the work ran on community donations through the FoxFund initiative, which he then closed in favour of votes: _“no more donations tho lads — just support foxy proposal for xi’an if you want to give back.”_

Public reception has attached as much to the writing as to the code. Asked in August 2026 about promoting the project, he declined the framing: [“marketing isn’t something i particularly care about … it’s not a product, it’s just an open source consensus stack”](https://t.me/hyperscale_rs/10497) – the site, he said, exists so he can link it to other people who work in consensus.

## hyperscale-vm (July 2026–)

The execution layer is the current front. hyperscale-rs runs the [Radix Engine](/contents/tech/core-protocols/radix-engine) today, but on **30 July 2026** the purpose-built replacement became its own public repository, [hyperscalers/hyperscale-vm](https://github.com/hyperscalers/hyperscale-vm), described as an “Effect-typed WASM execution engine for sharded BFT” and licensed MIT or Apache-2.0 from the start. It is a twelve-crate Rust workspace on the 2024 edition – its own binary encoding (`hbor`), an effects system, kernel, runtime, manifest builder, SDK and standard library – and in its first nineteen days it took 293 commits, all from him.

The commit titles read like the design notes of someone building a fee and settlement model rather than porting one: [“Price a declaration on the schedule that prices its execution”](https://github.com/hyperscalers/hyperscale-vm/commits/main), “Make an unresolved movement unable to reach committed state”, “Split projecting a receipt from folding it down”. The dependency runs the other way too: the one Milestone 1 item left open – splitting shards on fees rather than storage size alone – waits on the fee system, which waits on this VM.

Two fronts have moved since. On **13 August 2026** the engine stopped treating a transaction signature as authority in itself: [“Let a signature sign in and nothing else; guarded methods take badges”](https://github.com/hyperscalers/hyperscale-vm/commit/fc4ce4065af566a08b8a6b542fa52a3759ac619d) moves authorisation onto the [badge and proof](/contents/tech/core-concepts/badges) model the [Radix Engine](/contents/tech/core-protocols/radix-engine) already uses, so a guarded method is entered by presenting a proof rather than by having signed the transaction. From **16 August** the work has been making value _linear_ inside the VM: value crosses the guest boundary as [a handle the guest cannot open](https://github.com/hyperscalers/hyperscale-vm/commit/04f790e8d0abda0dcd2788c265bf3f9966a3465c), a cell carries [a type saying which resource it holds](https://github.com/hyperscalers/hyperscale-vm/commit/e3bbbb88f5ec8a39db3883b850c5427f06de65a0), and a contract body that [lets go of value](https://github.com/hyperscalers/hyperscale-vm/commit/5f26ec0dcd868edc73aea7db16c04c0dd4c60568) is refused rather than allowed to leak it. That is the asset-oriented half of the Radix programming model being rebuilt natively, rather than inherited from the engine hyperscale-rs runs today.

## External links

- [GitHub – @flightofthefox](https://github.com/flightofthefox)
- [X – @flightofthefox](https://x.com/flightofthefox)
- [hyperscale.rs – project documentation](https://hyperscale.rs)
- [hyperscalers/hyperscale-rs](https://github.com/hyperscalers/hyperscale-rs) and [hyperscalers/hyperscale-vm](https://github.com/hyperscalers/hyperscale-vm)
- [proven-network – GitHub organisation](https://github.com/proven-network), [documentation](https://docs.proven.network/)
- [RFC: Xi’an – Delivering Hyperscale for Radix](https://radixtalk.com/t/rfc-xian-delivering-hyperscale-for-radix/2280) (RadixTalk, 20 April 2026)
- [hyperscale-rs – Telegram channel](https://t.me/hyperscale_rs)