forked from DECA/DAOTask
85 lines
2.7 KiB
Markdown
85 lines
2.7 KiB
Markdown
# DECA Architecture
|
|
## Abstract
|
|
The project development will be done modularly and will be splitted into
|
|
multiple subprojects which require the proper research and development.The
|
|
Goal is to develop all the architecture require for the [DECA Protocol](https://docs.google.com/presentation/d/1H4V5X0X-9jnulwmmQBKk7PiStqKoPh_t_h7F0R3kLw0/edit#slide=id.p)
|
|
|
|
## Project Overview
|
|
|
|
### General Diagrams
|
|
|
|
|
|
### Development
|
|
|
|
- [ ] Module 0: Modify tunk to be IPFS compatible (Possibly use CAR)
|
|
- [ ] Module 1: YEW DAPP that connects to HELIA (Typescript)
|
|
- [ ] Module 2: YEW DAPP that connects to the DECA Contract using Ethers-web3
|
|
- [ ] Module 3: YEW DAPP that includes and updated version of OrbitDB and extracts data from Ethers-Web3(Depends on 1,2)
|
|
- [ ] Module 4: Fleek YEW integration with Docker (for the IPNS/DNS and CI/CD).
|
|
- [ ] Module 7: ERC1155 Development and testing (cctokens, DECA2, SBt)
|
|
- [ ] Module 8: DAO (Vaults, ranking/quadratic voting, whitelist, etc)
|
|
- [ ] Module 9: Liquidity Pools DeFi
|
|
- [ ] Module 10: Lending DeFi
|
|
- [ ] Module 11: Integration(requires from 1-8)
|
|
|
|
### Research
|
|
|
|
- [ ] Module 5: Architecture specifications for DECA Protocol (R&D, Class Diagrams).
|
|
- [ ] Module 6: Tokenomics Ultrasound Model (Research and Dev)
|
|
|
|
### Security Testing
|
|
|
|
- [ ] Module 11: Security Audit
|
|
|
|
### Future R&D
|
|
- [ ] Use Cases.
|
|
- [ ] Payto DAO (SmartWallet)
|
|
- [ ] Zero Knowledge Proof Carbon Offset (Privacy and Fungibility).
|
|
|
|
|
|
## Module Description
|
|
|
|
### Module 0
|
|
|
|
This module is to ensure that the trunk build website (yew mostly)
|
|
builds a decentralizable website and assets. Consider using CAR
|
|
management for the assets.
|
|
|
|
[Module 0 Specification](./module0.md)
|
|
|
|
### Module 1
|
|
|
|
This module will ensure that the website and its assets runs in a HELIA instance.
|
|
This will add seeds and thus network speed to the content distribution. All the
|
|
assets should be integrated in the project so that it does not depend on centralized
|
|
systems. This module is important to ensure frontend decentralization.
|
|
|
|
[Module 1 Specification](./module1.md)
|
|
|
|
### Module 2
|
|
|
|
This module will include its own ethers wasm implementation, so that it connects
|
|
to the Ethereum blockchain and perform some testing operations. The Goal is to
|
|
ensure the ethers connector can be decentralized and included in the project code.
|
|
This module is important to ensure comunication with the smart contracts in a
|
|
decentralized way.
|
|
|
|
[Module 2 Specification](./module2.md)
|
|
|
|
### Module 7
|
|
|
|
|
|
> dig1. Shows the front end DAPP architecture for SBT
|
|
|
|
### Module N
|
|
|
|
|
|
|
|
> Important Note: all modules should be tested in a decentralized environment
|
|
|
|
|
|
## References
|
|
[^1]: https://github.com/web3-storage/ipfs-car
|
|
[^2]: https://ipld.io/specs/transport/car/
|
|
|