Skip to main content
Newton’s privacy layer enables end users to submit encrypted sensitive data (PII, credentials, financial records) that operators threshold-decrypt during policy evaluation. The data never appears on-chain.

​
Overview

Many policies require access to sensitive data — identity documents, API keys, compliance records, or proprietary parameters. Newton’s privacy layer provides:
  • End-to-end encryption of sensitive inputs using HPKE (X25519/ChaCha20-Poly1305)
  • Threshold decryption — operators collectively decrypt data using t-of-n key shares; no single party ever holds the full decryption key
  • Zero on-chain exposure — only hashes and commitments go on-chain, never plaintext data
  • Dual-signature authorization — both the end user and the dApp must sign off before operators will decrypt anything

​
How It Works

The integration is three steps:
  1. Encrypt sensitive data on the client side using the system’s threshold public key (via newt_getPrivacyPublicKey)
  2. Upload the encrypted envelope to the Gateway, receiving a reference ID
  3. Create a task that includes the reference ID — operators threshold-decrypt the data during evaluation

​
HPKE Encryption

Newton uses the HPKE standard (RFC 9180) with the following cipher suite:
ComponentAlgorithm
KEMDHKEM(X25519, HKDF-SHA256)
KDFHKDF-SHA256
AEADChaCha20-Poly1305
SigningEd25519
HPKE Base mode encrypts data to the system’s threshold X25519 public key. This key is produced via interactive DKG (distributed key generation) across the operator set — no single operator holds the full private key. Sender authentication is handled separately via Ed25519 signatures on the serialized envelope.

​
SecureEnvelope Structure

Encrypted data is wrapped in a SecureEnvelope: 
{
  "enc": "<hex-encoded HPKE encapsulated key>",
  "ciphertext": "<hex-encoded HPKE ciphertext + Poly1305 tag>",
  "policy_client": "0x<policy client address>",
  "chain_id": 11155111,
  "recipient_pubkey": "<hex-encoded system Ed25519 public key>"
}
FieldDescription
enc32-byte X25519 ephemeral public key for HPKE decapsulation (hex)
ciphertextHPKE ciphertext including the ChaCha20-Poly1305 authentication tag (hex)
policy_client0x-prefixed EVM address of the target PolicyClient
chain_idChain ID for context binding
recipient_pubkeySystem’s Ed25519 public key (hex)
AAD construction: The additional authenticated data is keccak256(abi.encodePacked(policy_client_bytes, chain_id_be_bytes)). This binds the ciphertext to a specific PolicyClient and chain — tampering with either field causes decryption to fail.

​
Threshold Decryption

Newton distributes the HPKE private key across operators using interactive DKG (FROST DKG / Pedersen VSS). During task evaluation:
  1. Each operator computes a partial decryption share from its DKG key share
  2. Operators exchange shares via encrypted NATS messages
  3. Each operator reconstructs the plaintext locally from t-of-n shares
  4. The reconstructed plaintext is used for policy evaluation and BLS signing
The threshold keypair is cryptographically independent from operators’ ECDSA and BLS keys — a compromised signing key does not yield a decryption share. The combined public key is stored on-chain and readable via a single contract call (getThresholdPublicKey()), or via the newt_getPrivacyPublicKey RPC method. DKG ceremonies run only during operator set changes, not per-task.

​
Dual-Signature Authorization

Privacy-enabled tasks require two Ed25519 signatures to authorize decryption:
  1. User signature — the end user signs keccak256(abi.encodePacked(policy_client, intent_hash, ref_id_1, ref_id_2, ...)) with their Ed25519 key
  2. App signature — the dApp signs keccak256(abi.encodePacked(policy_client, intent_hash, user_signature)) with its Ed25519 key
Both signatures must be valid before operators will decrypt any data. A stolen reference ID alone is not sufficient.

​
RPC Methods

These RPC methods are under active development and not yet available in production. The API surface may change.

​
newt_getPrivacyPublicKey

Retrieves the system’s threshold HPKE public key for encrypting data. 
{
  "jsonrpc": "2.0",
  "method": "newt_getPrivacyPublicKey",
  "params": {},
  "id": 1
}
Returns: 
{
  "jsonrpc": "2.0",
  "result": {
    "public_key": "<hex-encoded X25519 public key (32 bytes)>",
    "key_type": "x25519",
    "encryption_suite": "HPKE-Base-X25519-HKDF-SHA256-ChaCha20Poly1305"
  },
  "id": 1
}

​
newt_uploadEncryptedData

Uploads an encrypted data reference for later use in privacy-enabled tasks. 
{
  "jsonrpc": "2.0",
  "method": "newt_uploadEncryptedData",
  "params": {
    "sender_address": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
    "policy_client": "0x0000000000000000000000000000000000000001",
    "envelope": "{\"enc\":\"...\",\"ciphertext\":\"...\",\"policy_client\":\"0x...\",\"chain_id\":11155111,\"recipient_pubkey\":\"...\"}",
    "signature": "0x<64-byte Ed25519 signature hex>",
    "recipient_pubkey": "0x<32-byte Ed25519 public key hex>",
    "ttl": 3600
  },
  "id": 1
}
FieldTypeRequiredDescription
sender_addressAddressYesEnd user’s EVM address (intent sender)
policy_clientAddressYesPolicyClient address this data is scoped to
envelopeStringYesSerialized SecureEnvelope JSON string
signatureStringYesEd25519 signature over the envelope bytes (hex, 0x-prefixed)
recipient_pubkeyStringYesSystem’s Ed25519 public key (hex, 0x-prefixed)
ttlNumberNoTime-to-live in seconds (data expires after this duration)
Returns: 
{
  "jsonrpc": "2.0",
  "result": {
    "success": true,
    "data_ref_id": "550e8400-e29b-41d4-a716-446655440000",
    "error": null
  },
  "id": 1
}

​
Using Privacy in Tasks

When creating a task that requires encrypted data, include the data references and authorization signatures in the newt_createTask request:
  • encrypted_data_refs — array of UUID reference IDs from newt_uploadEncryptedData
  • user_signature — end user’s Ed25519 authorization signature
  • app_signature — dApp’s Ed25519 authorization signature
The Gateway validates both signatures and distributes the encrypted envelopes to operators, who threshold-decrypt the data and merge plaintext into policyTaskData for evaluation. For stored secrets (API keys for PolicyData oracles), see Encrypting Secrets.

​
Use Cases

Use CaseWhat’s Encrypted
KYC-gated DeFiGovernment ID, proof of address
Compliance checkingFinancial records, tax documents
Private credential verificationAPI keys, OAuth tokens, signed attestations
Institutional policy enforcementInternal risk scores, portfolio data
Privacy-preserving allowlistsMembership proofs, signed approvals

​
Security Properties

ThreatMitigation
Unauthorized decryptionDual-signature authorization required before operators decrypt
Single point of trustThreshold decryption — no single operator holds the full private key
Ciphertext tamperingAEAD (ChaCha20-Poly1305) detects any modification
Context rebindingAAD binds ciphertext to specific policy_client + chain_id
Replay of encrypted dataUUID-based references; TTL expiration; authorization signatures include intent_hash
Key compromiseDKG key shares are cryptographically independent from ECDSA/BLS keys
Data persistenceTTL-based expiration with automatic cleanup

​
Next Steps

Consensus & Security

BLS aggregation and the economic security model

Encrypting Secrets

Store encrypted secrets for PolicyData oracles