# Performance (internal)

## Introduction 

An overview of Venn’s **latency** characteristics, based on our latest benchmark data. This page outlines what we measure, how we measure it, and what to expect when using Venn in production.

***

## Latency Component Breakdown

1. **User ↔ Venn Node:**
   * Time for the user to send the transaction to the Venn node (Blockbeat).
2. **Fetching the Trace:**
   * Fetching the full transaction trace (internal calls, balances, logs) needed for inspection.
3. **Security Validation:**
   * Running the transaction through Venn detectors to decide if it’s malicious.
4. **Consensus (Operator Network):**
   * Back-and-forth communication among security operators to agree on the legitimacy of transactions.
5. **Signing:**
   * Operators sign off on the final decision and submit it on-chain.

***

## Benchmark Results

| Step                    | Duration (ms) in L1 | Duration (ms) in L2's |
| ----------------------- | ------------------- | --------------------- |
| **User ↔ Venn Node**    | 200                 | 100                   |
| **Fetching the Trace**  | 500                 | 500                   |
| **Security Validation** | 20                  | 20                    |
| **Consensus**           | 200                 | 100                   |
| **Signing**             | 50                  | 25                    |
| **Total**               | 500 ms              | 250 ms                |

{% hint style="info" %}
Note: Several of these steps (e.g., X and Y) occur in parallel, which helps reduce the overall end-to-end latency. Therefore, the total end-to-end latency is **not** the sum of each individual step.
{% endhint %}

***

## Factors Influencing Latency in Venn

* **Chain Type:**
  * L2 networks (e.g., Optimism, Arbitrum) typically finalize blocks more quickly than L1, which reduces end-to-end latency.
  * Native gas and block times on L1 (e.g., Ethereum Mainnet) create additional on-chain confirmation delays.
* **Number of Nodes (Operators):**
  * As you add more operator nodes, consensus can take longer (more validators contribute and validate).
* **Security Model:**
  * **Default Security (Root Network):** A standard configuration provides predictable performance.
  * **Custom Security (Subnets)**: The more complex security models you run, the longer the “Security Validation” component takes.
* **Transaction Complexity & Trace Size:**
  * Transactions involving large call trees or significant internal activity require more time to fetch and analyze the complete trace.
* **Network Conditions:**
  * High congestion or rapidly increasing gas fees can hinder on-chain finalization for the firewall transaction.
* **Geographic Location:** 
  * The distance between your client and the operator network affects latency.

***

By understanding and optimizing these factors—chain choice, operator setup, security model complexity, and resource allocation—you can guarantee that Venn’s latency stays minimal while still providing robust, real-time protection.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.venn.build/venn-network/performance-internal.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.