Stoffel 0.1.3: deployment-shaped apps and docs from your code

Stoffel 0.1.3 is out.

Building with MPC should feel more like application development and less like assembling cryptographic infrastructure. You should be able to start with the feature you want to build, understand how it fits into your application, and carry it through to deployment.

Developer feedback showed us where that experience still required too much guesswork. Tutorials and documentation help, but the tools themselves need to make the next step clear.

This release brings more of that guidance into Stoffel: a more complete starting project, typed clients, clearer service boundaries, better configuration checks, and API documentation generated from your code. Together with updated guides, these changes leave fewer pieces to work out before you can focus on your application.

What changed

Start with an application, not just a program

A first project should give you something to adapt, not another architecture to work out. stoffel init now creates a Rust application with a private program, a typed participant client, separate coordinator and MPC-node binaries, tests, and scripts to run them together. A Docker Compose stack provides another way to run the services.

The project shows where Stoffel fits into your product. UI, authentication, and public business logic stay in your application. Private computation lives in StoffelLang, and participant-owned Rust code submits values through StoffelClient::run_typed without first collecting them in your backend.

Clients and services use the same compiled .stflb artifact. Rust input and output types are generated from it, so changes to the private program's interface become visible when you rebuild the application. You have a concrete integration to modify rather than a sample computation to translate into one.

A local workflow you can carry toward deployment

Local development is more useful when it teaches you how the application will run. The change in the default project is straightforward:

• Before: a private program and a Rust wrapper for local execution.

• Now: a typed participant client, separate coordinator and MPC-node services, tests, and launchers.

The old wrapper was useful for trying a computation, but turning it into an application integration was left to you. Network APIs existed; the scaffold did not yet show how to use them together.

Build the program once into artifacts/program.stflb, then let Cargo generate bindings from that exact bytecode. The client and services load the same artifact. In src/client.rs, the application-facing function is now a typed submission to the services, not local execution:

async fn run_private_feature(input: i64) -> Result<i64, Box<dyn std::error::Error>> {
    let inputs = Client0Inputs { input_0: input };
    let output: Client0Outputs = app::client()?.run_typed(inputs).await?;

    Ok(output.output_0)
}

async fn run_private_feature(input: i64) -> Result<i64, Box<dyn std::error::Error>> {
    let inputs = Client0Inputs { input_0: input };
    let output: Client0Outputs = app::client()?.run_typed(inputs).await?;

    Ok(output.output_0)
}

async fn run_private_feature(input: i64) -> Result<i64, Box<dyn std::error::Error>> {
    let inputs = Client0Inputs { input_0: input };
    let output: Client0Outputs = app::client()?.run_typed(inputs).await?;

    Ok(output.output_0)
}

This is the generated function with explanatory comments omitted. Client0Inputs and Client0Outputs are generated types; app::client() is the scaffold's configured client helper. It connects to the coordinator and node RPC endpoints using the participant's identity.

The distinction changes what you need to write. Your feature maps an application value into a typed input and uses the returned value. Service setup has its own files and launchers instead of becoming part of that function.

Of course, you can move things around to suit your app. The point is to give you a starting structure that makes those choices easier to think through, not one you have to follow forever.

The launchers start the services and wait for input readiness before you submit a participant's value. The Compose stack follows the same model with containerized services. The same client integration can connect to separately operated services later; local execution remains available for fixture checks.

That makes the transition easier to understand, not automatic. Deployment still requires your own networking, identities, secrets, storage, and supervision. Running every party on one machine is a development convenience, not independent operator trust.

Keep the program's interface close to its code

As a private program becomes part of an application, other developers need to understand how to use it. stoffel doc turns StoffelLang docstrings into a searchable HTML site, so you can describe an interface where you define it rather than maintain a separate API reference by hand:

stoffel doc --open

stoffel doc --open

stoffel doc --open

The same tool documents loose files, directories, and the embedded standard library. If your team uses Mintlify, it can generate MDX pages and navigation data from the same source. The documentation command guide covers both workflows.

Docstrings can explain arguments, return values, errors, and examples, with an MPC: section for protocol and cost details. They do not change the program's bytecode. Coverage and lint checks let you catch missing documentation in CI:

stoffel doc --check --deny-missing

stoffel doc --check --deny-missing

stoffel doc --check --deny-missing

Every embedded standard-library builtin is documented, with a compiler test keeping that coverage in place. The reference is available both for your own APIs and for the building blocks you use to write them.

Less guesswork when something goes wrong

Configuration errors should tell you what needs to change. The Rust SDK now checks party counts against the selected backend and names the expected formula when a topology is invalid. A valid AVSS configuration is no longer rejected by a check intended for HoneyBadger.

Source handling is more predictable too: unterminated strings report errors, and function-like text in docstrings no longer confuses test discovery or entry selection. Dependency updates and the remaining fixes are listed in the changelog.

Guides that help you make the project your own

Getting an example to run is not the same as knowing what to change next. The updated Quick Start shows how to adapt the private program and typed client. The Compose guide covers service startup, readiness, host/container endpoints, and troubleshooting. The developer skills give coding agents release-aligned instructions for those same workflows.

Try the new project

Start with the generated application. Install Stoffel, create a project, and build its bytecode before compiling the Rust code:

curl -fsSL https://get.stoffelmpc.com | sh
stoffel init my-private-app
cd my-private-app
stoffel check
stoffel build --output artifacts/program.stflb
cargo build

curl -fsSL https://get.stoffelmpc.com | sh
stoffel init my-private-app
cd my-private-app
stoffel check
stoffel build --output artifacts/program.stflb
cargo build

curl -fsSL https://get.stoffelmpc.com | sh
stoffel init my-private-app
cd my-private-app
stoffel check
stoffel build --output artifacts/program.stflb
cargo build

Start the services and wait for input readiness:

./scripts/run-local.sh

./scripts/run-local.sh

./scripts/run-local.sh

Then run the sample participant client in a second terminal:

./scripts/run-client.sh 42

./scripts/run-client.sh 42

./scripts/run-client.sh 42

The example prints Doubled result: 84. From there, adapt the private program and participant client to your feature. You need Rust/Cargo to build this application; installing the CLI itself uses a prebuilt binary.

Try Stoffel for yourself. Start with the quickstart.