Treehouse Protocol
  • The Decentralized Fixed Income Layer
  • Overview
    • Treehouse Architecture
    • Key Terms
    • Learning Resources
    • Technical Whitepaper
    • Support and Community
  • tETH
    • Introduction
    • Architecture
      • Yield Optimization
      • Gas Optimization
      • Token Accounting
      • Deployment Process
      • Redemption Process
      • Safety Mechanisms
      • Profitability Assessments
      • Fees
    • Risks
      • Counterparty Risks
      • Liquidity Risks
      • Oracle Risks
      • Overutilization Risks
      • Regulatory Risks
      • Smart Contract Risks
    • Security
      • Audits
      • Bug Bounty
      • Timelock
    • User Guides
      • How to Deposit
      • How to Withdraw
        • Below Redemption Band
          • Swap
          • Fast Redemption
        • Above Redemption Band
          • Normal Redemption
          • Fast Redemption
      • How to LP
      • Referral System
      • How to Bridge
    • Key Addresses
  • DOR
    • Introduction
    • Key Design Principles
    • Stakeholders
      • Checks & Balances
    • Consensus Mechanism
    • Payout Mechanism
      • Panelist Pool
      • Delegator Pool
      • Payout Example
      • Payout in DORs with Multiple Tenors
    • Slashing Mechanism
      • Slashing Formula
      • Distribution of Slashed Tokens
      • Slashing in DORs with Multiple Tenors
      • Exceptional Cases
    • Glossary
    • Applications
    • Appendix
  • TESR
    • Treehouse Ethereum Staking Rate (TESR)
    • Ethereum’s Proof of Stake (PoS) Mechanism
      • Consensus Layer Rewards
        • Attestation Rewards
        • Sync Committee Rewards
        • Proposer Rewards
      • Execution Layer Rewards
        • Priority Fees/Tips
        • Maximal Extractable Value (MEV) Bribes
    • Observation Period
    • Publication Time
    • Index Calculation
    • Data Precision
    • Disruptive Events To Index Calculations
      • Ethereum Fails to Finalize Blocks
      • Changes to the Staking Reward Mechanism
      • Too Few Validators
    • Pre-publication Reliability Checks
      • Rate Volatility Check
      • TESR Component Sanity Data Check
    • Governance
      • Rate and Methodology Adjustments
      • Monitoring
      • Cessation
      • Licensing and Distribution
    • Data Sources
    • Decentralization
      • How Consensus is Reached?
    • Get Published Rates
      • API
      • Smart Contract
  • DOR Panelist Terminal
    • Panelist Submission Guide
  • TELR
    • Treehouse Ethereum Lending Rate (TELR)
  • Methodology
  • Data Sources
  • Market Exclusion Criteria
  • Weighting Scheme
  • Update Frequency
  • Get Published Rates
    • API
  • TEBR
    • Treehouse Ethereum Borrowing Rate (TEBR)
  • Methodology
  • Data Sources
  • Market Inclusion Criteria
  • Weighting Scheme
  • Update Frequency
  • Get Published Rates
    • API
  • About Us
    • Road to Decentralization
    • Build With Us
  • Legal
    • Privacy Policy
    • Terms of Service
Powered by GitBook
On this page
  • What Is a Timelock?
  • Why a 5-Day Delay?
  • What This Means for You
  1. tETH
  2. Security

Timelock

All Treehouse contracts are secured by a 5-day timelock, ensuring no critical action executes immediately and giving everyone a clear window to see and respond to upcoming updates.


What Is a Timelock?

A timelock is a built-in delay between scheduling a governance action (like upgrading vault logic or changing fees) and when it actually happens. This pause keeps the protocol transparent and gives everyone time to review or react.

Why a 5-Day Delay?

  • Adequate Notice: A full five days gives users ample time to spot and evaluate any changes.

  • Action Window: If you’re uncomfortable with an upcoming update, there’s plenty of time to withdraw your funds.

  • Security Hedge: Even if an admin key is compromised, the attacker must wait five days, giving the community or multisig holders time to intervene.

What This Means for You

  • Transparency: Every upcoming change is publicly viewable on-chain.

  • Control: You have at least five days to decide if you want to stay in the protocol.

  • Safety: The timelock prevents immediate, unreviewed changes and strengthens the protocol’s non-custodial security.

By enforcing a 5-day buffer on all governance actions, Treehouse balances the need for protocol upgrades with strong user protections and clear visibility for everyone.

PreviousBug BountyNextUser Guides

Last updated 20 days ago