Selective Privacy Protocol Model

Anubis does not mandate complete anonymity for all transactions; instead, it offers a spectrum of privacy options to suit different application scenarios.

5.1 Definition of Privacy Classification

Grade	Name	Feature	Data Visibility	Applicable Scenarios
L0	Fully open (Transparent)	Standard EVM Trading	Sender, receiver, amount, and data are all publicly disclosed.	DAO voting, public donations, and NFT displays.
L1	Sender Privacy	Similar to a coin mixer	Sender hidden, receiver and amount public	Anonymous donations, salary payments
L2	Selective Privacy	Default mode	User identity is hidden, but contract address, amount, and asset type are public.	DEX trading, lending and collateralization, liquidity mining
L3	Complete Privacy	Dark pool mode	Sender, recipient, amount, and asset type are all hidden.	Large-scale OTC transactions, payments for trade secrets

Table 5-1 Definition of Privacy Rating

5.2 Detailed Explanation of Transaction Types (Based on EIP-2718)

To introduce complex privacy semantics while remaining fully compatible with existing Ethereum infrastructure (such as the MetaMask wallet and Etherscan block explorer), the Anubis network adopted the EIP-2718 typed transaction envelope standard. This design decision allows us to define entirely new privacy transaction payloads without disrupting the traditional EVM transaction structure, enabling seamless state transitions from public to private ledgers.

The Anubis protocol retains standard transaction types from the Ethereum Mainnet (Legacy 0x00, EIP-2930 0x01, and EIP-1559 0x02), which are classified as Level 0 (Fully Public) transactions for handling non-private asset transfers and contract interactions. To enable privacy-layer functionality, Anubis introduces four core private transaction types within the 0x70 to 0x73 range. These transaction types not only facilitate the flow of assets between the "Public Account Model" and the "Private Note Model" but also define the logic for value transfer and smart contract interoperability within a private state.

5.2.1 Overview of transaction types

Type ID	Mnemonic	Name	Function Description	Privacy flow	Gas Structural Characteristics
0x70	TX_SHIELD	Shield transactions	The publicly disclosed ERC-20/ETH will be locked and minted into a privacy note.	Public Private	Basic Gas + Status Write Fee
0x71	TX_TRANSFER	Private Transfer	Notes are transferred within a privacy pool, concealing the sender, receiver, and amount.	Private Private	Verifier Gas Dominates
0x72	TX_PRIV_CALL	Privacy contract call	Carrying ZK proofs to invoke arbitrary EVM contracts enables selective privacy interactions.	Private Public Interaction	Hybrid Gas (Verification + EVM Execution)
0x73	TX_UNSHIELD	Unshield	Destroy the privacy notes and retrieve assets back to the public address.	Private Public	Validation fee + State release fee

Table 5-2 Overview of Anubis Transaction Types

5.2.2 Type 0x70: Block Transaction

Blocking transactions is the entry point for users to enter the Anubis privacy ecosystem. From a system architecture perspective, this is a "lock and mint" operation: assets in the public account are locked to the Anubis privacy liquidity pool contract, and an equivalent amount of notes are created in the privacy state tree.

RLP encoding structure:

TransactionType 0x70 | | rlp()

Execution logic and privacy boundaries

• Asset lock-up (Public Layer) The EVM execution environment first deducts the value (ETH) from the sender (msg.sender) or calls ERC-20 transferFrom to transfer the tokens to the privacy pool contract. This step is completely public on-chain, and observers can know "who" deposited "how much" of the assets.

• Promise to insert (Privacy Layer) The system verifies the format of noteCommitment (belonging to the BN254 scalar field) and inserts it as a leaf node into the global Note Merkle Tree.

• Event Launch Issues a Shield(address indexed from, bytes32 commitment, uint256 amount) event.

• Privacy Analysis Although the deposit is public, the generated noteCommitment severs the link between the asset and subsequent spending. Once an asset is converted into a Note, it is impossible for outsiders to track when the Note is spent or to link it to future withdrawals (unless the amount has extremely unique characteristics, which is why it is recommended to use standard denominations such as 10, 100, and 1000).

5.2.3 Type 0x71: Privacy Transfer

This is the highest level of privacy protection (Level 3) transaction type in the Anubis network. To an external observer, it is an unreadable string of binary data and zero-knowledge proofs, making it impossible to deduce the sender, receiver, or specific transfer amount (relying on the homomorphic hiding property of the Pedersen commitment).

RLP encoding structure:

TransactionType 0x71 | | rlp([ chainId, nonce, // Randomized nonce for the spending key (not the account nonce), used for

// anti-replay protection. maxPriorityFeePerGas, maxFeePerGas, gasLimit, nullifiers, // A list of nullables for the input notes [nullifier_1, nullifier_2,...] commitments, // Outputs a list of commitments for // the notes [commitment_1, commitment_2,...] ephemeralKey, // Ephemeral Public Key, used for ECDH key negotiation encryptedCiphertext, // Encrypted note ciphertext (containing amount, recipient, and memo),

// decryptable only by the recipient's View Key. zkProof, // PLONK zero-knowledge proof v, r, s // Binding Signature ])

Detailed Explanation of Core Mechanisms:

• Input/output balance constraint The core logic of ZK proofs is constraints. Because both the input and output amounts are hidden within the Pedersen commitment. In this process, the verification nodes use homomorphic properties to verify the sum of commitments without needing to know the specific value of . This ensures the conservation of the money supply.

• Nullifier for deduplication and double-spending prevention For each input note, the circuit derives a unique: nullifier = H(spending_key, note_position,...) Through hash calculation, the validator node checks if this nullifier already exists in the global Nullifier Set. If it does, the transaction is rejected. This mechanism perfectly solves the double-spending problem while protecting privacy.

• Binding signature To prevent malicious relay nodes from tampering with transaction fees or recipients, transactions must be signed with the transaction hash using the consumption key. Since the consumption key never leaves the user's device, this signature ensures the non-repudiation and integrity of the transaction.

5.2.4 Type 0x72: Privacy Contract Call

This is the cornerstone of Anubis's "Selective Privacy" architecture, allowing users to interact with standard, fully public EVM contracts (such as Uniswap, Aave, and Compound) with a private identity.

RLP encoding structure:

TransactionType 0x72 | | rlp()

Execution process and instant account mechanism:

• Pre-validation phase The node first verifies zkProof to confirm that the user owns the assets corresponding to the nullifiers, and that the amount satisfies the conservation relationship: Input Notes Total Value = Public Value + New Commitments + Fee. This step ensures that the user has not created currency out of thin air.

• Transient funding The system temporarily creates a virtual Ephemeral Account within the execution context. It then "mints" the publicValue amount of assets from the privacy pool to that account.

• EVM invocation execution Execute targetContract.call(calldata) with the instantaneous account as msg.sender.

• Privacy Boundaries Target contracts (such as Uniswap) can only see the instantaneous account address and cannot trace the real user address or history behind it.

• Data transparency Calldata (e.g., swap(tokenA, tokenB, amount)) is public. This reflects Anubis' design philosophy of "public transaction logic, anonymous trader identities." Market participants can track transaction volume, but cannot profile traders.

• Status cleanup and asset recovery After the call ends, any remaining assets held in the instantaneous account (such as Token B obtained through Swap) must be "reclaimed". The transaction structure contains instructions that tell the system to package the balance in the instantaneous account into the output note corresponding to newCommitments. If there is still an unprocessed balance in the instantaneous account, the transaction will be rolled back.

5.3 Privacy Protection and Models in Contract Interaction

In Anubis's design, privacy is no longer a binary opposition (fully public or fully hidden), but rather a configurable spectrum. Through 0x72 type transactions, developers can build complex privacy-focused DeFi applications. This section delves into specific implementation models and privacy trade-offs within decentralized finance (DeFi) scenarios.

5.3.1 Privacy interaction mode of AMM DEX

In traditional privacy coin models (such as Zcash), users cannot directly interact with Uniswap because the AMM is a public function . The exact amountIn is needed to calculate amountOut. Anubis cleverly resolves this contradiction through an "Instant Deanonymization" mechanism.

Interaction sequence diagram

• Off-chain computation (Client Side)：

• User holding notes(For example, a value of 1000 USDC).

• The user wants to swap 500 USDC for ETH.

• ZK circuit generation proof Proof It is valid, and the user has authorized the “public” use of 500 USDC for the call.

• Generate Change Notes (500 USDC).

• On-Chain execution：

• Step 1 (System) Verify Proof, then destroy (Record Nullifier).

• Step 2 (System) The system creates a transient address 0xTemp... and injects 500 USDC into it.

• Step 3 (EVM) 0xTemp calls Uniswap Router: swapExactTokensForETH(500 USDC,...).

• Step 4 (EVM) Uniswap calculates the price and sends ETH back to 0xTemp. This process is completely transparent on-chain, and any observer can see that there is a buy order for 500 USDC.

• Step 5 (System) The system intercepted the ETH received by 0xTemp and, according to the instructions attached to the transaction, encapsulated it into a new privacy note .

• Step 6 (System) Insert (USDC) and (ETH) commitments into the Merkle Tree.

• Step 7 (System) Destroy the instantaneous address 0xTemp.

Privacy Analysis:

• Observer's perspective Observe a randomly generated address interacting with Uniswap, executing a transaction, and then become inactive. It's impossible to know who this address belongs to, nor can it be linked to previous transactions.

• Analytical value Because transaction amounts and token types are public, key metrics such as TVL (Total Value Locked) and trading volume of DeFi protocols can still be accurately measured, which is crucial for the healthy development of the ecosystem.

5.3.2 Composition across contracts

Anubis' architecture allows privacy transactions to invoke multiple contracts within a single atomic transaction, maintaining Ethereum's strong composability.

Example: Privacy leverage lending

Users can complete complex "Flash Loan + Leverage" operations in a single 0x72 transaction:

1. Unpack ETH from Privacy Notes.

2. Call Aave to deposit ETH as collateral.

3. Call Aave to borrow USDC.

4. Use Uniswap to exchange USDC for ETH.

5. Deposit again into Aave (revolving loan).

6. The final bond warrant (aToken) will be encapsulated as a privacy note.

Challenges and solutions for proving asset ownership:

In the above process, Aave records 0xTemp as the debtor. However, 0xTemp is temporary and expires after the transaction is completed.

• Solution: Privacy Proxy Registry

• Users pre-deploy a long-term existing Privacy Agency Agreement.

• 0x72 The transaction does not directly operate on Aave, but instead uses the Proxy command to operate.

• The Proxy holds a bond position (aToken).

• Control of the proxy is managed through ZK proofs (holding a specific View Key or Spending Key signature). This way, while the proxy address is public, who controls the proxy remains private.

5.3.3 Selective privacy implementation- Taking DEX Trading as an Example

solidity // DEX Contracts (Public Portion) contract AnubisSwap { event Swap( address indexed tokenIn, address indexed tokenOut, uint256 amountIn, uint256 amountOut, bytes32 proofHash, // Associated privacy proof );

function swap( address tokenIn, address tokenOut, uint256 amountIn, uint256 minAmountOut, bytes calldata zkProof, // Zero-knowledge proof bytes32 noteCommitment // New Note commitment ) external returns (uint256 amountOut) { // 1. Verify ZK proof (proving the sender has sufficient assets) require( verifyProof(zkProof, noteCommitment, amountIn), "Invalid proof" );

// 2. Execute swap logic (standard AMM) amountOut = _swap(tokenIn, tokenOut, amountIn); require(amountOut >= minAmountOut, "Slippage"); // 3. Create output notes _createNote(tokenOut, amountOut, noteCommitment);

// 4. Issue a public event (for analysis) emit Swap(tokenIn, tokenOut, amountIn, amountOut, keccak256(zkProof)); } }

On-chain visible information: DEX contract address, trading pair (USDC/WBTC), transaction amount (5000 USDC → 0.1 WBTC), timestamp

Information not visible on the blockchain: The real address of the transaction initiator, the initiator's transaction history, and the initiator's total assets.

5.4 Regulatory Compliance Framework

Anubis firmly believes that sustainable privacy-preserving blockchains must strike a balance between protecting users' fundamental rights and combating illicit financial activities such as money laundering and terrorist financing. We propose a "Programmable Compliance" architecture that utilizes zero-knowledge proof technology to achieve "proof of compliance without compromising privacy data". Anubis offers optional compliance mechanisms:

1. View key disclosure Users may choose to provide the view key to regulatory agencies.

2. Compliance proof Prove the legitimacy of the funding source without revealing the specific funding route.

3. Threshold decryption Only through collaboration among multiple institutions can a specific transaction be deciphered.

4. Auditable pool Optional KYC pools offer higher limits.

5. ZK-KYC (Zero-Knowledge Authentication) To prove "I am not on the sanctions list" without revealing "who I am".

5.4.1 ZK-KYC identity authentication protocol

Traditional KYC (Know Your Customer) requires users to upload passports or personal information on-chain, which compromises privacy and poses significant data breach risks. Anubis integrates a ZK-KYC solution based on ICAO e-passport standards.

Figure 5-1 ZK-KYC Identity Authentication Flowchart

Technical implementation process:

1. Trust anchor The system utilizes existing e-passport infrastructure. E-passports issued by over 170 countries worldwide contain digital signatures issued by national certification centers within their chips.

2. Client-Side proving

• Users can use NFC-enabled mobile phones to read passport data (including photo hash, personal information, and country signature).

• Run the ZK circuit locally, input: Passport private data.

• Circuit logic verification:

• Verify the validity of the passport signature (using the on-chain national public key registry).

• Passport verified to be valid.

• Verify that the user is not on an international sanctions list (verify OFAC and other sanctions list snapshots via Merkle Inclusion Proof).

• Output A ZK proof , it proves that "the holder is a lawful citizen and has not been sanctioned, "but does not include name, nationality, or passport number.

1. Identity token minting (SIT minting)：

• Users will submit to the Anubis identity registration contract.

• Once the contract verification is successful, one Soulbound Identity Token (SIT) will be minted and binded to the user's private address (using a nullifier mechanism to prevent the generation of multiple SITs from the same passport).

Applications of Permissioned Pools:

DeFi protocols (such as Aave Arc or RWA asset platforms) can be configured with modifiers to only accept interactions from valid SIT addresses:

Solidity

modify onlyCompliant() { require(IdentityRegistry.verifyCompliant(msg.sender), "ZK-KYC required"); _; } In this way, the organization usesUsers can conduct private transactions in a fully compliant environment, meeting regulatory requirements without having to disclose their trading strategies to the world or competitors.

5.4.2 Hierarchical disclosure mechanism for View Keys

Anubis utilizes a hierarchical key system that strictly decouples spending permissions from viewing permissions, providing a technical foundation for auditing.

• Spending Key (): Highest privileges, used to generate zero-knowledge proofs, and incurs costs. Never leaves the user's device.

• Incoming View Key (): Allows decryption of received transactions (amount, sender).

• Outgoing View Key () Allows decryption of sent transactions.

Auditing Interfaces and Scenarios:

Enterprise users can proactively provide and information to auditors or tax authorities. Auditors can use specialized audit tools:

• Decrypt all of the user's historical transaction details (time, amount, counterparty).

• Verify on-chain that all transactions have indeed occurred and have not been tampered with.

• Limitations Guarantee The auditor was unable to spend funds or view the user's interactions with other addresses (unless the other party also disclosed the View Key).

This mechanism perfectly replicates the "Read-only Access" of the traditional banking system, allowing companies to meet financial audit and tax filing requirements (transparent to regulators) while protecting trade secrets (keeping them confidential from competitors).

Characteristic	View Key Disclosure	ZK-KYC
Regulatory visibility	Complete transaction history	Compliance status only
Privacy protection	Weak	Maximize
Applicable Scenarios	Institutional Compliance	Retail investor compliance
Web3 Native	Medium	high

Table 5-3 Comparison of ZK-KYC and Traditional View Keys