Decentralized system architecture
Last updated
Last updated
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:
Now, we would like to consider each component separately and expand on their functionality.