> For the complete documentation index, see [llms.txt](https://anubis-network.gitbook.io/anubis-network/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://anubis-network.gitbook.io/anubis-network/transaction-lifecycle.md).
# Transaction Lifecycle
In the architecture of the Anubis protocol, the transaction lifecycle forms the core bridge connecting user privacy intentions with on-chain deterministic execution. Unlike Ethereum's linear logic of handling state changes through a single account model, Anubis introduces a complex hybrid state machine. This mechanism requires maintaining both public account state and private note state simultaneously in a single atomic execution. This design not only needs to ensure the completeness and reliability of zero-knowledge proofs at the cryptographic level, but also must address a series of challenges at the systems engineering level, such as concurrency, state synchronization, censorship resistance, and gas economics.
Anubis' transaction lifecycle, through highly sophisticated engineering design, establishes a self-consistent logic between seemingly irreconcilable privacy and transparency. From the underlying protocol extension of EIP-2718 to the generation of zero-knowledge proofs on the client side, and then to the execution of atomic mixed states on the chain, every step has undergone rigorous cryptographic verification.
This lifecycle design not only achieves full compatibility with the Ethereum ecosystem, but more importantly, it elevates privacy from an "add-on" function (such as a coin mixer) to a native attribute of the blockchain's underlying structure. Through Type 103 transactions, Anubis enables DeFi protocols to process billions of dollars in asset transfers compliantly and transparently without compromising user privacy data, laying a solid technical foundation for Web3 to enter the era of large-scale institutional applications.
This chapter will provide a detailed explanation of the entire transaction process in the Anubis network, from construction, proof, and propagation to final on-chain confirmation. We will delve into how the protocol utilizes the EIP-2718 standard to expand transaction types (Type 100-103), how it enables the transfer of privacy assets while maintaining full EVM compatibility, and how it ensures the atomicity and composability of DeFi operations through an innovative pre-compiled contract system.
Figure 7-1 Detailed Sequence Diagram of Anubis Transaction Lifecycle
#### 7.1 Architectural Philosophy and State Duality
Anubis' transaction lifecycle design follows three core principles: Default Privacy, Selective Disclosure and Minimizing Trust. In traditional Layer 1 blockchains, transactions are not only carriers of value transfer but also plaintext information broadcast across the entire network, resulting in the complete exposure of users' financial graphs. Conversely, while privacy-focused public blockchains conceal the transaction graph, they often sacrifice programmability. Anubis attempts to break this "Impossible Triangle," its core being the processing of State duality：
* **Public state**\
It adopts the standard Merkle Patricia Trie (MPT) structure to store smart contract code, storage slots, and public...Account balance. This section fully complies with the Ethereum Yellow Paper specifications, ensuring seamless operation of existing Solidity/Vyper contracts.9
* **Private state**\
A Sparse Merkle Tree (SMT) in an append-only mode is utilized to store Note Commitments, paired with a Nullifier Set to prevent double-spending. A note acts not only as an asset container but also as a value carrier encrypted via Pedersen commitments.
The core task of a transaction lifecycle is to assert the legitimacy of a state change to the public state layer through mathematical proof, without revealing the specific details of the private state (such as the transfer amount or the sender's identity). This cross-layer interaction requires the transaction to exhibit distinctly different forms at different stages of its lifecycle: on the client side, it is a "witness" containing a private key and plaintext data; in the mempool, it is an encrypted "envelope" containing zero-knowledge proofs; and during on-chain execution, it transforms into a deterministic renewed state root. 10
#### 7.2 Extended Transaction Types (EIP-2718) and Data Structures
To natively support privacy operations on EVM-compatible chains, Anubis adopts the EIP-2718 type transaction envelope standard. Unlike standard transactions such as EIP-1559 (Type 2), Anubis defines its own transaction type range of 0x64 to 0x67 (decimal 100-103) to carry privacy-specific metadata such as ZK proofs, null operators, and commitments.11
This design allows traditional Ethereum wallets (such as MetaMask) to identify and pass through these transactions via an RPC interface, while the underlying Anubis nodes can parse their specific payloads.
**7.2.1 Type 100: Block Transactions**
**Operation code: 0x64**
Shielded transactions are a one-way channel for assets to move from the public world to the private world. Essentially, it involves locking ETH or ERC-20 tokens in the public account (EOA) into the Anubis privacy pool contract and simultaneously minting an equivalent amount of privacy notes in the note commitment tree.
* **Privacy level**\
Level 0 Level 3 (Complete Privacy)
* **Fund flow**\
Public Address  Privacy Pool Contract
* **Gas payment**\
Payment is made by the public EOA that initiated the transaction.
**Data load structure:**
Fields
Type
Describe
chainId
uint256
Chain ID to prevent cross-chain replay attacks.
nonce
uint256
EOA's transaction counter.
asset
address
The blocked asset address (0x0 represents the native ANB).
amount
uint256
The amount to be blocked.
recipientPublic
bytes32
The recipient's private public key (Stealth Meta-Address).
encryptedNote
bytes
The ciphertext of the note (containing the amount and a random number) is encrypted using the recipient's public key.
signature
bytes
ECDSA signature of EOA.
Table 7-1 Type 100 Data Load Structure Table
**In-depth analysis:**\
Type 100 transactions do not require zero-knowledge proofs because the source of the input funds is public and verifiable. The validating node only needs to check if the EOA balance is sufficient, and then execute TransferFrom to transfer the tokens to the privacy pool. The generated note commitment, Commitment = Pedersen(amount, asset, blinding), is inserted into the Merkle tree, but at this point, it does not reveal which user the commitment belongs to, thus cutting off the traceability of subsequent fund flows.
**7.2.2 Type 101: Privacy Transfer**
**Operation code: 0x65**
This is the most basic privacy operation on the Anubis network, similar to Zcash's Sapling transaction. It allows users to transfer assets while completely hiding the sender, receiver, and amount. Due to the use of the UTXO model, this transaction typically involves "merging" multiple small notes and "splitting" them into new output notes.
* **Privacy level**\
Level 3 (Complete Privacy)
* **Fund flow**\
Private Note  Private Note
* **Gas payment**\
The cost is paid by the relayer through a cost abstraction mechanism.
**Data load structure:**
Fields
Type
Describe
root
bytes32
The Merkle tree root (supporting historical roots) on which the verification proof is based.
nullifiers
bytes32
A list of null values for the input notes to be spent.
commitments
bytes32
The newly generated list of output notes commitments.
proof
bytes
PLONK ZK-SNARK proof.
feeCommitment
bytes32
Fees paid to Relayer are recorded as commitments.
encryptedNotes
bytes
Encrypted metadata sent to the recipient (ECIES encryption).
ephemeralKey
bytes32
Temporary public key used for stealth address derivation.
Table 7-2 Type 101 Data Load Structure Table
**In-depth analysis**\
The core of Type 101 transactions lies in ZK proofs. The proof circuit needs to be constrained as follows:\
\
To prevent transaction correlation analysis, input and...OutputThe number of notes is usually fixed (e.g., 2 in, 2 out), and any shortfall is filled with "dummy notes" of zero value.12。
**7.2.3 Type 102: Unblocking Transactions**
**Operation code: 0x66**
When a user needs to withdraw their privacy assets back to their public account (e.g., for monetization on a centralized exchange or cross-chain transactions), a Type 102 transaction must be executed. This process destroys the privacy notes and transfers them from the privacy pool contract to the designated EOA.
* **Privacy level**\
Level 3  Level 0
* **Fund flow**\
Private Note  Public Address
* **Gas payment**\
It is usually deducted from the withdrawal amount or paid by the Relayer.
**Data load structure**
Fields
Type
Describe
nullifiers
bytes32
A null value for the privacy note to be destroyed.
recipient
address
A public Ethereum address that receives funds.
amount
uint256
The publicly disclosed withdrawal amount.
proof
bytes
Prove that the user owns the destroyed notes and that the amount matches.
Table 7-3 Type 102 Data Load Structure Table
**In-depth analysis**\
Although the receiving address and amount are public, the input notes are referenced by nullifiers, so outsiders cannot know from the on-chain data which previous Shield or Transfer transaction the funds came from, thus achieving "sender anonymity".
**7.2.4 Type 103: Privacy Contract Call**
**Operation code: 0x67**
Type 103 is a core innovation of Anubis, achieving Selective Privacy. It allows users to spend privacy notes to interact directly with any EVM smart contract (such as Uniswap, Aave), while exposing only the minimum dataset (such as trading pairs and amounts) required for the contract logic, thus hiding the user's identity and total assets.
* **Privacy level**\
Level 2 (Selective Privacy)
* **Fund flow**\
Private Note  Ephemeral Account  DeFi Contract  Private Note
* **Gas payment**\
Relayer payment service.
**Data load structure:**
Fields
Type
Describe
target
address
Target contract address (e.g., Uniswap Router).
data loss
bytes
Data (plaintext) of the call to the target contract.
publicAmountIn
uint256
The publicly disclosed amount injected into the contract.
publicAmountOut
uint256
The minimum amount expected to be returned from the contract and re-shielded.
proof
bytes
A ZK proof bound to the calldata hash.
Table 7-4 Type 103 Data Load Structure Table
**In-depth analysis**\
Type 103 transactions introduce a proof-binding mechanism. The circuit not only verifies ownership of the note but also computes a hash(target, calldata, amount) and uses it as a public input. This prevents malicious relayers from stealing valid ZK proofs and redirecting funds to other contracts (Front-running/replay Attack）13. During the execution, the system will temporarily create a temporary account to act as msg.sender, thereby cutting off the DeFi protocol's tracking of the user's real identity.
#### 7.3 Off-chain Lifecycle: Proof and Construction
Before a transaction is broadcast to the network, the client (wallet or SDK) must complete a series of complex computational tasks. As this involves private keys and plaintext notes, this stage must be executed on a user-controlled device or within a secure environment, forming the first line of defense for privacy protection.14
**7.3.1 Note discovery and synchronization**
Anubis wallets cannot query eth\_getBalance as easily as MetaMask because all notes are stored cryptographically on-chain.
* Log scan\
The wallet connects to an RPC node and pulls the EncryptedNote event log from the block.
* Tentative decryption\
The system attempts to decrypt each log entry using the user's view key. Due to the use of the ECDH key exchange protocol, only the legitimate recipient of the note can successfully decrypt it and obtain the amount and blinding factor.
* Status check\
For successfully decrypted notes, the wallet needs to further query the nullable index of the full node to confirm whether the note's nullifier has been recorded. Only notes that do not appear in the nullable set are in a valid, unspent state.
To optimize synchronization performance on mobile devices, Anubis employs a Bloom filter and fuzzy matching tagging mechanism, allowing lightweight clients to quickly filter out 99% of irrelevant transactions, greatly reducing bandwidth consumption.
**7.3.2 Stealth address derivation**
To ensure the privacy of the recipient, the sender must derive a one-time stealth address in accordance with the EIP-5564 protocol when constructing the transaction.
* The sender generates a temporary private key and temporary public key .
* Computational shared secrets .
* Calculate the stealth public key .
* This stealth public key  will be recorded in the commitment as the owner identifier for the output note. When the recipient scans the on-chain data, it will utilize  to calculate the shared secrets , if , then it is confirmed that the note belongs to you.
**7.3.3 Proof generation and delegation**
This is the most computationally intensive part of the lifecycle. Anubis uses the PLONK proof system, which generates proofs in about 1-3 seconds on desktop, but can take more than 10 seconds on mobile. To address the performance bottleneck on mobile devices, Anubis provides a delegated proof mechanism.
* **Local generation**\
The user equipment calculates the Witness (including private inputs such as Merkle Path and private key) and generates  using the Prover algorithm. This is the safest mode.
* **Delegated generation**\
Users encrypt and send Witness to trusted proof service nodes.
* Privacy trade-off\
Users must disclose the transaction's metadata (such as the transfer amount and recipient) to the proof node, but the user's spending private key never leaves the local device. Even if the proof node acts maliciously, it cannot steal funds, but can only leak transaction privacy.
* Application scenarios\
Suitable for mobile payment scenarios that are sensitive to latency but do not have extreme requirements for the privacy of metadata of a single transaction.
**7.3.4 Note consolidation**
Due to the limitations of ZK circuits (typically limiting the number of input notes to 2 or 4), the SDK will automatically trigger Mergers and Acquisitions when a user holds a large number of small notes (such as mining rewards or multiple payments) and attempts to make a large transfer. This may require generating multiple proofs consecutively, merging multiple small notes into a large note, and then executing the final transfer. This process is transparent to the user, but it manifests as a series of dependent atomic operations throughout the transaction lifecycle.
#### 7.4 Network Propagation and Relay Mechanisms
The constructed transaction is a large binary object containing ZK proofs. Since the initiator of a privacy transaction typically does not have a publicly disclosed ETH/ANB balance to pay gas (otherwise, they would associate their identity with gas payments), a relayer role must be introduced.15
**7.4.1 Cost abstraction and relay market**
Anubis's privacy transaction supports Cost Abstraction. The user specifies a fee (e.g., 5 ANB) to be paid to the Relayer in the transaction's output note.
* **Broadcast**\
Users broadcast their signed payload (excluding gas payment information) to the Relay Pool of the P2P network.
* **Orders received**\
The Relayer monitors the pool to verify the validity of the ZK proof and whether the fee notes are sufficient to cover the current gas costs plus profit.
* **Packaging**\
The winning Relayer encapsulates the user's privacy payload into a standard Ethereum transaction, using Relayer's own EOA signature and paying the gas.
* **On-chain**\
The transaction is packaged into a block. When the smart contract executes, ownership of the fee notes is transferred to the Relayer.
**7.4.2 Threshold encrypted memory pool**
To prevent MEV (Maximum Extractable Value) attacks and censorship, Anubis plans to introduce a threshold cryptographic memory pool in phase 2.0.
* **Mechanism**\
Users encrypt the entire transaction payload using the aggregated public key of the validator committee.
* **Sort**\
The verifier sorts and packages encrypted transactions without knowing the contents of the transactions.
* **Decryption and execution**\
Only after the block header is confirmed by consensus will the validator committee collaborate to publish the decryption private key fragment, decrypt and execute the transaction.
* **Influence**\
This completely eliminates "Sandwich Attacks" and censorship of specific privacy transactions because no one knows the contents of a transaction until it becomes irreversible (even the public call portion in Type 103 is encrypted).
#### 7.5 On-chain Execution and Atomicity Guarantees
When a block is executed by validators, Anubis’s unique dual-layer VM architecture comes into play. The EVM interacts with the underlying privacy engine via precompiled contracts, ensuring the atomicity of state transitions.
**7.5.1 Intervention of pre-compiled contracts**
Anubis EVM injects a specific set of pre-compiled contract addresses for handling expensive cryptographic computations. These pre-compiled contracts are implemented in Go/Rust native code, bypassing the overhead of the EVM interpreter.
* **0x0100 (VERIFY\_PROOF)**\
Receives a PLONK proof and common input. The validator performs a bilinear pairing check. If the check fails, the entire transaction is rolled back, and gas is consumed.
* **0x0103 (NULLIFIER\_CHECK)**\
It checks whether the nullable declared in the transaction already exists in the global NullifierSet. This is crucial for preventing double-spending. Unlike simple Boolean checks, this precompiled contract also handles nullable conflicts in concurrent transactions.
**7.5.2 Atomic state transition process**
With the most complex example, Type 103 (Privacy Contract Call) , its on-chain execution flow is as follows:
* **Verification phase:**
* Call VERIFY\_PROOF to verify the ZK proof. The proof includes: the user has the input notes, the total input amount is sufficient to cover publicAmountIn, and the null operator is calculated correctly.
* Call NULLIFIER\_CHECK to ensure that the entered notes have not been spent.
* **"Virtual" unblocking:**
* The system deducts the input notes from memory (logically destroys them).
* The system mints a specified publicAmountIn of tokens (e.g., USDC) from the privacy pool contract to a system-level temporary account.
* Key points: The address of this temporary account is randomly generated and has no connection to the user's real history.
* **External call:**
* Switch the EVM context to a temporary account.
* Execute a call(target, value, data). For example, call Uniswap V3 to perform a swap.
* Since it's a standard EVM call, all DeFi logic (slippage checking, transfers, event triggering) executes normally. The msg.sender seen by Uniswap is a temporary account.
* **Block again:**
* After the external call is completed, the system checks the token balance in the temporary account.
* If the balance  the publicAmountOut, the system transfers these tokens back to the privacy pool contract for locking.
* Based on the commitments in the Payload, the system inserts the newly generated output notes (representing tokens acquired via swap) into the Note Commitment Tree.
* **Status Committed:**
* Write the null sign of the input note to the NullifierSet and permanently mark it as spent.
* Update the Merkle Root of the Notes Tree.
* If an error occurs at any of the steps above (e.g., swap failure or insufficient balance), the entire transaction is atomically rolled back; no nullifier is recorded, and the note state is restored.20
**7.5.3 Cross-layer consistency**
Anubis must guarantee the consistency between the Public State (Account Balance) and the Private State (Note Tree). At any given time, the total amount of tokens locked in the privacy pool contract must equal the sum of all valid privacy notes. This invariance is enforced through both circuit constraints and contract logic:
#### 7.6 State Synchronization and Finality
State synchronization in privacy blockchains is more challenging than in regular blockchains because the state tree is encrypted and massive.
**7.6.1 Only add tree and frontier**
The note commitment tree is a Merkle tree of depth 32. For efficient updates, only the tree's Frontier—the set of nodes along the rightmost path—is stored on-chain. This allows insert new leaves and compute new roots within the  complexity, without reconstructing the entire tree.
**7.6.2 Processing chain reorganization**
When a fork or reorganization occurs, Ethereum only needs to roll back the account balances, but Anubis must roll back the Merkle tree state.
* Rollback logic\
The smart contract maintains historical Root and Frontier snapshots for the most recent 256 blocks. In the event of a reorganization with depth , the contract automatically loads the snapshot from  and discards all commitments inserted thereafter.
* Client response\
Upon detecting a reorganization, a user's wallet must reset the status of affected "Confirmed" notes to "Pending" or "Invalid." If the user has spent notes on the forked chain, the notes will revert to "Unspent" after the reorganization, allowing the user to re-initiate transactions.17
#### 7.7 Econometrics of Gas Model and Privacy Computation
In the design of the Anubis protocol, the economic model is not only a means of resource allocation but also the first line of defense for network security and resistance to denial-of-service (DoS) attacks. Because Anubis employs a hybrid state architecture—simultaneously maintaining the traditional EVM account state tree and the privacy-preserving UTXO note commitment tree—its computational resource consumption pattern differs significantly from the traditional Ethereum single-dimensional Gas model. Privacy transactions involve expensive cryptographic operations (such as elliptic curve pairing, multi-scalar multiplication MSM), and complex sparse Merkle tree (SMT) updates, necessitating the introduction of a more refined, multi-dimensional Gas pricing mechanism.
* **Privacy is infrastructure**\
Privacy computing fees are capped to ensure that users can afford privacy transactions even during periods of extreme congestion.
* **Verification cost subsidy**\
The agreement treasury can subsidize verification costs when necessary, maintaining the accessibility of privacy features.
* **Long-term incentive alignment**\
The larger the volume of privacy transactions, the more secure the network (the larger the anonymity set), therefore privacy users should not be excessively punished.
**7.7.1 In-depth analysis of the composition of computational costs**
Anubis's gas consumption model is designed to accurately reflect the consumption of underlying hardware resources, including CPU cycles, memory usage, disk I/O, and network bandwidth. We will analyze the gas consumption  of a privacy transaction. It can be broken down into the following four core components.\
1\. Basic transaction costs ()
Similar to standard Ethereum transactions, any transaction entering the Anubis mempool must pay a fixed base fee. This fee is set at 21,000 Gas which is used to cover the following costs:
* Signature verification\
Verify the transaction initiator's ECDSA signature (in Level 0 transactions) or Schnorr signature (used to authorize Note spending in privacy transactions).
* Anti-spam mechanism\
To prevent malicious nodes from broadcasting a large number of invalid transactions to the P2P network at extremely low cost, thus consuming the verification bandwidth of all nodes.
2\. Zero-knowledge proof verification cost ()
This is the largest single source of cost in privacy transactions. On traditional EVM chains, performing a single PLONK proof verification using a verification contract written in Solidity can consume over 300,000 Gas, which severely limits the scalability of privacy applications. Anubis addresses this issue by introducing native pre-compiled contracts 0x0100 (VERIFY\_PROOF).
* Native optimization\
The precompiled contract uses a highly optimized Rust library (integrating Halo2 or Arkworks backend) at its underlying level, and leverages assembly-level instruction sets (such as AVX-512) to accelerate finite field arithmetic operations.
* Cost fixed\
Following benchmarking, we have benchmarked the verification cost of a single standard PLONK proof (comprising approximately  constraints) at around 50,000 Gas. This value is dynamically adjusted; the protocol governance layer can upgrade the parameters based on the average hardware performance of all verification nodes in the network.18
* Batch discount\
The protocol supports aggregated proof verification. If a transaction contains multiple proofs (such as complex DeFi combination operations), the cost of subsequent proof verification will be discounted because some pairing checks can be performed together.
3\. State storage and update costs ()
Anubis's two-level state model means that the cost of state updates is also two-track.
* Null value writing\
For each Note spent, its corresponding Nullifier must be written to the global Nullifier Set to prevent double-spending. This is equivalent to a SSTORE operation, but because the Nullifier Set needs to support high-frequency queries and never be pruned, its write cost is set to 20,000 Gas.
* Promise Tree Insertion\
Each time a new Note is generated, its Commitment must be inserted into a Merkle tree of depth 32. This involves calculating the hash path update from the leaf node to the root. To optimize performance, Anubis uses an incremental Merkle tree algorithm similar to Zcash, but in terms of gas pricing, we price each insertion operation at 30,000 Gas. This is to reflect the long-term storage burden of maintaining massive Merkle tree data across all nodes.
4\. Data availability cost ()
While privacy transactions conceal the transfer amount and address, the encrypted Note must be published on-chain so the recipient can synchronize and decrypt it. This data is stored as Calldata, following the EIP-2028 standard; non-zero bytes consume 16 Gas, and zero bytes consume 4 Gas.
**7.7.2 Dual-track gas pricing mechanism**
To avoid vicious competition between privacy transactions and regular DeFi transactions in the same resource pool, Anubis innovatively implemented dual-track gas pricing. This mechanism is based on the multidimensional resource pricing theory, acknowledging that "zero-knowledge proof verification capability" and "EVM general-purpose computing capability" are two types of network resources that are not completely substitutable.19
**Mechanism design principles**
In a one-dimensional gas market (such as the Ethereum mainnet), if the minting of a popular NFT project causes gas prices to surge, even simple transactions can become extremely expensive. In the Anubis network, we do not want to see DEX transaction congestion in the public layer lead to a dramatic increase in transaction costs in the privacy layer, because the effectiveness of privacy relies on the continuous, high-frequency construction of anonymity sets.20
Therefore, two independent BaseFee are maintained in the block header:
* \
This is for standard EVM opcodes and storage read/write operations. The target is to use 15M Execution Gas per block.
* \
This is for privacy-related pre-compiled calls (such as VERIFY\_PROOF) and Note tree updates. The tuning goal is to process 500 proof verifications per block.
Dynamic adjustment algorithm
The two BaseFee are independently adjusted according to the exponential adjustment formula of EIP-1559:
Within the formula,  is an adjustment factor (usually 1/8).
* **Scene A**\
If a block is full of regular ETH transactions but no privacy transactions, will rise, and  will decrease. This encourages users to perform "Assets Shielding" during congestion, as privacy operations are relatively inexpensive at this time.
* **Scene B**\
If a large-scale privacy withdrawal occurs (e.g., exchange aggregation).  will rise rapidly to suppress the load on proof verification nodes, while normal contract interactions will not be affected.
| Resource Dimension | Units of Measurement | Target Capacity/Block | Hard Cap/Block | Pricing Mechanism |
| ------------------ | -------------------- | ------------------------------------- | ------------------------------------------------ | ------------------------------------------- |
| General execution | Execution Gas | 15,000,000 | 30,000,000 | EIP-1559 () |
| Privacy Computing | Privacy Gas | 25,000,000 (approximately 500 proofs) |
50,000,000 (approximately 1000 proofs)
| EIP-1559 () |
Table 7-5 Anubis Gas Dual-track Pricing Model
**7.7.3 Defense strategies against denial-of-service (DoS) attacks**
Due to the computationally intensive nature of VERIFY\_PROOF, malicious attackers might attempt to send a large number of failed verifications to deplete the node's computing power. Anubis has implemented strict defenses at the P2P network layer and memory pool layer:
* **Context-free prevalidation**\
The VERIFY\_PROOF precompiled function is designed as a pure function, independent of blockchain state (such as which account calls it). This means that nodes can concurrently perform mathematical verification on proofs using idle CPU cores before transactions enter the mempool. Only proofs that pass the mathematical verification are allowed to queue in the mempool. This leverages the asymmetric property of ZK proofs: "cheap to verify, extremely difficult to forge."18
* **Punitive deduction**\
If a transaction passes the pre-validation at the P2P layer but fails to be included in the block due to a state conflict (e.g., the nullifier has already been spent), the protocol will still deduct the full amount . This prevents attackers from exploiting race conditions.
* **Validator resource isolation**\
Validator nodes are advised to physically isolate the EVM execution thread and the ZK validator thread. Even if the ZK validator queue is full, it will not block block generation and consensus voting processes, ensuring network liveness.19