DeSyn's Decentralized Asset Management Journey - Contract
Last updated
Last updated
We have always believed that decentralized asset management is an important area for the future development of asset management. As one of the pioneers in this field, our advocated SDT Model, which is an innovative decentralized asset management approach, entirely based on smart contract.
As aforementioned, we have detailed the main features of the SDT model. Our goal in this part is to dive deeper into the model to highlight, 1) the characteristics of each of our contracts in the SDT model, 2) the decentralized management and open-source planning of the contracts, and 3) the audit status of our contracts.
Introduction to contracts
Decentralized management and open-source planning of contracts
Contract auditing
As of August 30, 2023, we have a total of 23 contracts, which can be mainly divided into the following categories:
The Factory contract is one of the core control contracts in the protocol. Blabs roles can use this contract to add token whitelists, set trusted modules, change oracles, Vault, and UserVault addresses, pause the protocol, and modify Pool bytecode. Users can use this contract to create new ETF pools and Blabs roles can also be modified.
The CRP Factory contract creates Configurable Rights Pools. The contract has a Blabs role, which is set to the creator’s address (EOA) at contract creation and cannot be modified. Blabs roles can perform sensitive operations such as modifying UserVault addresses and CRP bytecode.
The DSProxy Factory contract creates DSProxy contracts for users. Users can use DSProxy contracts to perform Action operations. It is generally called by the ProxyRegistry contract, but users can also call it directly to create contracts.
The DesynChainlinkOracle contract provides price feeds from Chainlink and self-priced services for the protocol. There is an admin role, which can modify price feeds and self-priced prices. Therefore, it is necessary to monitor modifications to price feeds, whether self-priced prices match the current market and modifications to admin addresses.
UserVault contract pays commissions to recommenders, the funds come from part of the Vault contract fees and do not involve user funds. The contract has an owner role, the owner role can modify sensitive parameters such as userVault and management_portion in the contract, and can also transfer funds in the contract through claimToken and claimEther.
The Vault contract is used to handle the issuance, redemption, management, and other fees of the protocol and does not involve user funds. The contract has an owner role, which can modify sensitive parameters such as vaultAddresscrpFactory in the contract, and can also transfer funds through claimToken and claimEther contracts.
The LiquidityPool contract is one of the core contracts that manages the ETF, and users' assets are stored in this contract. Theoretically, when the ETF officially starts operation, its controller should be the CRP contract and cannot be changed. Joining/exiting/ adjustment operations are all performed through CRP. So in theory, you only need to monitor whether the funds in this contract are sent to reduce significantly.
The Actions contract is a logic implementation contract, which is called by the user through the DSProxy contract DELEGATECALL. The user performs ETF creation/issuance/redemption/management operations through the Actions contract. This contract is only for the convenience of user operation, and users can also implement the operation of ETF by themselves.
This contract provides a library for safe mathematical operations for the protocol; this is a static library and does not involve any data storage.
The ProxyRegistry contract provides users with an entrance to create DSProxy; users can initiate Actions through DSProxy.
The RightsManager contract is used by the ConfigurableRightsPool contract to manage whether to enable user and token whitelisting. It is only set by the creator when the contract is initialized and cannot be changed subsequently. Therefore no monitoring is required.
The ConfigurableRightsPool contract is one of the core contracts that manages the ETF. Users can add and remove liquidity through this contract. The owner/admin can be designated by the creator, and can only perform the contract's token whitelist, fee collection, and new pool creation operations. There is no problem with excessive authority and the contract does not retain funds, so no monitoring is required.
Multicall is generally used by the front end to perform specified operations quickly and efficiently on the chain. It only provides an external calling function and does not involve any data storage.
The DesynChainlinkOracle contract provides the protocol with price feed sources and self-feeding services from Chainlink. There is an admin role, which modifies the price feed source and self-feed price.
The SmartPoolManager contract is called DELEGATECALL by ConfigurableRightsPool, which is a library used by CRP to manage user creation/issuance/redemption pools, fee collection, and fund transfers.
The Oracle contract provides the protocol with price feeds from Uniswap Pair. Its owner is a fixed EOA address. Token price feeds and time-weighted periods can be added through the setNewTokenInfo and setPERIOD functions respectively.
The Leverage Staking contract implements the 3x leverage staking strategy for ETH. The process of cyclically increasing leverage is implemented through increaseLever, and batch operations can use the interface with batchIncreaseLever. The process of reducing leverage is implemented through decreaseLever, and batchDecreaseLever is used for batch operations. This contract must be added to the whitelist module of the platform before performing trading operations (staking, lending, etc.). the operation of adding a whitelist module requires a multi-signature account on the platform to perform multi-signature operations.
Similar to No.17, both have the same ETH cyclic staking strategy and officially operate contract products.
U.S. bond product contracts, dSTBT-Test is a pool created by fund managers to raise and manage assets. The TBill contract module implements the management of U.S. bond products, mainly to achieve docking with Matrixdock, and the swap interface implements the mint and redeem processes of STBT.
The TBill contract module must be added to the whitelist operation module to perform the swap operation. The operation of adding the whitelist requires the multi-signature account of the platform to perform the multi-sign operation;
Same as No.19, they are all U.S. bond product contracts and are officially operational contract products;
DTBT is an erc20 token, which is used in the transaction process of TBill contract and matrixdock (mint, redeem, etc.) to realize the record of asset transfer, form a complete record track, and enhance the product experience. It does not have actual asset value, so no need to worry about its safety;
These contracts are mainly divided into the following 3 categories:
1. Core Protocol Contracts
Factory, CRPFactory, DSProxyFactory, UserVault, Vault, and LiquidityPool mainly involve factory contracts and asset custody-related contracts.
2. Protocol Operation Contracts
Actions, ProxyRegistry, Multicall, ConfigurableRightsPool, RightsManager, and SmartPoolManager mainly implement user operations, permissions, and other operation-type functionalities.
3. Strategy Module Contracts
Include Leverage Staking and STBT contracts, including 3x ETH Staking, LeverageStaking, TBill, etc., mainly implementing strategies like 3X Ethereum staking and short-term Treasury bills.
4. Support Contracts
Mainly include DesynChainlinkOracle and Oracle, which primarily provide price feed services; and DesynSafeMath, which implements secure mathematical operations.
From the classification and introduction of the above contracts, we have a better understanding of the purpose of each contract.
In this section, we will discuss the decentralized management of contracts and our open-source plan.
First, we firmly adhere to the decentralized philosophy. In practice, we will gradually complete the full decentralization of the project.
Next, the current protocol management address is the multi-signature wallet address 0xf8770931fC94d05Ab4982d06bd6572BDF520E174, a 3/5 multi-signature contract account with five private keys, where blockchain-related operations require confirmation from three private keys.
Lastly, our current open-source plan is:
Phase One (0 to 1): In the first phase, since the product has newly entered the market, considering many functionalities still need adjustments and upgrades, we will retain the upgrade rights for these contracts. However, the core protocol contracts are the most important, have the highest security requirements involving asset custody and safety, and will be open-sourced during this phase.
Phase Two (1 to 10): In the second phase, as some functionalities get stabilized and no longer need upgrades, such as protocol operation contracts, which generally connect the entire protocol process and permissions, optimizing the experience for fund managers and users, but do not hold assets in custody, these will be open-sourced in the second phase.
Phase Three (10 to 100): In the third phase, as the protocol started operating steadily, and different strategies attained stability, at this time, strategy module contracts related to fund investment strategies will be open-sourced.
Lastly, support contracts can be open-sourced at any time.
Audit is a vital aspect of our security. Currently, every line of our contract code is being audited by two agencies. In the future, we will add more agencies to conduct audits. For more information, please check the following link:
Audit ReportThank you,
DeSyn Team
