# References and Appendix \[Standards, cryptographic primitives, privacy-preserving computation references, and the Newton Privacy Envelope binary wire format specification.]

## References

### Standards and Specifications

* **RFC 9180** -- Hybrid Public Key Encryption (HPKE). IRTF. [rfc-editor.org/rfc/rfc9180](https://www.rfc-editor.org/rfc/rfc9180)
* **EIP-196** -- Precompiled contracts for addition and scalar multiplication on the elliptic curve alt\_bn128. Ethereum Improvement Proposals. [eips.ethereum.org/EIPS/eip-196](https://eips.ethereum.org/EIPS/eip-196)
* **EIP-197** -- Precompiled contracts for optimal ate pairing check on the elliptic curve alt\_bn128. Ethereum Improvement Proposals. [eips.ethereum.org/EIPS/eip-197](https://eips.ethereum.org/EIPS/eip-197)
* **ELIP-008** -- Cross-Chain Operator Set Management. EigenLayer Improvement Proposals. [github.com/eigenfoundation/ELIPs](https://github.com/eigenfoundation/ELIPs)

### Messaging Infrastructure

* **NATS** -- Cloud native messaging system. [nats.io](https://nats.io/)

### Policy and Compliance

* **Open Policy Agent (OPA)** -- Policy engine and Rego language documentation. [openpolicyagent.org/docs/latest](https://www.openpolicyagent.org/docs/latest/)

### Newton Protocol Documentation

* [Newton Protocol Whitepaper](https://newton.xyz/whitepaper) -- Protocol vision, market context, use cases, and ecosystem overview.
* [RPC API Reference](/developers/reference/rpc-api) -- JSON-RPC API surface, request/response structures, error codes, and simulation modes.
* [Smart Contract Integration Guide](/developers/guides/smart-contract-integration) -- INewtonPolicyClient interface, PolicyClientRegistry, and attestation validation paths.

### 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](https://github.com/Layr-Labs/eigenlayer-middleware)
* **HPKE (RFC 9180)** -- Hybrid Public Key Encryption for privacy-preserving data encryption. [rfc-editor.org/rfc/rfc9180](https://www.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](https://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](https://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](https://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](https://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](https://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](https://dl.acm.org/doi/10.1145/3658644.3690861)

### Post-Quantum Cryptography

* **ML-KEM (FIPS 203)** -- Module-Lattice-Based Key-Encapsulation Mechanism Standard. NIST, August 2024. [csrc.nist.gov/pubs/fips/203/final](https://csrc.nist.gov/pubs/fips/203/final)
* **ML-DSA (FIPS 204)** -- Module-Lattice-Based Digital Signature Standard. NIST, August 2024. [csrc.nist.gov/pubs/fips/204/final](https://csrc.nist.gov/pubs/fips/204/final)

***

*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:

```json
{
  "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:**

| Offset              | Field              | Size (bytes) | Encoding             | Description                                                  |
|---------------------|--------------------|--------------|----------------------|--------------------------------------------------------------|
| 0                   | `version`          | 1            | Unsigned integer     | Format version. Must be `0x01`.                              |
| 1                   | `enc`              | 32           | Raw bytes            | X25519 ephemeral public key (HPKE encapsulated key).         |
| 33                  | `ciphertext_len`   | 4            | Little-endian uint32 | Length of ciphertext field in bytes.                         |
| 37                  | `ciphertext`       | Variable     | Raw bytes            | HPKE ciphertext (plaintext + 16-byte ChaCha20-Poly1305 tag). |
| 37 + ciphertext\_len | `policy_client`    | 20           | Raw bytes            | Ethereum address (no checksum in binary).                    |
| 57 + ciphertext\_len | `chain_id`         | 8            | Little-endian uint64 | EVM chain ID.                                                |
| 65 + ciphertext\_len | `recipient_pubkey` | 32           | Raw bytes            | Ed25519 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:

| Version | Description                                                                  | Status   |
|---------|------------------------------------------------------------------------------|----------|
| `0x01`  | Initial format as specified in this appendix                                 | Active   |
| `0x02`+ | Reserved for future extensions (e.g., post-quantum KEM, additional metadata) | Reserved |

Implementations must reject envelopes with unrecognized version numbers.