Thebes.

The Substrate

Thebes is a Byzantine-fault-tolerant substrate built on a two-chain commit rule; prepare, then commit, with the chain advancing one block per round in the common case. The leader is chosen by a hybrid verifiable delay function; a Wesolowski VDF whose output is mixed with sorted validator-revealed entropy. The VDF takes real time to compute; even a purpose-built ASIC cannot predict the next leader faster than the network can observe its emergence. The validator reveals add entropy that the VDF itself cannot anticipate; the two inputs together produce a beacon that is at once unpredictable and verifiable in milliseconds.

The two-chain rule reduces communication from the three rounds of classical BFT to two; the construction is in the lineage of the HotStuff family of consensus protocols, with the responsive variant that collapses the prepare-and-commit pipeline. Each round produces a quorum certificate over the prior proposal; the certificate travels inside the next proposal's justify field; the chain commits when two consecutive certificates anchor to the same parent. Linear message complexity in the common case; safety preserved under one-third Byzantine failure; liveness preserved under one-third crash failure. The protocol is responsive; the cluster moves as fast as the network allows, not as fast as a hard-coded interval permits.

The substrate addresses a known pathology in pipelined leader-based BFT; an honest leader's proposal can be orphaned by a successor leader who skips it deliberately or accidentally. Without protection, the orphaned block's transactions are discarded and the orphaned proposer loses any reward attached to its inclusion. The protocol's re-proposal mechanism prevents this. When a timeout certificate is observed for a round whose proposal was not committed, the next leader carries the orphaned block forward inside its own proposal; the orphaned block is anchored to the chain through timeout-certificate evidence rather than through a hopeful re-broadcast. The cluster does not stall; the orphaned proposer's work is not lost; the chain continues without forking. The construction is verified against adversarial harnesses run across clusters of varying sizes; survivor-majority pinning while the proposer rotates through equivocation attempts is exercised at multiple validator counts, the safety and liveness properties are observed to hold uniformly across the range.

Inline-body transport is the second optimization. For proposals carrying small bodies; the body rides inside the proposal envelope itself, skipping the full chunk-vote-certificate round-trip that the protocol uses for large bodies. The inline path saves a full round of network exchange for the majority of application traffic; the chunked path remains available when bodies exceed the inline threshold. Both paths reduce to the same finalization invariants; the finalizer and the external watcher distinguish modes from the header alone.

Block-body availability is treated as a separately attested concern. Before a header is finalized the body is committed to and disseminated; a quorum of validators signs the pair of body hash and commitment, and the aggregated signatures form an availability certificate. The certificate is what gates header consensus, not the body bytes themselves; header pipelines run in parallel with body propagation, which is one of the levers that lets the substrate finalize at subsecond cadence even on a globally distributed validator set. The commitment is structured so the chunking layer can evolve independently of the certificate; the substrate's chunk-and-commit surface admits erasure-coded transports, which is the direction the protocol moves as body sizes grow.

The substrate self-heals when a peer goes silent. Adaptive leader timeouts shrink the time budget given to a dead peer; resumed-peer probation prevents a flapping peer from re-entering the rotation before its behavior stabilizes. The cadence holds at empty-cluster speed even with one peer down; the cluster does not pay the full quorum-timeout cost on every rotation where the dead peer would otherwise have been leader. The mechanism is parametric in the validator count; it applies identically to the quorum-minus-one survivor regime regardless of total cluster size.

Threshold ECDSA

Thebes signs cross-chain transactions with threshold ECDSA over the secp256k1 curve. Bitcoin; Ethereum; every chain in the EVM family; every chain that uses secp256k1 at all. The cryptography supports a key generation protocol that produces a public key whose corresponding private key is held by no single party; the key shares are distributed across the validator set; a quorum of validators jointly produces a signature whose verification is indistinguishable from a signature produced by a single party holding the full key.

The signing path is one round. Most threshold ECDSA constructions in the literature require five to seven interactive rounds between signers; each round a network exchange; each exchange a latency penalty paid on every signature. Thebes does not pay this penalty. The signing path is non-interactive in the multiparty sense; each party contributes a presignature offline, before any signature is requested; the actual signing request consumes one presignature and produces a complete signature in a single round. The construction relies on class-group ciphertexts; a homomorphic encryption scheme over the class group of an imaginary quadratic number field; the construction draws on the line of work on class-group cryptography in the cryptographic literature; the homomorphism is exactly what allows the protocol to collapse the multi-round interactive presignature into a non-interactive offline computation. The operational consequence is subsecond finality on a signed cross-chain transaction; the request and its signature complete in the same consensus round rather than across a multi-round handshake.

The presignature pool is replenished continuously during idle network time. A validator that has spare compute generates additional presignatures and contributes them to the pool; the protocol guarantees that no presignature is reused; the protocol guarantees that the pool depth tracked at the consensus layer is identical across all honest validators. A presignature is bound to a signing request through a consensus-finalized reservation; the binding ensures that the same presignature cannot be consumed by two different signing requests; the binding is observable on chain.

The user side of the signing protocol is what we call fused signing. The user holds one half of the signing material; the network holds the other. The user contributes their half to the signature request directly; the aggregate scalar arrives with the request payload; the network contributes its half through the threshold protocol; the two halves fuse into a single ECDSA signature in one round. The user's key share is never reconstructed on the network; the network's key shares are never reconstructed on the user device; the complete private key for any user account is never assembled in any place at any time, including during key generation, including during signing, including during recovery. The custody is two-of-two; the user must contribute, the network must contribute; either alone produces nothing.

The cryptography is verified against a production reference implementation using the same curve operations a Bitcoin node would use. The same signatures that Thebes produces are accepted by Bitcoin Core; the same signatures are accepted by every Ethereum execution client; verification is exactly the verification specified by the chains whose signatures we produce. No protocol modification is required at the destination chain; no special validator set is required; the signatures are valid by the existing rules of every secp256k1 chain.

Threshold Schnorr

For Schnorr-curve chains; the ed25519 family on one side, the secp256k1-taproot family on the other; Thebes implements threshold Schnorr through the FROST family of protocols, originally introduced in the academic Schnorr-threshold literature and adapted here to consensus-driven dealing. The construction is parametrized by curve; the same protocol runs over secp256k1 and ed25519 with curve-specific arithmetic injected at the field-operation layer; the distinguished feature is that the distributed key generation runs as a consensus-driven protocol rather than as a separate offline ceremony.

Consensus-driven distributed key generation means that the dealing of key shares, the verification of dealings, the broadcast of complaints, the aggregation of valid shares; all of this happens through the same chain that the validators are running anyway. There is no separate dealer network; there is no separate setup phase that requires a trusted coordinator; there is no offline ceremony that introduces a different trust model from the chain itself. The key generation is as trustless as the chain's consensus.

A Schnorr signature is one network round once a key is established; presignatures may be generated offline in the same way as for ECDSA; the user-fused variant works identically. The operational shape matches the ECDSA path; a signed transaction reaches subsecond finality through the same one-round-after-presignature mechanic. The chain's key share for a given subnet is rotated on a configurable schedule; rotation is itself a consensus-driven event; the rotation cannot be triggered without quorum agreement; the previous key remains valid for outstanding signatures until the rotation completes.

Curve coverage is intentional. Every Schnorr-curve chain that we sign for uses the same protocol with the same security properties; the substrate does not maintain separate implementations for separate chains; adding a new Schnorr-curve chain is adding a curve specialization, not adding a new signing protocol.

Post-Quantum Threshold Signatures

Thebes's quorum certificates carry post-quantum signatures over the MAYO-2 construction. MAYO is a multivariate-quadratic signature family submitted to the NIST post-quantum standardization process; MAYO-2 is the parameter set tuned for the signature-size and verification-cost regime that chain finality requires. The construction is the dual signing stack of the substrate; classical NIM-ECDSA for cross-chain user signatures; MAYO-2 for the chain's own internal consensus certificates.

Consensus today runs with per-validator MAYO-2 keys. Each validator holds a full MAYO-2 key pair of its own and signs the certificate independently; the certificate that consensus issues is a quorum of those independent per-validator signatures, each verifying against the validator's public key registered on chain. Forgery of any one validator's signature requires breaking MAYO-2 against that key; forgery of the quorum requires breaking the construction against enough validator keys to cross the threshold count, which is the same Byzantine fault assumption that backs every other quorum property of the chain.

The substrate also carries a separate MPC-driven threshold MAYO-2 scheme. The scheme is a Rust port of the Vinaigrette protocol submitted to the NIST Threshold Call in January 2026; under it a quorum of validators jointly produces a single MAYO-2 signature that verifies against one group public key, with the private key material never reconstructed on any node. The MPC threshold scheme is available as a capability; it is not the consensus signing mechanism today; the substrate is shaped to admit it as a future consensus path without changing the verification surface that smart contracts and external observers depend on.

The reason consensus runs per-validator today, with the threshold scheme on the shelf, is that the multivariate-quadratic family is younger than the lattice and hash-based families that share the NIST track. The literature has produced constructive critique of the family; we track it. It informs the scheme we picked, the parameters we chose, and the pace at which we move chain-wide threshold into consensus. Our response is engineering, not marketing. We run the threshold stack against the reference implementation across all seven layers; property tests, oracle vectors, adversarial inputs. The verifier does not know or care which mode produced the signature; the same MAYO-2 verification works for both.

The choice is deliberate. Cross-chain user signatures must be classical because the chains we sign for are classical; we cannot sign a Bitcoin transaction with a post-quantum scheme that Bitcoin does not verify. The chain's own certificates are not constrained by external verification; we choose the strongest scheme available for the longest validity horizon we can engineer for; that scheme is post-quantum by construction. A quorum certificate produced by Thebes survives the eventual arrival of cryptographically relevant quantum compute; an adversary that breaks secp256k1 still cannot forge a Thebes quorum certificate; the chain's internal history remains verifiable.

The protocol is structured in seven layers. Field arithmetic over GF(16) at the base; matrix operations over the field; secret sharing both Shamir and additive; Beaver triples for multiparty multiplication; oblivious linear solving for the inversion step; the distributed key generation; the threshold signing itself. Each layer is verified against a reference implementation; the reference is the Go implementation maintained by the paper's original authors; the oracle methodology is mechanical equivalence on test vectors generated by the reference. A discrepancy at any layer halts the layer above it; the construction is verified bottom-up, not by integration testing alone.

The threshold preprocessing is the engineering bottleneck and the engineering investment. The offline phase of threshold MAYO-2 signing runs a multiparty computation; it generates Beaver triples over GF(16), drives the oblivious linear solving step, and constructs the distributed key shares. Research implementations of these operations are slow. We rebuilt them to run continuously in the background of an active chain. The online phase of a threshold signature, once preprocessing is in place, is a few milliseconds per certificate; the offline phase amortizes across every signature a key produces for its lifetime. That cadence is the gate we hold ourselves to before threshold MAYO-2 is wired into consensus chain-wide.

Verification is the same standard MAYO-2 verification a single-party signature would require. A MAYO-2 signature at this parameter set is one hundred and eighty-six bytes; the quorum certificate that carries the signer set, the signatures, and the consensus metadata sits comfortably under a kilobyte even at full validator count. A smart contract or an external observer that holds the on-chain registry of validator public keys verifies a quorum certificate by checking each per-validator MAYO-2 signature against its registered key; the same observer holding a single group public key would verify a future threshold-mode certificate with one verification step. Either way the verifier is the same MAYO-2 verifier; either way the construction does not require post-quantum verifiers, only post-quantum signers.

Verified Inference

Thebes verifies inference by replay, not by signature alone. A smart contract that requests inference receives an output, the output hash, and a compute certificate. The certificate is a small MAYO-2 signature over the tuple of the model hash, the input hash, the output hash, the execution-environment hash, the timestamp, and the identity of the provider that produced the compute. The certificate is the commitment; the verification is the replay. Anyone who holds the registered weights and the registered execution environment can rerun the same input and reach the same output, byte for byte. A replayed output whose hash does not match the certificate is a non-repudiable proof of cheating; slashing follows.

The premise that makes replay verification possible is deterministic execution of large neural models. Floating-point math is not associative; reduction order in attention and matmul is not fixed by the math; library autotuners select different kernels per call; tensor-core accumulators differ across hardware generations; server load changes batch sizes and changes the kernels that run. Each of these is a source of non-determinism, and each is addressed explicitly on the inference subnet. The chosen kernels are batch-invariant by construction; the reduction order is fixed; the autotuner is replaced by a pinned schedule that ships with the registered execution environment. Rotary position embeddings are precomputed in double precision and committed to the chain by hash; every node loads the same table. Sampling at this stage is greedy. The composition of these choices is what allows two runs on two machines to land on the same output bits.

Determinism is anchored at the boundary of the hardware, not at the level of the silicon. A registered execution environment names the GPU family, the driver version, the CUDA toolkit version, the inference library version, and the deterministic-kernel build identifier. Two providers that share an execution environment reproduce each other's outputs exactly; a provider that drifts off the registered stack produces outputs that no other validator can reproduce. The chain treats unreproducible outputs as invalid the same way it treats unsigned ingress as invalid; the verifier does not need to know why the drift happened, only that it happened.

Inference runs in pairs. Each request is assigned to two validators drawn from the same execution-environment class by a verifiable random function over the block height and the request identifier; the pair is unpredictable to an adversary across many requests, so collusion is hard to set up. Each validator hashes its output and sends the hash; the chain accepts the result only when the two hashes match. A mismatch surfaces the disagreement on chain and opens a five-block challenge window during which any party holding the registered weights and execution environment can submit the replay-of-record. The matching pair signs the certificate jointly; the non-matching case is settled by replay rather than by trusting either side of the pair.

The chain of custody on every accepted inference is auditable end to end. The smart contract holds the certificate and the model hash; it confirms that the input it submitted matches the input the provider attests to having received, that the output it received matches the output the provider attests to having produced, that the provider's identity matches the public key whose signature verifies, and that the model and execution environment match what the chain registered. No part of the audit depends on a trusted oracle or a trusted operator. The replay can be performed by anyone, on any GPU in the registered class, at any later block.

Certificate verification runs on GPU. Batch MAYO-2 verification at the rate an inference subnet needs is faster on a purpose-built GPU kernel than on a CPU; a separate GPU Merkle SHA-256 kernel handles the model-hash and weights-hash precomputation. Both kernels are verified against pure-Rust reference implementations under the same oracle discipline as the rest of the cryptographic stack. The GPU is acceleration; it is not a trust root. Every output the chain accepts can be reproduced bit for bit, by anyone with the registered stack, on demand.

The Runtime

Thebes smart contracts execute inside a WebAssembly runtime built on Wasmtime. The substrate inherits the WebAssembly execution model and the Motoko language; both have strong adoption in the developer community we work with. The call surface, the type system, and the lifecycle semantics that smart-contract developers in this ecosystem already know are honored at the runtime boundary; contracts written against that surface, the Motoko language, and the ic-cdk Rust framework run on Thebes without modification. The layers below the surface are our own. Where the developer-facing surface is shared, the engineering underneath is not.

Four engineering choices set the substrate's runtime apart at the layer below that surface. Smart-contract installation slices a heavy storage commit across consensus blocks under a per-block byte budget. Wizer pre-initialization runs a module's initialization pass once at install time and snapshots the result so subsequent installs of the same module start from the snapshot. State-root hashing is page-granular; only pages a smart contract actually wrote since the previous block enter the rehash. Storage commits run on a dedicated worker thread decoupled from consensus, with a back-pressure signal that the proposer reads before adding more storage load to the next block. The four are described in the paragraphs that follow.

Smart-contract installation is sliced at byte boundaries. A large install, meaning a multi-megabyte WebAssembly module together with its initial heap, would stall block production if its storage commit landed in a single block. Thebes sequences the commit across multiple consensus blocks under a per-block byte budget; each block writes a bounded portion of the install; the install state machine progresses through checkpointed transitions persisted in RocksDB. The shape is the write-ahead-logged transaction shape from database literature, applied to smart-contract installation rather than to row updates; bounded per-block cost, checkpointed progress, resumable on crash. Execution begins only after the slicing completes; a crash mid-install resumes from the last checkpointed byte offset rather than from scratch. The slicing lives in the storage layer, not inside the WebAssembly runtime; the smart contract sees a single atomic install, the chain sees a sequence of bounded writes.

Wizer pre-initialization shortens cold start. Wizer originated in the WebAssembly toolchain community as an ahead-of-time-evaluation pass over a WebAssembly module's initialization function; the installation pipeline integrates it directly. A smart contract with a large data section runs its initialization once, in a separate pass before installation; the post-initialization memory image is snapshotted; every subsequent install of the same WebAssembly hash starts from the snapshot. Initialization that would otherwise run on every install becomes free for repeat installs; cold-start time for smart contracts with megabytes of initialization data collapses to the time it takes to copy the memory image into the runtime.

State-root hashing is page-granular. A smart contract with a large heap that mutates only a few pages per block does not pay the cost of rehashing its entire heap; the runtime tracks which pages were written through the Linux kernel's userfaultfd write-protect facility; the state-root computation reads only the pages that changed since the previous root. The construction follows the same principle as incremental Merkle path updates in classical cryptography; recompute only the leaves that changed and the paths above them, leave the unchanged subtree intact. A smart contract with a hundred and twenty megabytes of heap that touches a few kilobytes per block rehashes its root in microseconds. The technique scales to many large smart contracts per subnet; the per-block hashing cost is bounded by the aggregate dirty-page count, not by the aggregate smart-contract state.

Storage commits run on a dedicated worker thread, decoupled from consensus. The consensus task does not wait on RocksDB; the proposer reads a back-pressure signal from the storage worker before including new install messages in the next proposal; if the worker queue is saturated, the proposer waits a round and reattempts. The decoupling lets the chain continue finalizing during heavy storage activity; the back-pressure prevents the commit queue from overflowing under load. The pattern follows the separation that high-throughput log-structured storage systems use to keep the latency-critical accept path independent of the throughput-critical commit path.

The Smart Contract Surface

The substrate hosts smart contracts whose ingress and outgress surface is the standard smart-contract-host system-call convention. A smart contract receives messages addressed to its smart contract identifier; a smart contract sends inter-contract calls to other smart contracts on the same subnet, or, in subnets where outcalls are enabled, to external chains and to HTTP endpoints. A smart contract's response is delivered through the same finalized block as the message that requested it; the delivery is observable on chain; the receipt is queryable through a stable HTTP endpoint that returns the smart contract's exact reply bytes.

The substrate exposes a system runtime surface for capabilities that are not part of a smart contract's own state machine; the surface is uniform across subnets, and each subnet enables only the capabilities its specialization supports. Random bytes; smart-contract creation, upgrade, stop, and start; the threshold-signing methods; HTTP outcalls; every such capability is reached through the system runtime surface using the same call convention a smart contract uses to invoke another smart contract. The call surface, types, and lifecycle semantics follow the conventions that smart-contract developers in this ecosystem already know; the consensus, signing, availability, and runtime layers underneath are ours.

The application subnet supports synchronous smart contract execution unconditionally. Methods that perform pure computation, methods that read and write smart contract state, methods that verify a WebAuthn assertion or an ECDSA signature, methods that return a Candid envelope immediately; all of this is available today on the application subnet. A smart contract that does not depend on randomness sourced from the system runtime surface, does not depend on cross-contract calls whose replies it must return to the caller, does not depend on threshold signing or HTTP outcalls; that smart contract is fully buildable today.

Asynchronous smart contract execution is supported through the substrate's reply-propagation lift. A method that awaits a runtime-sourced random call, or awaits an inter-contract call whose reply must reach the original caller, completes through a runtime-layer step that lifts the smart contract's final response into the receipt visible to the ingress caller. The lift is part of the substrate, not bolted on by individual smart contracts; the same code path serves threshold signing, HTTP outcalls, and inter-contract calls whose reply matters, so the asynchronous surface is uniform across the capabilities that depend on it. A flag preserves the pre-lift code path byte-for-byte as a rollback target, in keeping with the substrate's discipline of never removing a verified path until its replacement has been observed at scale.

The Subnets

The substrate supports four subnet specializations; each specialization enables a subset of capabilities; each capability has a corresponding chapter above. The specializations are not separate codebases; the same binary runs on every subnet; the configuration determines which subsystems initialize and which remain dormant.

The application subnet hosts smart contracts whose execution is purely on-chain. Distributed key generation is not initialized; threshold signing is not initialized; HTTP outcalls are not enabled. The subnet's dependency surface is the smallest of the four; the subnet's reliability ceiling is correspondingly the highest. Memphis identity runs here; the application registry runs here; the asset smart contract that serves the frontend runs here; smart contracts that compose pure logic over their own state run here.

The signing subnet hosts smart contracts that require threshold signatures against external chains. Distributed key generation runs continuously; the presignature pools for ECDSA and Schnorr are maintained at configurable depths; the system runtime surface's signing methods are available to every smart contract on the subnet. Cross-chain wallets run here; custody smart contracts run here; protocol bridges and atomic-swap smart contracts that need to issue signatures into external chains run here.

The financial subnet adds the post-quantum certificate path to everything available on the signing subnet. Every quorum certificate is a threshold MAYO-2 signature; the chain history produced on this subnet survives the arrival of cryptographically relevant quantum compute; finality on this subnet is durable past the lifetime of classical discrete-logarithm hardness. High-value DeFi smart contracts whose history must survive long horizons run here; institutional custody whose settlement record cannot be invalidated by future cryptographic advances runs here.

The inference subnet adds verified GPU inference to everything available on the financial subnet. Registered providers serve models; smart contracts request inference and receive compute certificates; the certificates are verifiable against the providers' threshold MAYO-2 public keys. Machine-learning agents that act on chain, autonomous systems whose decisions must be auditable, on-chain inference for regulated use cases; these run here.

A smart contract composes across subnets through the same inter-contract call surface it uses within a single subnet. A smart contract on the application subnet may call into a custody smart contract on the signing subnet; a custody smart contract on the signing subnet may request an inference verification from a smart contract on the inference subnet; the call surface is uniform; the security properties of each subnet are preserved at the subnet boundary; the chain's finality guarantees extend across the composition.