Skip to main content

Soda Bubble expands across public chains with explicit decryption permissions

Soda Labs says a $3 million seed round will expand Bubble beyond COTI. Its architecture separates encrypted computation from decisions about who can read the result.

A dark blue cube connected to translucent teal nodes by blue and amber paths.
TechKili · Cloudflare Workers AI FLUX.2 klein. Conceptual illustration, not a Bubble deployment diagram.
Share this article:
In this article

Soda Labs announced a $3 million seed round led entirely by NextBlock on October 8, 2026, to expand Bubble, its confidential-computation infrastructure for public blockchains. The practical question for developers is not simply whether data can be encrypted. It is who may use each encrypted value, and whether the eventual result becomes public or remains accessible only to an authorized user.

The company-issued funding release describes an expansion from COTI to a chain-agnostic coprocessor. Soda says Bubble already supports COTI, Ethereum, Polygon, Arbitrum and Base; it describes Solana as an expansion in progress. The funding supports broader chain coverage, integrations and the validator network, rather than establishing that every planned chain is available now.

Public settlement, encrypted computation

Bubble's protocol documentation separates the host blockchain from the computation layer. On-chain contracts control access and trigger work; an off-chain engine uses multi-party computation with garbled circuits to operate on encrypted inputs. Bubble manages permissions and encrypted data around that process.

This arrangement lets an application retain public-chain coordination while moving confidential operations into a separate system. It also adds components to the deployment: developers need to understand the host contracts, the computation participants and the user-facing service that handles encryption and delivery. Confidential computation does not make all information about an application's public-chain activity private.

A new encrypted value needs a new permission

The access-control guide attaches permissions to handles, which identify encrypted values. Each operation produces a new handle. Developers must explicitly give the intended users or contracts access to that result; permission on an earlier input is not a reason to assume that a later output has the same readers.

Consider a payment application that computes a balance from private amounts. The account holder may need to read the balance, while another contract needs permission to use it in a subsequent calculation. Those are separate access decisions. This is an illustrative design example, not a deployment TechKili has tested.

The decryption guide then distinguishes two outcomes. “Decrypt for Everyone” stores the plaintext result on-chain, where anyone can see it. Decryption for a specific user re-encrypts the result with that user's AES key through the User Interactor. Choosing the public route can be intentional, but it ends confidentiality for that result.

On-chain decryption is asynchronous: an application requests it, then receives a callback with the result and signatures to verify. The interface therefore needs to handle a pending result and verification, instead of treating decryption as an immediate local read.

Check the security model behind the feature

Soda's gcVM technical paper analyzes privacy and correctness under defined assumptions about the garbler and evaluator participants. Those assumptions matter when assessing the actual network and its operators. Public auditability and data confidentiality are distinct properties; the paper is not an independent production audit of a particular deployment.

For a developer considering Bubble, the useful next step is to map every encrypted output to its permitted users and contracts, identify every intentional public disclosure, and check the participant configuration against the documented security model. A trial should also test the asynchronous decryption path and what happens when permission is missing.

The funding gives Soda resources to broaden an existing system. Whether that system suits a financial workflow depends on the access design, supported chain and operational assumptions—not on the size of the round.

Sources

Research uses Soda's documentation, technical paper and issuer announcement. The discovery article is labeled contributed content. TechKili has not independently tested Bubble or verified comparative performance claims.