Vetro Protocol

Vetro is a fully collateralized, yield-generating protocol for creating pegged tokens built for DeFi.

Version 2.0 introduces a modular and robust architecture that separates user interactions, treasury management, and token logic into distinct, auditable contracts. The protocol can issue tokens pegged 1:1 to various assets including USD (VUSD), BTC (vetBTC), and more. By integrating with premier yield protocols like Aave, Compound, and Morpho, the collateral is put to work, generating passive yield for the protocol.

Key Features

• Fully Collateralized: Always backed 1:1 by high-quality collateral.
• Multi-Asset Support: Issue pegged tokens for various assets - USD (VUSD), BTC (vetBTC), and more.
• Yield-Generating: Collateral is deposited into leading DeFi protocols (e.g., Aave, Compound,) to generate yield.
• Automated Liquidity Provisioning: A portion of the generated yield can be used to deepen liquidity on decentralized exchanges.
• Modular & Secure Architecture: Core logic is split into Gateway, Treasury, and PeggedToken contracts for clarity and security.
• Flexible User Actions: Users can either specify the input amount (deposit/redeem) or the desired output amount (mint/withdraw).
• Withdrawal Delay System: Optional time-lock mechanism for redemptions with instant redeem whitelist for trusted addresses.
• Robust Governance: A secure Owner-Keeper model separates strategic decisions from routine operational tasks.
• Secure and Audited: Built with security as a first principle, with comprehensive test coverage.

Architecture Overview

The Vetro Protocol system is composed of three core contracts that work in concert to provide a seamless and secure user experience.

graph TD
    %% Flow
    subgraph " "
        User -- "User Actions (deposit, mint, etc.)" --> Gateway
        Keeper -- "Operational Tasks (push/pull)" --> Treasury
        Gateway -- "mints/burns" --> PeggedToken[Pegged Token]
        Gateway -- "forwards/requests collateral" --> Treasury
        Treasury -- "deposits/withdraws collateral" --> Protocols["DeFi Protocols (Aave, Compound, Morpho)"]
        Treasury -- "validates price" --> Oracles[Chainlink Oracles]
    end

    class User,Keeper actor
    class Gateway,Treasury,PeggedToken contract
    class Protocols,Oracles external

    %% Styling
    classDef actor stroke:#01579b,stroke-width:2px
    classDef contract stroke:#ff6f00,stroke-width:2px
    classDef external stroke:#2e7d32,stroke-width:2px 

Loading

Core Components

1. Gateway.sol: The single entry and exit point for all users. It handles the logic for the four primary user actions (deposit, mint, redeem, withdraw) as well as the withdrawal delay system for enhanced security. To execute all calculations securely, the Gateway queries the Treasury for real-time asset prices and uses this data along with fees, price tolerance, and mint limits.
2. Treasury.sol: The custodian of all collateral. It manages the whitelist of supported assets, interfaces with yield-generating protocols, and integrates with Chainlink oracles. It serves as the single source of truth for asset prices and risk parameters.
3. PeggedToken.sol: The ERC20 pegged token contract (e.g., VUSD, vetBTC). It includes ERC20Permit for gasless approvals and ensures that only the Gateway contract can mint new tokens.

Withdrawal Delay & Redeem Request System

The Gateway implements an optional withdrawal delay mechanism that adds a time-lock to redemption operations, providing an additional layer of security for the protocol and its users.

How It Works

When the withdrawal delay is enabled, users have two options for redeeming their pegged tokens:

Option 1: Request Redeem (Delayed Withdrawal)

Users can submit a redemption request that locks their pegged tokens in the Gateway contract for a configurable delay period (e.g., 7 days):

1. requestRedeem(peggedTokenAmount): Locks the specified amount of pegged tokens in the Gateway and initiates a redemption request. After the delay period passes, the user can execute redeem() or withdraw() with any supported output token.

2. cancelRedeemRequest(): Users can cancel their pending request at any time before claiming, which immediately returns their locked tokens.

3. Multiple Requests: If a user submits a new request while having an active one, the amounts are merged and the delay timer resets.

Option 2: Instant Redeem (Whitelisted Addresses)

Certain addresses can be added to the instant redeem whitelist by the protocol owner, allowing them to bypass the withdrawal delay entirely:

• Whitelisted addresses can call redeem() or withdraw() directly without submitting a request
• Useful for protocol-owned liquidity, integrations, or trusted contracts
• Owner can manage whitelist via addToInstantRedeemWhitelist() and removeFromInstantRedeemWhitelist()

Configuration

The withdrawal delay system can be configured by the protocol owner:

• toggleWithdrawalDelay(): Enable or disable the withdrawal delay feature globally. When disabled, all users can redeem instantly.
• updateWithdrawalDelay(newDelay): Adjust the delay period (e.g., change from 7 days to 14 days).

Benefits

For Users:

• Enhanced Security: Time-lock provides a buffer period to detect and respond to potential security issues
• Flexibility: Users can cancel requests if they change their mind
• Partial Redemptions: Users can redeem a portion of their requested amount while keeping the rest locked
• Excess Redemptions: Users with claimable requests can redeem more than their locked amount (the excess requires instant redeem permission)

For Treasury Management:

• Enhanced Security: The withdrawal delay provides a buffer period to detect and respond to potential security issues
• Risk Management: The delay provides visibility into potential large withdrawals, allowing the protocol to prepare and manage liquidity risk effectively

Governance: The Owner-Keeper Model

Vetro Protocol employs a two-tiered access control model to enhance security:

• Owner: A highly-secured address (e.g., a multi-sig) responsible for strategic decisions like whitelisting new assets, setting fees, and appointing Keepers.
• Keepers: Authorized addresses with a limited set of permissions for routine operational tasks, such as managing funds between the Treasury and yield vaults or pausing deposits/withdrawals for an asset.

Local Development

This project uses Foundry.

Prerequisites

• Git
• Foundry

Installation & Setup

1. Clone the repository:

   git clone https://github.com/hemilabs/vetro-contracts.git
   cd vetro-contracts

2. Install submodules and dependencies:

   git submodule update --init --recursive
   forge install

Compiling

To compile the contracts, run:

forge build

Testing

To run the full test suite:

forge test

For more verbose output:

forge test -vvv

To calculate test coverage:

forge coverage

Security and Audits

Security is the highest priority for the Vetro protocol. The contracts have been designed with best practices in mind and include:

• Comprehensive test suite with high branch coverage.
• Protection against reentrancy attacks.
• Non-upgradeable core contracts.
• Strict checks for oracle price staleness and deviation.

This section will be updated with links to external audit reports once they are completed.

License

This project is licensed under the MIT License. See LICENSE for more information.