How Veilnyx routes private capital into public ERC-4626 vaults, Morpho included, what stays hidden, and what your vault actually sees.
For vault curators Ethereum mainnet
01 / EXECUTIVE SUMMARY
Confidential yield for Morpho vaults. Veilnyx lets an institution allocate into a Morpho vault without publishing who it is, how much it moved, or when. The vault receives an ordinary ERC-20 deposit and behaves exactly as it does today. For the curator, it is additive AUM from a segment that cannot deposit on a transparent chain, with no integration work and no change to the risk model.
02 / THE PROBLEM
A public vault deposit is a public disclosure
A deposit into a public yield vault is visible the moment it lands. Allocate it into a Morpho vault today, and any observer can read the depositing wallet, the position size, and when it entered or exited.
Wallet attribution. Once a wallet is linked to an institution, its full vault history is permanently exposed.
Strategy leakage. Size, timing, and rotation between vaults reveal the allocation strategy and can be front-run.
Sensitive flow data. Deposit and withdrawal patterns expose the depositor and, for an allocator, its clients.
For a fund, treasury, or foundation deploying meaningful capital, this is disqualifying, not a preference. The capital stays in custody or moves through OTC desks and never enters the vault.
FIG. 1 A direct vault deposit publishes the depositor, size, timing, and strategy in a single transaction.
03 / THE SOLUTION
Institutions allocate privately; your vault sees an ordinary deposit
Veilnyx places a shielded pool between the depositor and your vault. The institution moves USDC or wETH into a private Veilnyx account and then allocates it to your Morpho vault. Your vault receives an ordinary ERC-20 deposit and issues shares to any depositor; the shares return to the private account and earn the same yield, while the client’s position stays encrypted in the pool. The institution can still prove its own position to an auditor, regulator, or LP on demand through Palliora’s selective de-anonymization, without disclosing anything to the market.
FIG. 2 The institution allocates through a shielded pool; the vault receives an ordinary deposit, and attribution stays private.
04 / WHAT YOU GET AS A CURATOR
These institutions avoid the transparency of depositing, not your vault’s terms. Veilnyx removes that barrier and leaves your vault, strategy, and risk model unchanged.
Additive AUM. New capital from a segment that cannot deposit on a transparent chain, not existing depositors restructuring.
Distributable compliance. Positions are private to the market but provable to auditors, regulators, and LPs, clearing an institutional review.
Zero lift. It works with your existing permissionless Morpho vault; there is nothing to build, deploy, or maintain, and the adaptor lives entirely on the Veilnyx side.
Fees and risk unchanged. Same asset, same vault, same strategy, same fee schedule; Veilnyx’s protocol fee sits separately.
05 / ARCHITECTURE
How the integration works
Assets enter Veilnyx as private notes, not a balance on an address. Allocation instructions are proven cryptographically, and the pool contract is the only party that touches your vault. Attribution never leaves the pool.
FIG. 3 End to end. The vault is integrated with no wrapper, no bridge and no new contract on the curator’s side.
Key characteristics
Same-asset guarantee. Native ERC-20s directly (USDC, USDT, wETH), with no wrapping or synthetic representation, so accounting, share price, oracles, and risk model are unchanged.
Direct integration. Any permissionless ERC-4626 vault, Morpho included, works out of the box; the adaptor lives entirely on the Veilnyx side.
No cross-chain dependency. The asset stays native on Ethereum. No bridge, wrapper issuer, or second chain in the trust base.
Under the hood: the note model
For an engineer assessing the trust base, the mechanism in one pass.
Notes, not balances. A note commitment is a Poseidon hash of three field elements: asset ID, owner, and value. The owner field is itself a Poseidon hash binding the holder’s root address, the revoker’s public key, and a per-note blinding factor, so two allocations of identical size produce entirely different commitments.
Commitment tree. Commitments accumulate in a Poseidon Merkle tree of depth 25, giving a capacity of 33,554,432 leaves. Insertion is queued and batched up to ten leaves at a time, and each batch is proved by a dedicated tree-update circuit rather than hashed on-chain.
Spend authorisation and nullifiers. Spending a note publishes a nullifier derived from the commitment, its tree path, the holder’s view private key, and the revoker’s public key. The view private key is a private circuit input, so an observer holding only public data cannot compute a nullifier or link it back to a commitment. Authorisation itself is a Schnorr signature verified inside the circuit against the same signing key that derives the note’s root address.
Proof system. Groth16 over BN254, circuits written in Circom, dispatched on-chain by a single verifier registry. Every transaction shape presents exactly twelve public inputs regardless of how many notes it consumes or creates, because variable-length encrypted fields are compressed inside the circuit by a universal hash function. A phase 2 ceremony has been completed, and the delta constants in all nine deployed verifiers match the committed ceremony manifest.
What reaches the chain. Nullifiers, output commitments, tree roots, and public asset amounts. Note contents travel as encrypted memos. Each transaction carries a fresh symmetric seed from which one key per note is derived by a Poseidon chain; a recipient receives only their own note key, never the seed. The single entry point is Pool.transact(ShieldedTransaction).
References: Veilnyx whitepaper · docs.veilnyx.com · SDK quickstart: docs.veilnyx.com/veilnyx-sdk/quickstart · Palliora architecture: docs.palliora.org/learn/architecture
06 / VISIBILITY
What is published, and what is not
What an external observer can and cannot see is the first thing a curator’s engineer checks:
| Data | State | Note |
|---|---|---|
| Depositor identity | Private | No transaction links a client to their allocation |
| Position size | Private | Held as an encrypted note value |
| Entry and exit timing | Private | Not attributable to an account |
| Allocation across strategies | Private | Rotation happens inside the pool |
| Link between deposit and withdrawal | Private | Broken by the note model |
| The pool interacted with the vault | Public | An ordinary ERC-20 transfer |
| Aggregate amount in a transaction | Public | Not attributable to a client |
The market sees that the Veilnyx pool deposited into the vault, not which client it belongs to.
07 / COMPLIANCE
Selective de-anonymization, powered by Palliora
Strong on-chain privacy has failed institutional review from both sides: pure anonymity is sanctioned, and voluntary disclosure is toothless because the actors a regulator cares about will not cooperate.
Veilnyx is powered by Palliora, whose selective de-anonymization (SeDe) provides threshold disclosure at the protocol layer:
Voluntary proof. An honest client can prove its own position and history to an auditor, regulator, or LP on demand without disclosing anything to the market. Honest users are never required to prove innocence.
Involuntary tracing. Flagged illicit funds can be traced without the holder’s cooperation, but only when a quorum of independent guardians authorises it and a separate revoker, the only party able to decrypt, acts on a publicly recorded request.
No unilateral disclosure. No single party, not a guardian, the revoker, a counterparty, or Veilnyx, can unmask a position alone. Requests are lawful (for example, a court order), recorded on-chain, and limited to the illicit subgraph.
Sanctions screening runs at the boundary as funds enter the system.
Under the hood: how disclosure is authorised
Threshold disclosure is created when the transaction is proved, not retrofitted afterward.
Two independent halves. Decryption requires both a threshold contribution from the guardian set and the revoker secret. Neither half decrypts alone. The per-transaction seed that unlocks a transaction’s notes is ElGamal-encrypted to the revoker key at proof time, and the circuit constrains that ciphertext, so a transaction that omits it cannot be produced in the first place.
Guardian key material. Guardian keys come from distributed key generation with Feldman verifiable secret sharing. The threshold is the degree of the sharing polynomial and is carried in the shares themselves, not in the public key and not in a configuration flag. The group public key is fixed by the underlying secret, so the guardian set and the threshold can both change while the encryption key stays constant and previously encrypted notes remain decryptable.
Rotation with teeth. A reshare does not invalidate old shares by itself, because share destruction cannot be forced cryptographically. Activation of a new epoch is therefore gated on a quorum of the retiring nodes signing an attestation that they wiped the old share and authorised against the retired epoch and the retired set. Raising a threshold takes effect only once that quorum is reached. Compromise at or above the threshold inside a single epoch is not covered by refresh and requires a re-key into a new group with a new public key.
Requests are on the record. A registered revoker opens a request through the request manager contract, which requires a registered application namespace and an active guardian group, and emits an event carrying the request ID, group, namespace, and metadata. The guardian response and threshold combination then run off-chain against that on-chain record.
Set and threshold. The live guardian set operates at a 7 out of 10 threshold. Membership is registered on-chain and is currently operator-managed. The design guidance is to size the threshold so that a realistic single incident stays below it.
Screening. Sanctions screening is enforced on-chain by the pool against a screener contract, and it is blocking rather than advisory: a flagged address reverts the transaction.
References: Selective De-Anonymization (SeDe) technical paper: veilnyx.com/sede.pdf · Compliance: docs.veilnyx.com/veilnyx-overview/compliance · Palliora architecture: docs.palliora.org/learn/architecture
08 / LIQUIDITY
One vault, not two
Because Veilnyx deposits the native asset directly, confidential capital lands in the same vault as public capital: one pool, one share price, one TVL figure. Wrapping the asset into a confidential token standard instead requires a parallel vault that splits depth across two pools.
FIG. 5 Confidential deposits do not fragment the vault. Same asset, same share price, same TVL.
Under the hood: the vault adaptor
One contract, one external function, no per-user state, and nothing deployed on the curator’s side.
Interface. The adaptor exposes a single external function, handleAssets, taking exactly one input asset and one payload. The payload carries the action and the vault address, so the target vault is selected per call, and no contract is deployed per vault. The vault interface it consumes is a five-function subset of ERC-4626: deposit, redeem, asset, convertToShares, and convertToAssets.
Deposit path. In order: decode payload → resolve input asset → reject zero value → require input token == vault.asset() → require adaptor balance covers it → forceApprove the vault for exactly that amount → deposit(value, adaptor). The share count the vault returns becomes the value of a new private note denominated in the vault’s share token.
Redeem path. The input must be the share token, then forceApprove → redeem(shares, adaptor, adaptor). Redemption is by share count rather than by asset amount.
Custody and yield. Shares are held by the adaptor and represented to the client as an encrypted note in the share asset. The adaptor holds no storage and performs no per-user accounting, so yield accrues purely through the vault’s share price, exactly as it does for a public depositor.
Execution and failure. There is no batching in this path: each allocation executes inside the single shielded transaction that triggered it. There is no try/catch either, so a paused vault or short redemption liquidity bubbles up and reverts the entire shielded transaction, leaving no partial state on either side.
Enablement. Adaptors are enabled on the pool by an owner-only call, and a vault’s share token must be registered as a Veilnyx asset before it can be a valid output. That registration is what constrains the set of reachable vaults.
What the adaptor does not do. It passes no minimum output, deadline, or slippage bound and implements no first-depositor mitigation of its own; it accepts the share count the vault returns.
References: Veilnyx documentation: docs.veilnyx.com · Veilnyx whitepaper · Adaptor interface reference
Further reading: Selective De-Anonymization (SeDe): technical paper · Veilnyx documentation