DeSyn's Contracts Overview
Last updated
Last updated
We have always believed that liquidity is important area for the crypto world. 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 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.
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 Pool, and users' assets are stored in this contract. Theoretically, when the pool 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 pool 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 pool 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 pool. 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 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;
Changes to price source configurations,
Adjustments to asset conversion logic,
Admin address modifications.
The Oracle contract is managed by an admin role that can update pricing parameters and token mappings. To ensure integrity and trust in the system, the following aspects must be closely monitored:
Unified Yield and Fee Calculation
To ensure consistency and fairness, the protocol calculates yields, performance fees, and referral commissions by converting all values into a common base currency, such as USDT, BTC, or ETH. Oracle provides the real-time prices required for these conversions, supporting standardized reporting across various strategies and products.
Multi-Currency Support in Subscriptions and Redemptions
When users subscribe to or redeem from a pool using different tokens, the Oracle ensures accurate conversion between these tokens and the pool’s base asset. This allows the protocol to support a wide range of tokens in investment operations while maintaining precise value matching.
There are two key scenarios where the Oracle is essential:
The Oracle contract provides real-time price feeds for the protocol using RedStone as the exclusive and primary data source. It plays a critical role in ensuring accurate, secure, and consistent asset valuation across the protocol.
No direct changes unless further clarification is needed.
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
Support contracts act as foundational components that assist the protocol in calculations, security, and system interactions.
This includes:
Oracle: Provides price feeds exclusively from RedStone, enabling two critical functions within the protocol:
Converting yields, performance fees, and commissions into a unified base asset (e.g., USDT, BTC, ETH) for standardized financial reporting;
Facilitating multi-currency conversions during user subscription and redemption processes to support diversified asset inputs with accurate real-time exchange rates.
DesynSafeMath: A static utility library for secure mathematical operations. It does not store data or contain any business logic but ensures overflow/underflow safety throughout the protocol.
While support contracts do not hold user funds, they are vital for the accuracy, transparency, and smooth functioning of the entire system.
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:
Thank you,
DeSyn Team
