On-chain contracts can’t do everything: they give strong guarantees but have big limitations
Smart contracts are great because they make it obvious what code is running and how that code will behave. This predictability comes from a few core guarantees: once deployed, the code can’t be changed unless you’ve explicitly built in an upgrade mechanism; everything runs in the open; and, given the same inputs, the contract behaves the same way for everyone.
These guarantees are super useful, but achieving them on-chain comes with practical limitations driven by the underlying blockchain execution model. They expose all code and data publicly, run inside a tightly constrained VM with no access to the outside world, and require gas for every operation. That implementation model makes on-chain smart contracts a bad fit for most real-world application logic:
- Public execution creates real security and business risks. On-chain smart contracts run where everyone can see them. That works well when you want transparency, but is brutal when workflows touch sensitive data like proprietary trading strategies, compliance rules, user data, credentials, or certain kinds of governance logic. The ramifications range from obvious—attackers stealing credentials—to subtle—attackers exploiting their knowledge of approval structures for sophisticated spearphishing.
- Complex computations cost a ton. Because every operation in a smart contract is metered, anything computationally intense—pricing, scoring, risk modeling, aggregation, simulation—gets prohibitively expensive. The economics simply don’t scale.
- Smart contracts aren’t optimized for integrations or heavy compute. Even the fastest chain is orders of magnitude slower than a standard server, and throughput is capped because every validator must replay every computation. At the same time, on-chain smart contracts cannot call arbitrary external APIs, ingest real-time market feeds, or interact directly with private data sources; any attempt to pull in outside information requires indirect, complex, latency-heavy oracle workarounds. These constraints together make it nearly impossible to run substantial, performance-sensitive, or data-dependent logic on-chain.
- Interop is painful, and multi-chain deployments are worse. Smart contract models differ across chains, and some major ecosystems like Bitcoin and Zcash don’t support them at all. Even among chains that do, the semantics, costs, execution environments, and toolchains vary enough that “write once, deploy everywhere” is a fantasy. Deploying even the same piece of logic to multiple chains is expensive, fragile, and creates a long-term operational burden.
Off-chain code avoids on-chain drawbacks—but loses on-chain guarantees
To escape the on-chain limitations of smart contracts, teams run most of their critical logic off-chain. This gives them privacy, speed, flexibility, and expressiveness—but it also strips away the guarantees that make on-chain execution so appealing. For example:
- Operators can modify or redeploy code any time. In a standard backend, the operator can push a new build, patch, disable checks, or roll back to an old version. Even a well-intentioned team can make silent changes; a compromised operator can make malicious ones. Off-chain systems have no built-in notion of “this code should never change” or “this upgrade followed the right governance process.”
- Users can’t check what code is actually executed. Even if the operator never changes the code, users and counterparties cannot tell what source code actually executed. This is true even if the code itself is open source: nothing ties “what I interacted with” to “what the team claims was deployed.”
- The execution environment provides no assurance that logic ran as written. The operator controls the OS, environment variables, configuration files, and system state. A malicious host—or an accidental misconfiguration—can alter results at runtime by injecting state, bypassing checks, or influencing control flow.
Why we built Cubist Confidential Cloud Functions
The status quo pushes teams into a corner: either expose everything on-chain and pay the heavy costs, or move logic off-chain and lose crucial guarantees. What teams actually need is confidential, programmable infrastructure that lets them:
- run compute-heavy logic
- execute sensitive logic privately
- scale across chains without rewriting everything
- apply strong governance and safe upgrade paths to critical code
- produce evidence that security and compliance controls are real.
Together, these requirements expose a critical gap between what smart contracts are great at and what security sensitive production systems need. We built Cubist Confidential Cloud Functions (C2F) to bridge this gap.
Cubist Confidential Cloud Functions offers smart contract guarantees for private off-chain code
Cubist C2F is a confidential compute environment that gives developers assurance that code runs as written while still allowing that code to interact with the outside world. Web3 teams write their own custom logic—including private data (e.g., credentials or proprietary business logic) or external calls (e.g., to transaction monitoring services or real-time market feeds)—and execute it inside tamper-proof hardware and get cryptographic proof—an attestation—that it runs as written. Teams can use this attestation for their own peace of mind—or they can share it (and their Cubist C2F code, if desired) with regulators or other interested parties who need to verify the guarantees being enforced.
Cubist C2F is used for secure off-chain computation that’s either tied to a signing key (private smart contracts), or not tied to a signing key (verifiable off-chain code). Today C2F is being used in production for both types of computation, including by Squid to enable the newest version of their Cross-Chain Order Routing and Auction Layer (CORAL). CORAL v2 replaces on-chain smart contracts and General Message Passing (GMP) protocols with private, off-chain logic in Cubist C2F to enable sub-second cross-chain swaps across EVM, non-EVM, and non-smart contract chains for higher reliability and better pricing. As another example, DogeOS is using Cubist C2F to secure the canonical bridge for its EVM-compatible app layer on Dogecoin. Cubist C2F verifies zero-knowledge proofs of DogeOS execution to guarantee correctness while bringing covenant functionality and transaction introspection to Dogecoin.
The C2F platform consists of a WebAssembly (Wasm) runtime hosted within a secure sandbox powered by Wasmtime and running in a Nitro Enclave Trusted Execution Environment (TEE). (Here’s why we don’t use SGX.) We chose Wasm, a portable bytecode format, because it offers isolation by design. Our deep expertise in Wasm security is reflected in our leadership: our co-founder, Deian, serves on the Board of Directors for the Bytecode Alliance, the cross-industry standardization body for the Wasm ecosystem. Fraser (co-founder and CTO), John (founding engineer), and Deian have also published peer-reviewed research verifying that Wasm compilers and runtimes give the guarantees they’re supposed to, and on extensions to Wasm that make it possible for developers to write safe cryptographic code.
You can dive deeper into the architecture of the Cubist C2F system and related engineering design choices in our whitepaper.
Using Cubist C2F for private smart contracts
Cubist C2F makes it possible to move on-chain smart contracts off-chain, which lets organizations compute cheaply and in an inherently cross-chain way. Moving computation off-chain also keeps signing logic private, a prerequisite for large-scale institutional adoption of digital assets.
Whether on-chain or off-chain, a smart contract consists of arbitrary logic that controls the action of a signing key. To control which actions a key can take within Cubist C2F, developers write off-chain code in a Wasm-compatible programming language (e.g., Rust), with optional access to a network connection, a key value store, and storage and encryption for secrets. This code runs inside a TEE every time the Cubist API receives a signing request with the relevant key—and the key will only sign the transaction if the C2F-powered code says “yes”.
For tight enforcement, Cubist C2F is natively integrated with our CubeSigner key management platform, but C2F can just as easily be used with any other key management platform(s) of your choice. This lets you add private smart contract functionality or robust policy enforcement to your existing keys.
Using Cubist C2F for verifiable off-chain code
For some applications, it’s important to get guarantees about what code is actually executing, and about how that code can be updated. Using Cubist C2F, teams run critical application logic off-chain inside TEEs and receive verifiable evidence attesting to what code executed and what decision it made. This is ideal for workflows where auditability matters.
To use C2F this way, developers once again write their own custom code in a Wasm-compatible programming language and deploy it through their CI pipeline into Cubist C2F. The code can be invoked via an API call from the main application logic, and its outputs can be consumed by on-chain contracts, internal services, or external audit/compliance processes. External parties can also check a cryptographic attestation that a given piece of code was actually the code that ran (optionally in a privacy-preserving way).
Verifiable off-chain code in Cubist C2F can sit in front of any critical action or decision point to provide a clear audit trail of what logic authorized the action and why.
Teams are using Cubist Confidential Cloud Functions to build what they can’t build anywhere else
Off-chain smart contract capabilities
Teams are using Cubist C2F to enforce smart contract logic on chains that don’t have native smart contracts, and for coordinating logic across chains without maintaining separate on-chain contracts. Examples include:
- Smart contract functionality (i.e., enforcement of arbitrary logic) for Bitcoin, Zcash, Dogecoin, etc.
- Instant cross-chain settlements, swaps, and bridging without General Messaging Passing (GMP) or intermediary protocols.
- Cross-chain trading orchestration layers enforced by off-chain code without bridges or counterparty risk.
- Tokenization networks where compliance rules follow assets across chains and deal information stays private.
- Multi-chain private escrows whose conditions can be fulfilled across different chains.
- Instant payments with guaranteed on-chain settlement enabled by key-bound double spending prevention function.
- Non-custodial payment rails with partial captures, timed refunds and cancellations, fraud holds, etc.
Policy layer for transaction signing and code enforcement
Teams are using Cubist C2F as a confidential execution layer that can enforce arbitrary signing rules before actions hit the chain, which is something that no blockchain VM can do natively. Examples include:
- Restricting blind signing or message signing to specific conditions (e.g., certain exchanges or delegation types).
- Replacing an existing wallet’s policy engine to support arbitrary or bespoke controls for existing keys.
- Limiting smart contract calls to specific methods with specific values (e.g., depositing funds into a lending protocol if the protocol is healthy).
- Locking down smart contract keys so only auditor-approved, CI-reviewed contracts can be deployed on-chain.
- Managing a small but critical set of off-chain code that needs to run confidentially and be enforced correctly.
Secure asset management, wrapped tokens, and institutional controls
Teams are using Cubist C2F to enable programmable, verifiable policies around custody, asset movement, and risk management. Examples include:
- Permissionless wrapped assets that don’t rely on trusted corporations.
- Verifiable policies for DeFi protocol governance (e.g., vaults and bridges) to minimize risk to institutional users.
- Shared-custody and bi/tri-party models encoded as verifiable policies to give on-chain lenders cryptographic guarantees on liquidation logic.
- Reducing over-collateralization by encoding repayment and liquidation rules as verifiable, enforceable code.
Real-time risk management, monitoring, and alerting
Teams are using Cubist C2F to build monitoring and enforcement logic that reacts to on-chain conditions and transaction requests in real time or after the fact. Examples include:
- Parsing and simulating transactions to detect malicious intent before signing.
- Programmatic risk limits using real-time market data (e.g., “withdraw liquidity if TVL drops 20% in an hour”).
- Policy-based gating of operations tied to on-chain data or external signals (e.g., monitoring activity on one chain and taking an action on another, or restricting swaps and loan deposits based on CEX rates, etc.)
- Governance controls that require policy changes to be verified off-chain and approved before taking effect.
- Retroactive auditing of processed transactions to ensure they comply with a set of rules.
Get started with Cubist Confidential Cloud Functions
The Cubist C2F platform works with your existing Web3 tech stack and secrets manager. Write Rust code using your favorite libraries, deploy it to Cubist C2F via your regular CI/CD pipeline, and invoke it directly from your codebase. The goal is simple: isolate your most critical application logic and run it privately and verifiably.
There are a few ways to get started. Most teams begin by prototyping in a Cubist C2F test environment. Cubist C2F comes with an SDK that makes it easy to upload and invoke your confidential code. For larger projects, we offer guidance on architecture and security so teams don’t spend cycles reinventing patterns that already work. If you are already a CubeSigner customer, all you need to do is ask your Account Manager to enable Cubist C2F on your account. While Cubist C2F is natively integrated with CubeSigner, it also works seamlessly with every other key management platform, so if your keys are happy where they are then you don’t have to migrate them.
With Cubist C2F, confidentiality becomes a straightforward extension of your existing workflows. Cubist C2F is live in-production with customers (like Squid, Lombard, and DogeOS!) and has been released for General Availability. Request a demo or test environment here.
The future is at the intersection of on-chain and off-chain
Our commitment is to give teams a performant way to run sensitive logic without reshaping their development process or taking on tech debt. This means that developers don’t have to learn new programming models or bend their workflows around new constraints.
Looking ahead, our roadmap for Cubist C2F is focused on rolling out new starter kits and guides for different verticals, and continuing to make confidential execution feel like a natural part of Web3 development. We’ll share more details as these pieces come online, but the direction remains the same: make off-chain logic enforcement a standard part of every Web3 tech stack.
Keep reading
- Review the C2F Press Release.
- Dive into the C2F whitepaper to learn more about the system architecture.
- Learn how Cubist customer Squid is using C2F to replace on-chain smart contracts and GMP protocols.
- Check out C2F tutorials on how to build Private Smart Accounts and Cross-Chain Atomic Swaps.
- Discover C2F for writing and enforcing cross-chain wallet policies.
