Skip to main content

​
References

​
Standards and Specifications

​
Messaging Infrastructure

  • NATS — Cloud native messaging system. nats.io

​
Policy and Compliance

​
Newton Protocol Documentation

​
Cryptographic Primitives

  • BLS on BN254 — BLS signature operations on the BN254 (alt_bn128) curve, compatible with Ethereum precompiles (EIP-196, EIP-197).
  • EigenLayer BLS Middleware — On-chain BLS verification and operator set management. github.com/Layr-Labs/eigenlayer-middleware
  • HPKE (RFC 9180) — Hybrid Public Key Encryption for privacy-preserving data encryption. rfc-editor.org/rfc/rfc9180
  • HPKE Formal Verification — Bhargavan, K. and Lipp, B. (2024). “A Mechanized Cryptographic Proof of the HPKE Standard.” IACR ePrint 2024/243. eprint.iacr.org/2024/243
  • Ed25519 — EdDSA signing and verification on Curve25519.
  • X25519 — Diffie-Hellman key agreement on Curve25519.
  • secp256k1 ECDSA — Ethereum-native signature scheme for attestations and key derivation.

​
Privacy-Preserving Computation

  • Secure Multi-Party Computation (MPC) — Lindell, Y. (2020). “Secure Multiparty Computation (MPC).” Communications of the ACM, 64(1), 86-96. dl.acm.org/doi/10.1145/3387108
  • Honest-Majority MPC — Araki, T. et al. (2017). “Optimized Honest-Majority MPC for Malicious Adversaries — Breaking the 1 Billion-Gate Per Second Barrier.” IEEE S&P. ieeexplore.ieee.org/document/7958613 — See also: Escudero, D. et al. (2022). “High-Throughput Secure Multiparty Computation with an Honest Majority in Various Network Settings.” arxiv.org/abs/2206.03776
  • Fully Homomorphic Encryption (FHE) — Gentry, C. (2009). “A Fully Homomorphic Encryption Scheme.” PhD thesis, Stanford University. crypto.stanford.edu/craig/craig-thesis.pdf
  • Threshold FHE — Boneh, D. et al. (2024). “Toward Practical Threshold Fully Homomorphic Encryption.” ACM CCS. dl.acm.org/doi/10.1145/3658644.3690861

​
Post-Quantum Cryptography

Newton Protocol — Technical architecture for verifiable, privacy-preserving transaction authorization.

​
Appendix A: Newton Privacy Envelope Wire Format

This appendix specifies the binary serialization format for the Newton Privacy Envelope (SecureEnvelope) to enable interoperable implementations across languages and platforms.

​
A.1 JSON Transport Format

The primary transport encoding is JSON, used in the JSON-RPC API between clients and the gateway: 
{
  "enc": "<hex-encoded, 64 chars>",
  "ciphertext": "<hex-encoded, variable length>",
  "policy_client": "<0x-prefixed EIP-55 checksummed address>",
  "chain_id": "<integer>",
  "recipient_pubkey": "<hex-encoded, 64 chars>"
}
All hex strings are lowercase without 0x prefix (except policy_client which follows Ethereum address conventions).

​
A.2 Binary Wire Format

For compact transport and storage, the SecureEnvelope can be serialized to a binary format: 
NPE_ENVELOPE_V1 ::= SEQUENCE {
    version           UINT8       (0x01),
    enc               BYTES       (SIZE 32),
    ciphertext_len    UINT32_LE,
    ciphertext        BYTES       (SIZE ciphertext_len),
    policy_client     BYTES       (SIZE 20),
    chain_id          UINT64_LE,
    recipient_pubkey  BYTES       (SIZE 32)
}
Field-by-field specification:
OffsetFieldSize (bytes)EncodingDescription
0version1Unsigned integerFormat version. Must be 0x01.
1enc32Raw bytesX25519 ephemeral public key (HPKE encapsulated key).
33ciphertext_len4Little-endian uint32Length of ciphertext field in bytes.
37ciphertextVariableRaw bytesHPKE ciphertext (plaintext + 16-byte ChaCha20-Poly1305 tag).
37 + ciphertext_lenpolicy_client20Raw bytesEthereum address (no checksum in binary).
57 + ciphertext_lenchain_id8Little-endian uint64EVM chain ID.
65 + ciphertext_lenrecipient_pubkey32Raw bytesEd25519 public key of the intended recipient.
Total size: 97 + ciphertext_len bytes (minimum 113 bytes for a 16-byte ciphertext with empty plaintext).

​
A.3 AAD Computation (Canonical)

The Additional Authenticated Data for HPKE seal/open operations is computed deterministically: 
function compute_aad(policy_client: bytes20, chain_id: uint64) -> bytes32:
    // policy_client: 20 raw bytes (no 0x prefix, no checksum)
    // chain_id: 32 bytes, big-endian, zero-padded uint256
    packed = policy_client || to_uint256_be(chain_id)
    return keccak256(packed)
The chain_id is encoded as a 32-byte big-endian unsigned integer (Solidity uint256 encoding) to match abi.encodePacked behavior. This ensures that AAD computed off-chain matches AAD computed on-chain via Solidity’s keccak256(abi.encodePacked(address, uint256)).

​
A.4 Versioning

The version field enables future format evolution:
VersionDescriptionStatus
0x01Initial format as specified in this appendixActive
0x02+Reserved for future extensions (e.g., post-quantum KEM, additional metadata)Reserved
Implementations must reject envelopes with unrecognized version numbers.