Security Analysis

Anubis' security is based on both cryptographic assumptions and game theory.

11.1 Threat Models and Mitigation Measures

Threat Types	Description	Anubis Preventative Measures
Cryptographic Cracking	Attackers could break the discrete logarithm problem or forge ZK proofs.	Adopt a conservative approach BN254 and BLS12-381 curves. The PLONK protocol has complete security proofs. SRS comes from the Ethereum community's Powers of Tau ritual, which guarantees security as long as at least one person is honest.
Double Flower Attack	Repeatedly spending the same privacy note	Nullifier (empty value symbol) Mechanism: Each Note is bound to a unique and deterministic Nullifier. The Nullifier must be exposed upon spending; network nodes check the global set, and any duplicate Nullifier will result in a transaction rollback.
Deanonymization Attack	Inferring user identity through transaction patterns or monetary values.	Force Note merge: The wallet automatically merges small notes, reducing the risk of "Dust Attacks". Selective disclosure of amounts: In DEX interactions, disclosing the amount actually severs the complex arithmetic constraints, concentrating the privacy anchor purely at the address layer.
Validator Collusion	More than two-thirds of validators collaborated to decrypt mempool transactions and implement MEV.	Dynamic threshold adjustment: The decryption threshold is dynamically increased based on the distribution of network staking. Social consensus: Once evidence of large-scale frontrunning is discovered (statistical anomaly), the community can penalize malicious validators by hard forking.7

Table 11-1 Anubis Security Threat Model and Preventive Measures

11.2 Security Assurance

Anubis' security architecture is built on a multi-layered defense depth, aiming to achieve a strict balance between decentralization, privacy protection, and auditability. Under Anubis' selective privacy framework, the core of privacy guarantees lies in ensuring that attackers cannot infer the identity or transaction graph of protected entities from publicly available on-chain data.

1. Transaction non-linkability

• Cryptographic isolation of stealth addresses Anubis implements recipient privacy through a variant of the EIP-5564 standard. For each transaction, the sender generates a one-time stealth address based on the recipient's meta-address . This mechanism is based on the Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol, and the calculation formula is as follows: , In the formula, is a random temporary private key generated by the sender, which can only be used by the holder that can calculate the shared secret and identify the address. For an external observer, is computationally indistinguishable from a randomly generated public key. This ensures that even if the recipient uses the same meta address for receiving payments over a long period, their on-chain assets are dispersed across countless unrelated, one-off addresses, thus eliminating the possibility of address clustering analysis and rendering graph-based deanonymization attacks ineffective.28

• Input obfuscation and note-taking commitment When consuming notes, users don't directly reveal the specific note. Instead, they provide a zero-knowledge proof that the note they consumed exists in the global note commitment tree. Because Merkle path verification occurs within a zero-knowledge circuit, observers cannot know which leaf node was consumed. This constructs an anonymity set equal in size to the total number of currently unspent notes, which grows exponentially with increasing network usage, thus providing increasingly stronger privacy protection.29

2. Confidentiality of the notes

The asset types and amounts contained within the note are concealed via a Pedersen commitment . The Pedersen commitment scheme plays a vital role in the Anubis protocol, providing information-theoretic transition (or secrecy/hiding).

• Information-theoretic hiddenness This means that even with infinite computing power, an attacker cannot uniquely determine the amount from the commitment value . This property is crucial for preventing brute-force attacks on transaction amounts, especially in cases of small amounts (such as a standard 100 USDC transfer or multiples thereof), as it completely eliminates the possibility of deducing transaction amounts through rainbow table attacks.29

• Boundary control for selective disclosure In Level 2 privacy (selective privacy), the interaction logic of smart contracts (such as swap amounts) is public, but the user account's connection to the operation is severed. An attacker can see that "someone exchanged 5000 USDC for 0.1 WBTC," but cannot know "who" performed the operation. The system guarantees that as long as the user does not actively disclose their identity information through view keys, their identity information is computationally secure, and its security is strictly reduced to the difficulty of the Discrete Logarithm Problem (DLP). This design allows the system to protect the privacy of micro-level individuals while maintaining transparency of macroeconomic data (such as TVL and transaction volume).29

3. Defense statistics and heuristic analysis

In addition to cryptographic guarantees, Anubis has also designed mechanisms to resist metadata-based statistical analysis, one of the main threats currently facing privacy blockchains.

• Time blindness The wallet client introduces a random commit delay when generating transactions. Instead of broadcasting the transaction immediately after the user clicks "send," the client generates a random waiting time based on a Poisson distribution. This prevents attackers from correlating the user's IP address with on-chain transactions through network layer timestamps. This time-decorrelation mechanism increases the difficulty of traffic analysis.28

• Privacy protection in note merging The automated JoinSplit operation generates new random number when merging small notes. This ensures that there is no algebraic relationship between the commitments of the output notes and the input notes. Even if the source of the input notes is known (e.g., from publicly available top-ups), the output notes will be completely disconnected from the inputs due to the new blinding factor, preventing association analysis based on the homomorphic properties of commitment values.

11.2.1 Integrity guarantee

Integrity is the cornerstone of blockchain as a value transfer network. Anubis's integrity guarantee relies on the reliability of its zero-knowledge proof system and the immutability of its underlying ledger. The PLONK proof system we use has undergone rigorous formal definition and verification.

1. Computational completeness

Anubis uses the PLONK proof system to ensure the validity of all state transitions. According to the properties of the PLONK protocol, the system satisfies three core conditions: completeness, soundness, and knowledge soundness.

2. Anti-double-spending mechanism

Preventing double-spending while protecting privacy is a huge challenge because validator nodes cannot directly view spent notes.

3. Immutability of the ledger

Anubis' consensus layer employs a Proof-of-Stake (PoS) mechanism, combined with checkpointing and finality gadgets, to ensure that once a block is confirmed, the update of its commitment tree root and null value set is irreversible. Any attempt to roll back the state or tamper with historical records requires control of more than 2/3 of the validators' stake, which is extremely costly economically, and the protocol's built-in scrambling mechanism destroys the attacker's staked assets.30

11.2.2 Availability and Censorship Assurance

Privacy systems often face greater risks of censorship, especially from regulated centralized relay nodes or validators. Anubis ensures network censorship resistance and high availability through its protocol-layer design.

• Decentralized sorter Unlike some L2 solutions that rely on a single order, Anubis' transaction ordering is handled by a decentralized set of validators taking turns. This prevents a single entity from refusing to package specific types of privacy transactions due to regulatory pressure or malicious intent.

• Threshold Crypto Transaction Pool [v2.0 Plans] To completely eliminate censorship of privacy-sensitive transactions (e.g., validators might refuse to process complex transactions involving specific ZK circuits or discriminate based on transaction size), Anubis plans to introduce a threshold encryption mechanism. Transactions are encrypted upon entering the mempool, and validators package and sort them without knowing the transaction content (including gas fee payers and target contracts). Only after consensus is reached on the blocks and an aggregate signature is generated is the decryption key reconstructed, revealing the transaction content and allowing execution. This not only prevents censorship but also effectively eliminates MEV (Miner Extractable Value) attacks, ensuring fairness.31

11.3 Known Attacks and Mitigations

While Anubis boasts robust theoretical security, its practical deployment must address various side-channel attacks, implementation vulnerabilities, and complex economic attacks. This section provides a detailed analysis of known attack vectors targeting privacy blockchains and outlines Anubis's specific mitigation measures.

11.3.1 Timing analysis attacks

Attack Description Attackers can infer a user's identity or transaction characteristics by monitoring the timing patterns of transactions submitted to the network or the time taken to generate proofs. For example, due to computing power limitations, mobile devices may take significantly longer to generate proofs than high-performance servers. This time difference (e.g., 10 seconds vs. 2 seconds) could reveal the type of device a user is using, thus narrowing the scope of the anonymity set. Furthermore, if a user transfers funds immediately after receiving them, this close temporal correlation also weakens privacy protection.29

Anubis mitigation measures

Mitigation Strategies	Technical Implementation Details	Effect
Constant Time Operation	The underlying cryptographic libraries (such as elliptic curve multiplication) enforce branchless logic, and the execution time is independent of the input value (private key/amount).	Preventing the inference of private key or amount through execution time.33
Batch and Delay Processing	The wallet SDK includes a random delay strategy by default. Transactions are not broadcast immediately after they are generated, but instead wait for a random time window that follows a Poisson distribution.	Disrupting transaction timing and compromising timestamp-based correlation analysis.32
Proof of Generation of Fill	The delegated proof service adds a uniform random fill delay before returning results, thus standardizing the response time.	It masks the computing power characteristics of user devices to prevent device fingerprinting.

Table 11-2 Anubis Strategies for Mitigating Timing Analysis Attacks

11.3.2 Amount analysis attack

Attack Description In the "Selective Privacy" mode, if a user exchanges a non-standard amount on a DEX (e.g., 1234.5678 USDC), this unique amount itself constitutes a fingerprint. An attacker can identify the user by searching the flow of that specific amount on-chain and even tracing it across chains (e.g., a user withdrawing this unique amount from a centralized exchange). This attack exploits the uniqueness of metadata to bypass cryptographic protection.34

Anubis mitigation measures

• Recommendations for standardizing monetary amounts When performing privacy-preserving operations (especially Swaps or Deposits involving public metadata), Anubis Wallet intelligently suggests using standardized amounts (e.g., 10, 100, 1000) to enhance anonymity.

• Automatic change mechanism Similar to Bitcoin's UTXO model, Anubis' privacy transactions support multiple outputs. If a user needs to pay a non-standard amount, the system automatically splits the funds into a "public payment amount" and a "change amount." The change amount is returned to the user in a new privacy note, and the amount in this note is encrypted. While the public payment portion may still expose information, the privacy of the remaining funds is fully preserved.

• Blur and slippage exploitation In some DeFi protocols, slight slippage or fee obfuscation can be introduced, causing a small discrepancy between the publicly recorded amount and the amount the user actually intends to pay, thus undermining the effectiveness of precise matching analysis.

11.3.3 Dust attack

Attack Description Attackers send tiny amounts of funds (dust) to a large number of private addresses. If users inadvertently combine these dust notes in subsequent transactions, attackers can analyze the transaction graph to link these addresses, thereby compromising the user's anonymity. This is a common and low-cost method in deanonymization attacks.35

Anubis mitigation measures

• Mandatory note filtering The wallet SDK has a built-in dust prevention policy that ignores unrequested notes below a certain threshold (such as a value of 0.01 USD) by default. These dust notes will never be included in the input of the JoinSplit operation unless the user explicitly marks them as "spendable".

• Note isolation Even if dust is required, the system will suggest processing it separately or merging it only with notes of the same origin, avoiding mixing it with the user's main asset notes, thereby physically isolating the risk of transmission.

11.3.4 Replay and extensibility attacks

Attack Description Attackers intercept legitimate proofs of privacy transactions and attempt to resubmit them in different contexts or tweak the proof to generate new, valid transactions, resulting in double-spending or denial of service.

Anubis mitigation measures

• Uniqueness and binding of null operators The null operator mechanism fundamentally eliminates the possibility of replaying already spent notes. Once is recorded on-chain, any transaction attempting to reuse the same note will fail due to a collision.

• Transaction binding The generation process of zero-knowledge proofs incorporates transaction context information (such as Chain ID, contract address, and Nonce) as part of the public input into the hash calculation. This means the proof is strongly bound to a specific transaction context. Any tampering with the transaction metadata will cause a change in the public input hash, leading to proof verification failure. This ensures the non-scalability of transactions.26

11.3.5 Risks of abuse of precompiled contracts

Attack Description Anubis introduces privacy-related pre-compiled contracts (such as 0x0103 NULLIFIER_CHECK). If poorly designed, malicious contracts could abuse these interfaces. For example, by repeatedly calling isSpent(nullifier) ​​to brute-force guess a user's null identifier, they could probe the user's spending behavior or even launch a denial-of-service (DoS) attack.

Anubis mitigation measures

• Economic containment Set extremely high gas prices for sensitive pre-compiled contract calls. For example, a single isSpent query might consume 5000 gas, making large-scale brute-force attacks economically infeasible.

• Access Control List Certain critical state modification functions (such as markSpent) are strictly restricted to being called only by system-level transactions or verified Privacy Manager contracts. Contracts deployed by ordinary users are not authorized to directly modify the set of nullables.

• Dynamic rate limiting Introducing dynamic rate limits for specific opcodes at the execution layer prevents excessive privacy query operations within a single block and protects node computing resources.

11.4 Formal Verification

Given the complexity of privacy protocols and the critical importance of asset security, traditional test cases struggle to cover all boundary conditions. Anubis employs formal verification methods to mathematically prove the correctness of core circuits, smart contracts, and protocol logic. We are not satisfied with merely "no vulnerabilities found," but strive for a mathematically "vulnerability-free" guarantee.

11.4.1 Formal verification of ZK circuits

Zero-Knowledge (ZK) circuits are the core of the Anubis system. Any missing constraint within the circuits could lead to forged proofs. We leverage advanced tools such as CertiPlonk and Ecne to verify and validate our circuits.27

• Correctness of arithmetic circuits We transform the circuit logic into a polynomial constraint system and use theorem provers (such as Coq or Lean) to verify its consistency with the high-level specification.

• Verification target Proof circuit , if and only if the input and witness satisfy predefined business logic .

• Constraint integrity check Automated tools scan circuit code (such as Circom or Halo2 API) to detect unconstrained signals, the most common source of vulnerabilities in ZK circuits. For example, ensure that all division operations are accompanied by a "denominator not zero" constraint, and that all bit operations are accompanied by a "value between 0 and 1" constraint.27

• Non-interactive zero-knowledge property verification Verify the correct implementation of the Fiat-Shamir transformation to ensure that the generation of random challenge numbers when generating non-interactive proofs is strictly dependent on prior commitments, preventing attackers from forging proofs by manipulating random numbers.

11.4.2 Formal verification of smart contracts

System contracts on the Anubis EVM (such as privacy pool management and repeater logic) have also undergone rigorous verification and comply with the OWASP smart contract security verification standard.36

• Symbolic execution Use tools such as Manticore or Mythril to perform symbolic execution on Solidity bytecode, exploring all possible execution paths to discover integer overflows, reentrancy attacks, and unhandled exceptions. A detailed analysis of call paths for privacy-precompiled contracts is particularly important.37

• Invariant checks Define system-level invariants, such as "the total public balance in the privacy pool must equal the sum of all unspent notes." Formal verification tools will attempt to find any state transition sequences that could violate these invariants. If the tool reports "no solution," the system is proven secure within the model's scope.38

• Access control verification Verify the access control logic to ensure that only users with the correct view key or private key can trigger specific decryption or withdrawal operations, thus preventing privilege escalation vulnerabilities.

11.4.3 Protocol layer verification

• Consensus security Model testing was performed on Anubis's PoS consensus algorithm to verify that the protocol always satisfies security and liveness even when the proportion of Byzantine nodes is less than 1/3.

• Cross-layer interaction Verify the interface logic between the EVM execution layer and the ZK verification layer to ensure that parameter passing and return value processing are atomic when the EVM calls the precompiled contract, and that there are no inconsistencies in the state (e.g., the EVM successfully deducts the payment but the ZK state is not updated).