# Security Venzo is an onchain vault system for professionally managed asset products. Venzo Earn is designed to make vault access simple for users while the smart contracts underneath enforce deterministic accounting, permissioned operations, bounded valuation inputs, emergency controls, and auditable state transitions. For a vault user or LP, the central idea is straightforward: no single operational action should be able to silently change investor economics. Deposits, redemptions, fees, NAV updates, and strategy movement are either constrained by smart contract rules or recorded onchain so they can be independently monitored.
*** ## What Users Interact With Investors interact with standard vault functions. Behind those functions, Venzo separates the user-facing vault from the control plane that governs settlement, pricing, access policy, fees, strategy allocation, and registry discovery. Privileged actions are restricted by role-based access control, timelock-compatible governance, policy modules, and onchain checks.
*** ## Security Summary Venzo's security model combines governance controls, role separation, investor access controls, emergency pauses, NAV and oracle protections, deterministic epoch settlement, fee caps, strategy and custody controls, and onchain transparency. These layers are designed to make the vault understandable to users while preserving institutional-grade controls underneath. *** ## Vault Access Venzo vaults can be open to any address or run in policy mode. Policy mode allows the vault to require allowlisting, block denylisted accounts, or verify EIP-712 signed authorizations for specific calls. Signed authorization is bound to the function call data, vault address, account, per-vault account nonce, expiration block, chain id, and verifying contract domain. Once used, the nonce increments, preventing replay. *** ## Deposit Lifecycle Deposits are grouped into epochs. A user or approved operator requests a deposit, assets move into the vault, the request is recorded under the controller and deposit epoch, the epoch closes after the required duration, settlement consumes an eligible oracle report, the contract stores the report id, assets-per-share price, fee rates, protocol split, and settlement timestamp, then shares are minted to the vault and become claimable by the controller through `deposit` or `mint`. The important user protection is that the settlement snapshot fixes the economics for that deposit epoch. Later NAV reports, fee updates, or strategy movements cannot rewrite the claim.
*** ## Redemption Lifecycle Redemptions are also epoch-based. A user or approved operator requests a redemption, shares move into the vault, the request is recorded under the controller and redeem epoch, the epoch closes after the required duration, pricing consumes an eligible oracle report and stores priced assets, net shares, fees, protocol split, and settlement price, and settlement checks that the vault has enough idle assets before redemptions become claimable. Once claimed through `withdraw` or `redeem`, the redeemed shares are burned. Claimable redeem assets are reserved and excluded from strategy availability. Pending async deposit assets are also excluded from strategy availability until settlement. This helps prevent the strategy layer from using capital that is reserved for claims or not yet part of active NAV.
*** ## NAV And Oracle Controls Venzo settlement depends on versioned NAV reports, but reports are not accepted blindly. Only enabled reporters can submit or approve reports, and reporter membership is controlled by `ORACLE_ADMIN_ROLE`. The oracle can require quorum, meaning enough distinct authorized reporters must approve the same report data before it finalizes. Each reporter can approve a given digest only once. Reports include `computedAt`, and the oracle rejects future-dated reports or reports older than `maxReportAge`; freshness is checked again at settlement time. The report digest includes the current chain id and oracle contract address, preventing reuse across chains or oracle contracts. Optional metadata hashes can link the NAV value to offchain valuation materials such as portfolio snapshots, administrator reports, pricing files, or review artifacts. Settlement rejects a report computed before the relevant epoch close. `PricingModule` also compares the settlement assets-per-share price against active assets-per-share and reverts if the move exceeds `maxNavPriceDeviationBps`. The default tolerance is 2,000 bps, and governance can adjust it up to 10,000 bps through the pricing role. *** ## Pause And Emergency Controls Venzo has layered emergency controls: global vault pause, deposit pause, redeem pause, share-transfer disable, optional redeem cancellation, strategy allocation pause, and strategy execution pause. This allows operators to stop only the unsafe flow where appropriate, such as pausing new deposits without blocking settled redemptions. Pause and unpause permissions are separated so a fast-response account can pause while resumption can require multisig or timelock review. *** ## Limits, Capacity, and Fee Safety `LimitModule` sets product-level controls including maximum total assets, maximum pending deposit assets, minimum deposit assets, and minimum redeem shares. These controls help prevent dust requests, oversized inflows, and capacity breaches. `FeeManager` enforces fee caps: entry fee up to 20%, exit fee up to 20%, performance fee up to 50%, annualized management fee up to 10%, and protocol share up to 100% of minted fee shares. After initialization, entry and exit fee rates can only decrease. Fees are snapshotted into settled epochs, and performance fees use a high-water mark assets-per-share model.
*** ## Strategy And Custody Controls Strategy execution is separated from the vault. The vault can transfer idle assets to a configured `StrategyManager`, and the manager enforces policy before assets or adapter calls move. Controls include strategy allowlists, offchain/onchain strategy kind validation, adapter `vault()` and `asset()` binding, per-strategy and total debt caps, allocation pause, execution pause, allowed target lists, allowed selector lists, return-value validation, and vault balance-delta validation. This is a key Venzo differentiator: a strategy being whitelisted for trading does not mean it can take investor money away. Whitelisted execution is bounded. Operators cannot call arbitrary contracts, send assets to arbitrary destinations, bypass caps, use assets reserved for redemption, or rescue the vault's underlying asset. A strategy can only operate through approved paths within approved limits. *** ## Share Transfer And Rescue Controls Vault shares are ERC-20 tokens with 18-decimal fixed share precision. The vault can disable ordinary investor-to-investor share transfers through `shareTransferEnabled`, which is useful for permissioned products where secondary transfer must stay within eligibility rules. The vault includes a restricted `rescueToken` function for unrelated tokens accidentally sent to the vault. It cannot rescue the vault's underlying asset, the recipient must be nonzero, and the caller must hold `DEFAULT_ADMIN_ROLE`. *** ## Transaction Atomicity All user-facing and administrative operations are atomic Ethereum transactions. If an internal check fails, the entire transaction reverts. A deposit request reverts if transfer, pause, access, minimum amount, or capacity checks fail. A redeem request reverts if shares are insufficient, redemption is paused, access policy rejects the account pair, or the amount is below minimum. Settlement reverts for empty, already settled, not-closeable, stale, pre-close, inconsistent, or capacity-breaching epochs. Strategy execution reverts if the strategy, target, selector, pause state, or adapter call fails. *** ## Onchain Transparency `VaultRegistry` records the vault address, underlying asset, strategy manager, report oracle, vault type, name, symbol, and active flag. Registration and metadata refresh require `REGISTRAR_ROLE`, and registration validates internal consistency between the vault, strategy manager, and asset. Core contracts expose read-only state for roles, pause flags, access mode and policy, limits, oracle state, active NAV, epoch state, fee state, strategy state, and registry state. This lets investors, auditors, operations teams, and monitoring systems independently check how the vault is configured and whether live operations remain aligned with approved policy. *** ## Testing, Deployment Verification, and Boundaries The repository includes Foundry tests covering vault deployment wiring, access control, authorization-based access, pause behavior, limits, fees, pricing and settlement, strategy allocation and execution policy, accounting invariants, registry behavior, fully asynchronous vault behavior, and sync-deposit async-redeem vault behavior. Standard verification commands are `forge build`, `forge test`, and `forge fmt` . Before production deployment, each product should verify admin role transfer to the intended Safe or timelock, deployer role handling, oracle reporters and quorum, `maxReportAge`, `maxNavPriceDeviationBps`, fee settings, strategy allowlists, debt caps, targets, selectors, pause/unpause separation, registry records, and source verification on the relevant block explorer. Venzo's smart contracts enforce onchain permissions, deterministic accounting, price-consumption rules, and strategy execution constraints. Some inputs, especially offchain NAV components and strategy valuations, still depend on operational controls outside the EVM. Venzo addresses those boundaries through reporter separation, review workflows, metadata hashes, multisig or timelock governance, independent monitoring, and product-specific valuation procedures. --- # 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://venzofinance.gitbook.io/venzofinance-docs/legal-and-compliance/security.md?ask= ``` 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.