Strategy-Aware Assets
Design
In addition to capital gains, digital assets can be further utilized by granting the right of use to DeFi protocols. For example, Bitcoins that are staked onto a lending platform may earn interest as an extra return on top of the capital gain if stored in a mere wallet. Although the investor still has the ownership of the assets and is subject to the same market risk, the right of use granted on the assets exposes the investor to an additional source of risk brought by the protocols and the relevant strategies.
Risks and returns arising from a particular utilization/strategy of an asset characterize and differentiate the asset from other utilizations/strategies. More often than not, the DeFi protocols capitalize on a chain of digital asset utilization. This raises a problem not often considered for traditional assets where multi-utilization is barely possible. Without properly handled, portfolio management can become increasingly complex. One way to approach this problem is to use a separate wallet for each strategy. This allows comprehensive tracking of all investment strategies and assets. However, the cost of technical operations, such as the number of wallets that grows in multiples of the number of funds, renders it impractical.
In Avareum, we address this problem by redefining what an asset is. An asset is defined to be strategy-aware, meaning that it is uniquely defined by its entry-strategy action i.e. how it can be acquired. For example, an interest-bearing token stored in a wallet, which is acquired by lending a digital asset, is considered a different asset from an interest-bearing token staked on a platform, which is acquired by lending a digital asset and also staking the token onto the platform.
To summarize, the complete definition of a strategy-aware asset is composed of:
Asset identifier i.e. uniquely identifiable name or symbol
Asset attributes i.e. information related to the asset
The attributes include, for example, the minimum amounts for entering (converting a denomination asset to this asset) and exiting (converting this asset back to a denomination asset). These requirements will be enforced by the execution mechanism. If the entry amount is less than the limit set, the fund module will not execute the entry-strategy action, leaving the allocated fund as-is in the denomination asset. In contrast, if the exit amount is less than the limit set, the fund module will execute the exit-strategy action with the amount rounded up.
Entry strategy
The entry-strategy action takes the amount of denomination asset as an input parameter. It may take additional input parameters required by certain asset types. The entry action contains a sequence of actions used to transform the denomination asset of the given amount into the invested asset.
Exit strategy
The exit-strategy action takes the amount of the invested asset as an input parameter. It may take additional input parameters required for certain asset types. The exit action contains a sequence of actions used to liquidate the invested asset of the given amount into the denomination asset.
Balance-checking method
Since the same asset acquired by different strategies is stored differently, it needs a specific method for checking the amount of the asset. For example, an asset staked on a platform requires a more complex balance-checking method than that simply stored in a wallet.
Pricing method
Similar to the balance-checking method, each strategy-aware asset needs a specific method for pricing the asset. For example, the price of a liquidity-providing token is partly determined by the present value of the entire liquidity pool.
Implementation
Developing an asset management protocol that supports full automation and future extension involves a robust design and highly modular implementation. By the definition, the entry-strategy and exit-strategy actions are a sequence of actions that interact excessively with various protocols. This raises a couple of concerns:
Operating or transacting in a sequential manner takes time i.e. an action must wait for the completion of the earlier one. The overheads occur not only at the intermediate handling by our protocols but also in the underlying blockchain operations where intermediate transactions have to compete with transactions from other protocols. The delay degrades the user experience and may cause concerns during contingency operations.
Even a minor failure caused by a single action can lead to complicated error handling. When the denomination asset has been converted into an intermediate asset, an attempt to either resume or revert involves examining all possibilities of the unfinished state. For example, the intermediate asset might be the same as and thereby well blended into another portfolio component. Even when the recovery process has begun, it can be catastrophic should another error occur during the reverting operation.
To resolve such problems, our design wraps a sequence of highly coupled actions in a modular way. Specifically, all of the steps in an entry-strategy or exit-strategy action are compiled into a single contract by the workers on each blockchain. The entry-strategy or exit-strategy actions can then be treated as an atomic transaction i.e. no overheads due to sequential transactions, neither resuming nor reverting needed when failed.
Last updated
Was this helpful?