Overview

Overview of the Hourglass Index

Motivation

Digital assets that are linked to a given timeframe are often not fungible; even if they eventually become the same asset (i.e. at maturity). This often requires protocols to deploy new fungible tokens for each time-bound asset, or make those assets illiquid during a "lockup" period.

When there are multiple ERC-20 tokens representing the same asset at different points in time, it becomes impossible to manage an ever growing number of AMMs, one for each asset, let alone pay to support the liquidity necessary for safely pricing these assets.

Hourglass Indices aim to create a single fungible asset targeting an ever-changing basket of the underlying asset type. This single indexed asset can be used within an AMM to provide a much deeper pool of liquidity representing the defined mixture of time-bound holdings. Additionally, the underlying assets will have order book markets on Hourglass. The order book style pricing model allows the market to more effectively price the time value of assets while also remaining resistant to AMM based liquidity changes.

Index Token

Each Hourglass Index is represented by it's own ERC-20 token, which represents a pro-rata claim on assets under management (AUM) of the index. All AUM will be held outside of the index contract in an on-chain multi-sig wallet. The token is minted by depositing into the vault and burned when assets are redeemed from the vault.

The token is non-rebasing, in that the quantity of the token held by a given user will not change over time. Rather, the value of the the token should, depending on market forces, increase over time due to the value appreciation of AUM (zero coupon bond prices tend towards parity with the underlying the closer to maturity they are).

Deposits and Withdrawals

Depositing into the index and withdrawing from the index requires users to execute two steps! For deposits, users will not see a balance of the index token until the deposit has been 1) initiated by the depositor, 2) settled by the operator, and 3) finalized by the depositor. For withdrawals, users will not receive the deposit token back until 1) a withdrawal has been requested by a user holding sufficient shares for the request, 2) the withdrawal has been settled by the operator, and 3) the user finalizes the withdrawal request while still holding sufficient amounts of the requested withdrawal token (if these are transferred or sold to another address, the transferrer no longer has the ability to redeem those tokens).

Entry

As an asynchronous vault deposit contract, both deposits and withdrawals are not processed atomically. Instead, users request deposits and redemptions, which are then settled by the operator at a different time.

A user who wants to mint new shares of an Hourglass Index can do so by depositing the underlying asset denominating the index (sFRAX, ETH, etc.) into the contract. This results in the user’s assets being placed in the entry queue. Users will not immediately receive new index shares upon depositing into the queue as this only occurs when the net asset value (NAV) is updated. The number of shares to be minted per deposited asset are not known precisely at the time of deposit–this is relies on updating the conversion rate. Prior to a deposit being settled, the funds can be withdrawn by cancelling the deposit request.

Once the deposit is settled, it is "invested" and the deposit changes in value according to the overall index. To obtain the Index's ERC-20, the user must mint the shares of the index by interacting with the contract. Once minted, these can be transferred, redeployed, or withdrawn for the deposit asset.

Periodically (e.g. every 1-2 weeks), the Index's NAV is calculated and posted to this contract via an off-chain price oracle. Once the NAV is updated on chain, the conversion rate between the deposit assets and shares is determined. This conversion rate is used for all deposits and withdrawals requested between the previous and next conversion rate updates.

Exit

Users who want to redeem index shares for the deposit asset can do so by entering the exit queue–a FIFO queue enforcing an ordering priority for request processing. Unlike the entry queue, users in the exit queue cannot cancel their redemption request. However, these exit positions are transferrable ERC-1155s. As described above, once the oracle update occurs, it is possible that there is greater demand to enter than to exit, which necessitates either awaiting maturation of the underlying assets or liquidating holdings when market prices of these assets would not negatively impact the value of remaining holders.

By entering the exit queue, users are agreeing to pay the buffer fee. The buffer fee is taken in the deposit asset, subtracted from the amount a user is receiving, and is redistributed to the overall fund holdings, increasing the individual value of the outstanding shares.

Users who do not wish to have the redemption fee applied are able to exit via an AMM. Note: this redemption method only makes sense for small scale users that can accept AMM slippage or by arbitrageurs able to capture the spread between AMM index prices and NAV per share. When requesting a withdrawal to redeem shares for the underlying, there is no way to guarantee a set timeframe within which the deposit request will be satisfied, but it can be estimated by reviewing the current outstanding requested withdrawal amount, and the amounts of underlying maturity dates for the index's holdings. To avoid these constraints, as previously mentioned, users can exit via AMMs or the Hourglass Marketplace.

Buffer

The buffer is a targeted amount of deposit asset liquidity the index targets holding in order to facilitate more rapid redemptions of withdrawal requests. The liquidity available in this is not enforced as that would potentially lead to a situation of the fund being a forced seller at inopportune times in order to meet withdrawal demands. The buffer fee is a small backend loaded fee users pay when directly redeeming shares for the denomination asset from the index. The fee is redistributed to the remaining holders of the shares of the index, increasing holdings per share slightly. This increase is accounted for in the following conversion rate update.

Exit Queue (ERC-1155)

As mentioned within the Exit section, the withdrawal requests are transferrable–these positions are minted as ERC-1155 NFTs with the Token ID equal to the request's position within the queue.

To mint these positions, a user would request a withdrawal, which in turn burns the requested amount of Hourglass Index ERC-20s from their account and mints the ERC-1155 tokens back. These ERC-1155 tokens have the standard set of capabilities found in most other ERC-1155 compliant tokens.

If a user does not wish to wait for the redemption to be satisfied, these positions can be sold in part, or in whole to other market participants.

NAV

The net asset value (NAV) of the index is calculated as the total market value of all assets held within the index at a particular point in time for a particular set of market conditions. Not all assets have an obvious market price as fragmented Curve pools may suffer from low liquidity. As such, the components of the NAV will be strategically chosen as a combination of Curve pool prices and a trailing average of token settlement prices from other secondary liquidity marketplaces (e.g. Hourglass Marketplace).

Secondary Liquidity

Hourglass Index tokens conform to the ERC-20 token standard. Index tokens can be traded on AMMS, the Hourglass Marketplace, or other secondary liquidity sources.

Rebalancing

Rebalancing should occur in scenarios when the average duration of AUM meaningfully deviates from the target duration range. The assets the make up the index will be rebalanced in multiple ways, including, but not limited to:

1. Creating arbitrage opportunities for market actors to move the index closer towards its target average duration.

2. Periodic open market operations that serve to ensure the distribution of assets conforms to the target duration range.

Hourglass Indices will not contain hard coded logic to automate rebalancing. This is necessary because there are a number of ways an index could be rebalanced–it is difficult to say a priori what combination of the following approaches will be most efficient. Below is a set of open market operations that will be leveraged during manual rebalancing.

• Directly interacting with AMMs (Curve Finance's AMM & Frax Finance's TWAMM)

• Using the Hourglass Marketplace to set limit orders

A consequence of this is that we will set up the initial product in a non-atomic manner, where a multi-sig is approved to manage the assets making up the index. This multi-sig will perform open market operations related to rebalancing as needed.

Disclaimers

The value of Index shares are not guaranteed to increase over time. This could be due to any number of reasons, including but not limited to failure of underlying protocols to redeem assets, assets changing in value over time, market forces repricing assets, interest rate changes, blockchain or other computing infrastructure failures, excessive transaction costs, operations executions failures.