Overview
The secret storage flow:- Prepare your secrets as a JSON object matching your PolicyData’s schema
- Call
storeEncryptedSecretsfrom the SDK — it encrypts the plaintext locally and uploads the HPKE envelope - Operators decrypt the envelope during task evaluation to run your WASM oracle
secretsSchemaCid) defined on your PolicyData contract.
Secrets Format
Prepare a JSON object matching your PolicyData’s secrets schema:Store via SDK
Use thestoreEncryptedSecrets function from the SDK. It fetches the gateway’s HPKE public key automatically (or accepts one you’ve cached), encrypts the plaintext locally, and uploads the envelope in a single call.
Reference in PolicyData
Your WASM oracle accesses secrets at runtime through the Newton execution environment. Secrets are decrypted by operators and passed to your WASM component automatically — you do not need to handle decryption in your code.Secrets Schema
ThesecretsSchemaCid on your PolicyData contract points to a JSON Schema that defines the required shape of your secrets:
newt_storeEncryptedSecrets returns a validation error.
Security
- Secrets are encrypted client-side before leaving your application — the HPKE envelope is what travels over the wire
- The gateway decrypts the envelope in memory to validate against the schema, then stores the envelope (not the plaintext)
- Only the on-chain owner of the PolicyClient can upload or update secrets
- Operators decrypt the stored envelope locally during task evaluation — plaintext secrets are never persisted by operators and never sent over the network
- Key rotation is supported — upload new secrets at any time via
newt_storeEncryptedSecrets
Testing
Test your secrets work correctly before deploying:-
Test with inline secrets (no ownership required):
-
Test with stored secrets (requires ownership):
Next Steps
Privacy Layer
Full privacy architecture overview
RPC API
newt_storeEncryptedSecrets and related methods