TimeMint: Understand Timeswap V1 Intuitively
This is part of Document 1 of the the TimeMint Series.
A Leightweight Guidance
Timeswap V1 is a fixed-maturity lending protocol. Instead of continuously re-pricing risk through liquidations and oracle-triggered margin calls, it organizes risk around a maturity date and settles outcomes at that date through predefined payout rules. This gives the protocol a very different character from familiar money markets. It behaves more like a term credit market with explicit roles and clearly separated claim types.
The easiest way to understand Timeswap V1 is to view it as a marketplace where different participants choose different slices of the same credit exposure. Some users want immediate borrowing power against collateral. Some users want yield and can tolerate default risk. Some users provide base liquidity and collect fees, while taking residual risk. The protocol keeps track of these exposures separately and resolves them in a strict order at maturity.
Big Picture
Every Timeswap pool is tied to a specific maturity timestamp. Before that timestamp, users can open or adjust positions. After that timestamp, new credit creation is over, and the system moves into settlement mode.
This maturity-centered design matters because it changes when risk is realized. In many lending systems, risk is managed continuously by liquidating unhealthy positions. In Timeswap V1, risk is mostly crystallized at maturity and then distributed by the protocol’s waterfall (*) logic. This is why the role definitions are so important: each role sits at a different point in the eventual loss distribution.
(*) In this context we refer to the waterfall whenever we want to talk about who can claim assets and in which order when - after maturiy - lenders cannot fully reclaim their lent assets due to a credit default shortfall
How Term Pricing Works In V1
Timeswap V1 prices term credit through an internal three-variable curve state (x,y,z), not through an oracle interest rate. When users borrow or lend, they move this state, and the protocol accepts only moves that satisfy its curve constraints. The practical implication is that rate and collateral terms are endogenous: they are computed from current pool state, trade size, and time to maturity.
State variables are:
-
x – the pool’s borrow liquidity
-
y – the pool’s interest pricing variable
-
z – the pool’s collateral coverage variable
Pool interactions are linear combinations of the following state transitions:
-
x \to x + \Delta x – add / remove borrowable asset to / from the pool
-
y \to y + \Delta y – add / remove interest payout claims to / from the pool
-
z \to z + \Delta z – add / remove collateral coverage to / from the pool
At a high level, valid trades must preserve the pool geometry:
This is the protocol’s core consistency condition. If a proposed borrow or lend move would violate it, the trade is rejected.
In the next sections, let’s dive into the user rules and how they move the pools state variables:
The Main User Roles
Borrowers
The intuition of the borrowers role is clear. The borrower:
-
removes asset liquidity from the pool lowering the state variable x \to x - \Delta x
-
in exchange pools insurance claims increasing state variable y \to y + \Delta y
-
and pools interest claims increasing state variable z \to z + \Delta z
Usually the position size the borrower takes (the amount taken from the pool) translates 1:1 to a state move \Delta x. The other moves can be chosen by the borrower but always obeying the universal preservation rule given by condition (1)
the protocol computes a borrower’s due (d,q), where d is debt in asset units and q is due-collateral in collateral units. With \tau=T-t, a semi-technical representation of the borrow-side structure is:
The first expression says debt is principal plus a term component that grows with both time-to-maturity and the y-move. The second says collateral requirement combines a term-sensitive piece (through \tau\Delta z) and a curve-pressure piece that rises as trade size grows relative to remaining x-depth.
Borrowing Operation Intuition
Borrowers take out the borrowable asset and post collateral. In return, they receive immediate liquidity and incur a due position (a debt obligation with associated collateral accounting). Before maturity, they can repay debt and unlock collateral subject to protocol rules. If they do not fully repair their position by maturity, their unresolved exposure contributes to the settlement outcomes faced by lenders and LPs.
A borrower therefore uses Timeswap as a source of term liquidity. The key tradeoff is straightforward: the borrower gets funds now, but must either repay before maturity or accept that collateral will be absorbed by the protocol’s maturity settlement process.
Lenders
A lending operation can be seen as the following set of state moves:
-
adds asset liquidity to the pool increasing the state variable x \to x + \Delta x which is then pooled for borrowing
-
in exchange the lender receives post-maturity insurance claims which removes pooled claims by moving state variable y \to y - \Delta y
-
the lender also receives post-maturity interest claims - which decreases the state variable z \to z - \Delta z
After the operation the trade geometry given by (1) mints claim components for the lender:
These are the quantities later redeemed at maturity. In plain terms, b-claims are the asset-side repayment claims (in plain asset units) and i-claims are the collateral-side insurance claims (in collateral units).
If a reader wants a quick “rate intuition,” the protocol-implied simple term factor for borrowers is approximately d/\Delta x, so an approximate simple annualized borrow rate is:
Likewise, for lenders, the bond-side simple term factor is approximately (b_P+b_I)/b_P, with the same annualization idea. These are not separate oracle rates; they are outcomes of the curve at the moment of trade.
This is why collateral requirement and interest cannot be discussed independently in V1. They are jointly produced by one state transition on the same curve.
Lending Operation Intuition
Lenders provide the borrowable asset to the pool before maturity. In return, they receive two claim components, often described as bond-like and insurance-like claims. These are accounting claims inside the protocol that determine how much asset and collateral they can withdraw after maturity.
A lender is not just buying a single undifferentiated “deposit yield.” Instead, the lender receives claim rights that are paid according to the protocol’s ordering rules. If the system performs well, lenders receive expected payouts. If there is a shortfall, lender payouts are reduced according to the predefined waterfall.
Liquidity Providers (LPs)
LP providers are combining the roles of lenders and borrowers. A liquidity provision can be seen as the following moves in the state variable space:
-
adds asset liquidity to the pool increasing the state variable x \to x + \Delta x which is then pooled for borrowing
-
relinquish insurance claims into the pool which moves the state variable y \to y + \Delta y
-
also relinquish post-maturity interest claims - which increases the state variable z \to z + \Delta z
The LPs bear a due, like the borrowers do:
But at the same time they also get liquidity points, which gives them junior insurance and interest claims in the post-maturity settlement waterfall.
Liquidity Provision Intuition
LPs provide base liquidity to support pool depth and trading capacity across the maturity market. In Timeswap V1, LP participation is tightly connected to the protocol’s credit accounting, so LP behavior is not identical to a simple spot AMM LP role. LPs earn fees, but they are also exposed to residual outcomes after higher-priority claims are handled.
In practical terms, LPs are paid for bearing structural risk. They can do well when flow and pricing are favorable, but they are junior in stress outcomes relative to earlier claims in the waterfall.
Protocol Owner / Fee Collector
The protocol owner role collects protocol-level fees that are accumulated as trading and position activity occurs. This role does not directly eliminate credit risk for other participants; it is primarily a fee governance and revenue function.
What Changes At Maturity
Maturity is the protocol’s transition from position management to payout resolution. Once maturity is reached, the system no longer behaves like an open credit market for that pool. Instead, it applies deterministic settlement rules.
This transition is the core of Timeswap V1’s philosophy. Rather than relying on continuous oracle-triggered liquidation to maintain an always-healthy state, it allows exposures to exist through time and then resolves the net outcome at a fixed endpoint.
How Settlement Works After Maturity
After maturity, users do not create new pre-maturity style exposures for that pool. Instead, they redeem according to their role-specific rights.
Lender withdrawals
Lenders burn their claims and receive payouts in asset and, if relevant, collateral. If available asset reserves are sufficient, lender payouts are straightforward. If there is a shortfall, the protocol applies its waterfall logic and lenders receive reduced payouts according to that ordering.
This is where the difference between claim components becomes economically visible: not all claim parts are treated identically under stress.
The core maturity split is:
That single branch explains most of the post-maturity behavior.
LP burn
LPs burn liquidity after maturity and receive what remains for their tranche, including their share of accrued fee accounting and any residual reserves available to LPs after higher-priority obligations are handled.
In strong outcomes, LPs can realize attractive fee-adjusted returns. In stressed outcomes, LP residual value can be materially reduced.
This “residual” property can be summarized informally as: LP value is what remains after higher-priority claim obligations are satisfied, so LP outcomes are convex to overall pool health.
Borrower consequences
If a borrower has fully repaired positions before maturity, outcomes are simple and collateral can be reclaimed under normal rules. If not, the unresolved exposure is absorbed into the maturity settlement process and affects how collateral and asset are distributed across claims.
From a borrower’s perspective, maturity is the hard deadline where “manage now” turns into “settle by protocol rules.”
Why This Feels Different From Typical Lending
Timeswap V1 is not trying to be a standard continuously-liquidated lending market. Its structure is closer to a term credit exchange with explicit claim engineering. That leads to different advantages and different risks.
The advantage is a clear maturity-based framework where exposures are explicit and payouts follow known ordering rules. The tradeoff is that this does not guarantee lenders are always whole in market-value terms. If the pool finishes with a deficit, losses are distributed according to the claim waterfall.
This is why user education is critical. Borrowers, lenders, and LPs are not doing the same trade under different UI labels. They are taking different slices of a shared credit system, and those slices behave differently at maturity.
Practical Role Summary
Borrowers use Timeswap V1 for term liquidity and must manage debt before maturity if they want predictable collateral outcomes.
Lenders use Timeswap V1 for term yield exposure and must understand that payout quality depends on maturity-time pool health, not a perpetual liquidation guarantee.
LPs use Timeswap V1 to earn fees and provide depth, while accepting junior residual risk in stressed settlement states.
The protocol owner captures protocol fees and controls fee-level governance, but this role does not remove credit risk from user roles.
Final Intuition
The most compact mental model is this: Timeswap V1 is a maturity-driven credit engine with explicit tranching of outcomes. Before maturity, users choose and manage exposures. At maturity, the protocol closes the book and pays each role by rule, not by negotiation.
If readers keep that one picture in mind, the rest of the role behavior and user interactions become much easier to understand.