Pricing and settlement model
Challenges in price discovery in tokenized alternative assets¶
One essential part of the AXC protocol is to address the gap between the needs of token holders and the realities of alternative assets when it comes to pricing. Token holders require pricing which is precise, timely, simple, transparent, and complete whereas the reality of alternative assets is that the pricing of the underlying is none of these things. The table below describes the gap between token needs and underlying reality when it comes to pricing.
| Token holder expectations | Alternative assets realities | |
|---|---|---|
| Precision | Token holders expect prices which are precise and which allow the token holder to immediately calculate the price of a token. Before an exchange, the token holder needs to know the exact amount to be bid or asked, and the execution of the order is instantaneous. | Prices of alternative assets are usually not stated with precision and the process of buying and selling alternative assets typically may involve haggling and negotiation. |
| Timeliness | Token holders expect instant pricing with the gap between order and pricing measured in milliseconds. Because tokens have instant pricing, token holders can use prices to formulate trading strategies and use tokens as collateral. | Prices of alternative assets can take weeks to calculate after a transaction, and may be unavailable at the time of the transaction. |
| Complexity | Token holders expect that a token will have a single price from which one can easily calculate time series | Alternative assets may have investments divided into several internal classes with different prices which makes deriving a single price difficult |
| Transparency | Token holders expect a complete time series of transactions and full historical information on all trades | Alternative assets are reluctant to provide high frequency trading information in order to prevent strategies from being replicated. |
The goal of the AXC protocol is to satisfy the requirements of token holders by creating a liquid market to generate prices. However this creates a chicken and egg problem as price discovery is necessary to create liquid markets and liquid markets are necessary to create accurate prices. In order to resolve this dilemma we have taken a two step approach to create a set of bootstrap prices whose purpose is then to create sufficient liquidity to generate prices. The two steps are
Create a settlement model to remove the complexity for alternative assets
Compute a bootstrap price which will be used as an initial price
We provide the technical details of the settlement model and the bootstrap mode below
Settlement model for alternative assets¶
In creating settlement models for deposits and withdrawals, we seek to remove the complexities that exist in the way the underlying alternative asset is priced. In interacting with the token, the token holder wishes to have a single token with a single price that can be bought or sold with a single transaction. However, the underlying fund may not have such a simple pricing structure, and it is common for an alternative asset to issue a separate class of shares for each deposit.
We take as an example a sample underlying fund which illustrates the complex pricing model for the GROW Heritage Fund versus the Growth Yield Token. In this pricing model each deposit creates a new class of shares which are sold at a price of 1000 USD per share.
Simplified fund example¶
The custodian buys 100 USD of shares in January. The pricing model of the fund is that each purchase creates a new class of shares at 1000.00 USD per share
Class January - 100 shares at USD 1000.0
In February the value of Class S1 shares goes up to 1500.00 USD and the custodian buys 500k USD of shares. So the holdings at the end of February
Class January - 100 shares at USD 1500.00
Class February - 500 shares at USD 1000.00
Note that the NAV is not known at the time that the funds are deposited.
Basic computations (AUM/NAV)¶
The AUM and NAV of the fund at the end of February can be calculated as follows if the NAV for the shares in January are valuable.
AUM = (sum of different share classes * NAV of each share class + cash)
NAV = AUM / number of shares
Example:
Class January - 100 shares each at USD 1500.00
Class February - 500 shares each at USD 1000.00
Cash - 50k USD
Tokens outstanding = 350k
AUM = 700k USD
NAV = 2.00 USD
We note that this computation is not possible if the AUM of the January shares are not known at the end of February.
Deposit settlement example¶
Assume two token holders deposit funds
Example:
Deposit #1 = 10k USD
Deposit #2 = 20k USD
Underlying holdings after token deposit
Class January - 100 shares each at USD 1500
Class February - 500 shares each at USD 1000
Class March - 30 shares each at USD 1000
Cash - 50k USD
AUM = 730k USD
However to calculate the NAV it will be necessary to compute the tokens that were issued on deposit. Because the NAV of the underlying is not known at the time of deposit, the number of tokens outstanding must be determined by a pricing model at the time the tokens were purchased.
Withdrawal settlement model¶
The withdrawal pricing model takes into account that there are holdings divided into different classes and that the NAV is not known until the tokens are actually redeemed. Our aim is to keep the withdrawal price at the NAV price, although this requirement may be modified with the agreement of the client.
We will withdraw from different classes using FIFO (first in, first out). FIFO is the standard accounting mechanism for dealing with different assets. We estimate the number of tokens in each class to be withdrawn using an estimated NAV, and that and an extra amount to take into account any possible shift in the NAV,. We then place an order for the tokens to be sold, and cover differences between the withdrawal price and cash via cash reserve. In the event that cash reserve is unable to cover the difference then we perform an additional withdrawal in the next month.
For example, assume we wish to withdraw 5k tokens
So we would need to get USD 10K to cover the withdrawal. So we would need to convert 6666.67 S1 tokens to cover the withdrawal. However because the NAV may change it we may request a withdrawal of 8000 January tokens to cover the withdrawal in case there is an unexpected change in the NAV
Any excess withdrawals will be kept as offchain reserve.
Bootstrap Trial Price Calculation¶
Once we have removed the complexity of the underlying asset, we will need to create a bootstrap price that will serve as the initial bid or ask price for the token.
The current value of the token is jointly anchored by the on-chain reserve pool and the off-chain underlying assets; therefore, the token’s price cannot be determined solely by the off-chain assets. A reasonable calculation method is:
The token price is jointly determined by the project’s net asset value (on-chain + off-chain) and the token supply. The on-chain value is calculated as follows:
Where the protocol share represents the proportion of the reserve pool that is staked in DeFi protocols, the protocol price is the price provided by the third-party protocol, and the protocol’s additional income is optional (some protocols provide additional reward tokens in addition to the basic staking income).
The off-chain value is calculated as follows: The off-chain value is determined by the estimated RWA net value and the amount of unprocessed RWA subscriptions (the amount of funds withdrawn from the on-chain by the administrator each period, which has not yet been allocated to the actual RWA value). The off-chain RWA value is no longer updated daily, but is based on the annualized return of the underlying asset to derive the daily return rate r, and the estimated RWA value after t days is calculated as follows:
When the APY is in the range of 7% - 14.4%, the daily return rate is 0.0185% - 0.0369%.
Calculate the estimated value of RWA after t days under compound interest.
The net value of RWA will be updated and calibrated once a month. At other times, the off-chain RWA estimated value will be calculated based on the difference between the current time and the last calibration time, as well as the set estimated annual rate.
Special cases¶
For funds withdrawing in a 3-month queue, the off-chain RWA net value will be updated during the repayment period when the funds are burned into tokens. At this time, the RWA net value is as follows:
Furthermore, since all user funds are stored on-chain, for queued redemption operations, the actual share that needs to be applied for redemption from the fund is not the proportion of the entire locked tokens, but rather…
Limitations of the trial price calculation¶
We emphasize that these equations are used merely to create a trial price to bootstrap price discovery, and should be regarded as a first guess for the price of the token. There are several limitations involved in this calculation which we will consider to improve our algorithm.
The bootstrap price results in a smooth price which continuously increases upward. Therefore without additional work the bootstrap algorithm would result in the asset never liquidating in a lending pool regardless of market conditions. This problem may be addressed either as market actors adjust the price or by adding a random element to the bootstrap price.
Another issue results from the use of stale data in generating a bootstrap price. The NAV for the underlying may not be available for several weeks after a deposit or redemption transaction is undertaken, and so this may result in the bootstrap price being significantly different from the fair market value.
Finally, as AXC will be using the bootstrap price for an initial trade, there may be situations in which using the bootstrap price causes our liquidity pool to be exhausted or for the trial price to cause the token price to deviate significantly from the market value of the underlying. We will monitor market conditions and if necessary revise our bootstrap price to deal improve our pricing.