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

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

tbd

---

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	ERC-721 / ERC-1155 Fractional Vaults (e.g. ERC-4626 wrapping NFTs)
Cross-Chain Bridges	Bridge Routers (e.g., Axelar, Hop) Messaging & Relayer contracts

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.

---

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.

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.