Why Hourglass?

DeFi's earliest days were defined by fungible tokens. Uniswap, Aave, MakerDao, and other "blue-chip" applications thrived by pooling tokens together to automatically provide liquidity for spot, lending, and other markets. Another type of token, the non-fungible token, is well known for its association with collectibles, profile pictures, and other forms of artwork; OpenSea, Blur, and NFTFi are analogues for that market. Hourglass provides infrastructure for a different, important type of asset — the semi-fungible, time-bound token.

What are some examples of Hourglass markets?

Hourglass is uniquely suited to create markets for time-bound or otherwise semi-fungible tokens.

Time-bound tokens (TBTs) are receipts that can be redeemed for some underlying asset (and yield) at their maturity. Usually, they're minted after staking into a time-boosted vault, where users earn additional rewards for committing their liquidity. However, other forms of tokens, such as Term Repo Tokens (TRTs) and Pendle Principal Tokens (PTs) can be characterized as TBTs.

Why would someone incentivize a TBT?

Background

Although time-bound token use cases are most commonly discussed in the context of staking for rewards, it is worth understanding why time-bound tokens are in fact a useful construct for both the stakers and the incentivizing protocols, and not just the simple introduction of illiquidity for the sake of ponzi-like economics seen in many DeFi projects previously.

Suppose you run a DEX — the way you earn revenue is through fees from people (or aggregators) trading through your token pools. Where do these tokens come from? They're supplied by users in exchange for a share of the revenue. However, in most DEXs, users are able to supply and withdraw tokens (or, LP shares) on demand. Fundamentally, this is an issue, as it puts your DEX revenue stream at the risk of many users pulling their liquidity from the platform for a myriad of reasons. As a nascent decentralized protocol, this uncertainty may have knock-on effects. For example, maybe it makes it harder to hire a new UX designer because you aren't as certain about revenue in the next few months, or maybe it makes it more difficult to design a certain protocol feature, because it relies on some certainty of liquidity.

Instead, you introduce the concept of time-bound liquidity! Now, users will provide DEX liquidity but instead of being able to withdraw on demand, they will be time-locked for some period of time; say, 1 month. In exchange, the users will get extra rewards on top of their usual fee split, and everyone is happy.

In summary:

DEX: Now has an assurance that some amount of its liquidity will be available for collecting fees, and potentially for use in new product features.

User: Now exchanges the ability to exit their position at any time (by receiving a time-bound token) while still maintaining a level of liquidity, and earning extra rewards.

It's worth noting a final point: not only do time-bound tokens give some assurance about TVL and assets on a platform, but they also fundamentally increase the design space available to a project! New features that may not have been possible before are now possible through the power of time-bound tokens.

A Detailed Example

Let's use a real-world example: Frax.

Frax is a widely known DeFi protocol with a $1 billion market cap stablecoin. For a stablecoin to be useful, it must be liquid. Another way to say liquid is that if I hold FRAX, a stablecoin ostensibly worth $1, I must be easily able to trade it for something else worth $1, say USDC. Similarly, if I hold $1 USDC, I should easily be able to swap it for $1 FRAX.

The Frax protocol makes this possible by incentivizing users to become "liquidity providers" (LP) for their stablecoin. Users who LP receive back a receipt—an LP token, which they can "stake" for additional rewards. If a user "stakes" their LP token for a year, for example, Frax knows that they won't remove that liquidity for a year. This is tremendously valuable for the protocol, so it is willing to reward this by providing extra rewards to that user.

Other Examples of TBTs

• DEXs can incentivize time-locked liquidity providers to improve the UX for their traders and loyal LPs, and bolster their long-term composability with money markets and aggregators

• Lending Markets can incentivize time-locked lending liquidity to reliably keep borrow rates low and encourage usage

• Stablecoins can incentivize time-locked liquidity to prevent depegs (locked liquidity can't be sold in a bank run)

• Asset Managers like banks can use locked liquidity (a.k.a. certificates of deposit) to align terms on their assets/liabilities and prevent bank runs

• Real World Asset (RWA) providers like Maple and Ondo can use time-bound liquidity to avoid bank run scenarios against their termed RWAs

• Liquid Staking Protocols can incentivize time-locked liquidity to guarantee LST composability, book revenue, and minimize user churn (withdrawals)

• Liquid Restaking Protocols can incentivize long-term LRT deposits to guarantee a certain economic stake with their partner AVSs.

• L1s, L2s, and bridges can incentivize locked liquidity to bootstrap usage and network effects in their application ecosystems

• Insurance protocols can incentivize locked liquidity to create systematic guarantees about coverage on long-term liability

What other types of assets does Hourglass support?

Hourglass is designed for tokens who fundamentally derive value from some underlying asset or basket of assets. Usually, these tokens are denominated in some base form (ETH, USD), and they almost always contain three fundamental properties: risk, time (duration), and yield. Aside from the many TBTs outlined above, the following assets naturally integrate with Hourglass:

• LRTs

• Fixed-term loans

• Stripped tokens (e.g. Pendle PTs)

Why is Hourglass uniquely suited for these markets?

We'll use a specific real-world example to motivate the design of Hourglass Marketplace below. Ether.fi, one of Hourglass' partners, is currently incentivizing users to time-boost their Liquid ETH, offering increased rewards for committing their token for 3, 6, and 9 months respectively. Depending on which vault a user commits to, they would receive a unique time-bound token in return.

Because every date on the yield curve requires a new receipt token, we must now create markets for 3 tokens (representing the three maturities) instead of 1 token.

Liquidity Depth & Aggregation

Classic DeFi apps require pooling liquidity to make markets. Without Hourglass, we would need to make 3 unique liquidity pools on, say, Uniswap, to trade the TBTs. In the general case, we would need N liquidity pools.

On Hourglass, a liquidity provider can use their balance to support bids/asks for all N maturities at once. This improves capital efficiency by a factor of N!

Price Discovery

The price of a time-bound asset is subject to change as time passes and the interest rate market develops. Deterministic AMMs like Uniswap are completely unaware of these externalities in the naive case, and in the complex case must hard-code assumptions about these factors (for example, explicitly encoding some implied interest rate). This causes the AMM price to periodically fall out of sync with what a sophisticated actor would consider the "true value."

On Hourglass, exeprienced liquidity providers can dynamically update their bids and asks in accordance with their view on a token's price. If we assume that a healthy market of LPs actively manage liquidity on Hourglass, then Hourglass RFQ should always return better prices than pooled liquidity.