In one sentence. ComputeFlux puts itself at roughly 60% of the way to full decentralization, and this article names the four places it's still centralized rather than waiting for someone else to notice them.
Picture it like this. A bridge built outward from both banks. The spans over shallow water go up quickly. The center span — over the deepest, fastest part of the channel — takes as long as everything else combined. Every remaining item on this roadmap sits over the channel.
Why it matters. Roadmaps in this industry are usually marketing documents. This one reads as a scorecard: here is what's still done by hand, here is what relies on a hardcoded list, here is what the founding team still controls — and here is why each shortcut was the right call at the time.
Want the ambitious end? Skip to ZK proofs and the DAO launch.
Where We Stand and Why the Next Steps Are Hard
Article 21 covered the current architecture end to end, from a developer's laptop running a local multi-node network to a hardware SGX validator fleet in Kubernetes. Worth stepping back now and asking where all of it is headed.
Call the current state roughly 60% of the journey to a fully decentralized AI routing network: CometBFT consensus, DKG threshold signatures, a WASM runtime, TEE enclave deployment, a multi-protocol REST API. The remaining 40% is disproportionately hard, because it's exactly the parts that are still centralized. Epoch transitions need manual Sudo intervention. Validator discovery leans on hardcoded peer lists. Contract execution runs through Go Native dispatch rather than pure WASM. Governance sits with a development team, not a token-holder DAO.
Every one of those was a deliberate bootstrapping choice, not an oversight. What follows is how to remove them — and why each removal reintroduces the technical problem the shortcut was avoiding.
Q3 2026: Epoch Automation and DKG Bootstrap
Epoch Automation: Removing the Human from the Loop
The current epoch system recognizes the concept of epochs — discrete time periods with a defined validator set — but transitions between epochs require an external trigger. CheckEpochFromValidator() can detect that a new epoch should begin, but it doesn't autonomously initiate the transition. This is the Sudo equivalent of a circuit breaker that can detect an overload but needs a human to flip the switch.
Full automation requires solving three sub-problems:
1. Deterministic transition timing. Epoch boundaries must be computed deterministically from on-chain data so that all validators agree on when the transition occurs without any off-chain coordination. The natural approach is block-height-based: epoch N spans blocks [N * epoch_length, (N+1) * epoch_length - 1]. At the first block of epoch N+1, PrepareProposal automatically injects a SysCall_EpochStart transaction. This is deterministic because all validators see the same block height.
The subtlety is that block heights are not wall-clock time, and CometBFT block times can vary (1-5 seconds depending on validator count and network latency). A governance parameter for min_epoch_duration_seconds provides a safety net: if an epoch would end before the minimum duration has elapsed (e.g., due to a burst of fast blocks), the transition is delayed. This prevents epochs from being so short that validators cannot complete DKG ceremonies or relay settlement batches.
2. Graceful handoff of in-flight transactions. When an epoch transitions, the validator set may change. In-flight DKG signing ceremonies — where validators are in the middle of collecting partial signatures for a threshold signature — must either complete before the transition or be safely aborted and restarted by the new validator set. The relay's AsyncBatchState tracking (tx_to_realy.go) is a partial building block. It records a per-chain LastSync timestamp that behaves like a lock, gating whether a new sync or signing batch can start via IsHubSyncRuning and marking batches begun or finished via HubSyncStep2 and HubSyncEnd. Turning that timestamp lock into a true atomic reset — one that lets a new epoch's validators safely restart an in-flight ceremony from scratch — is precisely the gap this roadmap item has to close. It isn't solved yet.
3. Validator election with reputation weighting. The current validator set is manually curated. Automated epoch transitions require an election algorithm that selects validators based on objective, on-chain criteria. The proposed algorithm weights validators by a composite score:
score = w1 × uptime_ratio + w2 × DKG_participation_ratio + w3 × TEE_attestation_validity
uptime_ratio is the fraction of blocks for which the validator's Precommit was included. DKG_participation_ratio is the fraction of signing ceremonies where the validator contributed a valid partial signature. TEE_attestation_validity is the fraction of Vote Extensions where the validator's SGX quote was verifiable. Weights w1, w2, w3 are governance parameters, initially biased toward uptime (to ensure liveness) and TEE validity (to ensure security).
The challenge is that all three metrics are computed on-chain, within the TEE. This means the election algorithm must be efficient enough to run in every block without exceeding the enclave's CPU budget. An O(n log n) sorting of all validators by score every block would be expensive for large validator sets (100+). The solution is to maintain a priority queue that updates incrementally as metrics change, with amortized O(log n) per update.
DKG Bootstrap: Peer Discovery Without Hardcoded Lists
The current DKG initialization assumes a static, pre-configured list of validator addresses. This is the genesis.json model: before the network starts, operators agree on who the validators are and hardcode their P2P addresses. For a network that aims to support dynamic validator membership, this is unsustainable.
The DKG Bootstrap protocol must enable a new node to join the network without any prior out-of-band coordination. The approach is a three-phase bootstrap ceremony (discovery, enrollment, then a resharing step at the next epoch):
Phase 1: Discovery. The joining node connects to any existing validator (the "bootstrap peer") using a well-known seed address (DNS seed or a small set of hardcoded bootstrap nodes — this is the one hardcoded element that cannot be eliminated). The bootstrap peer responds with the current validator set, the current epoch number, and the current DKG public key. The joining node verifies that the bootstrap peer's response is signed by the threshold DKG key, proving that the information comes from the live network, not an impostor.
Phase 2: Enrollment. The joining node submits an on-chain transaction (RegisterValidator) with its P2P address, its validator public key, and a deposit. Existing validators verify the deposit and the TEE attestation (or simulated attestation in development). If approved (which, in the pre-DAO phase, means Sudo approval; in the DAO phase, means a governance vote), the node is added to the pending validator set.
Phase 3: Key Resharing. At the next epoch transition, the existing validators execute a proactive DKG resharing ceremony. Using the kyber library's resharing capability, each existing validator generates a new share of the DKG secret for the new validator set (old validators + new validators), encrypts it to each recipient's public key, and broadcasts it. The new validators decrypt their shares and verify them against the existing DKG public key. Once t validators confirm successful resharing, the epoch transitions to the new validator set with the new DKG key shares.
The hard part of resharing is not the cryptography — kyber handles that. It's ensuring that the resharing ceremony completes atomically despite the possibility of validators going offline mid-ceremony. The protocol must tolerate up to f unresponsive validators (where f is the BFT fault tolerance threshold) and still produce valid shares for all honest validators. This requires the resharing to be an asynchronous protocol with a timeout: if a validator doesn't produce their resharing message within resharing_timeout blocks, they are excluded from the new validator set, and the threshold is adjusted accordingly.
Q4 2026: Full WASM Contracts and Multi-Chain Relay
Removing the Go Native Dependency
The current execution model is a hybrid. A few methods — AuditModel with its Result type, for instance — run through contractgen-generated dispatch. The bulk of gateway logic doesn't: model registration, provider management, billing, and API key operations all execute as native Go inside the enclave. So updating any contract method means updating the entire node binary, re-running the enclave signing process, and coordinating a network-wide upgrade. That's a hard fork by another name.
Full WASM contracts move all gateway logic into WASM bytecode that is stored on-chain and executed by the wazero runtime. This is architecturally identical to how Ethereum executes EVM bytecode or how Polkadot executes ink! contracts, but with a critical difference: the WASM runtime runs inside the SGX enclave, so contract execution is confidential. Even the validators executing the contract cannot see the contract's internal state unless the contract explicitly exposes it.
The primary technical challenge is state access performance. In the Go Native model, a contract method accesses store.IndexedList directly — it's a Go struct dereference. In the WASM model, every state read and write must go through the WASM import/export interface, which involves crossing the WASM sandbox boundary, serializing SCALE-encoded data, and potentially performing cryptographic verification. The overhead of this boundary crossing can be 10-100x compared to native access.
The mitigation is a state cache within the WASM runtime. Rather than crossing the boundary for every individual field access, the runtime pre-loads the entire contract state for the current transaction into a WASM-accessible memory region. The contract reads and writes to this cache at native WASM speed. At transaction commit, the runtime diffs the cache against the pre-transaction state and writes only changed keys to the underlying PebbleDB. This is the same technique that Substrate's FRAME runtime uses, adapted for the wazero/SGX environment.
Multi-Chain Relay: Polkadot + EVM Event Sync
Settlement records stay on the TEE chain — mainchain fees make per-batch anchoring uneconomical, as Article 10 explains — so the relay moves only events that carry actual value. Phase 1 of the relay is unidirectional (mainchain → sidechain event sync) with trust in the RPC endpoint, covered in Article 11. Phase 2 adds bidirectionality and removes RPC trust through light client verification.
Direction 1 (existing): Polkadot → Sidechain. Validators poll the Polkadot relay chain for events (deposits, transfers) and commit them to the sidechain through consensus-validated RelaySync transactions. Phase 2 replaces the "trust the RPC" model with header-chain verification: the sidechain validators maintain a light client of the mainchain within their TEE, verifying each mainchain block header against the validator set's consensus signatures. When an event is submitted, the RelaySync carries a Merkle proof of the event's inclusion in the block, letting validators verify it without trusting the RPC endpoint.
Direction 2 (new): Ethereum → Sidechain (EVM events). An Ethereum user locks tokens in a bridge contract, and the sidechain must credit the user's ComputeFlux account. This requires the sidechain validators to maintain an EVM light client — verifying Ethereum block headers and Merkle-Patricia trie proofs for specific events. The technical challenge is that EVM block headers are significantly larger and more expensive to verify than Substrate headers (due to Ethereum's larger validator set and the complexity of the Beacon Chain consensus). The sidechain will likely use a BLS signature-aggregated sync committee approach (similar to the Altair light client protocol) to keep verification costs manageable within the TEE's CPU budget.
The bidirectional relay also requires solving the asset representation problem: what is the canonical representation of ETH on the sidechain, and how is it backed by locked ETH on mainnet? The proposed model is a lock-and-mint bridge: users lock ETH in a mainchain bridge contract, and the sidechain issues a wrapped representation (wETH) that can be used for API payments. The bridge is secured by the same DKG threshold signature scheme that signs settlement transactions, ensuring that no single validator can unilaterally mint or burn bridged assets.
Q1 2027: ZK Proofs and DAO Launch
ZK Proofs Replacing NIZK
The current reputation system relies on "trust but verify" — the system trusts that providers are serving the correct model until a community report or random audit suggests otherwise, then verifies through endpoint health checks and response schema validation. This is adequate for catching egregious fraud but cannot detect subtle cheating: a provider serving Llama-2-70B instead of Llama-2-13B passes all schema checks (the response format is identical) but delivers lower-quality output.
ZK proofs of inference offer a stronger guarantee: the provider submits a cryptographic proof that a specific model, with specific weights, produced a specific output for a given input. The proof can be verified by a smart contract (or WASM module) in milliseconds, even for large models.
The practical challenge is that ZK proving for transformer inference is currently orders of magnitude too slow and expensive for real-time API calls. Proving a single GPT-2 inference takes minutes on consumer hardware; proving a GPT-4 inference is research-grade. The pragmatic approach is a proof-of-sampling model: the provider periodically generates ZK proofs for randomly selected past inferences, and the network verifies these proofs asynchronously. If a proof fails, the provider's deposit is slashed and their reputation is penalized retroactively. This doesn't prevent the first fraudulent inference — but it ensures that sustained fraud is economically irrational, because the expected value of fraud (revenue from serving cheaper models) is less than the expected cost (slashed deposit × probability of being audited).
The choice of ZK scheme involves trade-offs: Groth16 produces small, fast-to-verify proofs but requires a circuit-specific trusted setup ceremony (which must be performed by the DKG validators within the TEE). PLONK eliminates the trusted setup but produces larger proofs. The likely path is Groth16 for inference proving (where the model circuit is fixed for long periods, making the per-circuit setup acceptable) and PLONK for general-purpose contract verification.
DAO Launch: Distributing the Sudo Key
The most consequential change in the roadmap is the transition from Sudo governance to DAO governance. This is not a technical upgrade — it's a power transition. The Sudo key (caller.T == 0) currently controls model approval, provider registration, pricing parameters, audit resolution, WASM upgrades, and validator set membership. Listing all of these in a DAO proposal system and implementing a secure voting mechanism is a governance design problem as much as a technical one.
The proposal-approval pipeline: a token holder submits a proposal with a deposit (refunded if the proposal passes, slashed if it's considered spam). There's a review period (e.g., 7 days) during which the community discusses the proposal. Then a voting period (e.g., 3 days) during which token holders vote. If the proposal meets quorum (minimum participation) and approval threshold (e.g., >50% in favor), it executes automatically.
The hard design questions: (1) Is voting power proportional to token holdings (plutocracy) or quadratic (favoring broad support)? ComputeFlux's likely model is token-weighted with a time-lock multiplier: tokens locked for longer periods have proportionally higher voting weight, aligning voting power with long-term alignment. (2) Can the DAO upgrade itself? Yes — the DAO's own governance parameters (voting period, quorum, threshold) are themselves subject to governance, enabling the community to evolve the rules without a hard fork. (3) What prevents a 51% attack on governance? Time locks, multi-signature execution (requiring multiple independent entities to execute approved proposals), and an emergency pause mechanism (requiring a higher threshold to activate, preventing its abuse).
Q2 2027: Mobile DApp and B2B White-Label
Mobile DApp. The React 19 codebase already uses responsive Tailwind design, so the technical path is a Progressive Web App (PWA) that wraps the existing SPA with a service worker for offline caching and a Web App Manifest for installability. Native React Native is a later optimization if PWA performance proves insufficient. The primary challenge is Web3Auth integration on mobile: the MPC-TSS key shares that enable social login must work without browser extensions, using deep linking for OAuth redirects and platform-specific secure storage (iOS Keychain, Android Keystore) for key material.
B2B White-Label. The multi-tenant architecture requires extending the APIKeyInfoV2 model with a TenantID field that isolates billing, rate limiting, and model access per tenant. The protocol compatibility layer (which already translates OpenAI/Anthropic/Gemini) is the strongest selling point for B2B: enterprises can point their existing OpenAI SDK at a ComputeFlux endpoint and get TEE-protected inference with on-chain billing without changing a line of application code.
Conclusion: The Roadmap as a Scorecard
Each milestone here is independently useful. Automated epochs improve reliability even without DKG bootstrap. WASM contracts enable faster iteration even before ZK proofs. Mobile support expands the user base even before full DAO governance.
They're also sequenced. DAO governance requires WASM contracts, so the DAO can upgrade itself. Full WASM contracts require an efficient state cache, which epoch automation helps stabilize. ZK proofs require a mature reputation system, which DAO governance is what makes credible. This is a dependency graph, not a wishlist.
Key Takeaways
- Four centralization points, named out loud. Epoch transitions still need a manual admin action, validator discovery relies on a hardcoded peer list, contracts run through the native path rather than a pure sandbox, and governance sits with a team rather than token holders.
- Each was a deliberate bootstrapping decision, not an oversight — and removing each one reintroduces exactly the hard problem the shortcut was there to avoid. That's why the remaining work is disproportionately difficult.
- This is a dependency graph, not a wishlist. Self-governing contracts are a prerequisite for a DAO that can upgrade itself; a stable state cache is a prerequisite for those contracts; epoch automation helps stabilize the cache.
- Every milestone is independently useful, which is the real test of an honest roadmap. Nothing on this list is valuable only if everything else also ships.
- Read this alongside Articles 1 and 6, which flag the same gaps from the inside. Whether a project's "how it works" and its "what's missing" agree with each other is one of the more reliable signals you can check.
With a clear sense of where ComputeFlux is headed, the natural next question is how it stacks up against what already exists today.
Next — Article 23: Competitor Comparison: the same question asked of OpenRouter, LiteLLM, Venice.ai, and Akash — and the answer isn't a feature table.