# Root vs Subnet (internal)

## Introduction 

Venn provides two security deployment options to fit different needs:

* **Root Network**: Venn's default, shared security layer- powerful, battle-tested, and ready for integration. Ideal for most protocols and developers in need of robust protection with a simple setup.
* **Subnets:** Customizable, dedicated security environments built on top of the Root Network. Best for unique implementations or specialized security requirements—allowing custom detectors, operator selection, and tailored fee structures.

***

## Core Differences: Root Network vs. Subnet

<table data-full-width="true"><thead><tr><th width="175.45703125">Aspect</th><th width="338.6171875">Root Network</th><th>Subnet</th></tr></thead><tbody><tr><td>Integration steps</td><td><p></p><ul><li><strong>Add Venn Modifiers to Your Smart Contracts</strong></li><li><strong>Deploy Updated Smart Contracts to Your Target Chain</strong></li><li><strong>Register Your Contracts with the Venn Root Network</strong></li></ul></td><td><p></p><ul><li><strong>Define Your Custom Security Requirements</strong></li><li><strong>Select Potential Operator Nodes to Fulfill Those Requirements</strong></li><li><strong>Add Venn Modifiers to Your Smart Contracts</strong></li><li><strong>Deploy Updated Smart Contracts to Your Target Chain</strong></li><li><strong>Register Your Contracts with Your Dedicated Subnet</strong></li></ul></td></tr><tr><td>Effort &#x26; Complexity</td><td><p><strong>Low Effort:</strong> </p><p></p><ul><li>Leverage Venn’s default detectors and SDK—no custom development.</li><li><strong>Quick Testing:</strong> Only basic integration tests (e.g., audit) are required.</li><li><strong>Minimal Coordination:</strong> Follow standard docs; no operator selection or custom security design.</li></ul></td><td><p><strong>High Effort:</strong></p><p></p><ul><li><strong>Custom Detector Development:</strong> Build, integrate, and thoroughly test the detection logic.</li><li><strong>Operator Selection:</strong> Identify and onboard a cohort of nodes aligned with your security needs.</li><li><strong>Use-Case Definition:</strong> Define precise threat models and validation rules.</li><li><strong>Comprehensive Testing:</strong> Perform backtesting and simulations to fine-tune performance.</li><li><strong>Extended Coordination:</strong> Deep collaboration between our security team, our engineering team, and chosen operators—more time-intensive and complex.</li></ul></td></tr><tr><td>Customization</td><td><p><strong>Limited:</strong></p><p></p><ul><li><strong>Protected Scope:</strong> Choose which smart contracts or specific functions to guard.</li><li><strong>Chain Selection:</strong> Pick from supported chains without modifying core detectors.</li><li><strong>Fee Model:</strong> Decide whether to subsidize security costs or pass fees to end users via a security surcharge.</li></ul></td><td><p><strong>High:</strong></p><p></p><ul><li><strong>Detectors &#x26; Rules:</strong> Create and configure entirely custom detection logic, thresholds, and policies.</li><li><strong>Operators:</strong>  select operator nodes specific to your subnet.</li><li><strong>Fee Structures:</strong> tailored to your economic and operational requirements.</li><li><strong>Environment Configuration:</strong> Customize every aspect of the security stack.</li></ul></td></tr><tr><td>SLA &#x26; Support</td><td>tbd</td><td>tbd</td></tr><tr><td>Pricing</td><td><ul><li><strong>Usage-Based Fees:</strong> Each protected transaction consumes a small on-chain fee (≈ $0.01) drawn from the pre-funded by the protocol security pool.</li><li><strong>Protocol-Subsidized:</strong> Protocol locks up (stakes) funds in the security pool; fees are deducted automatically.</li><li><strong>Billing Cycle:</strong> Security fees are collected weekly from the pool; any unspent funds can be unstaked and returned to the protocol.</li></ul></td><td><p></p><ul><li><strong>Custom Fee Models:</strong> Tailor your pricing to fit your needs—choose protocol-subsidized, user-paid, cross-chain aggregation fees, token swap levies, or other on-chain or off-chain payment structures.</li><li><strong>Onboarding &#x26; Setup Fees:</strong> Optional one-time fees for subnet configuration, operator provisioning, and custom SLA commitments.</li><li><strong>Billing Terms:</strong> Negotiable per integration—billing frequency, fee tiers, and staking requirements are defined in your subnet agreement.</li></ul></td></tr><tr><td>Use Cases</td><td><ul><li><p>DeFi Protocols</p><ul><li>AMMs</li><li>Lending &#x26; Borrowing</li><li>Derivatives</li><li>Yield Aggregators &#x26; Vaults</li><li>Stablecoin &#x26; Algorithmic Stablecoin</li><li>Launchpads &#x26; IDO Platforms</li><li>Insurance Protocols</li><li>Oracle Services/Price feeds</li><li>NFT / Marketplaces</li></ul></li></ul></td><td>Any use case can be potentially developed</td></tr></tbody></table>

{% hint style="info" %}
tbd
{% endhint %}

***

## Commonly used contracts suitable for Venn integration:

| Category                    | Contract Types                                                                                                         |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Token Standards**         | `ERC20` `SafeERC20` `ERC20Permit` `ERC20Capped`                                                                        |
| **Ownership & Access**      | `Ownable` `Pausable` `AccessControl TimelockController`                                                                |
| **Reentrancy & Safety**     | `ReentrancyGuard`                                                                                                      |
| **Upgradeable Proxies**     | `TransparentUpgradeableProxy` `UUPSProxy` `ProxyAdmin`                                                                 |
| **AMMs & Pools**            | `UniswapV2Pair` `UniswapV3Pool` `StableSwap CryptoPool`                                                                |
| **Staking & Rewards**       | `StakingRewards` `RewardPool`                                                                                          |
| **Governance**              | `GovernorAlpha` `GovernorBravo` `GovernorV2`                                                                           |
| **Snapshot & Voting**       | `Snapshot`                                                                                                             |
| **Vesting & Escrow**        | `TokenVesting` `TokenEscrow` `VestingRegistry`                                                                         |
| **Treasury & Fees**         | `FeeDistributor` `FeeCollector`                                                                                        |
| **Oracles & Data Feeds**    | Chainlink Aggregator Interfaces                                                                                        |
| **Batch Utilities**         | `Multicall` / `Multisend`                                                                                              |
| **NFT & Fractionalization** | <p><code>ERC-721</code> / <code>ERC-1155</code></p><p>Fractional Vaults (e.g. <code>ERC-4626</code> wrapping NFTs)</p> |
| **Cross-Chain Bridges**     | <p>Bridge Routers (e.g., Axelar, Hop) </p><p>Messaging & Relayer contracts</p>                                         |

{% hint style="info" %}
**Note:** You don’t need to use the exact OpenZeppelin contracts listed above—any version or fork of these patterns (or your own custom implementations) can also be secured by Venn. These examples simply illustrate common contract types and architectures found in DeFi.
{% endhint %}

***

## When to recommend Root Network and when a subnet

#### Root Network

* **Default Starting Point:** Almost every new integration should begin with the Root Network. It delivers robust, battle-tested security with minimal setup—ideal for most protocols and developers.
* **Rapid Time-to-Market**: If you need to go live quickly (within weeks), the standard configuration provides the fastest path.
* **Standard Threat Profiles:** For protocols whose security needs align with Venn’s core security logic, Root provides immediate value.

#### Subnet

* **Fallback for Specialized Needs:** If a prospect cannot—or chooses not to—move forward on the Root Network, then explore a Subnet.
* **Performance-Sensitive Integrations:** When latency or throughput demands exceed what Root’s shared operator network can guarantee, a dedicated Subnet can be tuned for low latency.
* **Custom Security Models:** If a protocol requires detectors or rules beyond Root’s standard set, a Subnet enables the implementation of those requirements.

{% hint style="info" %}
In practice, always lead with the Root Network. Reserve Subnets for advanced use cases where Root’s defaults won’t meet a client’s specialized performance or security needs.
{% endhint %}


---

# 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/root-vs-subnet-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.