Job Envelope

A job envelope is how Solidus's compute network gets a piece of sensitive data, a cropped face image, safely from the party that has it to the one GPU operator selected to process it, without letting the routing service in between ever see it. It's an application of a two-layer encryption pattern the cloud industry calls "envelope encryption": encrypt the actual payload with a fresh, single-use symmetric key (a data-encryption key, or DEK) using fast, standard authenticated encryption (AES-256-GCM); then separately encrypt, "seal". That small key to the public key of whichever party should be allowed to open it. The bulk-data encryption and the access-control decision become two independent operations, which matters because it lets the routing decision (who gets this job?) happen after the data is already encrypted, without re-encrypting anything.

The specific mechanics: the client generates the DEK and encrypts the minimized payload with it, staging only the ciphertext somewhere the selected operator can fetch it from. Separately, the DEK itself gets sealed, using public-key "sealed box" encryption, to the specific operator's key, so only that operator's matching private key can open it. A broker or router in the middle can see and forward the sealed DEK and a reference to the ciphertext, but structurally cannot open either: it never learns the plaintext, and the encryption scheme itself is what enforces that, not a policy promise.

Where it comes from

"Envelope encryption" as a named, documented two-layer pattern is popularized and formally documented by cloud key-management services, AWS KMS and Google Cloud KMS both describe their own client-side encryption flows using exactly this term. The specific public-key sealing primitive underneath Solidus's implementation, a "sealed box," which lets you encrypt a message to someone's public key without needing your own long-term keypair, is the crypto_box_seal construction from NaCl/libsodium, cryptography designed by Daniel J. Bernstein and collaborators and maintained today by Frank Denis. Solidus designed none of this; it composes both pieces for a specific job.

Solidus status

This is real, shipped, cross-language code, not a design document. Solidus implements the same job-envelope logic twice, independently, once in TypeScript (@solidus/compute-crypto, used by the routing broker and the client-facing side) and once in Rust (solidus-compute-crypto, used by the compute-node operator binary), and gates the two implementations against each other with a committed test fixture: a DEK sealed by one language's implementation is proven, in an automated test, to open correctly with the other's matching private key. That cross-language proof matters because a mismatch here would silently break every job on the network. The full flow, client generates and seals the DEK, broker forwards the sealed key and a data reference without ever holding an openable key, the selected node fetches the ciphertext directly and opens it, runs live on Solidus's public testnet.

What a job envelope does not do, and this is worth stating precisely rather than implying more than the mechanism delivers: it protects the payload in transit to the selected node and keeps it out of the broker's reach. It says nothing about what happens after the node decrypts the payload into memory to actually run the model, whether that node behaves honestly, and whether its own operating system could in principle read that transient plaintext, is a separate problem, addressed today only by contractual and economic preconditions (see Anti-Cheat Precondition), not a cryptographic one. The cryptographic answer to that separate problem, a confidential-compute tier, is specified but not built (see Trusted Execution Environment).

Proof you can run yourself: @solidus/compute-crypto's envelope.ts and its Rust counterpart are both in the public solidusnetwork/protocol and gpu-node repositories, alongside the committed cross-language interoperability fixture. Running both test suites independently reproduces the same passing result in each language, nothing requires trusting Solidus's account of it.