Soda Labs
Soda Labs Docs
Developer GuidesTypes and operations

Logics

Write branching logic over encrypted values, where conditions cannot be read on-chain, using the mux operation.

When using Bubble, encrypted data is never revealed on-chain unless a call to decrypt is made, the smart contract only receives handles that reference encrypted values. Because of this, the contract cannot use encrypted data inside control flow, such as if condition since this operation would require decrypting the values. Instead, all decisions that depend on secret values must be handled in a privacy-preserving way. There are two main approaches available to developers:

1. Mux operation

The mux function allows a smart contract to make a choice based on an encrypted condition without ever learning the underlying values. Instead of branching with if (condition), mux takes three encrypted handles:

mux(encryptedCondition, encryptedValueA, encryptedValueB) → encryptedResult

The important part is that the contract never sees the plaintext. The comparison that produced encryptedCondition was done inside the MPC network, and its result is stored as an encrypted boolean. The mux function uses this encrypted boolean to select between the two encrypted values securely and without branching. The selection is computed by the MPC network, and the contract receives another handle that points to the resulting encrypted value.

So instead of returning a boolean, mux returns a new encrypted handle, which can be passed to later contract functions or stored on-chain just like any other encrypted value. The contract does not know which branch was taken, there is no observable difference in gas usage, state changes, or execution trace that could leak information.

This means that mux enables data-dependent operations that look like conditional logic, but do not reveal the condition or the values involved. It is a core building block for writing privacy-preserving logic where the contract can continue working with encrypted outputs while still keeping all underlying values secret.

2. Asynchronous MPC callback flow

When more complex logic is needed (such as comparisons, arithmetic, validation, or multi-step decision-making over encrypted values), the contract may need the actual decrypted result in order to proceed. In these cases, the contract sends a computation or decryption request to the MPC network and then waits for the result to be returned via an asynchronous callback. This approach is used only when there is no privacy-preserving alternative - that is, when the contract truly needs the real public value in order to continue execution. Once the callback is executed and the result is returned on-chain, the smart contract can resume processing using the now-public value while maintaining correct and secure workflow semantics.

More details about this approach can be found in the Decryption section.

On this page