Toward shielded
transfers.

01 Abstract & position

A public token exposes a transaction graph. A hidden mascot, a new address or a gas sponsor does not change that fact. Our hypothesis is narrower and testable: an optional, non-custodial shielded balance system could reduce the public linkability of NULLCAT transfers while retaining an ordinary token for public wallets and applications.

We propose to test a note-based pool on Arc testnet, compare it against a public-transfer baseline and a stealth-address baseline, and measure both practical leakage and device performance. Deposits and withdrawals would remain public boundary events. A dedicated NULLCAT pool would also reveal which asset it serves. The intended protection concerns the relationships and amounts of transfers inside the pool, subject to a stated threat model.

Our preferred decision order is integrate a suitable established system, then consider a narrowly scoped local pool, and only then consider migration. A system on another chain is a separate cross-chain design, not a shortcut to native support. If the privacy set is too small, wallets cannot recover notes reliably, or costs are unacceptable, the correct result may be to postpone the feature.

The research objective is measurable privacy with explicit limits. “Total anonymity” is not a deliverable.

02 Research question

Can users transfer a token through an optional shielded layer without publicly exposing the internal sender–recipient relationship, while keeping proof generation, recovery and exits usable on ordinary devices?

We split this into three hypotheses. H1: a verifier and token adapter can enforce conservation and prevent double spends on the target chain. H2: a wallet can generate proofs and reconstruct balances locally without disclosing spending secrets to an RPC or indexer. H3: the resulting public transcript leaves materially more uncertainty than ordinary transfers under explicitly modelled traffic patterns. Passing H1 alone would not establish H2 or H3.

The first prototype would support one conventional ERC-20 and a small fixed transaction shape. Private swaps, arbitrary DeFi calls, cross-chain private payments and private governance are outside its initial scope. We would use a mock asset with no monetary value before integrating any actual NULLCAT contract. This isolates cryptographic and accounting questions from launch economics.

03 Arc compatibility

DOCUMENTED Arc is an EVM-compatible Layer-1 network with Reth execution and Malachite BFT consensus across a permissioned validator set. Its documented configuration lists mainnet chain ID 5042, testnet 5042002, and USDC for gas. These are platform capabilities, not evidence of a NULLCAT privacy deployment. [1] [2]

We would pin the chain configuration, compiler, circuits, SDK versions and verifier bytecode; run known-answer tests against the intended precompiles; and measure valid and invalid proofs on testnet. Ethereum's pairing precompile and gas schedule provide a reference, not a verified Arc execution cost. [3] [4]

Arc's native USDC interface uses 18 decimals while its ERC-20 interface uses 6, sharing one balance. The adapter must never count them as different assets or mix raw units. Native-value transfers involving blocklisted addresses can revert; PREVRANDAO is zero and must not generate note secrets. These constraints affect accounting, fee sponsorship and exit availability. [5]

Fees are denominated in USDC. We would measure proof and payload costs directly, including failed calls. Arc describes deterministic finality; the wallet should anchor accepted roots to finalized blocks and detect conflicting RPC responses rather than inherit assumptions about Ethereum L2 sequencer confirmations. A shielded-pool withdrawal is separate from a cross-chain bridge transfer. [6] [7]

NOT YET AVAILABLE Arc Privacy Sector (APS) is still described as a roadmap feature. A public token launched on Arc does not become confidential through its network choice. APS and a zero-knowledge note pool require separate threat models and separate experiments. [18]

We have not established a working NULLCAT verifier, shielded-wallet integration or broadcaster deployment on Arc. Initial NULLCAT transfers would remain public. The first implementation target is a mock ERC-20 on Arc testnet.

04 Threat model & visibility

The initial adversary is a passive observer of public chain data who also knows some deposits, withdrawals or counterparties. We then add an untrusted RPC, a curious broadcaster, a malicious participant and a censoring or unavailable service. A compromised device, stolen recovery material or an adversary observing all network endpoints is outside the protection we would claim for the first prototype.

Encryption does not hide a public event's existence. An empty or nearly empty pool offers little plausible ambiguity. We would make these limits visible in the wallet before a user shields, rather than hide them behind a binary “private” badge.

05 Protocol candidates

The following is an evaluation order, not a list of partnerships. No third-party project cited here has endorsed NULLCAT.

A. Integrate an established EVM shielded system

RAILGUN is a concrete reference for encrypted notes, private transfers and broadcaster-mediated submission. Its documentation separates a public EVM wallet from the private wallet layer. Its deployment links list other networks; we did not confirm a Arc deployment in those materials. A deployment on another EVM chain is not evidence of a maintained Arc deployment. [8] [9] [10]

We would first verify maintained deployments, licences, audits for the exact release, SDK portability, private-address recovery and broadcaster coverage. Reuse may reduce custom circuit work, but an audit of upstream code does not certify our adapter, frontend or deployment. Porting without maintained infrastructure may be less safe than waiting.

B. Test a minimal native pool

This is our experimental fallback: a purpose-limited contract suite with a verifier, a note commitment tree, a spent-nullifier set and a token adapter. We would study the separation of notes, nullifiers and viewing authority in Zcash's Orchard specification, without describing a simplified EVM prototype as Orchard or inheriting its security claims. Orchard is a protocol reference, not a drop-in ERC-20 library. [11]

A Groth16-style circuit is a candidate for the first verifier benchmark because it has a compact pairing-based verification structure. Its preprocessing and parameter-generation requirements become explicit trust assumptions; a production deployment would require a reviewed setup process and pinned verification keys. We have not selected a final proof system. [12]

C. Use stealth addresses as a comparison

ERC-5564 standardizes non-interactive stealth-address generation, with a separate meta-address registry described by ERC-6538. This can reduce the public association between a recipient and successive receiving addresses. Ordinary token amounts and transfers are still public, and funding an address for gas can introduce links. We would test it as a narrower baseline, not label it shielded transfers. [13] [14]

D. Study Arc Privacy Sector as a separate future route

Arc describes APS as a confidential Solidity execution environment alongside the public EVM. Its proposed design encrypts transaction payloads for execution inside validator hardware enclaves, with controlled access to private state and synchronous composition with public contracts. The documentation explicitly says it is not yet available. [18]

We would evaluate enclave attestation, key custody and rotation, operator compromise, access-policy administration, recovery and public/private boundary leakage. This trust model is different from proving a hidden state transition locally. APS would be an alternative experiment if released and independently reviewed; it is not an assumed dependency or a shortcut to total anonymity. We would first test a mock asset and compare its leakage against the same public and shielded baselines.

E. Evaluate a separate privacy execution environment

Aztec provides a reference for client-side private execution and note-based private state. Its documentation describes a distinct, non-EVM execution environment. Moving a NULLCAT representation there would introduce separate wallet, bridge, liquidity and security assumptions; it would not make transfers on Arc natively private. [15] [16]

We would revisit this route only if native integration fails a documented requirement and the added cross-chain risks can be justified. No bridge is selected or promised.

06 Proposed architecture

DESIGN HYPOTHESIS The smallest useful experiment separates a public token balance from private notes. The pool holds the deposited tokens; users hold the secrets needed to spend their corresponding notes. There is no ordinary public ERC-20 balance for each note owner inside the pool.

Notes, proofs and state transitions

A note would bind an asset identifier, a bounded value, ownership data, fresh secret randomness and a protocol domain into a hiding commitment. The domain would distinguish chain, pool and protocol version. A keyed nullifier derived under the selected scheme would reveal that a note has been spent without publicly opening its commitment. These are design requirements; their exact encodings and security arguments remain to be specified.

For an initial two-input, two-output transaction shape, the circuit would prove ownership authorization, inclusion under an accepted root, correct nullifier derivation, valid output commitments and bounded non-negative amounts. Padding and dummy inputs require explicit constraints; a zero-value note must not become a shortcut around membership or ownership checks. Public amounts use token base units, never floating-point numbers.

The contract separately checks root acceptance, unused nullifiers and proof validity, then updates state atomically with the token transfer. The proof statement must bind every value a relayer could otherwise alter: destination, asset, fee, outputs, chain, pool, expiry and encrypted payload commitment where applicable. Range checks, replay protection, ciphertext integrity and correct note delivery are part of the specification, not consequences of using a SNARK.

We would reject fee-on-transfer, rebasing and callback-dependent assets in the first experiment. Unexpected balance deltas must revert. Deposit caps and accounting monitors can limit exposure, but cannot repair an unsound circuit. A circuit bug can create liabilities that the public pool balance cannot back.

Submission and retrieval

Proof generation and note decryption would run locally. A broadcaster could submit a proof without receiving the spending witness. Its identity, fees and timing would still be observable, and it may learn network metadata or refuse service. We would compare at least two independent submission paths. A direct-send fallback could preserve liveness while weakening sender privacy; the wallet must explain that trade-off before using it.

An indexer would serve public commitments, encrypted notes and proofs of membership. The client must verify results against chain roots, reject missing or inconsistent data and support a full rescan. A membership witness request can itself reveal a note index, so a production design needs a reviewed retrieval strategy. Outsourcing secret inputs to an ordinary proof server is not equivalent to local proving.

07 Wallet support & recovery

Arc documents setup for MetaMask, Rabby, Coinbase Wallet and Rainbow. An EVM wallet can sign public transactions, but that does not establish support for NULLCAT shielded notes or private-balance recovery. Native USDC display and decimal handling also need wallet-specific testing. [17]

We would initially treat an EVM wallet as the signer for public approvals and deposits, with a separate, explicit private-wallet interface for note management. Reconnecting a public account must never misleadingly imply that a private balance has been restored. A wallet connection protocol transports requests; it does not implement the shielded protocol.

The private component needs spending authority, incoming viewing authority, encrypted local backups, a reviewed key derivation scheme and a clear recovery ceremony. Arbitrary wallet signatures are not automatically a safe source of private-wallet keys. We would test a fresh-device restore, indexer loss, interrupted sync, malformed notes and recovery after interrupted synchronization or conflicting RPC responses. Lost spending material may make notes unspendable; a viewing key does not restore spending authority.

Our target matrix includes desktop Chromium and Firefox, macOS Safari, iOS Safari and Android Chrome, plus selected external-wallet and hardware-wallet flows. None is marked supported yet. We would measure cold proof generation, memory pressure, background-tab suspension and proof retries. If a mobile device cannot prove within the agreed budget, we would offer an honest unsupported state or a reviewed local companion path, not silently upload secrets.

08 Experimental programme

Every row below is planned and unmeasured. These are proposed acceptance criteria for a research prototype, not published results or promised performance.

Each experiment must publish a manifest: code commits, circuit and parameter hashes, device specifications, compiler versions, chain ID, block range, test seeds and raw measurements. Privacy experiments would initially use generated traces and consented test participants. We would not publish real users' financial histories as a benchmark dataset.

09 Measuring privacy without pretending

We propose to report an observer's best linking success, posterior concentration and uncertainty, not just the number of deposited notes. Ten thousand notes controlled by one actor are not ten thousand independent people. Total value locked is an activity indicator, not an anonymity certificate.

For a clearly specified observer model, we would calculate Shannon entropy H = −Σ pᵢ log₂ pᵢ over candidate links and the effective candidate count 2ᴴ. As a purely illustrative example, four equally plausible candidates give two bits of uncertainty and an effective count of four. If one candidate has probability 1, uncertainty is zero even if a dashboard still displays four deposits. No such model has been fitted to NULLCAT activity.

Experiments would vary transaction shapes, public fee choices, timing correlations and service visibility, then report the latency and cost of any mitigation. We would also test whether fixed transaction shapes reduce one signal while making the small pool easier to recognize. A favorable result against one observer does not imply protection against all observers.

The desired output is a leakage report with assumptions, counterexamples and failure cases. If credible privacy requires more independent activity than the project has, we would label the system experimental and defer broad deployment. Fabricated activity is not a valid substitute.

10 New contracts or token migration?

New privacy contracts do not necessarily require a new token. If a conventional NULLCAT ERC-20 supports ordinary transfers, users could voluntarily deposit it into an audited pool and withdraw the same asset. A private balance would be an internal claim on locked tokens, not automatically a separately tradable token. Standard wallets and exchanges would continue to see public balances and transfers.

We would first inspect the real launch contract's transfer rules, fees, mint authority, upgrade controls and integrations. This has not been possible as a completed NULLCAT deployment review because no official token contract is recorded by the project today. A launchpad setting or branding change cannot retroactively conceal previous transfers.

If migration became necessary, its specification would need a conversion rule, supply reconciliation, an explicit bridge or escrow model, holder consent, treatment of liquidity positions and exchange balances, a support window and an independent review. Old history would remain public. A new contract address does not erase it. Dates, ratios, eligibility snapshots and automatic conversion are not set by this thesis.

11 Trust, disclosure & operational limits

Privacy Pools research explores proofs about membership in association sets without disclosing a complete transaction graph. It is relevant to selective disclosure, but choosing sets can reduce the anonymity set and add dependence on set providers. We would study this as an optional policy research track, not declare it a legal compliance guarantee or a completed feature. [19]

Our design preference is no universal decryption key. A user-authorized, scoped disclosure mechanism could reveal a particular receipt or viewing scope; we would document exactly what the recipient learns and what cannot be revoked after disclosure. An institution's reporting needs do not make a broad viewing key harmless. Legal and service-provider requirements would need review for the actual deployment and jurisdictions.

Administrative design is another trust boundary. We would compare immutable pool versions with a timelocked upgrade model and publish who can pause, upgrade or change limits. Pausing deposits while preserving exits is a goal to test, not a guarantee: a verifier vulnerability, compromised upgrade authority or chain-level exclusion can make an exit path unsafe or unavailable. An emergency plan must state that limitation.

Source verification, reproducible frontend builds, dependency review and secure key handling matter as much as verifier code. We would separate research infrastructure from production secrets, avoid unnecessary telemetry in the private wallet and publish an incident process. These are proposed controls; none replaces a contract and circuit audit.

12 Delivery gates & evidence ledger

We propose evidence-based gates rather than a launch countdown. Progress requires engineering resources and specialist review that have not been booked or funded by this document.

1. G0 — Define. Publish the selected threat model, protocol shortlist, chain requirements and exact token assumptions. Current state: this working paper.
2. G1 — Reproduce. Build an isolated mock-asset testnet prototype. Publish code and reproducible receipts. No deployment receipts exist for this thesis.
3. G2 — Measure. Run E1–E6 and publish failures as well as successful results. Revisit the design and wallet budget.
4. G3 — Review. Obtain independent circuit, contract and wallet reviews for the pinned release; resolve findings and publish scope and residual risks.
5. G4 — Decide. Publish a go/no-go report. Only then consider a separately announced, limited-value pilot with informed participants and clear operating limits.

Evidence at v0.2: primary-source literature and chain documentation reviewed; architecture and experiments proposed. Circuit implementation, deployment compatibility, wallet support, fees, proving benchmarks, privacy measurements, audit completion and a release date remain unverified. No graphs in this paper are measurements of a running protocol.

Future revisions should add dated measurements and identifiable artifacts, or explicitly retract failed assumptions. A credible research programme is allowed to conclude that a feature should not ship.

13 Conclusion

We plan to investigate an optional shielded layer before changing the identity or supply of the token. The practical work begins with a mock-asset testnet experiment, explicit public boundaries and reproducible wallet and verifier tests. Established infrastructure is our first candidate; custom cryptography is a research burden to minimize.

The thesis is therefore conditional: private internal transfers may be feasible, but usable privacy depends on sound circuits, working recovery, a realistic privacy set, reliable submission paths and the target chain's behavior. Until those conditions have evidence behind them, NULLCAT's privacy roadmap remains research. The cat can be mysterious. The claims must be inspectable.

Research revisions and any future official contracts will be announced through @Nullcatexe on X. This page does not authorize a token migration, a wallet connection or a transfer of funds.