How do you know a remote service is running the code you reviewed? Caution lets your app check before using it.
We built a wallet demo using multi-party computation (MPC) to show how. Before the wallet connects to a remote cosigner, it verifies the cosigner’s software. It then uses an encrypted connection tied to that verification.
Table of contents
- Watch the demo
- Why run MPC in an enclave?
- Decide what you are willing to trust
- Reproduce the measurements and verify the destination
- Make the client enforce the result
- Three links must hold
- Bind verification to the session with STEVE
- How StageX extends the verification path
- What the demo proves
- Beyond the demo
- Conclusion
Watch the demo
Watch the wallet verify the cosigner, generate key shares, and sign a transaction.
Why run MPC in an enclave?
Most people do not need MPC jargon to understand the problem. If a remote service is going to participate in cryptographic signing, the important question is whether your client can verify what code is on the other end before it asks for help. Caution makes that verification path concrete.
MPC can sound abstract, but the wallet use case is simple: instead of one private key living in one place, key generation and signing operations are split across two or more parties. In this demo, the client and server participate in additive two-party secp256k1 key generation and each retain one share. Neither side ever holds or reconstructs the whole private key, and neither share is enough to produce a signature alone.
That makes the remote cosigner a strong enclave use case. It has a narrow, security-critical job: keep one signing share secret and execute the MPC protocol correctly. With enclave isolation and STEVE (Secure Transport Encryption Via Enclave), the surrounding host may still relay, delay, or block the ceremony, but it cannot read the protected messages, alter them undetected, or extract the share from the enclave.
Decide what you are willing to trust
The provider makes the client and cosigner source available at a specific commit. That can be open source or licensed source. The requirement is not publicity; it is that you or an auditor you trust can inspect the exact code, build recipe and deployment inputs being vouched for.
A code review can tell you whether the design and implementation deserve trust. Attestation cannot. It only lets the client test the narrower claim that the reviewed workload, with the reviewed inputs, is the one now running at the destination. Authorization is a separate question again: who may use that workload once identified.
Caution is useful here because it does not ask the client to inherit the operator’s trust decision. It gives the relying party a way to convert a chosen review target into an enforceable workload identity.
Reproduce the measurements and verify the destination
Making attestation usable remains a practical challenge. In a 2025 IDC study of 600 IT leaders, 84.5% cited validating attestation chains of trust as a barrier to adopting confidential computing. Caution turns that abstract chain into a client-enforced workflow: reproduce the expected measurements, verify fresh evidence from the live enclave, and refuse the protected session if they do not match.
You build the reviewed revision with pinned inputs and derive the expected measurement values for the enclave image. If that build is not reproducible, the chain stops here. You cannot independently compute the identity you plan to enforce, so you are back to trusting an operator-supplied digest.
You then run caution verify against the live attestation endpoint. The verifier asks for fresh attestation and evidence, includes a client-supplied nonce, validates the certificate chain from the hardware manufacturer, and requires one complete accepted measurements profile to match. A single mismatched value and fails the check. A passing result means the measured workload at that endpoint matches the build you reproduced, under the specific hardware, firmware and attestation roots.
Today that trust file is Nitro-specific because the current demo runs on Nitro and the accepted measurements are Nitro PCRs. The practical pattern is larger than Nitro: reproduce the accepted measurements for the platform you are using, then make the client enforce them.
Make the client enforce the result
Verification matters only if it changes behavior. You run the client with the reviewed profile pinned, and every protected operation re-verifies fresh evidence before it proceeds. In the demo, protected enrollment then pins the cosigner’s application identity as a continuity check, while distributed key generation and signing happen only over the verified channel.
This is where STEVE changes the story from “verified once” to “verified when used.” A redeploy that changes PCRs is not just observable later; the client refuses the protected session until you review and approve the new profile. It cannot be changed in-flight, a single deviation from this policy will cause the connection to drop. Caution is not deciding whether a transaction is wise or authorized. It is making the client refuse the wrong remote workload.
Three links must hold
The claim is only as strong as its chain:
- The reviewed source must reproduce the accepted measurements.
- Fresh evidence must identify the live enclave as one of those measurements.
- That evidence must be bound to the exact protected session carrying the application request. Break any one link and the other two become much less useful.
Bind verification to the session with STEVE
This last link is easy to underrate. Plain attestation can tell you that some enclave, somewhere, produced valid evidence. A key exchange can give you encrypted transport to some peer. Those are not automatically the same peer or the same moment. Without session binding, an attacker who can relay connections can try to present valid evidence from one place while steering traffic through another channel.
Caution makes that protection straightforward to deploy: enable STEVE for a workload, and its ordinary application traffic is automatically routed through an attested, end-to-end encrypted channel that fails closed if verification is missing.
STEVE ties enclave verification to the encrypted connection your app actually uses, keeping application data protected between the client and the enclave. Learn more in our recent blog post.
How StageX extends the verification path
Caution builds on StageX, an open-source Linux distribution focused on reproducible builds and full-source bootstrapping. StageX matters here because “reviewed source” is only as meaningful as the toolchain that turned it into the measured image. StageX treats reproducible builds and full-source bootstrapping as one software-integrity claim. Its in-tree chain starts from hex0, a 181-byte hand-written i386 ELF seed, then builds the stage0 tools, a 32-bit userland, cross-compilers, a native 64-bit toolchain, and finally the packages and pallets used to produce the enclave image.
That does not prove the source is good. It does not mean caution verify rebuilds the entire ladder every time you connect. It means the measurements you pin can rest on a toolchain ancestry that is inspectable and reproducible much farther down than a conventional opaque compiler bootstrap. For a security-critical remote cosigner, that is the difference between “we reproduced an app artifact” and “we can account for more of how that artifact came to exist.”
What the demo proves
The complete demo is available on Codeberg. It includes the client and cosigner, the MPC protocol, the STEVE integration, and the Caution deployment files, so you can inspect how the source-to-session verification path is implemented.
The demo turns this verification path into a working system. You build the cosigner image from its published source and derive the expected measurements. caution verify checks them against fresh evidence from a live enclave. The client pins that profile and opens STEVE only when the live workload matches, then uses the verified session for enrollment, distributed key generation, and signing. Change the measured workload or the accepted profile, and the client refuses to proceed, even in-flight.
Note, the MPC implementation uses a pinned alpha release of CGGMP24 that is intentionally non-constant-time. It demonstrates the architecture, but is not presented as a production-ready custody implementation.
Beyond the demo
Today the demo uses Nitro. Caution’s longer-term goal is to support the same verification workflow across Nitro, SEV-SNP, and TDX and eventually combine them. In a hardware-diverse MPC design, separate participants could run the same reviewed workload on different enclave platforms and refuse to cooperate if any attestation differs. Trust would then be split not only across key shares, but across independent hardware roots.
Conclusion
Remote services running on servers normally ask you to trust that the code you reviewed is the code they deployed. This demo shows a different model: the client verifies the live software before it connects, then carries that verification into the encrypted session it actually uses. MPC makes the stakes concrete, but the pattern is much broader. With Caution, “this is the code we are running” becomes something users can check, not just something operators claim.
