The goal of this repository is to implement the diamond pattern (ERC-2535) through DeFi vaults.
All vaults will use the same diamond to store their common data. A vault is a facet of a diamond, as there can be many types of vault with different logic implementation.
Explanation with a dummy diagram:
A facet can also have a specific proxy storage (eternal storage, another diamonds stockage, etc...). This will depend on the evolution of the dApp complexity throught development lifecycle.
For greater compasability and module oriented project, a new diamond can be create for each these features: DEXs Integration, Royalities Integration, Streaming Payment Protocol, Streaming Payment Configuration, Multisigs Integration, etc...
An overview of the uses of each visibility layer is as follows:
| folder | layer | contents | description | example |
|---|---|---|---|---|
| - | interface |
enum, struct, event, custom error, modifier & function prototypes |
defines anything a child contract needs (even in IxyzInternal.sol) to split code in independent modules |
IRandomnessWritableInternal.sol, IRandomnessFallback.sol, IRandomnessReadble.sol |
| fallback | external | any function visibility | set of functions, which are only used when a callback is made to the diamond (e.g. VRFConsumerBaseV2.fulfillRandomWords). It can modify and/or read the state, which is why it can be nor in readable or writable only. |
RandomnessFallback.sol |
| readable | external | external or public functions | set of functions that defines a module's getters | RandomnessReadable.sol |
| writable | external & internal | any function visibility | set of functions that defines a module's core logic; internal function always declares as xyzWritableInternal.sol |
RandomnessInternalWritable.sol, RandomnessWritable.sol |
| ./ | storage | internal library functions, structs | library for accessing and modifying storage; useful when sharing access to storage between implementation contracts that will be deployed separately (such as in the "diamond" proxy architecture) | RandomnessStorage.sol |
Commits format & version naming: https://r-code.notion.site/Commits-and-versions-bedeee671dec446aa4f8688bc2d9db8c
- Yields percentage and timelock varies from vaults to vaults
- Generally speaking the longest you lock, the highest the rewards
- Deposit automatically timelock the transfered amount of ETH/tokens
- Receive proportional amount of shares depending on the ETH/tokens amount deposited
- Yields are by default paid in RCODE (project token)
- Claim rewards after the time setup by the vault, otherwise earn yield as soon as ETH/tokens are deposited
Note: in diamond storage for deposited balance, save the deposited type (native ETH, tokens, NFTs) and sub-type (e.g. ERC-20, ERC-777, ERC-721, ERC-1155...)
- Deposit ETH & mint shares through a dedicated function
- Withdraw ETH & burn shares through a dedicated function
- Deposit whitelisted ERC20 & mint shares through a dedicated function
- Withdraw whitelisted ERC20 & burn shares through a dedicated function
- Deposit using permit function for gas optimisation:
- Deposit tokens
- Other actions: TO LIST
Will surely use Uniswap, maybe 1inch.
- Support whitelisted LP tokens to earn yields
- Connect DEXs to manage on-chain swap:
- claim rewards and swap them (if possible) in the given array of token(s)
- direct LP tokens swap: add liquidity on DEXs & deposit LP token in the vault for yields
- Support whitelisted NFT collections in vaults
- Percentage of earned rewards will be paid to NFT creator as royalties
- RFT integration?
Integrate sablier.finance or superfluid. Maybe later both of them.
- Pay rewards in real time if the user set it up:
- each address/user must configure to enable (disabled by default)
- default config for all vaults
- one configuration
- forward rewards to another wallet
- timeframe payment
- Swap rewards & stream payment
- Some vaults only useable with/by multisig
- Can Safe multisig interact with our contract without any extra code? If not implement it (Safe plugins?)
- Can a multisig by the owner to manage upgrades of anything without any extra code? If not implement it (Safe plugins?)
- 2535: dimaonds
- 4626: vault
- 2612: permit (off-chain approval)
- 195 & 1820: interfaces registries
- 2981: NFT royalities
- EIPs for streaming payments?
- EIPs for multisigs?
- Code formatter & linter: prettier, solhint, husky, lint-staged & husky
- Foundry
- Solidity Patterns
- Solcurity Codes
- Secureum posts (101 & 101: Security Pitfalls & Best Practice)
- Smart Contract Security Verification Standard
- V1: Architecture, Design and Threat Modelling
- V2: Access Control
- V3: Blockchain Data
- V4: Communications
- V5: Arithmetic
- V6: Malicious Input Handling
- V7: Gas Usage & Limitations
- V8: Business Logic
- V9: Denial of Service
- V10: Token
- V11: Code Clarity
- V12: Test Coverage
- V13: Known Attacks
- V14: Decentralized Finance
- SWC
- Well refactored & commented code (NatSpec comment & PlantUML)
- Unit (TDD) & integration (BDD) tests (green)
- Paper code review (architecture & conception tests) - not required for this project
- Use auditing tools (internally)
- Secureum articles
- Formal verification testing: solidity smt & else
- Fuzz testing (echidna): (semi-)random inputs
- Static analysers (mythril, slither)
- Differential Testing
- MythX (report)
- Etc.. (rattle, etheno, surya…)
- invariant testing
- symbolic execution
- mutation testing