Enjoyoors
  • WHITEPAPER
    • Introduction
    • User-abstracted rehypothecation
      • Giga CDP of Enjoyoors
      • Giga CDP design
      • Deep secondary liquidity for gigaAssets
    • Protocol stability
      • Efficient portfolio management
      • Supply regulation for gigaAssets
      • System-wide insurance
    • Risk management framework
      • Market risks
      • Technical risks
      • gigaAsset allocation rules
    • Decentralized system architecture
      • Public chain infrastructure
      • Orchestrator appchain
      • Oracles
      • Interchain communications
    • Key protocol features
      • Epochs
      • Reward auctions
      • Intelligent peg adapters
    • Further considerations
      • Making RWAs work harder
      • Own DeFi ecosystem
      • Our priorities
  • SYSTEM ARCHITECTURE
    • Overview
    • Public Blockchain Infrastructure
      • Vaults
      • gigaAsset Manager
      • Target Protocols
      • Target Protocol Adapters
      • Intelligent Peg Adapters
      • AMM Pools
      • Rewards Treasury
    • AVS Relayer
      • Relayers
    • Enjoyoors Orchestrator AppChain (L3)
      • Enjoyoors Management System
      • Orchestrator AppChain Layers
      • Security Mechanisms
      • Price Oracle
      • Governance
      • gigaCDP
      • Portfolio Management System
      • Auctions
      • Insurance Pool
    • gigaAsset Bridge
    • gigaAssets
    • Epochs
  • PROTOCOL FLOWS
    • Deposit
    • Withdraw
    • Auction
  • RISKS
    • Protocol risks
Powered by GitBook
On this page
Export as PDF
  1. WHITEPAPER

Decentralized system architecture

PreviousgigaAsset allocation rulesNextPublic chain infrastructure

Last updated 3 months ago

Considering the protocol's ultimate omni-chain nature, the most pertinent question about its architecture is the extent of its decentralization. How non-custodial and permissionless it truly is, and whether users should be concerned about the safety of their funds. Given a greenfield opportunity to design Enjoyoors, we chose to develop an architecture that addresses potential concerns such as these, ensuring the protocol is both fairly decentralized and effective.

With this intention, we restricted client-facing vaults to only accepting funds and releasing them back to depositors, prohibiting transfers to third-party addresses or any bridging functionality. Additionally, we limited the permissions of protocol components that orchestrate vault operations and outlined a roadmap for fully decentralizing orchestration. Have a look at a high-level overview of the eventual protocol architecture:

Figure 5: Decentralized architecture of Enjoyoors

Now, we would like to consider each component separately and expand on their functionality.