← Docs index

Archived Phase 3 eERC Research

  • Version: 1.2.1
  • Date: July 2026
  • Author: Meridian Protocol Engineering
  • Status: Archived Phase 3 research; not an active architecture, roadmap, or integration plan
  • Current Architecture Decision: Private L1 Architecture Decision
  • Implemented Research Environment: Avalanche Fuji testnet

Archive Notice

This page preserves technical work completed for Meridian's Phase 3 research milestone. It is not the current product architecture and it does not describe work planned for production.

The current decision is a dedicated private Avalanche L1 using standard ERC-20 assets. eERC is not included in the architecture, roadmap, SDK, migration plan, or current implementation work.

The Fuji contracts, proof pipeline, and frontend evaluation remain here only as a record of the research that was completed. If a future deployment creates a specific need for token-level confidentiality, Meridian will start a new architecture review. This archive does not pre-approve that decision.

Public C-Chain availability alone is not a reason to use eERC. A public representation can use a standard ERC-20.

For the active decision and implementation boundary, read the Private L1 Architecture Decision. The technical material below is archived and should not be used to infer current scope.

Table of Contents

  1. Executive Summary
  2. Background and Motivation
  3. eERC Technical Overview
  4. Meridian Protocol Architecture Review
  5. Conditional Integration Research
  6. Auditor Role Mapping
  7. Privacy Boundaries
  8. Compliance Integration
  9. Gas and Performance Analysis
  10. Conditional Frontend and SDK Research
  11. Architecture Decision and Reconsideration Gate
  12. Security Considerations
  13. Open Questions and Future Work
  14. References

1. Executive Summary

This document records Meridian Protocol's current privacy architecture decision and preserves earlier eERC research. Production privacy is planned at the infrastructure layer through a dedicated private Avalanche L1 using standard ERC-20 assets. eERC is not part of that architecture.

Meridian Protocol is an onchain institutional credit infrastructure platform deployed on the Avalanche public blockchain. It comprises six composable protocol layers: structured credit vaults (Forge), credit default swaps (Shield), cross-chain margin architecture (Nexus), composability routing, yield optimization, and AI-driven risk management. The protocol is live on Avalanche Fuji testnet with full Foundry coverage including fuzz and invariant testing, and is heading toward audit and mainnet.

A private Avalanche L1 restricts access to the chain and its data at the network and infrastructure layer. eERC uses zk-SNARKs and ElGamal encryption to hide balances and transfer amounts for a particular token even from participants who can read the chain. Meridian does not currently have a validated requirement for that second control.

The production decision is therefore private L1 plus standard ERC-20. The remaining sections document the cryptographic foundations exercised on Fuji, the limits identified during review, and the conditional integration work that would be required if a future deployment establishes a specific token-confidentiality need.

Meridian's current codebase includes eERC research scaffolding and a Fuji proof pipeline. Those artifacts are not production dependencies. There is no eERC migration or rollout plan. Any future adoption decision requires a named use case, threat model, integration design, key-custody model, and security review.

2. Background and Motivation

2.1 The Institutional Privacy Problem

Institutional adoption of onchain credit infrastructure faces a fundamental tension: the transparency that makes public blockchains trustworthy is the same property that makes them unsuitable for institutional finance. When a pension fund takes a $50 million senior tranche position in a structured credit vault, or when a hedge fund writes $20 million in credit default swap protection, the market-sensitive nature of that information demands confidentiality.

On a standard ERC-20 blockchain deployment, any observer can determine:

  • Position sizes: The exact amount any address has deposited into any tranche, visible through token balance queries and event log analysis.
  • Yield claims: When and how much yield an address collects, revealing the effective return profile of their position and, by inference, the performance of the underlying credit pool.
  • Trading patterns: When tranche tokens are transferred on the secondary market, who is buying, who is selling, and at what volumes, enabling front-running, copycat strategies, and competitive intelligence extraction.
  • Risk exposure: An institution's aggregate exposure across multiple Meridian vaults, CDS pools, and margin accounts can be reconstructed by analyzing their address's interactions across the protocol.
  • Rebalancing signals: When the AI analyst adjusts tranche allocations or when the waterfall distribution shifts due to credit deterioration, sophisticated observers can detect these signals and trade ahead of the institution's response.

These information leakage vectors create real economic harm. Competitors can reverse-engineer an institution's credit strategy. Market makers can adjust pricing against a known large participant. Activist investors can identify vulnerability in a fund's risk exposure. The transparency that protects retail DeFi users becomes a weapon against institutional participants operating at scale.

This is not a theoretical concern. Traditional finance operates with extensive confidentiality protections: trade reporting delays, dark pools, block trading facilities, and regulatory frameworks that restrict information dissemination precisely because market participants have proven, repeatedly, that they will exploit information asymmetries. Bringing institutional credit onchain without comparable privacy protections is asking institutions to operate at a structural disadvantage compared to their off-chain alternatives.

2.2 Regulatory Landscape

The regulatory environment for onchain privacy is nuanced and jurisdiction-dependent, but the overall trajectory favors privacy solutions that include compliance hooks rather than privacy solutions that exclude them.

United States: The SEC's framework for digital asset securities (as clarified through enforcement actions and staff guidance through 2025-2026) does not prohibit confidential transactions per se. What regulators require is the ability to access transaction data upon request, audit trails for reporting obligations, and KYC/AML compliance at the access layer. A system where balances are encrypted but auditors can decrypt them upon regulatory request is structurally compatible with existing securities law requirements. The SEC's concerns center on market manipulation and fraud detection, both of which are addressed by eERC's auditor infrastructure.

European Union: MiCA (Markets in Crypto-Assets Regulation), which took full effect in 2025, explicitly contemplates privacy-preserving technologies provided they include "traceability" mechanisms for competent authorities. The eERC auditor model, where regulators can be designated as auditors with decryption capabilities, maps directly to MiCA's traceability requirements. The GDPR's data minimization principle actually favors encrypted balance storage, as it reduces the amount of personal financial data publicly exposed.

Switzerland (FINMA): Switzerland's progressive regulatory framework has been receptive to privacy-preserving DeFi, particularly where compliance infrastructure is embedded at the protocol level rather than bolted on after the fact. eERC's approach of building compliance into the token standard itself aligns with FINMA's principle of "same risks, same rules" applied to digital assets.

Singapore (MAS): The Monetary Authority of Singapore's Payment Services Act and Securities and Futures Act frameworks require transaction monitoring capabilities but do not mandate public transparency of individual positions. Encrypted positions with regulatory decryption keys are compatible with MAS requirements.

This regulatory discussion is background research, not a legal conclusion that eERC satisfies any jurisdiction's requirements. A production deployment would require counsel and regulator-specific analysis.

2.3 When eERC Would Be Reconsidered

Meridian is not currently choosing eERC for production. The research remains relevant only as an evaluated Avalanche-native option if a future deployment requires token-level confidentiality beyond the private L1's infrastructure access controls.

An eERC adoption review can begin only when all of the following are true:

  1. A named deployment identifies who may read the chain and which of those readers must not see balances or transfer amounts.
  2. Standard ERC-20 assets on the private L1 cannot satisfy that confidentiality requirement.
  3. The required workflows fit eERC's bounded operations or have reviewed adapters. Public-chain availability by itself does not satisfy this condition.
  4. Auditor key custody, historical-access requirements, proof generation, recovery, and failure handling are defined.
  5. The integration passes security review before production capital is admitted.

Native Avalanche integration. eERC is developed for Avalanche's EVM environment and can be deployed on C-Chain or an EVM-compatible Avalanche L1. Cross-chain use through Avalanche Interchain Messaging (ICM) is a separate bridge and messaging design decision. It is not automatic eERC interoperability.

No protocol-level modifications required. eERC operates entirely at the smart contract layer. It does not require custom opcodes, precompiles, or modifications to the Avalanche consensus protocol. This means Meridian can integrate eERC on the existing C-Chain without waiting for network upgrades or deploying to a custom subnet with modified execution.

Auditor access for compliance. The token owner configures one active auditor public key on the EncryptedERC contract. The active auditor can be replaced without redeploying the token, but the change applies only to future transactions. It does not automatically decrypt, re-encrypt, or transfer access to historical records. The Registrar handles user registration and public keys; it does not manage a list of simultaneous auditors.

EVM deployment with bounded composability. eERC runs as smart contracts in an EVM environment, but its proof-bearing encrypted operations are not a drop-in ERC-20 interface. The practical initial use cases are encrypted holdings, private transfers, tokenized ownership, and private settlement flows that do not require complex arithmetic over encrypted values. Existing DEX routers, automated market makers, lending protocols, aggregators, and Meridian routing contracts would require adapters, custom cryptographic protocols, or a different confidential-compute approach. Broader DeFi integration is therefore future research, not a current compatibility claim.

Client-side proof generation. The official TypeScript SDK provides React-oriented hooks and uses Wagmi and Viem. A community Next.js reference implementation demonstrates registration, deposits, encrypted transfers, and browser-side Groth16 proof generation with circuit artifacts served from the application's public directory. This establishes a concrete Next.js integration pattern, but not drop-in compatibility with the packaged SDK. Meridian must still validate worker behavior, WASM and proving-key delivery, server-side rendering boundaries, wallet lifecycle behavior, dependency security, and production bundling.

Standalone and Converter modes. eERC supports creating new private tokens and wrapping existing ERC-20 tokens with privacy. The research evaluated both modes, but Meridian has not selected either mode for production.

Alternative analysis. Other privacy approaches were considered and rejected:

ApproachWhy Not
Aztec Protocol (now Aztec Network)Separate L2, not on Avalanche, would require bridging and lose composability with Meridian's existing contracts
Tornado Cash-style mixersRegulatory toxicity, no selective disclosure, no compliance infrastructure, sanctioned by OFAC
FHE (Fully Homomorphic Encryption) via FhenixPromising but immature, massive computational overhead, not Avalanche-native
TEE-based (Secret Network model)Hardware trust assumptions, not EVM-compatible, not Avalanche-native
ZK-rollup with private state (zkSync/StarkNet)Different L1/L2, would require complete redeployment, loss of Avalanche ecosystem benefits

eERC remains an Avalanche-native token-privacy option documented by this research. It is not part of Meridian's current production architecture, and no adoption should be inferred from the remainder of this document.

3. eERC Technical Overview

3.1 Cryptographic Foundations

The eERC protocol is built on three core cryptographic primitives, each chosen for specific properties that enable efficient onchain privacy.

ElGamal Encryption on BabyJubJub

eERC uses the ElGamal public-key encryption scheme adapted for elliptic curve cryptography, specifically operating on the BabyJubJub twisted Edwards curve. BabyJubJub was chosen for its compatibility with zero-knowledge proof systems: its curve order is a prime that divides the scalar field of the BN254 pairing-friendly curve used by Ethereum's and Avalanche's ecPairing precompile, making it efficient to verify BabyJubJub operations inside zk-SNARK circuits.

The critical property of ElGamal encryption for eERC's use case is additive homomorphism. When token balances are encrypted under ElGamal, the protocol can update a user's encrypted balance by adding an encrypted transfer amount to it, without ever decrypting the balance. Specifically:

Enc(balance) + Enc(transfer_amount) = Enc(balance + transfer_amount)

This means the EncryptedERC contract can process transfers, mints, and burns by performing homomorphic operations on encrypted ciphertexts, never handling plaintext values. The contract itself never knows any user's actual balance. Only the user (who holds the private key) and designated auditors (who hold auditor decryption keys) can decrypt.

Each encrypted balance is stored as a pair of elliptic curve points (C1, C2) on BabyJubJub. The encryption of a value v under public key pk with randomness r is:

C1 = r * G           (where G is the BabyJubJub generator)
C2 = v * G + r * pk  (where pk is the recipient's public key)

Decryption requires the private key sk corresponding to pk:

v * G = C2 - sk * C1

The final step of recovering v from v * G requires solving the discrete logarithm, which is computationally feasible only for small values (up to ~40 bits with baby-step giant-step). This is sufficient for token balances represented in standard decimal precision.

zk-SNARKs (Groth16)

Every state-changing operation on an eERC token (transfer, mint, burn, deposit, withdraw) requires a zero-knowledge proof that validates the operation without revealing the amounts involved. eERC uses the Groth16 proving system, which offers:

  • Constant-size proofs: Regardless of the complexity of the statement being proven, the proof is always 3 elliptic curve group elements (~128 bytes).
  • Fast verification: Verification requires a single pairing check, which maps to Avalanche's ecPairing precompile and costs approximately 45,000-113,000 gas depending on the number of public inputs.
  • Small proof size: The compact proof representation minimizes calldata costs on Avalanche.

The trade-off is that Groth16 requires a trusted setup (a ceremony that generates proving and verification keys). The eERC protocol includes pre-generated ceremony artifacts for its standard circuits. Custom circuits (if Meridian were to extend the proof system) would require either using these existing ceremonies or conducting new ones.

The zk-SNARK circuits for eERC validate the following properties:

  1. Transfer circuit: Proves that (a) the sender has sufficient encrypted balance to cover the transfer amount, (b) the transfer amount is non-negative, (c) the sender's new balance is correctly computed, (d) the recipient's new balance is correctly computed, and (e) all ciphertexts are correctly formed under the respective public keys. None of the actual values (sender balance, recipient balance, transfer amount) are revealed.

  2. Mint circuit: Proves that a new ciphertext correctly encrypts a specified amount under the recipient's public key. Used when the token owner (in Meridian's case, the ForgeVault) creates new tokens.

  3. Withdraw circuit (Converter mode only): Proves that a user's encrypted balance is being correctly reduced and the corresponding plaintext amount is accurate, enabling conversion from encrypted eERC back to standard ERC-20.

Poseidon Hash Function

eERC uses the Poseidon hash function for all hashing operations within zk-SNARK circuits. Poseidon is a "ZK-friendly" hash function designed specifically for efficient computation inside arithmetic circuits. Compared to SHA-256 or Keccak-256 (which are efficient in hardware but expensive inside ZK circuits), Poseidon requires approximately 8x fewer constraints, directly reducing proof generation time and circuit complexity.

Poseidon is used for:

  • Hashing encrypted ciphertexts as public inputs to proof verification
  • Merkle tree construction (for batch operations)
  • Commitment schemes within the proof system

3.2 Contract Architecture

The eERC system comprises three primary smart contracts that work together to provide encrypted token functionality:

EncryptedERC Contract

The core token contract stores user balances as ElGamal ciphertexts and requires proof-bearing calls for private operations. It does not expose a normal ERC-20 surface that existing routers can consume unchanged. Transfers use custom calldata containing the recipient, token identifier, cryptographic proof, and encrypted balance data. Standalone deployments provide private mint and burn operations; Converter deployments add deposit and withdrawal at the boundary with an underlying ERC-20.

Key storage and behavior:

  • Encrypted user balances are stored by user and token identifier as BabyJubJub curve points.
  • The contract holds one active auditor address and public key.
  • Auditor ciphertexts for operations are included in transaction data and events so the active auditor can decrypt the operations created while that key was active.
  • State changes are accepted only after the relevant proof is verified.

Registrar Contract

Manages the mapping between Ethereum addresses and BabyJubJub public keys. Before a user can receive eERC tokens, they must register their BabyJubJub public key with the Registrar. A registered address can then be selected as the EncryptedERC contract's active auditor. The auditor itself is configured on the token contract, not maintained as a multi-auditor list in the Registrar.

Proof Verifier Contract

A Groth16 verification contract generated from the trusted setup ceremony. It exposes a verifyProof function that takes the proof elements and public inputs, performs the pairing check using Avalanche's ecPairing precompile, and returns a boolean. The EncryptedERC contract calls the Proof Verifier for every state-changing operation.

The Proof Verifier is deployed once per circuit type (transfer, mint, withdraw) and referenced by the EncryptedERC contract. Upgrading the proof system (e.g., switching from Groth16 to PLONK) would require deploying new verifier contracts and updating the references.

3.3 Deployment Modes

eERC supports two deployment modes. Both were evaluated in Meridian's research; neither is selected for production:

Standalone Mode

Creates an entirely new token with privacy built in from inception. There is no underlying ERC-20; the eERC is the token. The research evaluated how this mode could apply to tranche tokens if a future deployment requires their position sizes to remain hidden from authorized chain readers.

Standalone mode optionally supports hiding the total supply. For institutional credit vaults, hiding total supply would conceal the total size of the vault's capital base, which may or may not be desirable depending on the transparency requirements of the specific vault structure.

Converter Mode

Wraps an existing ERC-20 token with privacy. Users deposit the standard ERC-20 into the Converter contract and receive an equivalent encrypted balance. They can transfer encrypted balances between registered users, and withdraw back to the plaintext ERC-20 at any time.

The research also evaluated Converter mode for an underlying asset such as USDC. It could hide encrypted balances after conversion, but deposits and withdrawals at the plaintext boundary would remain visible. Meridian has not selected this design.

No initial eERC integration is planned. Standard ERC-20 assets are the current production decision.

3.4 Registration and Key Management

Before interacting with eERC tokens, users must complete a one-time registration process:

  1. Key generation: The user's client (browser, mobile app, or SDK) generates a BabyJubJub keypair. The private key is derived deterministically from the user's Ethereum wallet signature (signing a specific message), ensuring the BabyJubJub key can be recovered from the Ethereum key without additional backup requirements.

  2. Registration transaction: The user calls Registrar.register(babyJubJubPublicKey), associating their Ethereum address with their BabyJubJub public key onchain. This is a one-time gas cost.

  3. Auditor selection: The token owner selects one registered address as the active auditor on the EncryptedERC contract. Subsequent private operations include ciphertext for that active auditor in addition to the user ciphertexts.

Key management considerations for Meridian:

  • The BabyJubJub private key is as sensitive as the Ethereum private key. Compromise of either enables balance decryption.
  • Hardware wallet users can sign the derivation message with their hardware wallet, keeping the BabyJubJub key derivation in the secure element.
  • Institutional users with multi-sig wallets will need a key management strategy for the BabyJubJub key that mirrors their multi-sig setup. This is an open design question (see Section 13).

3.5 Transfer Flow

A complete eERC transfer proceeds as follows:

  1. Client-side preparation: The sender's client decrypts their current balance using their BabyJubJub private key, verifies they have sufficient funds, and constructs the proof inputs:

    • Current encrypted balance (fetched from chain)
    • Transfer amount (known to the sender)
    • Sender's BabyJubJub private key
    • Recipient's BabyJubJub public key (fetched from Registrar)
    • Active auditor public key (configured on the token contract)
    • Random blinding factors for new ciphertexts

  2. Proof generation: The client generates a Groth16 proof using the transfer circuit. This proves:

    • The sender's current encrypted balance contains a value >= the transfer amount
    • The new sender balance ciphertext correctly encrypts (old_balance - amount)
    • The new recipient balance ciphertext correctly encrypts (old_balance + amount) using homomorphic addition
    • Auditor-encrypted copies of the transfer amount are correctly formed
    • All randomness is fresh (preventing replay attacks)

    Proof generation takes approximately 2-5 seconds on modern hardware (laptop/desktop) and 5-15 seconds on mobile devices.

  3. Transaction submission: The client submits a transaction to the EncryptedERC contract containing:

    • The Groth16 proof (3 curve points, ~128 bytes)
    • The new sender encrypted balance
    • The transfer amount encrypted under the recipient's key
    • The transfer summary encrypted under the active auditor's key
    • The recipient's address

  4. On-chain verification: The EncryptedERC contract:

    • Calls the Proof Verifier to validate the zk-SNARK proof
    • If valid, updates the sender's encrypted balance to the new ciphertext
    • Homomorphically adds the encrypted transfer amount to the recipient's encrypted balance
    • Emits the auditor-encrypted transaction data for compliance access
    • Emits a Transfer event (with encrypted amounts, not plaintext)

  5. Recipient decryption: The recipient's client can decrypt the new balance using their BabyJubJub private key at any time. This is a local operation with no on-chain cost.

3.6 Auditor and Compliance Infrastructure

The eERC auditor system is the critical differentiator that makes eERC suitable for institutional credit versus general-purpose privacy tools.

Auditor capabilities:

  • Decrypt the auditor ciphertext included in private operations created while its key is active
  • Reconstruct the covered transaction history from indexed contract events
  • Perform compliance review asynchronously and off-chain

Auditor limitations:

  • Cannot modify balances or execute transfers
  • Cannot prevent transfers (enforcement is handled by the TransferRestriction module, not the auditor)
  • Cannot decrypt operations created under a different auditor key

Active auditor replacement:

  • The token owner can replace the active auditor with another registered address without redeploying the token contract
  • New operations use the replacement auditor's public key
  • Historical operations are not automatically re-encrypted for the replacement auditor
  • The former auditor retains the ability to decrypt historical data created under its key if it retained that private key

Current single-auditor boundary:

  • The reviewed EncryptedERC implementation has one active auditor per token contract
  • Multiple organizational roles must share access through an organization-controlled audit service, use separate token deployments, or rely on a future custom extension

4. Meridian Protocol Architecture Review

4.1 The Minter-Knows Pattern and Zone Model

The original research evaluated ForgeVault through what the codebase called the "Minter-Knows" pattern, structured around a three-zone data model. This section is a conditional design analysis, not the current production architecture:

Zone 1: Public Data Information that is visible to all observers and is intended to remain public even after eERC integration:

  • Total pool deposits (totalPoolDeposited)
  • Total yield received and distributed (totalYieldReceived, totalYieldDistributed)
  • Pool status (Active, Impaired, Matured, Defaulted)
  • Tranche allocation percentages (Senior/Mezzanine/Equity target APRs)
  • Distribution interval and timing
  • Protocol fee parameters

Zone 1 data serves the market transparency function: potential investors need to evaluate the vault's overall health, size, and yield profile before investing. Hiding this data entirely would undermine market efficiency without providing meaningful individual privacy.

Zone 2: Vault-Internal Data (Plaintext Mirrors) Per-user share counts and yield accumulators maintained internally by the ForgeVault contract:

  • _shares[trancheId][user]: Plaintext mirror of each user's share balance
  • _yieldCheckpoint[trancheId][user]: Per-user yield accumulator state
  • _pendingYield[trancheId][user]: Unclaimed yield amounts
  • totalShares[trancheId]: Total shares per tranche

Zone 2 data is currently stored as plaintext mapping values inside the ForgeVault contract. In the current architecture, this data is technically readable by anyone who queries the contract storage directly (via eth_getStorageAt). However, the contract only exposes this data through the getShares() view function, which is documented as "not publicly exposed in production" and exists solely for testing.

In the conditional eERC design, Zone 2 would remain plaintext inside the vault contract because the waterfall distribution math requires it. The vault would know actual share counts while the token layer hid balances from chain readers.

The security of Zone 2 under eERC depends on restricting the getShares() function (and the underlying storage slots) from public access. In production, getShares() would be removed or access-restricted, and the storage layout would rely on Solidity's private visibility (which prevents contract-level access but not raw storage reads). For full Zone 2 protection, a confidential execution environment (e.g., an Avalanche subnet with TEE nodes) would be required. This is discussed further in Section 13 as a future enhancement.

Zone 3: Token-Layer Data (Encrypted) The original research proposed token balances stored in an EncryptedTrancheToken backed by eERC:

  • Per-user tranche token balances (encrypted under eERC)
  • Transfer events (encrypted amounts)
  • Approval state

In that conditional design, Zone 3 balances would be ElGamal ciphertexts and transfer amounts would be hidden inside zk-SNARK proofs. This is not Meridian's current token architecture.

4.2 ForgeVault and Tranche Token Architecture

The ForgeVault contract manages structured credit positions across three tranches (Senior, Mezzanine, Equity) with a waterfall yield distribution mechanism. The key interaction points with the token layer are:

Invest flow (invest() / investFor()):

  1. User transfers underlying asset (e.g., USDC) to the vault
  2. Vault updates plaintext mirrors: _shares[trancheId][user] += amount
  3. Vault updates totals: totalShares[trancheId] += amount
  4. Vault calls trancheTokens[trancheId].mint(user, amount) to create tranche tokens

Under eERC, step 4 would generate a zk-proof and mint encrypted tokens. The vault (as the token owner/minter) has the authority to mint without a user-generated proof; the mint proof is generated by the vault's backend or a designated operator.

Withdraw flow (withdraw()):

  1. Vault verifies _shares[trancheId][user] >= amount (using plaintext mirrors)
  2. Vault updates plaintext mirrors: _shares[trancheId][user] -= amount
  3. Vault calls trancheTokens[trancheId].burn(user, amount) to destroy tranche tokens
  4. Vault transfers underlying asset back to user

Under eERC, step 3 requires a burn proof. The vault, as the owner, can generate this proof or delegate to an operator.

Waterfall distribution (triggerWaterfall()):

  1. Vault calculates available yield from balance surplus
  2. Vault builds tranche states using totalShares[i] (plaintext mirrors, not token balances)
  3. WaterfallDistributor calculates yield allocation per tranche
  4. Vault updates yieldPerShare[i] accumulators

Critically, the waterfall uses plaintext mirrors exclusively. It never reads from the token contracts. This means eERC integration at the token layer does not affect the waterfall calculation at all. The plaintext mirrors in Zone 2 are the source of truth for all vault-internal math.

Transfer hook (onShareTransfer()): When tranche tokens are transferred on the secondary market (user-to-user), the token contract calls the vault's onShareTransfer hook to sync the plaintext mirrors:

  1. TrancheToken's transfer() / transferFrom() executes the token transfer
  2. Token contract calls vault.onShareTransfer(from, to, amount)
  3. Vault settles pending yield for both parties
  4. Vault updates mirrors: _shares[trancheId][from] -= amount, _shares[trancheId][to] += amount

Under eERC, the transfer hook must receive the plaintext amount to update mirrors. In the encrypted model, the vault (as the token owner and hook target) has auditor-level access and can decrypt the transfer amount from the auditor-encrypted copy. Alternatively, the hook can receive the plaintext amount as a parameter and verify it against the proof. This is detailed in Section 5.6.

4.3 Existing eERC Research Scaffolding

The Meridian codebase includes research scaffolding used to test eERC integration boundaries:

MockEERC (src/mocks/MockEERC.sol)

A standard ERC-20 that mimics part of eERC's interface for unit testing. It does not establish a production integration contract:

  • onlyOwner can mint (owner = ForgeVault)
  • Transfers trigger a hook callback to the vault via onShareTransfer(address,address,uint256)
  • Balances are plain uint256 (no encryption in the mock)

The mock uses OpenZeppelin's Ownable for access control (rather than TrancheToken's custom onlyVault modifier) because the production EncryptedERC contract uses Ownable. This design choice ensures the behavioral contract is identical between mock and production.

EncryptedTrancheToken research adapter (src/forge/EncryptedTrancheToken.sol)

Extends MockEERC and implements ITrancheToken. It validates an adapter shape against the mock and is not selected for production. Key differences from the standard TrancheToken:

  • Access control: Ownable.onlyOwner instead of custom onlyVault modifier
  • Hook mechanism: Overridden transfer() / transferFrom() with explicit _callTransferHook() instead of _update() override
  • Hook enforcement: require(success) on hook call (the mock version silently swallows failures; the encrypted version requires success because plaintext mirror sync is mandatory)
  • Error type: OwnableUnauthorizedAccount(address) instead of string revert

The NatSpec documentation in EncryptedTrancheToken explicitly states:

"In production, MockEERC would be replaced by EncryptedERC (Standalone mode) with real ZK proofs for mint/burn/transfer."

This confirms that one adapter boundary was explored in the test suite. It does not confirm compatibility with real EncryptedERC or a planned integration path.

4.4 Compliance Layer

Meridian's existing compliance infrastructure provides the onchain identity and access control layer that eERC's privacy model operates within:

InvestorRegistry (src/compliance/InvestorRegistry.sol)

An onchain KYC/accreditation registry. Key features:

  • Authorized verifiers (KYC providers) attest investor status with jurisdiction codes (ISO 3166-1 alpha-2) and expiration timestamps
  • isVerified(address) returns whether an address has valid, non-expired KYC
  • isAccredited(address) provides the same check with semantic clarity for accreditation contexts
  • Batch verification support for onboarding multiple institutional participants
  • Verifier management (add/remove authorized KYC providers) controlled by the registry owner

TransferRestriction (src/compliance/TransferRestriction.sol)

An abstract module that enforces investor verification on token transfers:

  • onlyVerifiedTransfer modifier checks both parties against InvestorRegistry
  • Minting (from=0) and burning (to=0) always pass (the vault controls these)
  • Exempt addresses bypass checks (for protocol contracts like routers)
  • Transfer restrictions are opt-in (disabled by default for backward compatibility)

VaultLegalMetadata (src/compliance/VaultLegalMetadata.sol)

Stores legal documentation references onchain for each vault (offering memorandum hash, jurisdiction, regulatory status). Provides the legal metadata layer that institutional participants and regulators reference.

These three contracts form Meridian's existing compliance substrate. The research evaluated how eERC might interact with them, but no production integration is planned.

4.5 Cross-Chain Margin Architecture (NexusHub)

The NexusHub is Meridian's central margin engine on C-Chain. It tracks multi-asset collateral positions, receives cross-chain balance attestations from remote L1 NexusVaults, and triggers liquidations.

The cross-chain flow:

  1. User deposits collateral on a remote Avalanche L1 NexusVault
  2. NexusVault sends an attestation message via Teleporter (Avalanche's native cross-chain messaging)
  3. NexusHub on C-Chain receives the attestation and updates cross-chain collateral values
  4. If the aggregate position is unhealthy (below 110% collateralization), anyone can call triggerLiquidation()
  5. Hub sends a liquidation message back to the remote NexusVault

Privacy considerations for NexusHub are distinct from ForgeVault because the margin engine operates on aggregate collateral values rather than token positions. The privacy integration for NexusHub is discussed in Section 5.8.

4.6 Credit Default Swap Pools (Shield)

The CDSPool is an automated market maker for credit default swaps. LPs deposit collateral to sell protection; buyers purchase protection at a price determined by a utilization-based bonding curve. Premium payments stream to LPs proportionally via share appreciation (ERC4626-style).

Privacy integration for CDSPool is complex because CDS positions have directional implications: knowing that an entity is buying protection against a specific reference entity signals a bearish credit view. This information leakage can move markets and is precisely the kind of competitive intelligence that institutional participants need to protect. The CDSPool privacy design is covered in Section 5.7.

5. Conditional Integration Research

This section preserves the token-level integration design evaluated in the original April 2026 research. It is not the current production architecture or roadmap. These mechanics may be reconsidered only through the decision gate in Section 11.

5.1 Design Principles

The conditional research design used these principles:

  1. Vault math never touches encrypted values. The ForgeVault's waterfall distribution, yield accounting, and tranche allocation logic operates exclusively on plaintext mirrors (Zone 2). Encrypted values exist only at the token layer (Zone 3). This keeps the critical financial logic simple, auditable, and gas-efficient.

  2. No current production switch exists. The research considered an optional encrypted token path, but the production architecture uses standard TrancheToken. A future encrypted path would require a purpose-built, reviewed factory and adapter implementation.

  3. Compliance and token privacy solve different problems. InvestorRegistry and TransferRestriction control who can hold tokens. A conditional eERC layer would control what authorized chain readers can see about amounts. Their interaction requires implementation and security review.

  4. The reviewed implementation has one active auditor key. Multiple institutional roles require an organization-controlled access layer, separate deployments, or a custom extension. Replacing the active key changes future access only.

  5. Client-side complexity is not yet abstracted for Meridian. Alejandro's Next.js repository demonstrates a workable browser integration pattern, but Meridian would still need to adapt and harden proof generation, key management, circuit delivery, wallet behavior, and failure handling.

5.2 Zone Model Under eERC

The conditional research model evaluated these zone changes:

ZoneCurrent StateConditional eERC State
Zone 1 (Public)Pool totals, status, tranche params, fee configUnchanged. Pool-level data remains public for market transparency
Zone 2 (Vault-Internal)Plaintext mirrors in private mappings; technically accessible via eth_getStorageAtSame storage, but getShares() removed from public interface. Storage-slot privacy via Solidity private visibility (partial protection; full protection requires confidential execution)
Zone 3 (Token Layer)Standard ERC-20 balances, fully visibleElGamal-encrypted balances. Only holder and designated auditors can decrypt

New privacy guarantees:

  • An external observer cannot determine how much any specific address has invested in any tranche
  • An external observer cannot determine the size of secondary market transfers
  • An external observer can see that an address interacted with a vault (transaction to/from the vault address) but cannot determine the amount
  • The vault's total AUM remains partially observable through Zone 1 totals (this is intentional for market transparency)

Remaining information leakage (acceptable):

  • Transaction timing: when an address interacts with the vault is visible
  • Interaction type: whether a transaction is invest/withdraw/claim is inferable from function selector
  • Counterparty in transfers: sender and recipient addresses are visible (amounts are hidden)
  • Gas usage: different operation sizes may correlate with different gas costs, though this is minimal with fixed proof verification costs

5.3 Conditional TrancheToken Design

The research evaluated a new-vault contract replacement rather than an upgrade. This is not a current migration path.

Current deployment (ForgeFactory creates a vault):

ForgeFactory.createVault(...)
  → deploys 3x TrancheToken (standard ERC-20)
  → deploys 1x ForgeVault (references TrancheTokens)

Conditional design evaluated in research:

ForgeFactory.createVault(..., useEncryptedTokens: true)
  → deploys 3x EncryptedTrancheToken (eERC Standalone)
  → deploys 1x ForgeVault (same contract, references EncryptedTrancheTokens)
  → deploys or references shared Registrar + Proof Verifier

The research assumed ForgeVault could continue through ITrancheToken, but real EncryptedERC is not a drop-in implementation. A production adapter would require separate validation.

The EncryptedTrancheToken constructor sets up the eERC Standalone token with:

  • Token name and symbol (e.g., "Meridian Senior Tranche", "mSR")
  • 18 decimals (matching USDC precision after scaling)
  • Owner set to the ForgeVault address (only the vault can mint/burn)
  • Transfer hook target set to the ForgeVault address
  • Registrar reference for user key management
  • Proof Verifier reference for zk-SNARK validation

5.4 ForgeVault Modifications

The conditional design identified the following ForgeVault changes. Their feasibility does not establish an adoption decision:

1. Remove getShares() public view function (or restrict access)

Currently exposed for testing. In production with eERC, this function would leak the plaintext mirror data that eERC is designed to hide. Options:

  • Remove entirely (preferred for privacy; testing uses direct storage reads in test harness)
  • Restrict to owner/admin only
  • Restrict to registered auditor addresses

2. Mint/Burn proof delegation

When the vault calls trancheTokens[trancheId].mint(user, amount), the production EncryptedERC contract requires a zk-proof for the mint operation. Since the vault is the token owner, it has special privileges:

  • Option A: Owner-bypasses-proof. The EncryptedERC contract could exempt the owner from proof requirements for mint/burn, since the owner is a trusted contract that already controls the token supply. This is the simplest integration path.
  • Option B: Backend proof generation. A backend service generates mint/burn proofs on behalf of the vault. The vault submits the proof alongside the mint/burn call. This is more cryptographically rigorous but adds infrastructure complexity.

The original research preferred Option A for simplicity. Meridian has not adopted either option.

3. Transfer hook amount access

The onShareTransfer(address from, address to, uint256 amount) hook currently receives the plaintext transfer amount. Under eERC, the transfer amount is encrypted. The vault needs the plaintext amount to update mirrors.

Solutions:

  • Option A: Hook receives plaintext amount. The EncryptedTrancheToken contract extracts the plaintext amount from the proof verification and passes it to the hook. The vault can verify the amount against the proof's public inputs. This is the current design in EncryptedTrancheToken._callTransferHook().
  • Option B: Vault decrypts from auditor copy. The vault, registered as an auditor, decrypts the transfer amount from the auditor-encrypted copy. This requires the vault contract to perform onchain decryption, which is gas-expensive.

The original research preferred Option A. The mock adapter implements that pattern, but production compatibility remains unverified.

5.5 Waterfall Distribution with Encrypted Balances

The waterfall distribution is the core financial mechanism of ForgeVault. Under eERC integration, it continues to operate identically because it uses Zone 2 plaintext mirrors, not Zone 3 token balances.

The distribution flow:

  1. triggerWaterfall() calculates availableYield from the vault's underlying asset balance
  2. Builds TrancheState structs using totalShares[i] (Zone 2, plaintext)
  3. WaterfallDistributor.distributeYield() allocates yield per tranche based on target APRs and seniority
  4. Updates yieldPerShare[i] accumulators (Zone 2, plaintext)

No encrypted values are involved at any step. The yield distribution is determined entirely by plaintext internal accounting.

Yield claiming (claimYield()):

The user's claimable yield is calculated from plaintext mirrors:

claimable = _pendingYield[trancheId][user] +
            (yieldPerShare[trancheId] - _yieldCheckpoint[trancheId][user]) * _shares[trancheId][user]

The yield is paid out in the underlying asset (e.g., USDC), not in tranche tokens. This means yield claims are a standard ERC-20 transfer visible on-chain. The research evaluated Converter-mode eUSDC as one possible mitigation, but Meridian has not adopted it.

Privacy implication: An observer can see that a user received a USDC transfer from a ForgeVault and infer that it is a yield payment. The amount of the yield payment reveals information about the user's position size (larger position = larger yield). To mitigate this:

  • Yield claims could be batched (vault pays a batch of users in a single transaction via a claim aggregator)
  • Yield could be auto-reinvested into the tranche (the user's position grows without a visible outbound transfer)
  • Yield could be paid in an encrypted asset (eUSDC via Converter mode)

These were research options, not a scheduled implementation phase.

5.6 Secondary Market Transfers

When tranche tokens are transferred between users on the secondary market (e.g., via the SecondaryMarketRouter or direct transfer), the eERC privacy model provides:

  • Hidden transfer amounts: The number of tranche tokens transferred is encrypted inside the zk-proof. An observer sees that address A sent tokens to address B, but not how many.
  • Encrypted balances: Post-transfer, both the sender's and recipient's balances remain encrypted.
  • Mirror sync via hook: The onShareTransfer hook ensures the vault's plaintext mirrors stay in sync with the encrypted token balances.

The transfer flow under eERC:

  1. Sender's client generates a transfer proof (proving sufficient balance, correct ciphertext updates)
  2. Sender submits the transfer transaction to the EncryptedTrancheToken contract
  3. EncryptedTrancheToken verifies the proof, updates encrypted balances
  4. EncryptedTrancheToken calls _callTransferHook(from, to, amount) with the plaintext amount extracted from the proof
  5. ForgeVault's onShareTransfer receives the plaintext amount, settles yield for both parties, updates mirrors

SecondaryMarketRouter integration:

The SecondaryMarketRouter facilitates OTC-style trades of tranche tokens. Under eERC, the router would need to:

  • Coordinate proof generation between buyer and seller
  • Ensure the trade price (which may be negotiated off-chain) is not leaked on-chain
  • Handle atomic settlement: the buyer pays the underlying asset, the seller transfers encrypted tranche tokens

The router does not need to know the trade amount; it only needs to verify that the transfer completed successfully (which is guaranteed by the proof verification). The trade price can be settled via a separate payment channel or encrypted payment.

5.7 CDSPool Privacy Integration

Credit default swap positions carry significant information content. A large protection purchase against a specific reference entity signals negative credit expectations. If this information leaks, it can:

  • Trigger a self-fulfilling credit deterioration (market participants withdraw from the reference entity)
  • Enable front-running by other CDS market participants
  • Reveal an institution's credit risk assessment models

The CDSPool privacy integration is more complex than ForgeVault because CDS pools use an ERC4626-style share appreciation model rather than a mint/burn token model.

LP positions (protection sellers):

LP deposits could use eERC Converter mode: the LP deposits USDC into the pool, and the pool issues encrypted LP shares. The share appreciation mechanism (where totalAssets() increases as premiums accrue) operates on aggregate pool values that are already public (Zone 1), so privacy applies only to individual LP positions.

Protection buyer positions:

Protection positions are stored as ProtectionPosition structs inside the CDSPool contract:

struct ProtectionPosition {
    address buyer;
    uint256 notionalAmount;
    uint256 premiumRate;
    uint256 startTime;
    uint256 endTime;
    ...
}

These are Zone 2 data (contract-internal, private mappings). eERC does not directly apply to these positions because they are not token-based. To hide protection positions, the CDSPool would need to store encrypted notional amounts and use zk-proofs for premium calculations. This is a significantly more complex integration than the ForgeVault tranche token approach.

Research conclusion: LP-share encryption was the narrower tractable option. It is not part of Meridian's current production plan. Protection-position privacy would require custom ZK circuits beyond eERC's standard operations.

5.8 NexusHub Cross-Chain Privacy

NexusHub's cross-chain margin architecture introduces unique privacy challenges:

Collateral deposits on remote L1s: Users deposit collateral on remote NexusVaults (on Avalanche L1 subnets). These deposits could use eERC Converter mode on the remote L1, hiding individual deposit sizes while allowing the NexusVault to track aggregate collateral.

Cross-chain attestations via Teleporter: NexusVaults send balance attestation messages to the central NexusHub on C-Chain via Avalanche's Teleporter protocol. Currently, these attestations contain plaintext collateral values. Under eERC integration, attestations could contain encrypted values, but the NexusHub needs plaintext values to perform health checks and trigger liquidations.

Privacy-preserving cross-chain attestation model:

Option A: Attestations include both encrypted values (for privacy from other observers) and plaintext values encrypted under the NexusHub's auditor key. The Hub decrypts the attestation, performs health checks, and stores the encrypted version for external observers.

Option B: The remote NexusVault includes a zk-proof in the attestation proving that the collateral value exceeds the health threshold, without revealing the actual value. The Hub verifies the proof and only requests the plaintext value if the proof indicates unhealthy status (triggering liquidation). This is more complex but provides stronger privacy.

Research conclusion: Option A was simpler, while Option B required custom proofs. Neither is selected for production.

5.9 Yield Vault (ERC4626) Privacy Considerations

The YieldVault (ERC4626-style auto-compounding vault) and StrategyRouter present a different integration surface. ERC4626 vaults use a shares-to-assets ratio model where the share price increases as yield accrues. Privacy considerations:

  • Share balances: Can be encrypted using eERC Standalone mode (same as tranche tokens)
  • Share price: Is a public ratio (totalAssets / totalShares) that is Zone 1 data. Making share price private would prevent users from evaluating vault performance, which defeats the purpose.
  • Deposit/withdraw amounts: Hidden by eERC at the token layer, but inferable from the change in totalAssets (if only one deposit occurs in a block). Batching mitigates this.

Research conclusion: Standalone mode could hide share balances while leaving share price public. Meridian has not adopted this design.

6. Auditor Role Mapping

6.1 Auditor Taxonomy for Structured Credit

eERC's generic "auditor" concept must be mapped to specific institutional roles within Meridian's structured credit framework. Each role has different access needs and trust assumptions:

RoleWhat They Need to SeeTrust LeveleERC Mapping
Vault OriginatorCovered positions and transfers in its vaultHigh (created the vault)Access through the organization-controlled active auditor key or audit service
Protocol Risk TeamAggregate exposure and flagged transaction reviewHigh (protocol governance)Authorized view through the audit service; not a second onchain auditor key
Compliance OfficerCovered histories for compliance reviewHigh (regulatory mandate)Authorized view through the audit service; not a second onchain auditor key
Regulatory AuthorityRecords required by a lawful requestHighest (legal authority)Controlled disclosure from historical records; replacing the active key does not grant history
External AuditorRecords required for a defined audit periodMedium (contractual, time-bound)Controlled report or time-bounded access through the audit service
Counterparty (in OTC trades)Their own position and the counterparty's position (for settlement verification)Low (arm's length)Not an auditor; uses own private key to decrypt own balance

6.2 Registrar and Auditor Configuration

Each EncryptedERC token references a Registrar for user registration and public-key lookup. The active auditor address and key are configured separately on each EncryptedERC token contract.

Shared Registrar model (original research preference): Deploy a single Registrar instance that serves the relevant EncryptedERC tokens. This simplifies user registration and key lookup. Sharing the Registrar does not grant audit access across tokens because each token contract selects its own active auditor.

Per-vault Registrar model (alternative): Deploy a separate Registrar per vault only where registration domains themselves must be isolated. Auditor isolation should be enforced by configuring separate active auditor keys on the token contracts and by controlling the off-chain audit service.

6.3 Auditor Replacement and Historical Access

The token owner can call setAuditorPublicKey with another registered address. This replaces the active auditor for future operations. It is more precise to call this auditor replacement, not rotation of the encrypted history:

  1. Replacement: New private operations encrypt their auditor summary under the new active auditor key.
  2. Historical access: Existing records remain encrypted under the former key. The replacement auditor does not receive historical access automatically.
  3. Former auditor access: Replacing the key does not erase the former auditor's knowledge or prevent use of a retained old private key against historical records.

Forward secrecy gap: eERC does not provide forward secrecy by default. If an individual compliance officer leaves the organization, mitigation options include:

  • Contractual obligations (the departing officer is legally bound not to use the old key)
  • Key escrow (the organization holds the auditor private key, not the individual)
  • A separately designed migration or re-encryption process, which is not provided by the reviewed implementation

Research conclusion: A future deployment would need organization-controlled key custody rather than keys held by individual compliance officers.

6.4 Supporting Multiple Compliance Roles

The current contract does not provide multiple simultaneous auditor keys. Meridian's production design should keep the onchain key organization-controlled and expose role-based access through a separate compliance workbench. That service can give the originator, risk team, compliance officer, external auditor, or regulator only the records they are authorized to review while preserving a single cryptographic auditor identity onchain.

Where organizations require cryptographic separation rather than application-level access control, Meridian can use separate token deployments with different active auditors. Supporting multiple simultaneous auditor ciphertexts inside one token would require a custom extension and new cost, circuit, security, and operational review. It is not part of the current implementation plan.

7. Privacy Boundaries

7.1 What is Hidden vs. Visible

A precise enumeration of what eERC integration hides and what remains visible:

Hidden (encrypted or zero-knowledge proven):

DataHidden FromMechanism
Individual tranche token balancesPublic observers, other users, non-auditor protocol contractsElGamal encryption of balances
Transfer amounts (tranche tokens)Public observers, other userszk-SNARK proof; amount embedded in encrypted state transition
Mint amounts (on deposit)Public observerszk-SNARK proof for mint operation
Burn amounts (on withdraw)Public observerszk-SNARK proof for burn operation
Yield claim amounts (conditional research)Public observersWould require encrypted yield payment
LP position sizes in CDSPool (conditional research)Public observerseERC Converter mode for LP shares

Visible (public or inferable):

DataVisible ToReason
Vault total AUM (totalPoolDeposited)EveryoneZone 1 public data; needed for market evaluation
Tranche allocation percentagesEveryoneZone 1 public data; defines the vault structure
Pool status (Active/Impaired/Defaulted)EveryoneZone 1 public data; critical market information
Yield-per-share accumulatorsEveryoneZone 1 public data; defines current yield rates
Transaction senders and recipientsEveryoneEthereum address model; eERC hides amounts, not participants
Transaction timingEveryoneBlock timestamps are public
Function selector (invest/withdraw/claim)EveryoneEVM calldata; the operation type is visible even if amounts are hidden
Vault contract addressesEveryoneDeployed contracts are public
Protocol fee rate and treasury addressEveryoneZone 1 public data; governance transparency

7.2 Per-Role Visibility Matrix

Data PointPublic ObserverToken Holder (own data)Vault Originator (auditor)Protocol Risk Team (auditor)Regulator (auditor)
Own balanceN/ADecrypt with private keyDecrypt with auditor keyDecrypt with auditor keyDecrypt with auditor key
Other user's balanceNoNoDecrypt with auditor keyDecrypt with auditor keyDecrypt with auditor key
Transfer amountsNoOwn transfers onlyAll transfers in vaultAll transfersAll transfers
Vault total AUMYesYesYesYesYes
Pool statusYesYesYesYesYes
Yield ratesYesYesYesYesYes
Own yield claimsNo (future)YesYesYesYes

7.3 Metadata Leakage Analysis

Even with eERC's encryption, certain metadata remains observable and can be used for statistical analysis:

Transaction frequency analysis: An observer can track how often an address interacts with a specific vault. High-frequency interaction may indicate an active institutional participant. Mitigation: batching transactions, using relayers, or introducing random delays.

Gas cost correlation: Different position sizes may result in slightly different gas costs due to variable-length proof data or computational complexity. In practice, Groth16 proofs are constant-size, so gas cost variation is minimal and comes only from calldata differences (encrypted amounts of different magnitudes have the same ciphertext size in ElGamal).

Deposit/withdraw timing correlation: If a user deposits USDC into a vault and then the vault's totalPoolDeposited increases by the same amount in the same block, an observer can correlate the deposit amount with the USDC transfer amount (which is plaintext ERC-20). Mitigation:

  • Batched deposits (multiple users deposit in the same transaction via a deposit aggregator)
  • Deposit via eUSDC (conditional research option, not adopted)
  • Deposit through a privacy-preserving relay contract that breaks the direct correlation

Tranche selection leakage: When a user invests, the function call specifies the trancheId parameter (0=Senior, 1=Mezzanine, 2=Equity). This is visible in calldata. An observer knows which tranche a user chose, even though they don't know the amount. Mitigation:

  • Encode the tranche selection inside the zk-proof (requires a custom circuit that selects the tranche as a private input)
  • Accept the leakage as low-risk (knowing someone chose "Senior" without knowing the amount is minimal information)

Research conclusion: Any future review must treat tranche selection, timing, and deposit-amount correlation as remaining leakage. No mitigation rollout is currently planned.

7.4 Privacy-Preserving Analytics

Meridian separates the off-chain AI Analyst Workbench from the smaller set of onchain automation contracts. A private L1 protects data written to that chain by restricting infrastructure access. It does not, by itself, protect source documents, prompts, model inputs, generated analyses, or application databases used by the Workbench.

The Workbench should run in a private application environment with authenticated users, encrypted storage and transport, tenant-level access controls, retention rules, and audit logs. Sensitive source material and full model output should remain off-chain. Only an approved result, attestation, hash, or authorized transaction should be written to the private L1. Blockchain provides controlled execution, provenance, and tamper-evident records for that approved output; it is not the storage or privacy mechanism for the full analyst workspace.

Meridian's onchain AI layer (AIAnalyst, AIStrategyOptimizer, AIKeeper, AICreditEventDetector) currently operates on plaintext aggregate data. Under eERC, these contracts would need to continue functioning without decrypting individual positions.

The AI layer primarily operates on Zone 1 aggregate data:

  • Total pool deposits, yield rates, utilization ratios
  • Pool status transitions (credit events)
  • Bonding curve parameters (CDS pricing)
  • Cross-chain collateral attestations

None of these require individual position data. The AIAnalyst assesses aggregate pool health, not individual investor risk. The AIKeeper triggers waterfalls and liquidations based on aggregate thresholds. The AICreditEventDetector monitors oracle feeds for credit events, which are public market data.

Recommendation: Keep private documents and analysis inside the access-controlled Workbench. Feed the onchain automation layer only the aggregate inputs and approved outputs needed for a specific action. No eERC change is required for the Workbench itself because eERC protects token state, not application data.

8. Compliance Integration

8.1 InvestorRegistry and eERC Registrar Unification

Meridian's InvestorRegistry and eERC's Registrar serve complementary functions:

FunctionInvestorRegistryeERC Registrar
PurposeKYC/accreditation verificationBabyJubJub key registration
Registration dataVerified flag, jurisdiction, expiry, KYC providerBabyJubJub public key
Access controlVerifiers (KYC providers) add/remove investorsUsers self-register keys
ExpirationKYC verifications expire and must be renewedKeys persist until explicitly revoked

Unification approach:

The original research preferred a gated registration flow rather than merging the two contracts:

  1. User completes KYC through a Meridian-approved verifier
  2. Verifier calls InvestorRegistry.verifyInvestor(user, jurisdiction, expiry)
  3. User generates BabyJubJub keypair (client-side)
  4. User calls Registrar.register(publicKey) - this call is gated by a modifier that checks InvestorRegistry.isVerified(msg.sender)
  5. Both registrations are now linked: the user has KYC and a privacy key

Benefit: Only KYC'd users can register for privacy features. This prevents anonymous addresses from receiving encrypted tokens, which would undermine the compliance model. The Registrar's register() function is modified to include a require(investorRegistry.isVerified(msg.sender)) check.

8.2 TransferRestriction Module Adaptation

The existing TransferRestriction module enforces that both parties in a transfer are verified investors. Under eERC, this check continues to work identically because it operates on Ethereum addresses (which are visible in eERC transfers), not on token amounts (which are hidden).

The onlyVerifiedTransfer modifier checks:

require(
    from == address(0) ||  // minting
    to == address(0) ||    // burning
    exemptAddresses[from] ||
    exemptAddresses[to] ||
    (investorRegistry.isVerified(from) && investorRegistry.isVerified(to)),
    "TransferRestriction: unverified"
);

This check does not reference amounts or balances, only addresses, so the policy is compatible with eERC's encryption model. Enforcement still requires a purpose-built integration with the custom proof-bearing transfer path. EncryptedTrancheToken cannot simply inherit the existing ERC-20 transfer() and transferFrom() overrides.

8.3 KYC/AML Workflow with Privacy

The complete KYC/AML workflow for an institutional investor joining a Meridian vault with eERC privacy:

  1. Onboarding: Investor contacts Meridian or an approved KYC provider, submits identity documentation, completes accreditation verification.

  2. Registry entry: KYC provider calls InvestorRegistry.verifyInvestor(investorAddress, "US", expiryTimestamp).

  3. Key registration: Investor's client generates BabyJubJub keypair (derived from Ethereum wallet signature). Client calls Registrar.register(publicKey) (gated by KYC check).

  4. Vault investment: Investor calls ForgeVault.invest(trancheId, amount) with USDC approval. Vault mints encrypted tranche tokens.

  5. Ongoing compliance: The organization-controlled active auditor key decrypts covered transaction records created while that key is active. Authorized compliance staff review those records through the off-chain audit service.

  6. KYC expiration: When the investor's KYC expires (accreditationExpiry), they cannot transfer their tokens (TransferRestriction blocks it) but can still withdraw (burn is exempt from transfer restrictions). This incentivizes timely KYC renewal without freezing investor funds.

  7. Regulatory request: If a regulator requests covered data, authorized compliance staff decrypt the relevant historical records using the organizational key that covered that period and provide the required disclosure. Replacing the active auditor with the regulator would cover future operations only and would not grant historical access.

8.4 Jurisdictional Considerations

Different jurisdictions have different requirements for privacy and transparency:

US (SEC-regulated securities): If tranche tokens are classified as securities, Rule 144 transfer restrictions apply. The TransferRestriction module enforces holding periods and accreditation checks. eERC privacy is compatible because the SEC requires audit trail access (provided by the auditor infrastructure), not public transparency of individual positions.

EU (MiCA): MiCA requires "traceability" for competent authorities. eERC's auditor model satisfies this requirement. MiCA also requires disclosure of "material information" about crypto-assets, but this refers to asset-level disclosure (what the token represents, risks, etc.) not position-level disclosure (who holds how much).

GDPR considerations: Storing encrypted balances on a public blockchain raises GDPR questions about data subject rights (right to erasure, right of access). Encrypted data that cannot be decrypted by unauthorized parties arguably falls outside GDPR's definition of "personal data." However, if the data can be linked to an identified individual (e.g., through the Ethereum address + KYC records), it may still be personal data. The eERC model mitigates this by ensuring that the public blockchain contains only encrypted data, while the mapping between addresses and identities exists only in the KYC provider's records (off-chain).

9. Gas and Performance Analysis

9.1 zk-SNARK Verification Costs

The primary gas cost of eERC operations is zk-SNARK proof verification. On Avalanche:

OperationEstimated Gas (Groth16)Estimated Gas (Standard ERC-20 equivalent)Overhead
Transfer with proof~300,000 - 500,000~65,000~5-8x
Mint with proof~200,000 - 350,000~50,000~4-7x
Burn with proof~200,000 - 350,000~50,000~4-7x
Registration~100,000 (one-time)N/AN/A

The ecPairing precompile, available on Avalanche C-Chain (EIP-197), is the primary cost driver. A single Groth16 verification with N public inputs requires approximately 45,000 + N * 34,000 gas for the pairing operation, plus calldata costs for the proof and public inputs.

9.2 Avalanche Fee Model Advantages

Avalanche's fee model significantly reduces the practical cost of eERC operations compared to Ethereum:

  • Low base fees: Avalanche C-Chain base fees are typically 25-50 nAVAX (compared to 10-100+ gwei on Ethereum)
  • Fast finality: 1-2 second finality means proof-verified transactions confirm quickly
  • Subnet option: For very high-volume institutional use, Meridian could deploy on a dedicated Avalanche L1 subnet with custom gas parameters (lower fees, higher gas limits)

At current Avalanche C-Chain fees, a 500,000 gas eERC transfer costs approximately $0.01-0.05 USD. This is negligible for institutional transactions.

9.3 Batching and Optimization Strategies

Deposit batching: Multiple deposits can be aggregated into a single transaction via a DepositAggregator contract. The aggregator collects plaintext USDC deposits (via approve+transferFrom), then executes a single encrypted mint operation with a batch proof. This reduces per-user gas costs and, critically, prevents deposit amount correlation (multiple deposits with different amounts result in a single totalPoolDeposited change).

Proof aggregation (future): Recursive proof composition (proving multiple transfers in a single outer proof) could reduce per-transfer verification costs. This requires SNARK-recursion-friendly proof systems (e.g., Nova, folding schemes) and is a research direction for future eERC versions.

Calldata optimization: Compressed proof encoding (using point compression on BabyJubJub) can reduce calldata costs by approximately 40%. This is an optimization at the SDK level with no contract changes required.

9.4 Client-Side Proof Generation

Proof generation occurs entirely client-side. Performance characteristics:

DeviceProof Generation TimeAcceptable?
Modern desktop (M1/M2 Mac, recent Intel/AMD)2-3 secondsYes
Modern laptop3-5 secondsYes
Mobile (iPhone 15+, recent Android)5-15 secondsAcceptable with loading indicator
Older mobile (iPhone 12, mid-range Android)15-30 secondsMarginal; consider delegated proof generation

For institutional users operating through desktop interfaces, proof generation time is negligible. For mobile users, a progress indicator during proof generation provides acceptable UX.

Delegated proof generation: For users with constrained devices, a trusted backend can generate proofs on behalf of the user. The user provides their private key material (encrypted under the backend's key) and the backend generates the proof. This introduces a trust assumption (the backend sees plaintext values during proof generation) but may be acceptable for institutional users who already trust their institution's infrastructure.

10. Conditional Frontend and SDK Research

10.1 Privacy SDK Research

AvaCloud provides a TypeScript Privacy SDK for eERC operations. Meridian has not added it as a production dependency.

The current SDK is React-oriented and declares Wagmi and Viem peer dependencies. Alejandro's eERC Next.js frontend demonstrates a workable Next.js pattern using App Router client components, browser-side snarkjs.groth16.fullProve, and circuit artifacts served from /public/circuits. It is a reference implementation, not a plug-and-play Meridian integration.

If eERC passes the future decision gate, Meridian can adapt that integration shape after moving expensive proving work away from the main UI thread where practical, removing secret and circuit-input logging, clearing dependency and build checks, validating against the current EncryptedERC contracts and circuits, and testing registration, deposit, transfer, recovery, and failure flows.

@meridianprotocol/sdk
  └── @AvaCloud/privacy-sdk (eERC cryptographic operations)
        ├── Key generation and management
        ├── Proof generation (WASM-compiled Circom prover)
        ├── Encryption/decryption (BabyJubJub ElGamal)
        └── Registrar and EncryptedERC contract interaction

The Privacy SDK handles:

  • BabyJubJub keypair derivation from Ethereum wallet signatures
  • Proof generation for transfer, mint, and burn operations (WASM-compiled Circom prover runs in the browser)
  • Balance decryption (client-side, using the user's BabyJubJub private key)
  • Registrar interaction (registration, key lookup)

10.2 Client-Side Key Management

The BabyJubJub private key is derived from an Ethereum wallet signature on a deterministic message:

message = "Meridian Protocol eERC Key Derivation v1\nChain: 43113\nAddress: 0x..."
signature = wallet.signMessage(message)
babyJubJubPrivateKey = poseidonHash(signature)
babyJubJubPublicKey = privateKey * G  (BabyJubJub generator)

This approach means:

  • The BabyJubJub key is recoverable from the Ethereum wallet (no additional backup needed)
  • Hardware wallet users can derive the key securely (the signature stays in the secure element)
  • The key is deterministic and reproducible across devices (same wallet = same BabyJubJub key)

The derived key is cached in the browser's secure storage (localStorage encrypted with a session-derived key, or IndexedDB with CryptoKey API) for the duration of the session. It is never transmitted to any server.

10.3 Encrypted Balance Display

The frontend displays balances by:

  1. Fetching the user's encrypted balance from the EncryptedTrancheToken contract
  2. Decrypting client-side using the BabyJubJub private key (derived from wallet signature)
  3. Displaying the plaintext balance in the UI

For other users' balances (e.g., in a vault participant list), the UI shows "Encrypted" or a placeholder. The compliance dashboard reconstructs the covered records available to the organization-controlled auditor key; it does not assume unrestricted decryption of every balance at every point in time.

The Ponder indexer (used by Meridian's frontend) would index encrypted events without decrypting them. Decryption occurs exclusively in the browser, not in the indexer.

10.4 Transaction Construction Flow

The conditional research flow for an investment transaction was:

  1. User selects tranche (Senior/Mezzanine/Equity) and enters amount in the UI
  2. SDK checks InvestorRegistry.isVerified(user) - rejects if not KYC'd
  3. SDK checks Registrar.isRegistered(user) - prompts registration if needed
  4. SDK constructs the USDC approval transaction (standard ERC-20, plaintext)
  5. SDK constructs the ForgeVault.invest(trancheId, amount) transaction
  6. The encrypted token operation is constructed through the eERC SDK or an explicitly trusted proof service; the exact ForgeVault adapter remains future implementation work
  7. User signs and submits both transactions (approval + invest)

For transfers:

  1. User enters recipient address and amount
  2. SDK fetches recipient's BabyJubJub public key from Registrar
  3. SDK generates transfer proof client-side (2-5 seconds)
  4. SDK constructs the transfer transaction with proof calldata
  5. User signs and submits

11. Architecture Decision and Reconsideration Gate

11.1 Current Production Decision

Meridian's current production architecture is:

  1. Confirm an originator's private-book requirements, including validator membership, RPC and explorer access, transaction allowlists, KYC policy, auditor roles, and disclosure obligations.
  2. Provision a dedicated private Avalanche L1 through AvaCloud with restricted network and application access.
  3. Deploy Meridian's protocol contracts using standard ERC-20 assets.
  4. Keep the AI Analyst Workbench off-chain in an access-controlled application environment. Only approved outputs, hashes, attestations, or authorized transactions go to the L1.
  5. Complete security review and audit before production capital is admitted.

The dedicated private L1 has not yet been provisioned. eERC is not included in this production architecture.

11.2 Research Retained

The Phase 3 research remains valid evidence of work completed on Fuji:

  • eERC registrar and verifier infrastructure were exercised.
  • Browser-side proof generation and verification were tested.
  • Mock and adapter contracts explored Meridian integration boundaries.
  • Auditor replacement, historical-access limits, bounded composability, and frontend requirements were documented.

These artifacts are research references. They are not production dependencies, roadmap commitments, or proof that eERC is required for Meridian.

11.3 Reconsideration Criteria

Meridian will reconsider eERC only when a named deployment establishes a requirement to hide token balances or transfer amounts from parties who are otherwise authorized to read the chain.

Before adoption, that deployment must define:

  • the asset and exact confidential fields;
  • the readers who may access the chain but must not see those fields;
  • why standard ERC-20 plus private-L1 access controls is insufficient;
  • whether required workflows fit eERC's bounded operations;
  • auditor custody, replacement, historical access, recovery, and compromise handling;
  • frontend proof generation, circuit delivery, wallet behavior, and failure recovery;
  • adapter, protocol-composability, and security-review requirements.

Making an asset available on C-Chain does not by itself trigger eERC. A public representation may use a standard ERC-20. Token-level encryption is considered only if that public or private representation has a separately documented confidentiality requirement.

11.4 No Migration Plan

There is no eERC migration, dual-mode rollout, or SDK integration plan. If the reconsideration gate is met later, Meridian will produce a new implementation specification for that named deployment and validate it independently. The conditional designs in Sections 4 through 10 must not be read as the current architecture.

12. Security Considerations

12.1 Threat Model

Adversaries and their capabilities:

AdversaryCapabilityWhat eERC Protects Against
Competing institutionMonitors public blockchain, analyzes transaction patternsPosition sizes, strategy inference
MEV searcherFront-runs transactions based on pending mempool dataTransfer amounts (MEV based on amount is prevented; MEV based on existence of transfer is not)
Market manipulatorUses position data to manipulate credit marketsCannot determine large positions to target
Data aggregatorScrapes blockchain for portfolio analyticsEncrypted balances cannot be indexed
Former or compromised auditorHas historical auditor keyHistorical records under that key remain exposed; future operations use the replacement key

What eERC does NOT protect against:

  • Compromise of the user's Ethereum private key (attacker can derive BabyJubJub key and decrypt)
  • Compromise of an auditor's private key (attacker can decrypt the historical records covered by that key)
  • Side-channel attacks during proof generation (timing, power analysis on client devices)
  • Social engineering (user reveals their position off-chain)
  • Regulatory compulsion (legal authority demands decryption, which is the intended design)

12.2 Cryptographic Assumptions

The security of the eERC integration rests on:

  1. Discrete Logarithm Problem on BabyJubJub: ElGamal encryption is secure as long as the discrete logarithm problem is hard on the BabyJubJub curve. BabyJubJub has a ~254-bit group order, providing approximately 127 bits of security. This is considered adequate for the foreseeable future (excluding quantum computers).

  2. Knowledge of Exponent Assumption (KEA) for Groth16: The soundness of Groth16 proofs relies on the KEA assumption in the bilinear group model. This is a well-studied assumption with no known practical attacks.

  3. Trusted Setup Integrity: Groth16 requires a trusted setup ceremony. If the ceremony's toxic waste is not properly destroyed, the setup participant could forge proofs (creating tokens from nothing). The eERC protocol uses pre-generated ceremony artifacts from Ava Labs. For maximum security, Meridian could conduct its own ceremony for custom circuits.

  4. Poseidon Hash Collision Resistance: The Poseidon hash function is relatively new compared to SHA-256. Its security has been analyzed in several academic papers, and no practical attacks are known for the parameter sets used in eERC. However, it has less cryptanalytic history than established hash functions.

12.3 Smart Contract Risks

Proof verification bypass: If the Proof Verifier contract has a bug allowing invalid proofs to pass, an attacker could mint arbitrary tokens or transfer without sufficient balance. Mitigation: the Proof Verifier is a simple, auto-generated Groth16 verification contract with minimal attack surface. Independent audit recommended.

Plaintext mirror desync: If the plaintext mirrors in ForgeVault become desynchronized with the encrypted token balances (e.g., due to a hook failure that is not properly reverted), the waterfall distribution could allocate yield incorrectly. Mitigation: the EncryptedTrancheToken._callTransferHook() requires success (with require), ensuring the vault's mirrors are always updated when a transfer occurs. If the hook fails, the entire transfer reverts.

Registrar key squatting: An attacker could register a BabyJubJub key for an address they don't control, preventing the real owner from registering. Mitigation: registration requires a transaction from the address itself (msg.sender), and with the KYC gate, only verified addresses can register.

12.4 Operational Security

Auditor key storage: Auditor private keys must be stored with the same security posture as cold wallet keys. Recommended: hardware security module (HSM) or multi-party computation (MPC) key management for organizational auditor keys.

Proof generation infrastructure: If delegated proof generation is used, the proof generation server has access to plaintext values during computation. This server must be treated as a critical security boundary with appropriate access controls, logging, and monitoring.

Incident response: If an auditor key is compromised, the token owner should replace the active auditor key on every affected EncryptedERC contract. This protects future operations only. Historical data encrypted under the compromised key should be considered exposed, and the response plan must address notification and any applicable disclosure obligations.

13. Open Questions and Future Work

The following questions remain open and are flagged for future research and design work:

  1. Multi-sig BabyJubJub key management: How do institutional users with multi-sig Ethereum wallets derive and manage BabyJubJub keys? Options include threshold key derivation (t-of-n BabyJubJub keys derived from t-of-n Ethereum signatures) or centralized key management with internal access controls. Neither approach is fully satisfactory.

  2. Historical access after auditor replacement: Can historical encrypted data be re-encrypted under a replacement auditor key without requiring each user to re-submit proofs? This would require a re-encryption scheme (proxy re-encryption or similar) that is compatible with ElGamal on BabyJubJub.

  3. Zone 2 full protection: Plaintext mirrors in ForgeVault are accessible via eth_getStorageAt to anyone who can identify the storage slots. Full Zone 2 protection requires either (a) encrypting the storage values themselves (expensive, complex) or (b) deploying on a confidential execution subnet (e.g., an Avalanche L1 with TEE-enabled nodes). The cost-benefit analysis of each approach needs further evaluation.

  4. CDS protection position privacy: Hiding CDS protection buyer positions requires custom ZK circuits that prove premium calculations and settlement amounts without revealing notional values. This is a substantial research effort beyond eERC's standard circuits.

  5. Cross-chain encrypted attestations: The NexusHub cross-chain model with privacy-preserving attestations (Option B in Section 5.8) requires zk-proofs of collateral health that can be verified on C-Chain without revealing collateral values. This intersects with Avalanche's Teleporter protocol and may require Teleporter-aware proof circuits.

  6. Quantum resistance: ElGamal encryption is vulnerable to quantum attacks (Shor's algorithm can solve the discrete logarithm problem efficiently). Post-quantum migration paths for eERC are not yet defined. This is a long-term concern (5-10+ year horizon) but should be considered in the protocol's upgrade architecture.

  7. Proof generation UX on mobile: 5-15 second proof generation times on mobile devices may be unacceptable for high-frequency institutional trading desks. WebAssembly optimization, GPU-accelerated proving, and hardware-accelerated cryptographic coprocessors in modern mobile SoCs (Apple's Secure Enclave, Android's StrongBox) are potential optimization paths.

  8. Total supply privacy trade-offs: Standalone mode supports hidden total supply. For institutional credit vaults, hiding total AUM could prevent investors from evaluating the vault's scale and diversification. The decision to hide or reveal total supply should be configurable per vault and documented in the vault's offering materials.

  9. MEV protection for encrypted transactions: While transfer amounts are hidden, the existence of a pending encrypted transfer in the mempool is visible. MEV searchers could extract value from the ordering of encrypted transactions (e.g., sandwiching a large deposit by observing the USDC approval amount, which is plaintext). Mitigation requires either private mempools (Flashbots-style) or encrypted transaction ordering.

  10. Regulatory evolution: Privacy regulations are evolving rapidly. The EU's "Travel Rule" (FATF Recommendation 16) may require identifying information to accompany transfers above certain thresholds. eERC's auditor model can satisfy this if auditors have access to both the transfer data and the KYC records, but the implementation details depend on final regulatory guidance.

14. References

  1. ava-labs/EncryptedERC - Reference implementation of the eERC standard. GitHub: https://github.com/ava-labs/EncryptedERC

  2. AvaCloud eERC Announcement - "AvaCloud Unveils eERC: Revolutionizing Blockchain Privacy with Encrypted Confidential Transfers." https://www.avax.network/about/blog/avacloud-unveils-eerc-token-standard

  3. Technology Behind eERC - Avalanche Builder Hub Academy. https://build.avax.network/academy/encrypted-erc/03-encrypted-tokens/03-technology-behind

  4. eERC Contracts Flow - Step-by-step contract interaction documentation. https://build.avax.network/academy/encrypted-erc/05-eerc-contracts-flow/01-step-by-step

  5. ERC-20 vs eERC Comparison - Feature comparison matrix. https://build.avax.network/academy/blockchain/encrypted-erc/03-encrypted-tokens/02-comparison

  6. Groth16 - Jens Groth, "On the Size of Pairing-Based Non-interactive Arguments," EUROCRYPT 2016.

  7. BabyJubJub - Barry WhiteHat, Marta Bellés, Jordi Baylina, "Baby Jubjub Elliptic Curve," EIP-2494 (draft).

  8. ElGamal Encryption - Taher ElGamal, "A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, 1985.

  9. Poseidon Hash - Lorenzo Grassi et al., "Poseidon: A New Hash Function for Zero-Knowledge Proof Systems," USENIX Security 2021.

  10. Avalanche Interchain Messaging (ICM) - Avalanche documentation on Teleporter and cross-chain communication. https://docs.avax.network

  11. MiCA Regulation - Regulation (EU) 2023/1114 of the European Parliament and of the Council on markets in crypto-assets.

  12. FATF Recommendation 16 (Travel Rule) - Financial Action Task Force, "Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers," 2021.

  13. alejandro99so/eerc-frontend - Community Next.js 15 reference implementation for browser-side eERC registration, deposits, encrypted transfers, and Groth16 proof generation. https://github.com/alejandro99so/eerc-frontend

Archived Phase 3 research. This is not Meridian's current architecture, roadmap, or integration plan. Read the Private L1 Architecture Decision for the active decision. Questions and feedback should be directed to brooke@meridianprotocol.xyz.

Meridian Protocol · Archived Phase 3 eERC Research v1.2.1 · July 2026