Use Cases
The main use cases of Timeswap
Last updated
The main use cases of Timeswap
Last updated
If you'd like to integrate your assets (e.g., governance, LP tokens, vault/deposit receipt tokens) into Timeswap, get in touch with us by filling out this form:
Having a novel design in the lending/borrowing space allows us to unlock several unique use cases, to name a few:
Non-liquidatable borrowing: Borrowers can borrow against their holdings without having to actively monitor their positions, only deciding at maturity whether to default or repay their loans.
Downside protected borrowing: At maturity, borrowers have the option to default or repay their loans, this means that their downside (with respect to their capital) is protected.
Yield swapping: In pools with interest-bearing assets as collateral (paired with the native asset as the supplied/borrowed asset), lenders can lend the native asset to lock-in a fixed rate. For example, lending DAI in a DAI/gDAI pool.
Capital efficiency: Instead of selling their token holdings to capture another opportunity, users can simply borrow against their holdings, this removes the burden of 'opportunity cost'.
Fixed-term lending/borrowing: Instead of having variable interest rates that is unpredictable (and can be costly for borrowers who are borrowing to hedge), a fixed-term lending/borrowing protocol offers predictability.
Leverage looping: Borrowers can borrow tokens in loops to get leveraged exposure on the price of the token pair.
Productive treasuries: Teams are commonly rich in their native tokens, and oftentimes these assets are left idle. Timeswap enable teams to lend out their native tokens in return for interests.
Funding through debt instead of equity: Instead of having to sell their native tokens to fund operational costs (i.e., raising capital through equity), Timeswap enables teams to borrow against their native tokens.
Token utility for long-tail assets: Adding a collateral utility to a token is highly valuable, but conventional lending/borrowing protocols require oracle support to setup a market. The difficulty of getting their native tokens eligible for a feed (costly and requires deep on-chain volume) prevents projects from expanding their token utilities. Timeswap changes this by removing all the dependencies and democratising access.
Token buyback mechanism: As a lender/LP (in a pool where borrowers are using the native token as collateral), borrowers defaulting would allow the team to purchase their native tokens at a predefined price level, while earning interest at that.
Here are some pools we launched with our partners, that can only be done through our design:
We launched two pools for USDC/ARB:
One allowing lenders to lend USDC, and borrowers to borrow USDC against their ARB holdings.
One allowing lenders to lend ARB, and borrowers to borrow ARB against their USDC holdings.
The feat: We are the first money market for ARB. We launched this pool ~2 hours after the ARB TGE occured (March 23, 2023).
How Timeswap's design enable this:
Other lending/borrowing protocols require an oracle (that has really high refresh rate to account for the extreme volatility).
Oracle support for ARB was only live after ~1 day of the TGE.
Our oracle independence and non-active value monitoring allows us to launch without needing all the other infrastructural dependencies to stabilise.
With support from PlutusDAO, we launched a pool for USDC/plsARB:
Allowing lenders to lend USDC, and borrowers to borrow USDC against their plsARB holdings.
The feat: We are the first money market for plsARB, and the most scalable way for plsARB holders to access capital.
How Timeswap's design enable this:
With there being no sufficient liquidity in the first 2 months of the launch of plsARB (a token with $9mn m.cap but ~$60k DEX liquidity), plsARB holders were essentially locked out from their positions.
There is no oracle support for plsARB.
Our oracle independence and non-liquidatable design allows us launch without needed sufficient on-chain liquidity.
