Fund Tokens

A fund token, also known as an NAV token, is a digital token that serves as a certificate of ownership in the investment fund or portfolio. Similar to stock shares, the investor will receive fund tokens, after subscribing to a fund, in the amount proportional to the deposited fund. Unless specified otherwise, the fund tokens can be used to redeem for denomination assets at any time. The total value owned by the investor equals the number of fund tokens multiplied by the fund token price.

Investors may keep fund tokens in their own software or hardware wallets at their own risk. If security is of concern e.g. in institutional investment, custodians can also be used. Fund tokens are fungible among the subscribed fund and transferable without taxes or restrictions. Investors can manage their fund tokens at no extra cost i.e. no transfer fees or taxes, which are otherwise present in traditional operations and regulations.

Near Real-time Subscription and On-demand Redemption

Real-time fund subscription and redemption is ultimately desirable because it provides a better user experience, like ETFs. Investors can receive and redeem fund tokens instantly without having to wait until a specific time, unlike mutual funds. Despite its desirability, the fact that the funds need to operate non-atomically across different blockchains and process requests sequentially renders operating real-time subscription and redemption challenging. We also highlight some other operational concerns below.

1. In order to facilitate real-time fund redemption, a sufficient amount of cash must be reserved along with a maximum withdrawal limit. This renders inefficient use of funds and an unnecessary strategic plan for cash reservation.

2. Other asset management protocols capable of facilitating real-time fund redemption, in turn, transfer assets of the current holding to the withdrawing investor. Not only does this appears unconventional but also restricts the asset universe to only those available within the operating blockchain. For cross-chain funds like Avareum's, transferring raw assets is not a choice.

To facilitate near real-time subscription and on-demand redemption with fair benefits of our investors, we impose bid-ask spreads at subscription and redemption. The operations work as follows.

Avareum Fund Tokens

Assume, for example, that the token price (NAV per unit) is currently $100 at the time the investor submits a subscription request of size $1000. The request is put into a request queue, waiting to be processed. Due to market volatility, at the time the request is being processed, the token price might become $101 with a corresponding ask price of $102.01. In which case, the investor shall receive approximately $1000 / $102.01 = 9.80 tokens in return instead of 10 tokens. Likewise, when 9.80 tokens are claimed at redemption, with the tokens currently priced at $100 and anticipation to receive $980. However, after waiting in a queue waiting and liquidating the investor's portion, the token price might become $101 with a corresponding bid price of $99.99. The investor shall receive 9.80 * $99.99 = $979.90 in return.

Near real-time subscription and on-demand redemption comes with issues that we shall also discuss.

1. Investors will experience certain delays when there is an insufficient amount of the denomination asset for withdrawal since it takes some time for the fund manager to fully liquidate assets at withdrawal. The delay can be short and lengthy, depending on the fund investment policy, the number of assets, protocols, and blockchains on which the fund operates. Even when there is a sufficient amount of the denomination asset, investors might also experience certain delays from the queuing process, asynchronous nature of execution, and unpredictable network congestion. For example, when the fund manager is undergoing a rebalancing process, all investors' requests will be temporarily blocked until the ongoing process finishes. This puts the other investors' requests waited in a queue. Although not expecting to occur frequently, we implement a bulk-service queue in support of overloading requests.

2. As a consequence, due to the unpredictable waiting time and volatile prices, the investors do not know the exact amounts at the time of submitting subscription and redemption requests. The investors will be informed of the estimates which are anyway subject to a deviation. Note that this characteristic is similar to that of mutual funds despite a different mechanism used. Our deviation is supposedly substantially lower because of the immediate asset allocation process.

3. Since the subscription process must be settled before the fund deposited by the investor is allocated, the funds, which belong to the other investors who have invested earlier, have to unfairly absorb transaction costs incurred during the allocation process of the subscribing investor. This also exposes a vulnerability to draining attacks where outsiders flood multiple subscription and redemption requests, thus draining the funds. To alleviate the problem, we employ a bid-ask mechanism at subscription and redemption, which, once set properly, will exactly offset the transaction costs. See Derivation of Bid-Ask Spreads for more details.

Token Price Calculation

The price of a fund token is calculated by dividing the net asset value of the fund portfolio by the total number of fund tokens. Since management and performance fees are collected using a continuous price dilution model, the total number of fund tokens, minted and credited, increases all the time. As described below, any token price calculation used in the protocol will include the dilution effect, thus reflecting an actual price in real-time. This real-time price reporting is rarely seen in traditional open-ended funds but is considered crucial in digital asset investment due to 24/7 market hours.

The token price calculation module can operate independently of other modules. The following steps show how token price calculation works in general.

1. Calculate:

   $\mathtt{fees} = \mathtt{management\_fee} + \mathtt{performance\_fee}$

   The detailed calculations are given in Fee Management. If the fee management module has just preceded i.e. $\tau=0$ , recalculation simply gives $\mathtt{fees} = 0$. To improve efficiency e.g. visualizing purpose, the calculations may be performed off-chain without having the states saved.
2. Calculate: $\mathtt{nav} = \sum_{i=1}^n \mathtt{volume}_i \cdot \mathtt{price}_i - \sum_{i=1}^m \mathtt{debt}_i =$ portfolio's net asset value which is the sum of all the asset values, netting all the debt positions.

   Note that the asset prices can vary from second to second and differ among different market sources. See Price Oracle for more details. The asset volumes, such as staking credits, can also vary. $\mathtt{tokens} =$ the token supply, including tokens in all the fee vaults $\mathtt{price} = \dfrac{\mathtt{nav}}{\mathtt{tokens}+\mathtt{fees}}$

Example 1: Subscription

The following table illustrates calculations of the number of fund tokens returned to investors after depositing. The pre-execution and post-execution sections refer respectively to the calculations performed before/after the subscription handling process begins/completes. The deposit section, whose numbers are partly dependent on the pre-allocation result, focuses on the investor token calculations. Each row in the table represents an individual subscription request. Assumed parameters are highlighted in darker colors while the rest can be derived from prior information.

Request #1 is the first deposit request to this fund with a deposit value of $1000 and receiving 9.9 fund tokens in return.

Request #2 is a subsequent deposit request with a deposit value of $4000 and receiving 39.25 fund tokens in return.

Example 2: Redemption

The following table illustrates calculations of the value of the denomination asset returned to investors after withdrawing. The pre-execution and post-execution sections refer respectively to the calculations performed before/after the redemption handling process begins/completes. The withdraw section, whose numbers are partly dependent on the pre-allocation result, focuses on the investor token calculations. Each row in the table represents an individual redemption request. Assumed parameters are highlighted in darker colors while the rest can be derived from prior information.

Request #3 is a withdrawal request, subsequent to Request #2, with 9.9 fund tokens and receiving $904.99 in return.

Request #4 is another withdrawal request with 20 fund tokens and receiving $1712.43 in return.

Derivation of Bid-Ask Spreads

In this section, we will show that when $\delta_\mathtt{bid}, \delta_\mathtt{ask}$ are set properly, the transaction costs absorbed by the existing AUM can be approximately, if not perfectly, balanced out.

Assume an upcoming subscription request of size $x$ (in the denomination unit) and an ask spread rate $\delta_{\mathtt{ask}}$. Subscribing at the ask price should add as compensation to the entire fund by this amount. $x - \dfrac{x}{\mathtt{price} (1+\delta_{\mathtt{ask}}) } \cdot \mathtt{price} = x \cdot \Big(1 - \dfrac{1}{1+\delta_{\mathtt{ask}} } \Big) = x \cdot \dfrac{\delta_{\mathtt{ask}}}{1+\delta_{\mathtt{ask}}}$

Now, assume that asset allocation operations for $x$ result in a total transaction cost of $x\cdot \phi$, where $\phi$ is the average rate of the total transaction cost. To fully cover the total cost, the rate parameter $\delta_{\mathtt{ask}}$ must be set as follows.

$x \cdot \dfrac{\delta_{\mathtt{ask}}}{1+\delta_{\mathtt{ask}}} = \phi \cdot x$

Or, equivalently:

$\delta_{\mathtt{ask}} = \dfrac{ \phi }{1+\phi}$

For a redemption request of size $x$ (in the denomination unit) and a bid spread rate $\delta_{\mathtt{bid}}$. Redeeming at the bid price should add as reimbursement to the entire fund by this amount.

$x - x \cdot (1 - \delta_{\mathtt{bid}}) = x \cdot \delta_{\mathtt{bid}}$

Likewise, to cover the total liquidation cost of $x\cdot \phi$, the rate parameter $\delta_{\mathtt{bid}}$ must be set as follows.

$x \cdot \delta_{\mathtt{bid}} = \phi \cdot x$

Or, equivalently:

$\delta_{\mathtt{bid}} = \phi$

In some cases, it might be convenient to make the bid and ask spread rates symmetric by simply setting:

$\delta_{\mathtt{bid}} = \delta_{\mathtt{ask}} = \max \Big\{ \dfrac{ \phi }{1+\phi} , \phi \Big\} = \phi$