Skip to main content
Secure multiparty computation (MPC) gives you a way to compute over private inputs without first pooling those inputs in one plaintext service. Stoffel gives you a way to build that private computation into an application without starting from protocol papers, custom networking, and one-off runtime code. The goal is not to hide every MPC concept. A Stoffel developer still needs to understand shares, parties, thresholds, protocol messages, and openings. Stoffel makes those concepts part of a compiler, bytecode format, VM, CLI, and Rust SDK so they can fit into a normal development loop. Comparison of a traditional MPC project path with a Stoffel project path, showing how Stoffel keeps application iteration visible while protocol plumbing stays packaged.

​
The gap Stoffel closes

Raw MPC development usually combines several hard problems at once:
  • designing the private computation;
  • choosing and integrating a protocol backend;
  • representing secret-shared values correctly;
  • coordinating parties and thresholds;
  • deciding where values are allowed to open;
  • connecting the private computation back to application code.
Stoffel separates those concerns into developer-facing surfaces:
ConcernStoffel surface
Private computationStoffelLang source (.stfl)
Build artifact.stflb bytecode
Local feedbackstoffel check, stoffel build, and local MPC runs
Runtime executionStoffel VM parties and MPC backends
Application integrationRust SDK and generated bindings
Output boundaryexplicit openings or client outputs
That separation is the main reason to use Stoffel. It gives the private part of the application a buildable artifact and a repeatable local workflow.

​
What Stoffel gives you

Stoffel packages the MPC workflow into a toolchain rather than a collection of protocol fragments. Stoffel toolchain diagram showing StoffelLang, the CLI, bytecode artifacts, VM parties, and Rust SDK integration connected by one bytecode contract.

​
A language boundary for private computation

You write the private workflow in StoffelLang instead of embedding protocol logic directly into the host application. That keeps the sensitive computation easier to review: inputs, share operations, and outputs live in a program designed for the MPC runtime.

​
A compiled artifact

The compiler produces .stflb bytecode. That artifact becomes the contract between the private computation and the surrounding application: what the program expects, what it can run, and where outputs are defined.

​
A local development loop

The CLI gives you an ordinary loop before deployment work begins:
The point of local MPC is not to prove the full deployment is safe. It gives developers a fast way to catch language, build, integration, and runtime assumptions before coordinating real infrastructure.

​
An application integration path

The Rust SDK connects application code to Stoffel programs. The application still owns product logic, authentication, authorization, storage, client behavior, and output delivery. Stoffel owns the private-computation surface: bytecode, VM execution, party configuration, and secret-shared runtime values. Privacy boundary comparison showing a conventional backend receiving plaintext inputs versus a Stoffel-backed workflow with client shares, MPC parties, and authorized output boundaries.

​
What remains explicit

Stoffel is not “MPC without MPC concepts.” It is a developer workflow for MPC concepts. You still make explicit decisions about:
  • which inputs are private;
  • which values become shares;
  • how many parties run the computation;
  • what threshold assumptions the deployment uses;
  • which backend fits the computation;
  • which values open;
  • who receives the output;
  • what metadata, logs, timing, and access patterns may reveal outside the MPC protocol.
Those decisions stay visible because hiding them would make the application harder to reason about. Stoffel’s job is to make them programmable and testable, not to make them disappear.

​
When Stoffel is a good fit

Stoffel is a good fit when the application needs to compute over sensitive values and you do not want those values to become ordinary plaintext backend state. Good early use cases usually have:
  • a clear private computation boundary;
  • inputs that can be modeled as private values or shares;
  • outputs that can be named and reviewed explicitly;
  • a team that wants local iteration before deployment planning;
  • Rust application code that needs to call into the private workflow.
In those cases, Stoffel helps turn the privacy requirement into a concrete development path: write the private computation, compile it, run it locally, integrate it, then validate the deployment assumptions.

​
When Stoffel may not be the right fit

Stoffel may be the wrong starting point if:
  • the application only needs encryption at rest or in transit;
  • the sensitive data never needs to be computed on;
  • the required output would reveal the private input anyway;
  • the team cannot define who should learn the result;
  • the problem is mainly access control, logging, or data retention rather than compute-time plaintext exposure;
  • the deployment cannot support multiple MPC parties or the needed coordination model.
This page should help you decide whether to try the workflow, not convince every project to use MPC.

​
Try the workflow

If the boundary fits your application, the next useful step is hands-on:
  1. Install the stoffel CLI.
  2. Create a project.
  3. Check and build a .stfl program.
  4. Run local MPC.
  5. Connect the program from Rust.
Start with Installation, then continue to Quick start. For the runtime layers, read System architecture.