There are some functions used for testing purposes only, each of them is marked with 'todo:' mark. They MUST be removed before ANY real deployment.
Made by using TransparentUpgradeableProxy paradigm from OpenZeppelin. All the data storages were separated from the respective implementations. Storages contain "storage" in their names, and implementations contain "implementation".
Contract is ERC20 and ERC777 compatible foundation for all the operations (upd: after audit Client made a decision to remove ERC777 hooks functionality - see See the Amendmens after Audit). Consists of two parts:
Token per se.
A mechanism to set the price manually. Is designed to serve the requests from the UI for the USD-nominated sales.
Is represented by three contracts, responsible for:
- stakes (investments into a project)
- debt (debt of a project)
- revenues (managing revenues distribution in accordance with the stakes)
Contract, responsible for holding a Project Catalog, manages Projects. It moves Projects through the stages (called Road Blocks).
Set of three contracts, responsible for holding NFTs. Contextualy, everything in the system is an NFT - a project, a piece of art, stake in a project, collection. It provides an ability to trade anything. For the projects there are other type of trading - through the Stakes. One can consolidate the stakes that way consolidating quasi-equity. Sale is organized in two transactions:
- owner approves operator (a buyer) and fixes a price he wants to sell an NFT for;
- buyer, who is an operator for particular NFT after 1), transfers NFT to another address, and uses as one of the arguments of a transferNFT() pre-agreed price that was entered by the owner. If anything mismatches then contract reverts. Three contracts constitute the Marketplace:
Holds all the NFTs.
Holds ownership of NFTs, is analogous to ERC1155.
Operates with transactions, holds them until they are executed.
OZ implementation of Governor Compound Bravo Compatible and GovernorToken as ERC20Votes contracts was taken as a base, but the complexity comes from the NFT structure. A person that holds Tokens and Project Stakes for a particualr project has the options to do the following:
- delegate both Tokens and Project Stakes for a system-wide proposal vote
- delegate both Tokens and Project Stakes for a project specific proposal vote if this project is the same as Stakes are issued for.
- delegate ONLY Tokens for a project specific proposal vote, if such project differs from the one that such person holds Stakes for.
Each contract is placed in a separate folder. Name of such folder corresponds with a purpose of Contract. As it was "TransparentUpgradable" architecture selected, therefore each Smart Contract consists of several parts. Assume there is a Contract that has a purpose of selling things and that is called "Shop". In this case, this contract can be found in folder "/contracts/Shop" and Naming of the contract parts will be the following:
- ShopProxy: part of the contract, that serves as an interface, allows to change the business logic implementation and fallbacks all the business queries to such a logic;
- ShopStorage: Storage of a respected contract. Part, that is designed to keep contract's data on-chain;
- ShopImplementation: Business logic of a respected contract, that works with data, kept in ShopStorage and that can be changed by ShopProxy;
- IShop: interface of a contract, that is to be used by other contracts of entire contract set if there is a need for that.
contracts
└───Finance
│ └───DebtManager
│ │ // some comments for DebtManager folder, that contains:
│ │ // - proxy,
│ │ // - storage,
│ │ // - implementaion (logic),
│ │ // - interface
│ │ // of a contract, reponsible for Debt.
│ │ // See General structure section for
│ │ // contracts business description, as well as BRD.
│ │ // Other contract folders are more or less the same.
│ └───RevenuesManager
│ └───StakesManager
└───Governance
│ └───GovernanceToken
│ └───Governor
│ └───GovernorCore //Governor inheritance structure
└───Libs //third party's libs, own libs
└───Mocks //UPD: contract mocks, used for testing
└───NFT
│ └───Libs //NFT's specific libs
│ └───NFT_TransactionPool
│ └───NFTCatalog
│ └───NFTOwnership
└───ProjectCatalog
└───Token
└───PriceOracle
└───Token
The contracts were audited, here is the first round findings. Issues were addressed the following way:
-
Finding #1
- ... Recommendation: An NFT's price should not be updated until the implementTransaction() function is called to ensure the NFT was actually purchased at the value last_price is being set.
- Code amended: NFTCatalogImplementation.sol
-
Finding #2
- ... Recommendation: The fromTokensToEther() function should either check the msg.sender's balance and transfer the tokens from the msg.sender or check the to address' balance and send the tokens from the to address.
- Code amended: TokenImplementation.sol
-
Finding #3
- ... Recommendation: Checking that only the msg.value is equal to the transaction price is sufficient.
- Code amended: NFTCatalogImplementation.sol
-
Finding #4
- Recommendation: The team should consider only allowing Project owners to mint or implementing a mint allowance system for Projects.
- Code amended:
- NFTCatalogImplementation.sol
- nft_catalog_business_requirements.js, block of tests
-
Finding #5
- ... Recommendation: The addStakes() function should be called before transferring the ERC777 tokens.
- Code amended: StakesManagerImplementation.sol
-
Finding #6
- ... Recommendation: The registerRevenue() function should check a revenue does not already exist for the project at the current.
- Code amended:
- RevenuesManagerImplementation.sol
- finance_business_requirements.js
-
Finding #7
- ... Recommendation: The team should consider disabling Governance Token transfers so the intended functionality is more apparent.
- Code amended:
- GovernanceTokenProxy.sol
- GovernanceTokenImplementation.sol
- GovernanceTokenStorage.sol
- governance_token_business_requirements.js, some other technical changes - ie, update of a project_id value inside of a test
- ERC777 HOOKS: As per Client's request, some of Token's (so called "native token") methods were removed to reduce the risks of using ERC777 functionality. Specifically, "hooks" related functions as well as their usage were removed from the code.
- Files affected:
- TokenImplementation.sol, removed hooks;
- ERC777Wrapper.sol, removed hooks;
- ERC777.behavior.js, tests amended to reflect hooks absence;
- token_as_ERC777.js refactored to token_as_ERC.js, tests amended to reflect hooks absence.
- NOTE! However, ERC777WrapperStorage.sol - a storage for Token, still contains the data structures for the hooks, as the Client may consider using them in the future by changing logic of this upgradable contract.
- Other contracts' functions and events containing "ERC777" were refactored to contain "NativeToken".
- Files affected:
- GOVERNOR CONTRACT: became available for testing, so the following changes were introduced:
- Contract was heavily refactored;
- After testing started, another contract mock appeared (three contract mocks in total now), therefore there is a new folder contracts/Mocks, that contains the mocks;
- GovernorCore was moved to contracts/Libs as GovernorCoreWrapper.
- MINOR REFACTORING
- UPGRADEABLE feature - introduced Libs/InheritanceHelpers.sol, that helps to straighten up inheritance hierarchy;
- Audit Finding #4
- Recommendation: eliminate an ability to mint Ticket, ProjectArt, Collection, Other types of NFT for everybody, except Project Owners.
- Code amended:
- NFTCatalogImplementation.sol, added a guard at mint();
- nft_catalog_business_requirements.js, all the tests, as Collection now is mintable by a Project Owner only;
- Client's request to allow Vote propose for Project Owners only
- Code amended:
- GovernorDataStorage.sol, added links to the required contracts;
- GovernorImplementation.sol, added funcs to initialize the contracts, added guards;
- governor_business_requirements.js - amended the tests in the way to reflect the changes.
- Limitations:
- For system-wide proposal anybody can propose a vote if threshold is overcome.
- Code amended:
- Finding #1
- Remove conversion from any NFT but Debt and Stake, also Tokens, keep conversion 1:1, remove an idea to update the price of a particular NFT.
- Code amended:
- NFTStructs.sol, updated the structure;
- NFTCatalogImplementation.sol, updated mint(), removed last_price, removed updateNFTPrice() func;
- GovernanceTokenImplementation.sol, significant change of a function depositNFTs();
- GovernanceTokenStorage.sol, added links to other contracts.
- All other contracts and tests in terms of calling NFTImplementation.mint() - no need to have a price as an argument
- Refactoring
- Interfaces were moved from storage to implementation to make upgrade easier.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent