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
    • Risks
      • Counterparty Risks
      • Liquidity Risks
      • Oracle Risks
      • Overutilization Risks
      • Regulatory Risks
      • Smart Contract Risks
    • Security
      • Audits
      • Bug Bounty
    • 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
  1. About Us

Road to Decentralization

Treehouse is committed to creating an inclusive and resilient ecosystem where community involvement and governance are pivotal in shaping the evolution of digital asset fixed income markets. While blockchain aims to eliminate inefficient intermediaries, effective governance is essential for ensuring internal processes, providing a voice to ecosystem participants, and preventing gridlock.

Drawing from historical precedents, Treehouse recognizes the importance of establishing a governance system with balanced power distribution and checks and balances. We aim to leverage smart contracts to streamline governance interactions, reducing bureaucratic overhead often seen in traditional organizations. In the rapidly evolving blockchain landscape, agility is paramount, and Treehouse remains vigilant and flexible to meet the needs of all stakeholders.

Initially, decision-making authority will primarily rest with the development team.

As Treehouse matures, we will gradually transition towards token-based governance, ensuring that the ecosystem is self-sustaining and responsive to the needs of its participants.

PreviousAPINextBuild With Us

Last updated 10 months ago