Back to selected work

NoxChain. Private asset settlement on an existing blockchain stack

Dmitry Sergeev·11 min read

Category:Infrastructure

Project status:Discontinued by client

Tags:
  • ZK Stack
  • Shielded assets
  • Compliance
  • Selective disclosure
  • Noir
  • Ethereum exit

Our work

We developed the shielded asset ledger and institutional controls for NoxChain on ZK Stack. The custom work covered private eligibility checks, role-specific disclosure, holder recovery and an Ethereum exit path supported by public reconstruction data.

An institutional ledger needs to verify ownership and transfer eligibility without publishing client positions. Moving the same records onto a permissioned network does not solve that problem if the operator can still read every transaction. NoxChain separates execution from access to financial data. It uses ZK Stack for the chain and adds a shielded asset ledger, wallet-held credentials, role-specific disclosure and an Ethereum exit path.

The engineering scope follows that separation. Execution, sequencing and chain validity proofs come from an existing stack. The custom work addresses what an institutional asset network needs beyond it: private compliance checks, a usable holder register, controlled recovery and enough public state to leave without the operator. We integrated those functions around the same asset and control records. A confidential transfer is insufficient if its eligibility cannot be checked, and a valid ledger is insufficient if holders cannot recover their claims when its operator stops.

Choosing the base narrowed the work to the missing layer

NoxChain is a dedicated ZK Stack deployment, not a blockchain implementation written from scratch. The architecture retains the EVM execution environment, sequencing stack, state tree, batch prover, Ethereum proof verification and external node software. Releases are pinned and reviewed before adoption. NoxChain supplies its own ecosystem deployment, admission controls, split data-availability validators, paymaster and cash escrow integration around those components.

The choice preserves an existing execution and settlement path while leaving application privacy to the shielded layer. A restricted RPC endpoint uses mutual TLS and method-level authorisation. Registered accounts receive sponsored gas, avoiding a separate participant-funded gas account that could create additional links. Custom ecosystem contracts place upgrades under NoxChain governance, at the cost of deferring native interoperability with other ZK Stack chains. These are integration decisions rather than a rewrite of consensus or EVM execution.

The privacy and proving layers draw from different projects because no single base supplies all the required controls.

SourceReusedBoundary
ZK StackChain and settlementCustom integrations
ZcashNotes and asset modelAdapted nullifiers
Aztec toolingNoir and UltraHonkCustom circuits
MoneroAddresses and view tagsNo chain fork

The note design draws on Orchard and Zcash Shielded Assets, while Noir and Barretenberg provide circuit compilation, recursive proving and UltraHonk verification. NoxChain does not inherit Zcash's node or consensus, and it does not fork the Aztec network. Monero was considered as a base but did not match the required multi-asset issuance, programmable eligibility and mandatory disclosure model. Its one-time-address and view-tag ideas remain useful at the wallet and scanning layers. Reusing these components reduces the scope of new infrastructure, but the combined circuits and integrations still require their own review.

Transfers prove compliance without publishing credentials

An on-chain identity registry can become a durable link between a person and their portfolio. NoxChain keeps the credential in the holder's wallet. A KYC provider checks the person or entity and signs a bounded attribute vector covering classifications such as residency, investor category, screening status and expiry. Identity documents remain in the provider's records. Issuance does not publish the credential or create a public account-to-person entry.

Each asset defines its transfer rules in NoxPolicy, a restricted declarative language. A deterministic compiler maps those rules to Noir templates, with the policy source, compiler version and verification-key hash registered for review. An independent reference evaluator checks that compiled policies make the intended decisions. This makes the eligibility rule reproducible rather than leaving it in operator middleware. Credential reuse is conditional: the same credential works across assets whose policies accept its issuer and attributes, not automatically across every issuer.

The transfer proof covers both parties' eligibility. The sender does so inside its transfer-leg proof, while the recipient prepares a receive ticket bound to a one-time address, an amount limit and a short validity window. The sender's circuit verifies that ticket recursively. Policy verification also occurs inside the leg proof, using the registered policy key as a private input. The operator therefore verifies a common outer circuit without learning which asset-specific policy was evaluated.

Expiry and revocation remain active constraints. The revocation-root check uses a 15-minute validity bound. A ticket cannot extend acceptance beyond its permitted root window. Issuer-key removal follows a shorter control-state window, invalidating credentials under the removed epoch. These checks make compliance part of a valid state transition, while the truth of the original KYC assessment remains the credential issuer's responsibility.

Privacy needs uniform transactions as well as encryption

Different transaction shapes can reveal business activity even when their fields are encrypted. NoxChain uses bundles with exactly two legs, each spending two notes and creating two notes. Unused slots contain zero-value dummy notes and ciphertexts have fixed sizes. A cash-for-security trade and a simple transfer therefore share the same outer structure. The operator sees commitments, nullifiers, proof inputs and submission timing rather than plaintext holdings or transfer amounts.

For delivery versus payment, buyer and seller prove separate legs and check the outputs addressed to them. Both sign a common bundle digest. The block circuit applies the complete bundle or neither leg, preventing one side from receiving the asset while withholding payment. A short expiry limits how long a party can retain a signed trade before submitting it. The venue and counterparties still know the terms they negotiated; confidentiality concerns disclosure beyond that necessary relationship.

Public-boundary movements remain visible. Deposits, withdrawals, issuance totals and exits have public information needed for settlement or supply checks. Member submission timing also remains observable. The architecture's operator-blind claim applies to the contents of shielded transfers, not to every possible inference about network activity. Uniform structures reduce one class of leakage without erasing those boundaries.

Per-note keys enable recovery without seller tracking

We separated the registrar's recovery authority from the secrets used to follow and spend a note. NoxChain adapts nullifier derivation around a per-note key. The recipient derives that key from its own key material and fresh salt, then supplies the sender with only a commitment through the receive ticket. The sender can create the agreed output without obtaining the value needed to calculate its future nullifier.

For registered assets, the ticket encrypts the per-note key to the registrar. The registrar can therefore identify and act on the note within its own register. Knowledge of that key does not permit an ordinary owner-authorised spend. A forced replacement uses a separate SUPERSEDE proof path requiring registrar authorisation and a recorded order. Court-ordered transfer, inheritance and lost-key recovery are integrated into the asset lifecycle rather than implemented through an unrestricted operator key.

Holder freezes use an asset-scoped tag that covers the holder's notes without publishing their identity. A supersede order identifies the target notes, freezes the relevant position and applies its notice period unless immediate effect is required. The replacement note goes to a recipient with a valid ticket. Existing nullifiers prevent a previously spent note from being superseded again. Registrar access remains powerful, but it is scoped to the asset and the defined control path rather than shared with the ledger operator.

Disclosure records are mandatory, access is role-specific

Transfer acceptance includes the encrypted-record checks for the designated registrar and supervisory channel. The circuit proves that these ciphertexts contain the actual note and transfer information. A sender cannot submit a valid leg while omitting the record or encrypting an unrelated amount. Grumpkin ECDH and Poseidon2-based encryption are included in the circuit so that record construction is checked alongside ownership, value conservation and policy compliance.

The registrar channel exposes the information required for that asset's register. It does not give the registrar a decryption key for other issuers' assets. The audit channel uses a separate committee key created through distributed key generation. Decryption requires three of five members, with proofs of correct partial decryption. Members send encrypted shares to the requesting authority, which combines them. A single committee member cannot read the audit record from its own share.

Operational access is tied to an approved request in the Disclosure Registry. Requests identify a scope, authority and legal-basis commitment, and nodes check request state before releasing shares. A subject-scoped request first opens the relevant trace-key escrow, then identifies matching legs in the authorised date range before requesting their decryptions. Filing initially publishes a commitment because investigations may be confidential. The record opens after the bounded confidentiality period, while aggregate request counts are published earlier.

The threshold and the logging process have different guarantees. Cryptography prevents one or two members from decrypting alone. The protocol's node controls require approved, recorded requests, but three colluding key holders could decrypt outside that process. Independent committee membership and controlled key handling are therefore material trust assumptions. Similarly, once an authority receives plaintext or a trace key, the ledger cannot make it forget that information. Accountable disclosure limits the supported access path without pretending to eliminate recipient misuse.

Ethereum anchors validity without readable portfolios

Client proofs first feed the shielded block prover, which aggregates them into an UltraHonk proof. ShieldedPool verifies that proof on NoxChain and updates the note, nullifier and control roots. ZK Stack then proves the chain's execution, including that verification, and settles the containing batch on Ethereum. This is a two-layer verification path. It does not mean Ethereum computes every client's private proof or that an operator admission receipt is already Ethereum-final.

The state log carries the roots, supply vector and data-segment commitments into the Ethereum settlement path. Public data availability includes ordered note commitments, nullifier leaves, registry data, supply information and timestamps. The private segment holds EVM state diffs and encrypted recipient, registrar and audit payloads. It is therefore more precise to describe the public segment as reconstruction data without plaintext portfolios than to say that Ethereum receives only hashes.

A custom validator pair checks the public blob commitments and a five-of-seven consortium availability certificate for the private segment. The split keeps ciphertext archives off the public network while making tree reconstruction independent of the operator's database. Wallets fetch whole block ranges and compute their own note paths, avoiding note-specific lookup requests that would disclose ownership to a server. Public-history archivers remain necessary after Ethereum's blob retention period, with each retrieved copy checked against its Ethereum commitment.

Supply checks need no individual balance disclosure

Each shielded block updates per-asset supply using public issuance, burn and boundary deltas. For bridged cash, an observer can compare proven supply and pending withdrawals with the corresponding Ethereum CashEscrow balance. Securities use registrar-signed outstanding figures, and a mismatch places the asset into a guarded state that stops new issuance. Registrars can additionally reconcile their decrypted registers against supply.

These checks expose inconsistencies without publishing each holder's balance. They also distinguish reserve types. An Ethereum escrow balance is directly observable, whereas a native bank-deposit token still depends on the bank's signed accounting information. Supply limits and reserve checks provide additional controls, but they do not replace circuit soundness or prove that every off-chain issuer obligation is truthful. These checks rely on the custom conservation and encryption constraints; soundness of those circuits remains part of the trust model.

Public reconstruction data supports holder exits

A private state database controlled entirely by the operator would make exit dependent on its cooperation. NoxChain instead lets holders reconstruct tree paths from public history and combine them with note openings already held in their wallets. This requirement explains the split data-availability design. Publishing proofs alone would not provide the witness material needed to establish ownership and non-spending during an exit.

A censored holder can submit a valid bundle to ForcedInbox on Ethereum. The forced-inclusion rule gives the operator seven days to include it or provide the permitted proof that a nullifier was already spent. An uncleared deadline, or 14 days without a newly executed batch, allows Exodus to be triggered. Exit proofs then reference the last shielded roots proven on Ethereum, and consumed nullifiers prevent duplicate exits. The forced path uses Ethereum-anchored control state, so recently applied controls that have not reached that anchor create a documented timing gap.

The exit outcome depends on the asset. Bridged cash is paid from CashEscrow. Securities and native cash tokens produce records in ExodusRegister, which the asset terms designate as the fallback register. That records the holder's claim; it does not turn a bond or bank liability into immediately available Ethereum cash. Holders also need their note openings, spend authorisation and an available, verified copy of public history. Exit reveals the asset, amount and Ethereum destination, and does not cover arbitrary EVM contract balances awaiting other workflows.

The custom components connect privacy to recoverable ownership

We integrated policy evaluation, encrypted transfer records and holder recovery around the shielded ledger. Registered policy keys identify the rules applied to a transfer. Ciphertext commitments bind the disclosure record to the circuit statement, while control records and nullifiers govern supersede operations.

Public reconstruction data connects the shielded roots to the Ethereum exit path. Admission, shielded inclusion and Ethereum settlement remain separate stages, so an interface acknowledgement does not stand in for an anchored exit claim. Forced inclusion and Exodus use the public record when the operator is unavailable, subject to the asset and control-state boundaries described above.

NoxChain combines an existing chain stack with private eligibility checks, role-specific disclosure and holder recovery. The contracts, circuits and public data split keep those functions connected through the asset lifecycle.

See our architecture in practice.

DEVLAB · ARCHITECTURE EXAMPLE

Agent
Commerce

A look inside the software architecture behind Agent Commerce.

View architecture
Agent Commerce — Software Architecture, designed by Dmitry Sergeev