Architecture
Goal: Make it as easy as possible for protocols to integrate with the Mix.eth front end. Have a standard interface for interacting with protocols in both the inferface AND underlying design.
There was initially a line of thinking towards creating JSON no-code 'protocol definitions' with things like required data subscriptions and action mappings and auto-generated forms. I think there will be too many little edge cases in different protocols to make it truly useful, and that we should focus on great documentation and ease of adding protocols from a software architecture perspective - both for our own use and to help third party teams with integrations.
The app should be designed in such a way that minimal changes are needed to add a new protocol, and the changes are isolated from the rest of the system as much as possible.
Zerions' general approach is to have a standardized way to interpret value within DeFi protocols and complex derivative tokens. It also features on-chain registry of protocols and assets, with some metadata.
It has contracts called Adapters that provide the standard interface to getting balances of assets & debt within protocols, as well as for interpretting the value of complex derivative tokens.
This very much aligns with Mix' architecture goal. We'll utilize the DeFi SDK value reading capabilities and expand upon it's 'Adapter' design to provide a standard interface for write actions.
Mix functionality is grouped into 'Widgets'. Each protocol should be useable with a widget via the same interface as other protocols.
Portfolio
Earn Interest
The user will simply select an asset + protocol, and the UI component will perform the same action on the ProtocolAdapter selected.
Mix Assets
Withdraw
The registry functionality could be expanded to essentially serve as a TCR for supported protocols and tokens within Mix. This is an alternative to just updating a config file and pushing a new version of the website out.
The dxDAO may be interested in this approach so that its' governance mechanism can explicitly give approval to adding protocols and assets. This could be also just done via signal proposals, and have the developers add to normal config files to execute the DAO's will.
Software updates (pushing new website versions) will still need to happen in any case.