denniswon · March 17, 2026 13:58 · denniswon · Mar 17, 2026 · denniswon · Mar 17, 2026
diff --git a/gistfile1.txt b/gistfile1.txt
 ---
  Good context gathered. I can see the current flow is:

  1. newton-identity encrypts with RSA-OAEP (AWS KMS public key) → hex ciphertext
  2. Signs the encrypted string with EIP-712 (EncryptedIdentityData)
  3. Gateway verifies EIP-712 signature, then stores the encrypted data on-chain via submitIdentity
  4. At evaluation time, operators decrypt via AWS KMS

  The Newton SDK already has a full HPKE privacy module (X25519 + HKDF-SHA256 + ChaCha20-Poly1305) with AAD binding, Ed25519 signing, and
  uploadEncryptedData RPC.

  Here are my first batch of questions:

  1. Gateway RPC method change — Currently newton-identity calls newt_sendIdentityEncrypted which stores the RSA-OAEP ciphertext directly on-chain.
  After migration, should identity data go through the same newt_uploadEncryptedData RPC that the SDK's privacy module uses (storing via data_ref_id
   pattern), or do we keep newt_sendIdentityEncrypted but change it to accept HPKE-encrypted envelopes instead of RSA ciphertext? The former unifies
   the code paths; the latter keeps identity data storage separate from general privacy data.

  2. EIP-712 signing vs Ed25519 signing — The current flow EIP-712-signs the encrypted data (EncryptedIdentityData(string data)) using the Identity
  Owner EOA via Turnkey. The SDK privacy module uses Ed25519 signing instead (separate key pair from the EVM wallet). For the migration, should we
  keep EIP-712 signing with the Turnkey wallet (simpler UX — no second key pair), switch to Ed25519 like the SDK privacy module (consistent with the
   privacy layer), or use both (HPKE encrypt + Ed25519 sign the envelope, but also EIP-712 sign for on-chain identity binding)?

  3. On-chain storage model — Currently the IdentityRegistry.submitIdentity(owner, domain, data) stores the encrypted string directly in contract
  storage. The Privacy Layer's uploadEncryptedData stores data off-chain in the gateway and returns a data_ref_id. For identity data, do we keep
  on-chain storage (contract state) with just the encryption scheme changing, or move to the off-chain data_ref_id pattern like the rest of the
  privacy layer? On-chain gives permanence/auditability; off-chain gives flexibility and lower gas costs.

 ---
  Good context gathered. I can see the current flow is:

  1. newton-identity encrypts with RSA-OAEP (AWS KMS public key) → hex ciphertext
  2. Signs the encrypted string with EIP-712 (EncryptedIdentityData)
  3. Gateway verifies EIP-712 signature, then stores the encrypted data on-chain via submitIdentity
  4. At evaluation time, operators decrypt via AWS KMS

  The Newton SDK already has a full HPKE privacy module (X25519 + HKDF-SHA256 + ChaCha20-Poly1305) with AAD binding, Ed25519 signing, and
  uploadEncryptedData RPC.

  Here are my first batch of questions:

  1. Gateway RPC method change — Currently newton-identity calls newt_sendIdentityEncrypted which stores the RSA-OAEP ciphertext directly on-chain.
  After migration, should identity data go through the same newt_uploadEncryptedData RPC that the SDK's privacy module uses (storing via data_ref_id
   pattern), or do we keep newt_sendIdentityEncrypted but change it to accept HPKE-encrypted envelopes instead of RSA ciphertext? The former unifies
   the code paths; the latter keeps identity data storage separate from general privacy data.

  2. EIP-712 signing vs Ed25519 signing — The current flow EIP-712-signs the encrypted data (EncryptedIdentityData(string data)) using the Identity
  Owner EOA via Turnkey. The SDK privacy module uses Ed25519 signing instead (separate key pair from the EVM wallet). For the migration, should we
  keep EIP-712 signing with the Turnkey wallet (simpler UX — no second key pair), switch to Ed25519 like the SDK privacy module (consistent with the
   privacy layer), or use both (HPKE encrypt + Ed25519 sign the envelope, but also EIP-712 sign for on-chain identity binding)?

  3. On-chain storage model — Currently the IdentityRegistry.submitIdentity(owner, domain, data) stores the encrypted string directly in contract
  storage. The Privacy Layer's uploadEncryptedData stores data off-chain in the gateway and returns a data_ref_id. For identity data, do we keep
  on-chain storage (contract state) with just the encryption scheme changing, or move to the off-chain data_ref_id pattern like the rest of the
  privacy layer? On-chain gives permanence/auditability; off-chain gives flexibility and lower gas costs.

 ✻ Cogitated for 1m 9s

 ❯ 1.What are pros vs cons of storing data onchain on identity registry contract vs. storing in our database. Help me brainstorm whether we should
 merge identity storage separate from general privacy data. Would it be viable to store identity data through the same path as other general privacy
 data but still use Identity Registry for just link data between users and policy clients? Would that have advantage of gas saving and potentially
 also cross-chain interoperability in the future? 2. most ideal if we can just use Ed25519 because we are for sure migrate from AWS KMS to Newton
 privacy layer? is that possible to use Turnkey still but also comply with privacy module? If not, HPKE encrypt + Ed25519 sign the envelope, but
 also EIP-712 sign for on-chain identity binding should also be okay, but UX might not be ideal. One question is what happens to the encrypted HPKE
 data in case the identity owner who encrypted the data "loses" their ed25519 key? Or am i missing something here? 3. On-chain gives
 permanence/auditability; off-chain gives flexibility and lower gas costs. --> let's dive and brainstorm more. Definitely flexibility and lower gas
 costs highly preferred, especailly in Multichain setting, UX is one of the most important aspect. My thinking is that if we move to off chain
 data_ref_id  and just store the link and the data_ref_id instead of the entire encrypted data, it will be ultimately long term better solution but
 I need you to objectively challenge/review my ideas and thinking here

 ⏺ These are great questions with real architectural trade-offs. Let me work through each one systematically.

  ---
  1. On-Chain Identity Registry vs. Off-Chain Privacy Data Store

  Current Architecture

  Identity Data: newton-identity → RSA-OAEP encrypt → EIP-712 sign → Gateway → submitIdentity() → on-chain storage
  Privacy Data:  newton-sdk     → HPKE encrypt      → Ed25519 sign → Gateway → uploadEncryptedData → off-chain (DB)

  The Hybrid Model You're Proposing

  Keep IdentityRegistry for link data only (who is linked to whom), move encrypted identity data to the off-chain privacy data store (same path as
  general privacy data).

  Link data:     IdentityRegistry.linkIdentity()     → on-chain (policyClientLinks mapping)
  Identity data: uploadEncryptedData (HPKE envelope)  → off-chain (data_ref_id in gateway DB)
  Reference:     IdentityRegistry stores data_ref_id  → on-chain pointer to off-chain data

  Pros of the Hybrid Model

  ┌─────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │         Benefit         │                                                      Detail                                                       │
  ├─────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Gas savings             │ Storing a 32-byte data_ref_id on-chain vs. ~512+ bytes of RSA ciphertext is 10-15x cheaper. On Mainnet at current │
  │                         │  gas prices, this matters significantly per identity registration.                                                │
  ├─────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Cross-chain             │ A data_ref_id is chain-agnostic. The encrypted data lives in the gateway, and any chain's IdentityRegistry can    │
  │ interoperability        │ reference it. No need to replicate encrypted blobs across chains.                                                 │
  ├─────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Unified encryption      │ One HPKE encrypt/decrypt path for both privacy data and identity data. One key rotation scheme, one audit         │
  │ infra                   │ surface, one set of operator decryption logic.                                                                    │
  ├─────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Data update flexibility │ Updating identity data (re-KYC, address change) doesn't require an on-chain tx — just upload a new envelope, get  │
  │                         │ a new data_ref_id, and update the on-chain pointer.                                                               │
  ├─────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ TTL/expiration          │ Off-chain store can enforce TTLs on identity data (GDPR "right to be forgotten"), which is much harder with       │
  │                         │ on-chain storage.                                                                                                 │
  └─────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  Cons / Risks to Challenge Your Thinking

  Risk: Gateway availability = data availability
  Detail: If the gateway is down, operators can't decrypt identity data for policy evaluation. On-chain storage is always available to any node.
  Mitigation: Gateway already must be available for task evaluation. Identity data access is already gated behind the gateway's decrypt path. This
    isn't a new dependency.
  ────────────────────────────────────────
  Risk: Data permanence
  Detail: On-chain data survives even if the Newton gateway shuts down. Off-chain data depends on the gateway's DB durability.
  Mitigation: Use replicated storage (S3/IPFS backing), or store the HPKE envelope itself in a content-addressed store. The data_ref_id could be a
    content hash.
  ────────────────────────────────────────
  Risk: Auditability
  Detail: On-chain storage provides a public, immutable record that identity data was submitted. Off-chain loses this.
  Mitigation: The IdentityBound event can still be emitted when a data_ref_id is registered on-chain. The event + on-chain ref provides the audit
    trail. The actual encrypted blob being off-chain doesn't weaken the audit — nobody could read the on-chain blob anyway.
  ────────────────────────────────────────
  Risk: Contract migration
  Detail: IdentityRegistry.submitIdentity() currently stores the full encrypted string. Changing it to store a data_ref_id requires a contract
    upgrade or new function.
  Mitigation: Add a new function registerIdentityDataRef(owner, domain, dataRefId) alongside the existing one. Deprecate submitIdentity over time.
  ────────────────────────────────────────
  Risk: Atomicity
  Detail: Currently, one tx stores the data. With the hybrid model, you upload first (off-chain), then register the ref (on-chain). If the second
    step fails, you have orphaned off-chain data.
  Mitigation: The orphaned data has a TTL and gets cleaned up. Or make the gateway handle both steps atomically behind a single RPC call.

  My Assessment

  Your instinct is right — the hybrid model is the better long-term architecture. The key insight is: nobody reads encrypted blobs from on-chain
  storage directly. Operators always go through the gateway to decrypt. So the on-chain encrypted data provides no additional availability over an
  off-chain store backed by the same gateway.

  The data_ref_id pattern is strictly better for:
  - Multi-chain (one data blob, many chain references)
  - Gas costs (32 bytes vs 500+ bytes)
  - Data updates (new envelope, update pointer)
  - Compliance (TTL, deletion)

  The one thing to nail down: should data_ref_id be a content hash of the envelope (content-addressed, deterministic) or a UUID (opaque,
  gateway-assigned)? Content hash gives you dedup and verifiability. UUID gives the gateway more control over storage lifecycle.

  ---
  2. Ed25519 vs. EIP-712 Signing & Key Loss

  Can Turnkey Support Ed25519?

  Turnkey's signRawPayload signs arbitrary bytes with the wallet's key. But Turnkey wallets are secp256k1 (Ethereum) — not Ed25519. Turnkey doesn't
  offer Ed25519 key generation or signing.

  So the options are:

  Option A: Derive Ed25519 key from Turnkey wallet
  - Sign a deterministic message with the Turnkey secp256k1 key (e.g., "newton-privacy-key-derivation-v1")
  - Use the signature as entropy to derive an Ed25519 key pair
  - Pro: No second key for the user to manage. Deterministic — same wallet always produces the same Ed25519 key.
  - Con: Non-standard. The Ed25519 key is bound to the Turnkey wallet — if user migrates wallets, they need to re-derive.

  Option B: Generate standalone Ed25519 key pair
  - Use generateSigningKeyPair() from the SDK privacy module
  - Store the private key... where? The user is in a popup — no persistent storage.
  - This doesn't work for the popup model unless the integrating app manages the key.

  Option C: HPKE encrypt + Ed25519 sign + EIP-712 sign (belt and suspenders)
  - HPKE encrypt the data (privacy layer encryption)
  - Ed25519 sign the envelope (privacy layer auth — app/SDK provides this)
  - EIP-712 sign the data_ref_id or envelope hash (on-chain identity binding via Turnkey)
  - Pro: Identity binding remains on-chain verifiable via EIP-712, encryption is privacy-layer standard
  - Con: Two signatures per operation

  My Recommendation

  Option A (derived Ed25519) is the cleanest UX if viable. The derivation scheme would be:

  // In the popup, after Turnkey auth:
  const derivationMessage = "newton:ed25519:identity-privacy:v1";
  const secp256k1Sig = await turnkeyProvider.request({
    method: 'personal_sign',
    params: [derivationMessage, ownerAddress]
  });
  // Use first 32 bytes of signature hash as Ed25519 seed
  const ed25519Seed = keccak256(secp256k1Sig).slice(0, 32);

  This is deterministic (same owner always gets the same Ed25519 key) and requires no key storage.

  What Happens If the Ed25519 Key Is "Lost"?

  With Option A, the Ed25519 key is derived from the Turnkey wallet — it can't be lost independently. If the user loses their Turnkey wallet,
  they've lost their identity authority entirely (the Identity Owner EOA is gone).

  With standalone Ed25519 keys: the encrypted data becomes unrecoverable for re-signing purposes, BUT the gateway can still decrypt (it has the HPKE
   private key). The Ed25519 key is for sender authentication, not decryption. So:

  - Data decryption: Not affected by Ed25519 key loss (HPKE recipient key is the gateway's)
  - Re-uploading/re-signing: Would require a new Ed25519 key pair and re-encryption
  - Existing data_ref_id references: Still valid, still decryptable

  The Ed25519 key is not a decryption key — it's a signing key proving who encrypted the data. Losing it means you can't prove authorship of future
  uploads, but existing data remains accessible.

  ---
  3. On-Chain vs. Off-Chain Deep Dive

  Scenario Comparison

  Let me walk through concrete scenarios to stress-test the off-chain data_ref_id model:

  Scenario: User registers identity data on Sepolia, then an app on Base wants to verify

  ┌──────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │      Model       │                                                       What Happens                                                       │
  ├──────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Current          │ Data is in Sepolia's IdentityRegistry. Base operators must cross-chain read from Sepolia, or data must be replicated to  │
  │ (on-chain)       │ Base's registry (another on-chain tx + gas).                                                                             │
  ├──────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Off-chain        │ Data is in the gateway DB. Sepolia's registry has data_ref_id = 0xabc.... Base's registry can store the same             │
  │ data_ref_id      │ data_ref_id. Operators on any chain query the gateway with the ref. One upload, N chain references.                      │
  └──────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  Scenario: User needs to update KYC data (annual re-verification)

  ┌───────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │   Model   │                                                What Happens                                                │
  ├───────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Current   │ New on-chain tx to overwrite identityData[owner][domain]. Gas cost on every chain where data is stored.    │
  ├───────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Off-chain │ Upload new envelope → new data_ref_id. One on-chain tx to update the pointer. Old data can be TTL-expired. │
  └───────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  Scenario: Regulatory deletion request (GDPR)

  ┌───────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │   Model   │                                                           What Happens                                                           │
  ├───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Current   │ On-chain data is immutable. Even if you overwrite with empty bytes, the old data is in historical state. Technically             │
  │           │ non-compliant.                                                                                                                   │
  ├───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Off-chain │ Delete from gateway DB. data_ref_id on-chain becomes a dangling pointer (returns "not found"). Actually deletable.               │
  └───────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  Scenario: Gateway outage during policy evaluation

  ┌───────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │   Model   │                                                      What Happens                                                      │
  ├───────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Current   │ Operators read encrypted data from on-chain, decrypt via KMS. Gateway only needed for the initial submitIdentity call. │
  ├───────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Off-chain │ Operators need the gateway to fetch the encrypted envelope. If gateway is down, identity data is unavailable.          │
  └───────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  This last scenario is the strongest argument for on-chain storage. But consider: operators already need the gateway for task orchestration. If the
   gateway is down, no tasks are being evaluated anyway. So identity data availability is not the bottleneck.

  The Migration Path I'd Recommend

  Phase 1 (now):   RSA-OAEP → on-chain         (what exists today)
  Phase 2 (next):  HPKE → off-chain data_ref_id (this migration)
  Phase 3 (later): data_ref_id on-chain pointer  (contract upgrade)

  Phase 2 can be done without a contract change if the gateway accepts HPKE-encrypted identity data via newt_uploadEncryptedData and the gateway
  internally calls submitIdentity with the data_ref_id as the "data" string. The contract doesn't care what the string contains — it just stores
  bytes. The semantic meaning of the stored string changes from "encrypted blob" to "data reference ID", but the contract is unaware.

  Phase 3 (optional) adds a purpose-built contract function and event, but isn't strictly required for the migration.

  ---
  Next Batch of Questions

  4. On the derived Ed25519 approach (Option A) — are you comfortable with the derivation scheme (secp256k1 sign a constant message → keccak256 →
  Ed25519 seed)? Or do you see concerns with binding the privacy key to the Turnkey wallet? The main trade-off: it means wallet migration (changing
  Identity Owner EOA) also rotates the Ed25519 key.

  5. For the data_ref_id storage — should the gateway return the ref after upload and then newton-identity stores it on-chain via
  submitIdentity(owner, domain, dataRefId) (two-step, popup handles both), or should the gateway handle the on-chain storage internally like it does
   today (one RPC call, gateway submits the tx)?

  6. Timeline/ordering — should this migration happen in newton-identity first (swap encryption, keep same gateway RPC), or does the gateway need
  changes first (new HPKE-based identity data handler)? What's the dependency order between this repo, newton-prover-avs, and newton-sdk?
No results found