Qubic Outsourced Computation Explained: How Smart Contracts Are Going Cross-Chain

Qubic's June 3rd “Tech on Deck” AMA centered on a development that will reshape how the protocol interacts with the outside world: Outsourced Computation. Core developers FNordSpace and Raika joined moderator Joetom to break down the architecture, explain the authorization model, and lay out a roadmap targeting a July 29 go-live date. The session also offered a look at the realities of building on Qubic's unconventional codebase, drawing over 3,500 live viewers.

What It's Like Building on Qubic's Bare Metal Architecture

Before diving into Outsourced Computation, the team discussed what Qubic core development actually involves. The picture that emerged is one of constant adaptation. Network health dictates the day: if the chain gets stuck or tick speeds degrade, everything else pauses until the issue is resolved.

The Qubic codebase runs directly on UEFI with no standard C++ library available. That constraint colors everything. Basic functionality that most C++ developers take for granted has to be implemented from scratch. AI coding tools help catch small bugs, but they routinely suggest patterns that won't compile in a bare metal environment. The sandbox system for smart contract execution carries its own assumptions about memory and state that AI tools aren't aware of. As Raika noted, developers often end up guiding the AI more than the AI guides them.

Both developers shared war stories. FNordSpace's first public release caused the network to tick once and freeze, a small bug that shook his confidence in those early days. Raika spent months tracking a concurrency bug in the pending transaction pool before isolating it. These experiences drove process improvements: the team now has structured testing plans, better unit test coverage, and network recovery mechanisms. Raika also built a contract verification tool that has become essential as the volume of community-submitted Qubic smart contracts grows.

Outsourced Computation: From On-Chain Observer to Cross-Chain Actor

FNordSpace led the technical deep dive, drawing on three weeks of close collaboration with CFB to design the architecture. He opened with an important correction: Outsourced Computation has nothing to do with renting out compute power, to clarify any confusion. He confirmed this with CFB multiple times.

The concept fits alongside a system Qubic already has. Oracle Machines bring external data into the chain. A smart contract can query them for something like the current Bitcoin price and receive a verified answer. Information flows inward. Outsourced Computation reverses that flow. It allows a Qubic smart contract to send an authorized instruction outward, where an external system acts on it. FNordSpace put it simply: Oracle Machines gave smart contracts eyes and ears. Outsourced Computation gives them hands.

One critical difference separates the two systems. Oracle Machines return results. Outsourced Computation does not. It is fire-and-forget. The smart contract issues an intent, the network authorizes and delivers it, and the OC's job is done. If the contract needs confirmation that the action succeeded, it queries an Oracle Machine separately.

How the Qubic Outsourced Computation Invocation Works

The authorization process has four stages. A smart contract invokes an OC during execution and pays a fee. Every computor executing the contract at that moment records the request parameters into a core data structure. Computors then independently sign the request. Once 451 of the 676 computors have signed, the request is authorized. This two-thirds quorum threshold ensures no instruction leaves the chain without broad consensus, and the signature bundle lets external systems independently verify that the Qubic network sanctioned the action. Finally, each computor forwards the signed bundle to its processor, a separate machine built to carry out the specific off-chain task.

The processor is where the action happens, and it's developed by the smart contract developer, not by Qubic. The protocol provides the authorization machinery and the delivery mechanism. What the processor does with the authorized instruction is entirely up to whoever builds it.

Cross-Chain Actions, Custody Transitions, and Real-World Use Cases

Three categories of use cases emerged from FNordSpace's work with CFB. Cross-chain actions allow a Qubic smart contract to trigger transactions on Bitcoin, Ethereum, or other blockchains through a purpose-built processor. Custody transitions become possible, where a contract could rotate the authorized signers on a multisig wallet in another chain. And external service integrations open the door to real-world interactions: a user pays a contract in QU, the contract verifies the payment, and an OC triggers an action like unlocking a bike or releasing escrowed funds.

Blockchain bridges stand out as a near-term application. Current Qubic bridges depend on middleware that constantly monitors the tick chain. With OC, a smart contract could push instructions to the other chain directly, eliminating the need for an always-on listener and reducing reliance on third-party middleware that users can't easily audit.

One design constraint worth noting: because all 676 computors forward the authorized bundle to their processors, the receiving system must handle deduplication. A single instruction from Qubic arrives as 676 identical requests, and the destination needs logic to recognize them as one order. This can be handled at the processor level, but it has to be accounted for in the design.

Qubic Token Burn and Fee Model

The economics follow the same pattern as Oracle Machines. Each OC invocation costs a fee paid by the smart contract, and that fee is burned, permanently removing QUBIC tokens from circulation. Alongside existing execution fees and Oracle call fees, Outsourced Computation adds another deflationary channel that scales with network usage.

Outsourced Computation Roadmap: Timeline to July 29 Go-Live

The development roadmap is staged and concrete. Architecture documents were in review with CFB at the time of the AMA. Basic implementation started June 3. A mock OC targets the testnet by June 17 and mainnet by July 1, exercising the full invocation and authorization path without real-world actions. The production release, opening the protocol for developers to build on, is set for July 29. If the system stabilizes earlier, the team indicated the schedule could move up.

Qubic's Three Infrastructure Pillars Near Completion

With Outsourced Computation approaching its go-live, Qubic's smart contract infrastructure reaches a milestone. Smart contracts handle on-chain logic. Oracle Machines bring external data in. Outsourced Computation sends authorized intent out. Together, these three pillars give Qubic smart contracts bidirectional communication with the outside world at the protocol level.

The community now has a clear set of dates to watch: testnet mock in mid-June, mainnet testing in early July, and a full go-live on July 29. A follow-up Tech AMA covering release management and additional developer topics is planned. For anyone building on Qubic or evaluating where the protocol is headed, the next eight weeks will be telling.