# Introduction to Term Finance ### A transparent and scalable non-custodial fixed rate liquidity protocol for digital assets. The Term Finance Protocol enables noncustodial fixed-rate collateralized lending on-chain ([Term Repos](/protocol/term-repos)) modeled on tri-party repo arrangements common in TradFi. Borrowers and lenders are matched through a unique recurring auction process ([Term Auctions](/protocol/term-auctions)) where borrowers submit sealed bids and lenders submit sealed offers that are used to determine an interest rate that clears the market for participants of that auction. Participants who bid more than the clearing rate receive loans and participants willing to lend below the clearing rate make loans, in each case at the market-clearing rate. All other participants’ bids and offers are said to be “left on the table.” At the conclusion of an auction, borrowers receive loan proceeds and lenders receive ERC-20 tokens ([Term Repo Tokens](/protocol/term-repo-tokens)), which are receipts that lenders will burn to redeem for principal plus interest at maturity. Protocol smart contracts service these transactions by ledgering repayments and monitoring collateral health and liquidations. For execution workflows that manage existing positions, see [Terminal 1 Overview](/terminal-1-execution/overview). Please join the Term Finance [Telegram](https://t.me/+Q8nMs4zuM5tmMjAx) for updates. {% content-ref url="/pages/kvrluct62Z6axtzDZe4k" %} [Term Repos](/protocol/term-repos) {% endcontent-ref %} {% content-ref url="/pages/yMxLY9bc66kINEih6l6f" %} [Term Auctions](/protocol/term-auctions) {% endcontent-ref %} {% content-ref url="/pages/yVdFPLVBPe4zo0euBIFN" %} [Term Repo Tokens](/protocol/term-repo-tokens) {% endcontent-ref %} # Term Repos The Term Finance Protocol enables the deployment of Term Repos. A Term Repo is a specific on-chain implementation of fixed-rate collateralized lending modeled on tri-party repo in the TradFi context.

Flow of a standard tri-party repo transaction

### Defining Characteristics Key characteristics of Term Repos include the following: * ***Fixed-term, fixed-rate*** - Term Repos involve fixed-term, fixed-rate loans as opposed open-ended, floating-rate loans common in DeFi. Borrowers must repay their loans on the maturity or [repurchase date ](/protocol/term-repos/terminology#repurchase-date)and must do so within the [repurchase window](/protocol/term-repos/terminology#repurchase-window). * ***Non-callable*** - Term Repos are non-callable in that lenders cannot redeem and borrowers cannot repay prior to the maturity or [repurchase date](/protocol/term-repos/terminology#repurchase-date). * ***Collateralized*** - Term Repos are meant to facilitate short-term liquidity management needs and made on an over-collateralized basis backed by liquid digital assets (e.g. wBTC, wETH, USDC, USDT). * ***Non-custodial*** - Collateral backing a Term Repo is not held in custody but rather locked in a decentralized smart contract (known as a [Term Repo Locker](https://app.gitbook.com/o/mtdlWPfF7nYcHeExrZ09/s/5pvpy8IqtxZOybRubGkj/~/changes/125/protocol/term-repos/margin-maintenance)) that is verifiable by both borrowers and lenders in real-time. The Term Repo Locker does not allow for rehypothecation of collateral and is accessible only by users using their private keys and in strict accordance with the terms of the smart contract arrangement. Each Term Repo has a separate Term Repo Locker associated with it. * ***Auction mechanism*** - The interest rate for a Term Repo is determined by an auction known as a [Term Auction](/protocol/term-auctions). Each Term Repo has its own Term Auction. Term Repos may differ among each other in the characteristics listed above. For example, one Term Repo may have a 4-week term while another Term Repo has a 6-week term. # Key terms The terms of a Term Repo arrangement are configurable and set by the deployer. Key terms with descriptions and examples are set forth in the table below.
TermSet ByDescriptionExample
Purchase TokenDeployerRefers to the ERC-20 token in which a Term Repo loan is denominatedUSDC
Collateral Token(s)DeployerRefers to the ERC
-20 token(s) eligible to be posted as collateral		WETH
Purchase PriceUserRefers to the principal amount borrowed or lent (denominated in Purchase Tokens)1,250,000 USDC
Repo RateTerm AuctionAn annualized interest rate that is applied to the Purchase Price to determined the Repurchase Price due at maturity3.5%
Repurchase PriceTerm AuctionThe amount due at maturity/on the Repurchase Date from a borrower to a Term Repo1,253,160 USDC
Repurchase DateDeployerThe date (and time) on which a loan is due/Term Repo matures4 weeks
Repurchase WindowDeployerThe amount of time after the Repurchase Date that a borrower has to repurchase their collateral before it is liquidated (typically 24 hours)24 hours
Initial MarginDeployerThe ratio of the market value of collateral posted to the purchase price received by a borrower that is required to open a borrow position150%
Maintenance MarginDeployerThe ratio of the market value of collateral posted to the repurchase price owed by a borrower to avoid liquidation125%
Price Oracle FeedDeployerThe price oracle feed by which borrower collateral is marked to market (updated every hour OR if price movement exceeds a threshold, e.g. 0.5%)Chainlink
Servicing FeeDeployerA servicing fee, quoted at an annualized rate, applied on a borrower’s principal loan amount for servicing a Term Repo0.5%
Liquidated DamagesDeployerAnytime collateral is liquidated, the defaulting borrower is charged liquidated damages assessed as a percent of debt that was covered in liquidation. This goes in part to incentivize liquidators and in part to the Protocol8.0% (2.8% of which goes to protocol, see below)
Protocol Liquidated DamagesDeployerThe portion of liquidated damages that accrues to the Protocol2.8%
De Minimis Collateral ThresholdDeployerTo protect the borrower against excessive liquidation, liquidations cannot exceed the minimum amount necessary to bring a borrower back to the initial margin ratio, except in the case borrower’s collateral value net of his or her repurchase obligation is at or below the de minimis threshold$500
# Margin maintenance Borrowers may manage their collateral during the term of a Term Repo transaction by calling certain external functions. ### Term Repo Lockers Each Term Repo has a Term Repo Locker, which is a smart contract that locks collateral on behalf of borrowers and lenders for that Term Repo. {% hint style="info" %} By segregating Term Repo Lockers by maturity and purchase token/collateral token pairs rather than instituting a single large commingled collateral pool reduces user exposure to cybersecurity risks and exploits. {% endhint %} ### Price oracle All borrower balances, including collateral and repurchase balances are valued in USD using decentralized price oracles (primarily [Chainlink](https://chain.link/)). These oracles are source of truth for the fair-market value of all tokens on the Protocol (including all collateral tokens) and are decentralized to mitigate against unilateral attack by a malicious data provider (for more information, see risk disclosures on [oracle risk)](/protocol/risk-disclosures/term-repo-risks#oracle-risk). ### Withdraw collateral If at any time a borrower has [margin excess](/protocol/term-repos/terminology#margin-excess), the borrower may withdraw collateral by calling the public function `externalUnlockCollateral`. A borrower may not make any withdrawals that would put their account into a [margin deficit](broken://pages/wJn1mggFYDqxJs5R8FY2). ### Add collateral If at any time a borrower wishes to post additional margin to their account as additional buffer against liquidation, they may do so by calling the public function `externalLockCollateral`. There are not limits to the amount of collateral a borrower my lock in this manner. # Maturity On the maturity or repurchase date, borrowers are obligated to repurchase their collateral tokens at the repurchase price. ## Repurchase Window Borrowers must repay within the [repurchase window](broken://pages/qAu1HYuKYRubps7ZHmbW), which is typically a 24 hour window beginning on the [repurchase date](/protocol/term-repos/terminology#repurchase-date) and time. Failure to do so results in a default and liquidation due to a [failure to repurchase](broken://pages/hMmexk0Cy8zR9nHeZwoc). Lenders cannot burn Term Repo Tokens to obtain repayment during the repurchase window. ## Redemption Window Once the repurchase window closes, the redemption window begins. The redemption window is open ended. Lenders holding [Term Repo Tokens](/protocol/term-repo-tokens) may burn them to convert them into Purchase Tokens. {% hint style="info" %} To the extent there are insufficient purchase tokens to cover the aggregate [repurchase price ](/protocol/term-repos/terminology#repurchase-price)owed across all borrowers party to a Term Repo, the redemption rate of the Term Repo's corresponding Term Repo Tokens will be subject to a haircut applied equally across all lenders. {% endhint %} # Collapse position Borrowers may not repurchase ahead of the repurchase date, but may collapse their position by obtaining and burning corresponding Term Repo Tokens. Term Repos are non-callable loans where both borrowers and lenders commit to borrowing and lending for the full term. Neither party to a transaction is able to terminate the transaction prior to the repurchase date. Borrowers are, however, able to negotiate to purchase Term Repo Tokens that represent claims against their repurchase obligation from lenders. To the extent borrowers obtain corresponding Term Repo Tokens, they will be able to collapse the two positions (asset and liability) by burning the Term Repo Tokens against their repurchase balance by calling the `borrowerCollapseLoan`function. For routed execution that repays and unwinds linked exposure in one flow, see [Close / Loop-out](/terminal-1-execution/workflows/repay-loop-out). # Defaults Default occurs when a borrower (i) fails to maintain sufficient margin or (ii) fails to repurchase on time (or within the repurchase window). Default occurs when a borrower (1) fails to maintain sufficient margin or (2) fails to repurchase its collateral tokens within the repayment window.
Margin deficit A margin deficit occurs when the value of a borrower's collateral is no longer sufficient to meet the [maintenance margin ratio](/protocol/term-repos/terminology#maintenance-margin-ratio). The protocol tracks this by monitoring a borrower's [transaction exposure](/protocol/term-repos/conventions#transaction-exposure), which is calculated as follows: $$\text{transactionExposure} = \text{maintenanceMarginRatio}\*\text{repurchasePrice}-\text{collateralMarketValue}$$ where the [collateral market value ](/protocol/term-repos/terminology#collateral-market-value)is measured in real-time using [Chainlink oracle price feeds](https://data.chain.link/). Where a borrower's [Transaction Exposure ](/protocol/term-repos/terminology#transaction-exposure)is negative, their collateral is eligible for [liquidation](/protocol/term-repos/defaults/liquidation).
Failure to repurchase The repurchase date marks the maturity date of a Term Repo. Borrowers are required to repurchase their collateral tokens on the repurchase date and they must do so within the [repurchase window](/protocol/term-repos/terminology#repurchase-window), which typically lasts 12 to 24 hours from the repurchase date. Failure to do so means that the borrower is in default and their collateral is eligible for [liquidation](/protocol/term-repos/defaults/liquidation).
# Liquidation Liquidation is the process whereby collateral tokens are seized and sold to a liquidator in the event of default. {% hint style="info" %} Liquidations occur without notice. Borrowers are advised to monitor their transaction exposure closely. To the extent a borrower posts multiple collateral tokens against a loan, borrowers do not have the ability to determine which collateral is sold in liquidation and in what order their collateral is liquidated. {% endhint %} ### Liquidation When a borrower's collateral becomes eligible for liquidation, anyone choosing to act as a liquidator may purchase a portion of the borrower's collateral tokens at the prevailing [Chainlink oracle price ](https://data.chain.link/)by calling the `batchLiquidation` function and specifying the amount that the liquidator wishes to repay on behalf of the borrower. The proceeds from the liquidation (total repayment amount) go towards paying down the borrower's debt. [Liquidated damages](/protocol/term-repos/terminology#liquidation-penalty) are applied to the collateral liquidated in a liquidation transaction such that the total collateral seized from the borrower is equal to: $$\text{totalCollateralSeized} = (1+\text{liquidatedDamages}) \* \dfrac{\text{totalRepaymentAmount}}{\text{collateralPrice}}$$ where liquidated damages are split between [liquidation incentives](/protocol/term-repos/terminology#liquidation-discount) to the liquidator and [protocol liquidated damages](/protocol/term-repos/terminology#protocol-seize-share): $$\text{liquidatedDamages} = \text{liquidatorIncentive} +\text{protocolLiquidatedDamages}$$
Liquidation Fee Example If liquidated damages are set at 8.0% and the protocol seize share at 2.8% then a liquidation transaction that seeks to repay $100,000 of a borrower's repurchase debt would seize $108,000 of collateral, with $105,200 worth of collateral going to the liquidator and $2,800 going to the protocol.
# Liquidation protection Liquidations are limited only to the amount necessary to cure default. Borrowers are protected against excessive liquidations. The amount that can be liquidated through the `batchLiquidation`function cannot exceed the minimum amount necessary to bring the borrower's margin ratio back to the initial margin ratio (in the case of margin deficit) and the minimum amount necessary to cover a borrower repurchase price (in the case of failure to repay) after adjusting for [liquidated damages](/protocol/term-repos/terminology#liquidation-penalty). This is in contrast to arbitrary close factors found in other lending protocols and should protect against excessive liquidations. {% hint style="info" %} Liquidation protection will be enforced only to the extent the fair market value of collateral less a borrower's outstanding repurchase obligation exceeds the de minimis collateral threshold to avoid an infinite liquidation loop. {% endhint %} # Terminology Definitions and terminology relating to Term's digital repo transactions. ### Purchase Price The price at which collateral tokens are transferred by a borrower to a lender in a repo transaction and can be thought of as the amount borrowed in a repo agreement. ### Repurchase Price The price at which collateral tokens are to be transferred back to a borrower upon maturity or termination of a repo transaction. The difference between the repurchase price and the purchase price reflects the interest earned by the lender/owed by the borrower and is calculated by applying the pricing rate over the term of a repo transaction. The formula for determination of the repurchase price can be found in [Conventions ](/protocol/term-repos/conventions)section. ### Price Differential The price differential is the difference between the [repurchase price ](#repurchase-price)and [purchase price ](#purchase-price)in a repo transaction and can be viewed as the interest earned by the lender/owed by the borrower over the term of a repo transaction. ### Pricing Rate (Repo Rate) The per annum percentage rate for determination of the repurchase price, also known as the "repo rate". ### Purchase Date The purchase date is the date on which the purchased tokens are to be transferred by borrower to the lender. ### Repurchase Date The date on which the borrower is to repurchase the collateral tokens from lender. ### Repurchase Window A window of time beginning on the repurchase date and typically lasting 12 to 24 hours during which repurchase must occur. ### Purchase Token The base digital currency in which the [purchase price ](#purchase-price)and repurchase price are de-nominated. ### Collateral Token The digital asset "sold" to the lender as part of a repo transaction that serves a collateral for a borrower's loan. ### Initial Margin Ratio The ratio of the value of [collateral tokens ](#collateral-token)to the [purchase price ](#purchase-price)required to bid in a Term auction, quoted as a percentage rate. This is a function of the purchase price because the [pricing rate ](#pricing-rate-repo-rate)is not known until after all bids have been submitted and an auction has been cleared. The initial margin requirement is typically higher than the [maintenance margin requirement ](#maintenance-margin-requirement)to maintain a buffer against liquidation. ### Maintenance Margin Ratio The ratio of the value of [collateral tokens](#collateral-token) to the [repurchase price](#repurchase-price) required to avoid liquidation. ### Market Value of Collateral The market value with respect to any [collateral tokens ](#collateral-token)as of any point in time based on the price for such collateral tokens obtained via real-time Chainlink oracle feeds. ### Transaction Exposure Transaction exposure measures the margin deficit or excess of an account. We apply the maintenance margin ratio to the current market value of collateral based on Chainlink oracle feeds and compare that to the repurchase price as shown [here](/protocol/term-repos/conventions#transaction-exposure). Where an account is in margin deficit (negative transaction exposure) its collateral is eligible for liquidation. ### Margin Excess Where the [market value of collateral](#market-value-of-collateral) of a borrower exceeds the [maintenance margin ratio ](#maintenance-margin-ratio)multiplied by the [repurchase price ](#repurchase-price)owed by such borrower, the borrower is said to be in margin excess. ### Margin Deficit Where the [market value of collateral](#market-value-of-collateral) of a borrower is less than the [maintenance margin ratio ](#maintenance-margin-ratio)multiplied by the [repurchase price ](#repurchase-price)owed by such borrower, the borrower is said to be in margin deficit. ### Liquidated Damages Liquidated damages are a surcharge to the amount of collateral seized in liquidations when valued at fair market value measured as a percentage rate. The surcharge is split between the portion that goes to the liquidator ([liquidation incentive](#liquidation-incentive)) and the portion that accrues to the protocol ([protocol liquidated damages](#protocol-seize-share)) such that: $$\text{liquidatedDamages} = \text{liquidatorIncentive} +\text{protocolLiquidatedDamages}$$ ### Liquidator Incentive The liquidation incentive is the portion of the [liquidated damages ](#liquidation-penalty)that accrues to the liquidator. ### Protocol Liquidated Damages Protocol liquidated damages are the portion of the [liquidated damages ](#liquidation-penalty)that accrues to the protocol. ### Recovery Rate The rate at which all lenders to a term pool recover in the event that after all repurchases and liquidations are accounted for, there is insufficient purchase tokens to allow for 1:1 redmption of repo tokens. ### De Minimis Collateral Threshold The de minimis collateral threshold is the value where liquidation protection will no longer be enforced to avoid an infinite loop of partial liquidations. It is measured as the market value of collateral less the Protocol's outstanding repurchase exposure to that borrower. # Conventions Conventions used by Term Finance. ### Day-count convention In calculating the repurchase price due at maturity based on the market clearing repo rate, we follow an Actual/360 day count convention. $$ \text{DayCountFactor} = \frac{\text{Days}(\text{AuctionDate},\text{ MaturityDate})}{360} $$ ### Repurchase Price The Repurchase Price, given the Purchase Price and any given repo rate is calculated as follows: $$ \text{RepurchasePrice} = \text{PurchasePrice} \left(1+ \text{RepoRate}\*\text{DayCountFactor}\right)\ $$ # Rollovers Borrowers may elect to rollover or extend the term of their repo transactions. As a convenience feature, borrowers are able to elect to rollover or extend their repo transaction prior to maturity. They may do so by electing a specific auction to extend their [repurchase date ](/protocol/term-repos/terminology#repurchase-date)by calling the `borrowerElectRollover`function. Only auctions that (i) settle in the same [Purchase Token ](/protocol/term-repos/terminology#purchase-token)and (ii) accept the same [collateral tokens ](/protocol/term-repos/terminology#collateral-token)are eligible for rollover. The [auction date ](/protocol/term-auctions/terminology#auction-date)and [time ](/protocol/term-auctions/terminology#auction-time)of the rollover auction must also fall within the [repurchase window](/protocol/term-repos/maturity#repurchase-window). For execution guidance on routed rollover flows, permits, and route checks, see [Terminal 1 Rollover](/terminal-1-execution/workflows/one-click-rollover). By electing to rollover an existing Term Repo, a borrower is able to tender a bid in a rollover auction without locking new collateral. Collateral held against an existing Term Repo are credited against their bid in the rollover auction thereby saving the step of obtaining bridge funds between the repurchase date and the clearing of a subsequent auction to refinance an existing position. {% hint style="info" %} Rollovers require that a borrower submit a rollover amount and a bid rate. Rollover bids will only succeed if the rollover bid satisfies the market clearing rate determined in auction. To the extent a rollover bid fails, borrower will be required to repay in the time remaining or face liquidation. {% endhint %} {% hint style="info" %} When electing rollovers, be sure to have sufficient collateral to satisfy the maintenance margin required in the new Term Repo. Insufficient margin would result in a failed rollover bid and could lead to liquidation if the existing Term Repo is not repaid in the time remaining. {% endhint %} {% hint style="info" %} To the extent a borrower's remaining repurchase obligation is reduced below the rollover amount in between the time a rollover is elected and the time the rollover bid is processed (perhaps through a liquidation event), the Protocol will attempt to roll the entire amount outstanding unless otherwise edited or cancelled. {% endhint %} {% hint style="info" %} Where multiple auctions are eligible for rollover, a user is only able to elect into ONE of them. Users can switch, but they cannot elect to roll a single position into multiple auctions. {% endhint %} # Term Auctions Term Auctions are sealed-bid, single-shot, double-auctions, also known as "call-markets" where bids and offers are batched by an auctioneer for matching and execution at pre-specified times. ## Term Auctions Term Auctions are sealed-bid, second-price, single-shot, single-price [double-auctions](https://en.wikipedia.org/wiki/Double_auction), or "call-markets," where lenders submit offers to lend [purchase tokens](/protocol/term-repos/terminology#purchase-token), and borrowers submit bids to borrow [purchase tokens](/protocol/term-repos/terminology#purchase-token). The Protocol then determines some interest rate that clears the market (the [clearing rate](/protocol/term-auctions/terminology#clearing-rate)): lenders willing to lend below the [clearing rate](/protocol/term-auctions/terminology#clearing-rate) make a loan and borrowers willing to pay at or above the [clearing rate](/protocol/term-auctions/terminology#clearing-rate) receive a loan, in each case at the [clearing rate](/protocol/term-auctions/terminology#clearing-rate). By batching many orders together at periodic intervals, double auctions increase liquidity and decrease transaction costs. {% hint style="info" %} Fills in auction are assigned with priority given to lenders most willing to pay (highest bid) and borrowers most willing to lend (lowest offer). A bid above the market clearing rate or an offer below the market clearing rate is not guaranteed to result in a fill. Fills will be assigned until the total market clearing volume is exhausted on either side of the market. {% endhint %} # Auction characteristics Defining characteristics of Term Auctions. ### *Sealed-bid* Term Auctions are "sealed-bid" auctions, where participants' tenders (to borrow or lend) are hidden from the public through a hashing algorithm until the market clears and bids/offers are revealed. ### *Single-shot* Term Auctions are "single-shot" auctions. Offers submitted during the auction window are batched and held to clear at a pre-announced point in time. This is in contrast to continuous auctions that operate much like central limit order books found on centralized exchanges. ### *Single-price* Term Auctions are "single-price" auctions, where all borrowers and lenders transact at a single clearing price. Lenders asking at or below the clearing price (low cost suppliers) and borrowers bidding at or above the clearing price (most willing to pay) are eligible to receive an allocation through the auction. ### *Second-price* The clearing price is determined as an average of second best offer on the borrowing and lending side. This is to reduce incentives for participants to tender any bids or offers at any price other than their true valuation. e.g. incentive compatibility. ### *Double-auction* Term Auctions are "[double-auctions](https://en.wikipedia.org/wiki/Double_auction)" where both borrowers and lenders actively participate and submit offers to borrow and lend, respectively. This is in contrast to the more familiar single-auction in which only one party (typically the buyer) is active (e.g. auction house or e-bay seller selling to the highest active bidder). ### *Pro-rata on the margin allocation* Allocations prioritize cheapest cost suppliers on the lending side and borrowers most willing to pay. This ensures that resources are allocated to the most efficient suppliers and those with the best use of proceeds. Where there is excess supply or demand at the clearing price on the margin, those marginal lenders (borrowers) are allocated in proportion to their share of all offers (bids) at the marginal price. This process is standard convention in traditional finance (e.g. [U.S. Treasury auctions](https://www.newyorkfed.org/medialibrary/media/research/current_issues/ci11-2.html)). # Auction timeline Timeline of a typical Term Auction. The timeline of a typical Term auction begins on the [announcement date ](/protocol/term-auctions/terminology#announcement-date)where the details and terms of an auction are announced and ends on the [auction date](/protocol/term-auctions/terminology#auction-date) where assigned [bids ](/protocol/term-auctions/terminology#bid)and [offers](/protocol/term-auctions/terminology#offer) are settled.
Announcement Date The announcement date is the date on which the date of an upcoming auction is set and the terms of the underlying [Term Repo](/protocol/term-repos) are fixed and deployed. Auctions will typically be announced and deployed at least a week in advance of the [auction date](/protocol/term-auctions/terminology#auction-date). Users will be able to view and search auctions on the user interface with details specifying the (i) term of the repo transactions up for auction, (ii) the [purchase token ](/protocol/term-repos/terminology#purchase-token)and [collateral tokens](/protocol/term-repos/terminology#collateral-token) involved in the transaction, (iii) the [initial ](/protocol/term-repos/terminology#initial-margin-ratio)and [maintenance ](/protocol/term-repos/terminology#maintenance-margin-ratio)margin ratios, as well as (iv) any applicable fees.
Auction Window The auction window is the period of time during which [bids ](/protocol/term-auctions/terminology#bid)and [offers](/protocol/term-auctions/terminology#offer) may be tendered for consideration in a [Term auction](/protocol/term-auctions) by calling the public `lockBids`or `lockOffers` functions. The auction window typically begins 12-24 hours prior to the [auction time](/protocol/term-auctions/terminology#auction-time) on the [auction date](/protocol/term-auctions/terminology#auction-date). Submissions of [bids ](/protocol/term-auctions/terminology#bid)and [offers](/protocol/term-auctions/terminology#offer) are only allowed during the auction window. Any validly submitted [bid ](/protocol/term-auctions/terminology#bid)or [offer](/protocol/term-auctions/terminology#offer) will be considered in the auction. Any submitted tender may be edited or canceled during the auction window.
Reveal Period The [reveal period ](/protocol/term-auctions/terminology#reveal-period)is the process in which hashed bid and offer prices on chain are revealed by Protocol keepers. On-chain validation measures are taken to ensure that revealed prices match the hashes recorded in the Protocol to prevent tampering. The reveal period begins once the open period ends and an auction is closed to further tenders. The logic behind reveals are available for inspection through the `revealBid` and `revealOffer` functions.
# Complete Auction The complete auction process is where a clearing rate is determined and the auction is cleared and settled. The `completeAuction` function is callable once validly submitted tenders have been revealed. This is a two-step process where the Protocol: 1. determines a [pricing rate ](/protocol/term-repos/terminology#pricing-rate-repo-rate)to clear the market (the [clearing rate](/protocol/term-auctions/terminology#clearing-rate)); 2. assigns fills based on the resulting [clearing rate](/protocol/term-auctions/terminology#clearing-rate); and finally 3. settles fills and unlocks tenders "left on the table" # Clearing rate Generally speaking, the clearing rate is determined by sorting revealed bids and offers and passing the result into an (on-chain) algorithm that searches for an interest rate where supply meets demand. The logic can be found in the internal function `_calculateClearingPrice`, which runs our clearing price algorithm that seeks to maximize the total volume matched between borrowers and lenders at any given interest rate. ### Second-price auction In practice, there will typically be a range of interest rates that lead to the same equilibrium. Say, for example, the most competitive bid eligible for matching is 3.5% and the most competitive offer eligible for matching is 3.0%. In this example, any interest rate between 3.0% and 3.5% will result the same allocation. A simple solution would be to split the difference by setting the clearing rate at the midpoint between 3.0% and 3.5% (e.g. 3.25%). This solution, however, is vulnerable to situations where participants could be incentivized to manipulate the clearing price slightly in their favor by systematically "shading" their bids/offers. To avoid this type of strategic behavior, the Protocol takes the average between the *second* most competitive bid and *second* most competitive offer in determining the clearing rate following [McAffee 1992](https://www.sciencedirect.com/science/article/abs/pii/002205319290091U). By implementing this solution, participants are encouraged to report bid/offer their true valuations. # Assignment Once a clearing rate is determined, bids and offers can be assigned. All bids higher than the clearing rate and all offers lower than the clearing rate are eligible for assignment. All others are said to be "left on the table." The assignment process prioritizes lowest cost suppliers on the lending side and borrowers most willing to pay and continues until all possible matches at the clearing rate are exhausted. This ensures that resources are allocated to the most efficient suppliers and those with the best use of proceeds. Where there is excess supply or demand at the clearing price on the margin, those marginal lenders (borrowers) are allocated in proportion to their share of all offers (bids) at the marginal price. This process is known as [pro-rata on the margin allocation ](/protocol/term-auctions/auction-characteristics#pro-rata-on-the-margin-allocation)and follows standard convention common in traditional finance (see e.g. [U.S. Treasury auctions](https://www.newyorkfed.org/medialibrary/media/research/current_issues/ci11-2.html)). The logic behind the assignment process can be found in the internal functions: `_assignBids` and `_assignOffers` within the `TermAuction.sol`contract. {% hint style="info" %} Submitting a bid greater than or an offer below the clearing rate does not guarantee assignment. Bids can be invalidated if the collateral posted against their bid is no longer sufficient to satisfy the maintenance margin at the time of auction clearing. Moreover, it is possible that the assignment methodology results in a situation where allocations may be exhausted before marginal bidders/offerors are assigned. {% endhint %} # Settlement ### Peer-to-pool settlement Because properly submitted [bids ](/protocol/term-auctions/terminology#bid)and [offers](/protocol/term-auctions/terminology#offer) require that [collateral tokens ](/protocol/term-repos/terminology#collateral-token)and [purchase tokens](/protocol/term-repos/terminology#purchase-token) be locked at the time each tender is submitted, settlement is straightforward. Collateral tokens belonging to assigned bids remain with the collateral agent, while purchase tokens belonging to assigned offers are transferred from the agent to assigned borrowers. Lenders receive ERC-20 tokens ([Term Repo Tokens](/protocol/term-repo-tokens)), which are essentially receipt tokens, that can be burned to claim principal plus interest at maturity. ### "Left on the table" All other tenders not assigned in the auction are said to be "left on the table." Collateral tokens and purchase tokens associated with tenders left on the table are unlocked and returned to their respective wallets. # Terminology Definitions and terminology relating to Term Auctions. ### Tender The Oxford Learner's dictionary defines the *noun* [tender](https://dictionary.cambridge.org/us/dictionary/english/tender) as: a formal offer to supply goods or do work at a stated price. In the context of business and finance, tenders typically refer to sealed or private offers submitted in response to a request. This is in contrast to open or publicly submitted offers common in public auctions. In Term Auctions, users are asked to submit tenders to borrow or lend, specifying the amount they are looking to borrow and lend as well as the rate at which they are willing to do so. A tender to borrow is a "bid" and a tender to lend is an "offer". Validly submitted tenders while the auction is open for tenders are sent to the Protocol for the determination of the clearing rate once the auction closes. ### Bid A bid is a tender to borrow a specified amount of [purchase tokens ](/protocol/term-repos/terminology#purchase-token)at a specified [pricing rate ](/protocol/term-repos/terminology#pricing-rate-repo-rate)or repo rate. Bidding requires that the borrower lock the [collateral tokens ](/protocol/term-repos/terminology#collateral-token)they intend to use to back their loan at the time a bid is submitted to ensure that the auction clears if the borrower is assigned in the auction. The amount required to be locked is equal to the amount they are looking to borrow multiplied by the [initial margin ratio](/protocol/term-repos/terminology#initial-margin-ratio). All bids are sealed until the time an auction is closed for further submissions. Any bid higher than or equal to the [clearing rate ](#clearing-rate)is eligible for assignment. ### Offer An offer is a tender to lend a specified amount of [purchase tokens ](/protocol/term-repos/terminology#purchase-token)at a specified [pricing rate ](/protocol/term-repos/terminology#pricing-rate-repo-rate)or repo rate. Submitting an offer requires that the borrower lock the [purchase tokens ](/protocol/term-repos/terminology#purchase-token)they are offering to lend at the time an offer is submitted to ensure that the auction clears if the lender is assigned in the auction. All offers are sealed until the time an auction is closed for further submissions. Any offer lower than or equal to the [clearing rate ](#clearing-rate)is eligible for assignment. ### Clearing Rate The clearing rate is chosen by the Protocol and is set at the rate where supply meets demand. Any borrowers who bid higher than the clearing rate and any lenders who asked less than the clearing rate are eligible to be assigned in the auctions. All others are said to be "left on the table." ### Announcement Date The announcement date is the date on which the date of an upcoming auction is set and the terms of the underlying [Term Repo](/protocol/term-repos) are determined. ### Auction Date The auction date is the date on which an auction closes, a clearing rate is determined, and successful bids and offers are assigned. ### Auction Time The auction time is the time on the [auction date](#auction-date) at which no further tenders will be accepted and the clearing process begins. ### Auction Window The auction window is the period of time during which participants are allowed to submit tenders for consideration in an auction. The auction window typically begins 12 to 24 hours prior to the [auction time](#auction-time) where an auction closes to further submissions and the clearing process begins. ### Assignment Assignment is the action of processing successful bids and offers after a clearing price has been determined by the Protocol. Lenders who are assigned in the auction will receive ERC-20 tokens that will be redeemable 1:1 for the [repurchase price ](/protocol/term-repos/terminology#repurchase-price)on the [repurchase date ](/protocol/term-repos/terminology#repurchase-date)(maturity date). Borrowers who are assigned in the auction will receive purchase tokens in an amount equal to the amount they successfully bid for. Their collateral will remain locked in the Protocol, subject to liquidations and timely repayment. ### Reveal Period The reveal period begins shortly after the auction closes at the [auction time](#auction-time). During this period, all validly submitted tenders will be revealed on-chain to determine the clearing rate and to process assignments. # Term Repo Tokens Term repo tokens are composable ERC-20 tokens that represent a claim to payment on a specific maturity date from a specific Term Repo. A unique feature of Term Repo transactions is that lenders receive ERC-20 tokens known as Term Repo Tokens in an amount equal to the [repurchase price ](/protocol/term-repos/terminology#repurchase-price)due to them on the [repurchase date](/protocol/term-repos/terminology#repurchase-date). These repo tokens represent a claim against the Term Repo and are normalized to convert 1:1 with the underlying [purchase token](/protocol/term-repos/terminology#purchase-token) at maturity when burned. The amount of repo tokens received by each lender is a function of the [clearing rate](/protocol/term-auctions/terminology#clearing-rate) and amount of [purchase tokens](/protocol/term-repos/terminology#purchase-token) successfully tendered in auction. The exact formula can be found in the [Conventions](/protocol/term-repos/conventions) section. While lenders are not allowed to redeem prior to the repurchase date, they are free to find willing buyers of their Term Repo Tokens if they find themselves in need of liquidity. {% hint style="info" %} To the extent there are insufficient purchase tokens to cover the aggregate [repurchase price ](/protocol/term-repos/terminology#repurchase-price)owed across all borrowers party to a Term Repo, the redemption rate of the Term Repo's corresponding Term Repo Tokens will be subject to a haircut applied equally across all lenders. {% endhint %} # Key metadata State variables relevant to pricing are stored in each Term Repo Token:
| Term | Set By | Description | | ------------------------ | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Term Repo Id | Deployer | The Term Repo (see above) that the Term Repo Token belongs to | | Repurchase Date | Deployer | The date on which a particular Term Repo Token can be redeemed | | Redemption Value | Deployer | A ratio specifying the number of purchase tokens redeemable per unit of Term Repo Token | | Mint Exposure Cap | Deployer (updates) | The number of Term Repo Tokens that can be minted against corresponding assumption of liability outside of auctions by authorized market makers | | Purchase Token | Deployer | The purchase tokens that Term Repo Token can be redeemed for | | Collateral Token(s) | Deployer | The collateral tokens backing the loans that Term Repo Tokens are redeemable for | | Maintenance Margin Ratio | Deployer | The maintenance margin ratio required to be observed by borrowers to Term Repo | | Total Supply | Deployer (updates) | The total supply of a particular Term Repo Token | \ \
\
# Valuation Term Repo Tokens should be valued at the price of the underlying purchase token multiplied by the redemption value (typically 1:1) adjusted for (i) the time value of money and (ii) the perceived risk of collateral backing those loans and (iii) the required maintenance margin ratios applied to those loans. The time value of money should reference the redemption timestamp, which is the earliest time at which Term Repo Tokens can be redeemed (typically begins within 24 hours of the repurchase date).
# Fees and Penalties Overview of applicable protocol fees. Users of the protocol are subject to two types of fees: a loan servicing fee and liquidated damages. # Servicing Fee Borrowers are charged a loan servicing fee, typically ranging from 0.30%-0.50% per annum applied to the purchase price received in auction. The servicing fee is a fee earned by the protocol for processing loans, maintaining records, and monitoring collateral. The fee is quoted as an annualized rate applied to and deducted from any loan proceeds obtained as a result of a successful bid by a borrower. {% hint style="info" %} While the servicing fee is nominally charged to the borrower, borrowers will take this into account when placing bids such that the economic burden of the fee will fall on both borrowers and lenders, (see [tutorial ](https://www.khanacademy.org/economics-finance-domain/ap-microeconomics/unit-2-supply-and-demnd/28/v/example-breaking-down-tax-incidence)on the economics of tax incidence at Khan Academy). {% endhint %} {% hint style="info" %} Fixed fees have been shown to be economically efficient in contrast to bid-ask spread fees, which can lead to strategic behavior ([Jantshcgi et al, 2022](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4069827)). {% endhint %}
Servicing Fee Example * Servicing Fee = 0.5% per annum * Term Repo Term = 4 weeks (28 days) * Borrower Purchase Price (amount accepted in auction) = 100,000 USDC * All fees calculated on an actual / 360 basis * Payable up-front by the borrower (no fees to lenders) Servicing Fee = **38.88... USDC** = 100,000 USDC \* 0.005 \* 28 / 360
# Liquidated Damages Borrowers in default are subject to liquidated damages typically set at 8% of any debt covered in liquidation. Borrowers in default are subject to [liquidated damages](/protocol/term-repos/terminology#liquidation-penalty) (a surcharge), which is applied to any debt covered in liquidated and collected in collateral tokens. Liquidated damages are split between liquidators (typically 5.2%) as a liquidation incentive and the protocol (protocol liquidated damages, typically set at 2.8%).
Liquidated Damages Example * Liquidated Damages = 8% * Protocol Liquidated Damages = 2.8% * Liquidation Incentive = 8% - 2.8% = 5.2% * Repurchase Exposure covered in liquidation = 100,000 USDC * Markt price of (USDC) based on price oracle = $1.01 * Market value of (ETH) based on price oracle = $1,800 Fair Value Liquidation = 56.111 ETH = 100,000 USDC \* 1.01 USD/USDC / (1,800 USD/ ETH) Liquidated Damages = 4.4889 ETH = 8% \* 56.111 ETH Liquidation Incentive = 2.9178 ETH = 5.2% \* 56.111 ETH Protocol Liquidated Damages = 1.571 ETH = 2.8% \* 56.111 ETH Total Collateral Liquidated = 60.6 ETH
# Risk Disclosures **Disclaimer:** Neither Term Foundation nor any of its affiliates or service providers assume any liability for losses arising from or relating to the risks described here. # Term Repo Risks #### Liquidations For a borrower: * The Protocol will not issue margin calls, will not credit your collateral balance to meet deficiencies, and your collateral will be liquidated in order to satisfy margin requirements without prior notice to you and without an opportunity for you to choose the collateral to be liquidated or the timing or order of liquidation. * If the equity associated with your wallet falls below the maintenance margin requirement or is not repaid within the repurchase window (default), liquidators can liquidate any of the collateral locked against your defaulting position. * Some users mistakenly believe that they must be contacted for a liquidation to be valid and that their collateral cannot be liquidated to cure a default unless they have been contacted first. This is not the case. As noted above, the Protocol will not issue margin calls and your collateral can be immediately liquidated without notice to you in the event that you default on a position. * You are not entitled to choose which collateral tokens are liquidated to cure default (to the extent more than one collateral token has been posted collateral against the same position). Liquidators decide which collateral tokens to liquidate. For a lender: * Although the Protocol enables instant liquidations and borrowers are required to overcollateralize their loans, on-chain liquidations are subject to slippage and available liquidity, which means that liquidating collateral may not result in sufficient proceeds to repay a lender. #### Forked Assets Digital assets lent out by a lender and digital assets posted as collateral by a borrower may from time to time result in forked assets as a result of a fork, airdrop or similar event. Users should be aware that forked assets arising from digital assets lent out or posted as collateral through Term Finance will not be retrievable. #### Oracle Risk Like many DeFi protocols, borrower equity is determined using price oracles on Term Finance. If any of these oracles are compromised, the Protocol may no longer function correctly, and attacking or manipulating an oracle can be used as a means to attack and manipulate key Protocol operations, and may lead to unwarranted liquidations. To mitigate these risks, the Protocol uses decentralized oracles ([Chainlink](https://chain.link/)) that aim to diversify the group of data providers to a point where unilateral manipulation becomes unfeasible for an attacker. Decentralization, however, does not guarantee against manipulation and Protocol users assume sole responsibility for such risks. # Smart Contract Risk Since smart contracts typically cannot be stopped or reversed, vulnerabilities in their programming can have damaging effects. For example, in June 2016, a vulnerability in the smart contracts underlying The DAO, a distributed autonomous organization for venture capital funding, allowed an attack by a hacker to syphon approximately $60 million worth of Ethereum from The DAO’s accounts into a segregated account. In the aftermath of the theft, certain developers and core contributors pursued a “hard fork” of the Ethereum network in order to erase any record of the theft. Despite these efforts, the price of Ethereum dropped approximately 35% in the aftermath of the attack and subsequent hard fork. In addition, in July 2017, a vulnerability in a smart contract for a multi-signature wallet software developed by Parity led to a $30 million theft of Ethereum, and in November 2017, a new vulnerability in Parity’s wallet software led to roughly $160 million worth of Ethereum being indefinitely frozen in an account. More recently, in February 2022, a vulnerability in a smart contract for Wormhole, a bridge between the Ethereum and Solana networks, led to a theft of $320 million worth of Ethereum. Flaws in the source code for digital assets have been exposed and exploited, including flaws that disabled some functionality for users, exposed users’ personal information and/or resulted in the theft of users’ digital assets. The cryptography underlying the Protocol could prove to be flawed or ineffective, or developments in mathematics and/or technology, including advances in digital computing, algebraic geometry and quantum computing, could result in such cryptography becoming ineffective. In any of these circumstances, a malicious actor may be able to take assets from the Protocol or attack the operability of the Protocol. Any such exploits or hacks could results in a total loss of digital assets for a Protocol user. # Digital Asset Risk #### The trading prices of many digital assets, including digital assets interoperable with the Term Finance Protocol, have experienced extreme volatility in recent periods and may continue to do so. Extreme volatility in the future, including further declines in the trading prices of digital assets pose a significant risk of loss from using the Protocol to engage in digital asset transactions. Beginning in the fourth quarter of 2021 and continuing throughout 2022, digital asset prices began falling precipitously. This has led to volatility and disruption in the digital asset markets and financial difficulties for several prominent industry participants, including digital asset exchanges, hedge funds and lending platforms. For example, in the first half of 2022, digital asset lenders Celsius Network LLC and Voyager Digital Ltd. and digital asset hedge fund Three Arrows Capital each declared bankruptcy. This resulted in a loss of confidence in participants in the digital asset ecosystem, negative publicity surrounding digital assets more broadly and market-wide declines in digital asset trading prices and liquidity. Thereafter, in November 2022, FTX, the third largest Digital Asset Exchange by volume at the time, halted customer withdrawals amid rumors of the company’s liquidity issues and likely insolvency. Shortly thereafter, FTX’s CEO resigned and FTX and several affiliates of FTX filed for bankruptcy. The U.S. Department of Justice subsequently brought criminal charges, including charges of fraud, violations of federal securities laws, money laundering, and campaign finance offenses, against FTX’s former CEO and others. FTX is also under investigation by the SEC, the Justice Department, and the Commodity Futures Trading Commission, as well as by various regulatory authorities in the Bahamas, Europe and other jurisdictions. In response to these events, the digital asset markets have experienced extreme price volatility and declines in liquidity, and regulatory and enforcement scrutiny has increased, including from the DOJ, the SEC, the CFTC, the White House and Congress. In addition, several other entities in the digital asset industry filed for bankruptcy following FTX’s bankruptcy filing, such as BlockFi Inc. and Genesis Global Capital, LLC, a subsidiary of Genesis Holdco, LLC (“Genesis Holdco”). The SEC also brought charges against Genesis Global Capital, LLC and Gemini Trust Company, LLC on January 12, 2023 for their alleged unregistered offer and sale of securities to retail investors. Continued disruption and instability in the digital asset markets as these events develop, including further declines in the trading prices and liquidity of digital assets pose a significant risk of loss from utilizing the Protocol to participate in transactions involving digital assets. # Ethereum Network Risk The Protocol is expected to be network agnostic in the long run but will be built on top of the Ethereum Network to start. The functionality of the Protocol is subject to a number of factors relating to the capabilities and development of the Ethereum Network, such as the nascency of its development, its dependence on the internet and other technologies, its dependence on the role played by users, developers and validators and the potential for malicious activity. For example, the realization of one or more of the following risks could materially adversely affect the Protocol: * IRREVERSIBLE TRANSACTIONS - The loss or destruction of a private key required to access a digital asset may be irreversible. If a private key is lost, destroyed or otherwise compromised and no backup of the private key is accessible, the owner would be unable to access the digital asset corresponding to that private key and the private key will not be capable of being restored by the Ethereum Network. You are solely responsible for the safekeeping of your private key. * NETWORK UPGRADES - The Ethereum Network is in the process of implementing software upgrades and other changes to its protocol. For example, in 2020, the Ethereum Network may begin the first of several stages of an upgrade called Serenity, or Ethereum 2.0. Ethereum 2.0. is a new iteration of Ethereum that would amend its consensus mechanism to include proof-of-stake and sharding. A digital asset network’s consensus mechanism is a material aspect of its source code, and any failure to properly implement such a change could have a material adverse effect on the functionality of the Protocol. * KEY CONTRIBUTOR RISK - The Ethereum Network is still in the process of developing and making significant decisions that will affect policies that govern the supply and issuance of ETH as well as other Ethereum Network protocols. For example, the Ethereum Network has on two separate occasions reduced the quantity of ETH rewarded per block and may make additional changes in the future, see “Overview of the ETH Industry and Market—Creation of New ETH” for additional information. The open-source nature of many digital asset network protocols, such as the protocol for the Ethereum Network, means that developers and other contributors are generally not directly compensated for their contributions in maintaining and developing such protocols. As a result, the developers and other contributors of a particular digital asset may lack a financial incentive to maintain or develop the network, or may lack the resources to adequately address emerging issues. Alternatively, some developers may be funded by companies whose interests are at odds with other participants in a particular digital asset network. As a result, there may be a lack of consensus or clarity on the governance of any particular decentralized digital asset network, which may stymie such network’s utility and ability to grow and face challenges. Historically the Ethereum Network’s development has been overseen by the Ethereum Foundation and other core developers. The core developers evolve over time, largely based on self-determined participation. To the extent that a significant majority of users and miners adopt amendments to the Ethereum Network, the Ethereum Network will be subject to new protocols that may adversely affect the performance of the network. If a significant majority of users and miners adopt amendments to a decentralized network based on the proposals of such core developers, such network will be subject to new protocols that may adversely affect the functionality of the Protocol. * SCALABILITY - Many digital asset networks face significant scaling challenges due to the fact that public blockchains generally face a tradeoff between security and scalability. One means through which public blockchains achieve security is decentralization, meaning that no intermediary is responsible for securing and maintaining these systems. For example, a greater degree of decentralization generally means a given digital asset network is less susceptible to manipulation or capture. In practice, this typically means that every single node on a given digital asset network is responsible for securing the system by processing every transaction and maintaining a copy of the entire state of the network. As a result, a digital asset network may be limited in the number of transactions it can process by the capabilities of each single fully participating node. As of June 30, 2020, the Ethereum Network could handle approximately 13 transactions per second. In an effort to increase the volume of transactions that can be processed on a given digital asset network, many digital assets are being upgraded with various features to increase the speed and throughput of digital asset transactions. As of December 31, 2022, the Ethereum Network handled approximately 10 transactions per second. In an effort to increase the volume of transactions that can be processed on a given digital asset network, many digital assets are being upgraded with various features to increase the speed and throughput of digital asset transactions. For example, in 2023, the Ethereum Network may begin the final stages of a series of upgrades initially referred to as Ethereum 2.0 that include sharding. As corresponding increases in throughput lag behind growth in the use of digital asset networks, average fees and settlement times may increase considerably. For example, the Ethereum Network has been, at times, at capacity, which has led to increased transaction fees. Since January 1, 2020, ETH transaction fees have increased from $0.08 per ETH transaction, on average, to a high of $200.27 per transaction, on average, on May 1, 2022. As of December 31, 2022, ETH transaction fees stood at $2.73 per transaction, on average. Increased fees and decreased settlement speeds could affect the scalability of the Protocol. There is no guarantee that any of the mechanisms in place or being explored for increasing the scale of settlement of Ethereum Network transactions will be effective, or how long these mechanisms will take to become effective, which could adversely impact the functionality of the Protocol. * 50% ATTACK - If a malicious actor or botnet (a volunteer or hacked collection of computers controlled by networked software coordinating the actions of the computers) obtains a majority of the validating power on the Ethereum Network, it may be able to alter the Ethereum Blockchain on which transactions in ETH rely by constructing fraudulent blocks or preventing certain transactions from completing in a timely manner, or at all. The malicious actor or botnet could also control, exclude or modify the ordering of transactions. Although the malicious actor or botnet would not be able to generate new tokens or transactions using such control, it could “double-spend” its own tokens (i.e., spend the same tokens in more than one transaction) and prevent the confirmation of other users’ transactions for so long as it maintained control. To the extent that such malicious actor or botnet did not yield its control of the validating power on the Ethereum Network or the ETH community did not reject the fraudulent blocks as malicious, reversing any changes made to the Ethereum Blockchain may not be possible. Further, a malicious actor or botnet could create a flood of transactions in order to slow down the Ethereum Network. Although there are no known reports of malicious activity on, or control of, the Ethereum Network, it is believed that certain groups of coordinating or connected ETH holders may together have more than 50% of outstanding ETH, which if staked and if the users run validators, would permit them to exert authority over the validation of ETH transactions. This risk is heightened if over 50% of the processing power on the network falls within the jurisdiction of a single governmental authority. If network participants, including the core developers and the administrators of validating pools, do not act to ensure greater decentralization of ETH, the feasibility of a malicious actor obtaining control of the validating power on the Ethereum Network will increase, which may adversely affect the security of the Protocol. * FORKING RISK - The Ethereum Network operates using open-source protocols, meaning that any user can download the software, modify it and then propose that the users and validators of ETH adopt the modification. When a modification is introduced and a substantial majority of users and validators’ consent to the modification, the change is implemented and the network remains uninterrupted. However, if less than a substantial majority of users and validators’ consent to the proposed modification, and the modification is not compatible with the software prior to its modification, the consequence would be what is known as a “hard fork” of the Ethereum Network, with one group running the pre-modified software and the other running the modified software. The effect of such a fork would be the existence of two versions of ETH running in parallel, yet lacking interchangeability. For example, in September 2022, the Ethereum Network transitioned to a proof-of-stake model, in an upgrade referred to as the “Merge.” Following the Merge, a hard fork of the Ethereum Network occurred, as certain Ethereum miners and network participants planned to maintain the proof-of-work consensus mechanism that was removed as part of the Merge. This version of the network was rebranded as “Ethereum Proof-of-Work”. A fork may also occur as a result of an unintentional or unanticipated software flaw in the various versions of otherwise compatible software that users run. Such a fork could lead to users and validators abandoning the digital asset with the flawed software. It is possible, however, that a substantial number of users and validators could adopt an incompatible version of the digital asset while resisting community-led efforts to merge the two chains. This could result in a permanent fork. A future fork could create complications that adversely affect the operation of the Protocol. In the event of a fork, the Protocol will use its discretion to determine which network should be the appropriate network for the Protocol's purposes and may not have the ability to ensure that forked collateral assets will be accessible. * SMART CONTRACT RISK - Moreover, in the past, flaws in the source code for digital assets have been exposed and exploited, including flaws that disabled some functionality for users, exposed users’ personal information and/or resulted in the theft of users’ digital assets. The cryptography underlying ETH could prove to be flawed or ineffective, or developments in mathematics and/or technology, including advances in digital computing, algebraic geometry and quantum computing, could result in such cryptography becoming ineffective. In any of these circumstances, a malicious actor may be able to exploit or hack the Protocol. Moreover, functionality of the Ethereum Network may be negatively affected such that it is no longer attractive to users, thereby dampening demand to support the Ethereum Network. Even if another digital asset other than ETH were affected by similar circumstances, any reduction in confidence in the source code or cryptography underlying digital assets generally could negatively affect the demand for digital assets and therefore adversely affect usability of the Protocol. * ILLICIT ACTIVITIES - The Protocol uses third-party services to screen prospective users of the protocol against various watch lists, including the Specially Designated Nationals List of the Treasury Department Office of Foreign Assets Control (“OFAC”) and countries and territories identified as non-cooperative by the Financial Action Task Force. If a user were nevertheless to transact with such a sanctioned entity user would be at increased risk of potential criminal or civil lawsuits. # FAQ ## How is the interest rate determined? At a high level, the algorithm implemented by our smart contracts determine a [clearing rate](/protocol/term-auctions/complete-auction/clearing-rate) by iterating through sorted bids and offers received in auction to find the rate where supply meets demand and the total volume of loans matched between lenders and borrowers is maximized. You can review the logic behind this algorithm in the internal function [\_calculateClearingPrice](broken://spaces/g2unsUVhFxcxuJwNIofz/pages/GqsRFmLHt7cj5pz3HhR0#_calculateclearingprice) in the [TermAuction.sol](broken://spaces/g2unsUVhFxcxuJwNIofz/pages/GqsRFmLHt7cj5pz3HhR0) contract. ## What determines whether my tender(s) are accepted? The interest rate submitted in auction determines whether your tender filled in auction. **Offers** **at or below** the market clearing rate and **bids** **at or above** the market clearing rate are eligible for assignment. All other bids and offers outside of this range are said to be "left on the table", and associated tokens are returned to the owners’ wallets. Assignments prioritize the cheapest suppliers on the lending side (i.e., those with the lowest interest rates) and the borrowers most willing to pay (I.e., those with the highest interest rates). For more precise details view our documentation on the [assignment process](/protocol/term-auctions/complete-auction/assignment). ## What happens to my tokens when I submit tenders? To ensure that auctions clear and settle as expected and to prevent "spoofing", auction participants are required to lock their collateral into non-custodial smart contracts at the time of bid/offer submission. Lenders lock the amount they have tendered to lend out and borrowers lock the collateral tokens backing the they are seeking to borrow. Participants may cancel or edit their tenders at any time to have their tokens returned or adjusted. ## What happens if more than one of my tenders are accepted? To the extent that you submit multiple bids (or offers) into a single auction and more than one of them are accepted, all accepted bids (or offers) are aggregated into a **single position** at the market [clearing rate](/protocol/term-auctions/complete-auction/clearing-rate). Tokens locked belonging to bids (or offers) not accepted in auction are automatically returned to your wallet. ## What fees will I pay and where will they go? Generally speaking, lenders are not subject to any protocol fees. Borrowers are subject to two fees: (i) a [servicing fee](/protocol/fees-and-penalties/servicing-fee) that is quoted on an annualized basis and is applied to the amount borrowed and (ii) [liquidated damages](/protocol/fees-and-penalties/liquidated-damages) to the extent their position is liquidated due to a decline in collateral value below the [maintenance margin requirements](/protocol/term-repos/terminology#maintenance-margin-ratio) or failure to repay upon maturity within the repayment window. ## If I borrow, what will happen to my position if the underlying collateral changes in price? Borrowers are required to ensure that the market value of collateral posted against a loan meets or exceeds the required [maintenance margin ratio](/protocol/term-repos/terminology#maintenance-margin-ratio). If your collateral value falls below the requirement, your collateral will be subject to [liquidation](/protocol/term-repos/defaults/liquidation). Our smart contracts are designed to mitigate losses from liquidation by limiting the amount of debt that can be covered by a liquidator to the minimum amount necessary to return your collateralization ratio back to the [initial margin ratio ](/protocol/term-repos/terminology#initial-margin-ratio)plus some minor buffer. To the extent the value of your collateral increases, you will be able to withdraw any excess collateral over and above the maintenance margin ratio. ## Can I exit my loan early? No, with some caveats. Term Repo loans are non-callable loans. Borrowers commit to borrowing and lenders commit to lending through the full term to maturity. This prevents "bank-run" dynamics where lenders try to pull before borrowers are ready to repay and leads to a more stable and sustainable market. Lenders are, however, free to find buyers of their Term Repo Tokens if they need liquidity prior to the maturity date. Borrowers, similarly, can negotiate with Term Repo Token holders (lenders) to buy back their loan. To the extent borrowers are able to "buy back" Term Repo Tokens they are able to burn them against their debt to [collapse their position ](/protocol/term-repos/collapse-position)prior to the maturity date. ## What are the risks of extending/rolling over a loan? Rollovers allow borrowers to leverage collateral posted against an existing loan against a new Term Repo without having to repay, withdraw, and redeposit. Rollovers, however, are not guaranteed to fill: * Rollover bids will be rejected if the rollover bid rate specified by the borrower is less than the clearing rate of the rollover auction. * If the rate tendered meets the market clearing rate in the rollover auction, it is possible that the bid will only receive a **partial fill**. In this case, only a portion of the amount elected to be extended will be filled and the remainder needs to be repaid prior to the expiration of the repurchase window. * Users are also responsible for ensuring that the collateral being rolled over is sufficient to cover the maintenance margin ratio required by the terms of the new Term Repo loan being rolled into. If collateral rolled is insufficient to cover the maintenance requirement, the rollover may fail. * Lastly, in some rare cases, it is possible that the rollover auction will not complete in a timely fashion such that the new auction fails to clear before the repurchase window of the old Term Repo loan expires. ## What happens if I don't repay my loan on time? Loans must be repaid upon maturity within the [repurchase window](/protocol/term-repos/terminology#repurchase-window), which is typically a twenty-four hour window from the maturity date. Failure to do so within the repurchase window means that your collateral will be eligible for liquidation and subject to applicable [liquidated damages](/protocol/fees-and-penalties/liquidated-damages). Be sure to monitor your positions carefully for upcoming maturities and repay/rollover your position as necessary to avoid liquidation. ## Who are the members of the Term Labs team? Term Labs is developed by a team with deep TradFi, Big Tech and DeFi experience: **-** [**Dion Chu**](https://www.linkedin.com/in/dion-chu-3385b519/), CEO\ **-** [**Robert Chu**](https://www.linkedin.com/in/robert-chu-7146bb2a/), CTO\ **-** [**Billy Welch**](https://www.linkedin.com/in/billy-welch-4632843b/), BD & Marketing\ **-** [**Dai Yu**](https://www.linkedin.com/in/daiyu/), CFO \ **-** [**Andrew Zhou**](https://www.linkedin.com/in/andrew-zhou-1bab8b51/), Lead Smart Contract Engineer
# Overview Terminal 1 is the execution layer for managing fixed-term positions. Terminal 1 is the execution layer for managing fixed-term positions across Term and connected venues (e.g., Aave, Morpho, and DEX aggregators). It bundles dependent steps into a single atomic route where possible: a route either completes in full or reverts. Terminal 1 reduces approval friction through Permit-based signing flows and bounded spending caps where supported. Terminal 1 does not replace the Term protocol. The existing protocol documentation ([Term Repos](/protocol/term-repos), [Rollovers](/protocol/term-repos/rollovers), [Fees and Penalties](/protocol/fees-and-penalties), [Risk Disclosures](/protocol/risk-disclosures)) remains the reference for core mechanics.
### What Terminal 1 does * Builds execution routes for fixed-term position management. * Bundles dependent steps into one transaction where possible. * Adds Permit-based UX to reduce repeated token approvals. ### What Terminal 1 does not change * Auction mechanics. * Margin and liquidation rules. * Base protocol fees and penalties. ### Core workflows * **Intents (limit orders):** express a desired borrow or lend (amount, term, rate and size constraints). When matched, Terminal 1 can execute settlement and any dependent steps as a single route where supported. Intents define what you want; routes define how execution is composed. * **Refinance** moves an active borrow to an external platform or protocol. * **Close / Loop-out** repays debt and exits linked exposure. * **Rollover** extends an active borrow into any future term. * **Looping** increases or restructures exposure through repeated borrow and swap steps. ### Before you execute Review route inputs/outputs, fees, and buffers. Confirm approval scope and token spend limits. See Risks & Failure Modes for common failure cases. # Concepts Core execution concepts used by Terminal 1. Terminal 1 uses a small set of execution concepts across every workflow. These concepts explain how routes are composed and constrained at execution time: how dependent steps are bundled atomically, how tokens are authorized through approvals or Permit-based spending caps, and how fees, slippage, and buffers affect the amounts a route can safely execute. Use this section to understand why a route succeeds or reverts, and what levers you can review before signing.
* [Routes & atomic execution](/terminal-1-execution/concepts/routes-and-atomic-execution) * [Permits, approvals & spending caps](/terminal-1-execution/concepts/permits-approvals-and-spending-caps) * [Fees, slippage & buffers](/terminal-1-execution/concepts/fees-slippage-and-buffers)
# Routes & atomic execution How Terminal 1 bundles dependent actions into a single execution path. A route is an ordered bundle of dependent actions executed as a single transaction where possible (e.g., swap → repay → settle). Routes are atomic: either every step completes and the route succeeds, or the transaction reverts and no state changes are applied. Terminal 1 builds routes by selecting compatible venues and amounts, then constrains execution with explicit minimums/maximums so the route fails safely if prices, balances, allowances, or market liquidity change. ### Execution environments Terminal 1 can express a route in two ways: * **Atomic execution (single transaction):** the full route executes in one transaction and either completes in full or reverts. This is the primary execution path for EOAs and for workflows that require flash loans. * **Safe mode (native Safe batch):** for Safe wallets, many routes can be expressed as a native Safe batched transaction generated via the Safe API. This makes each step visible in the Safe interface prior to execution. Routes that require flash loans cannot be expressed as a native Safe batch. ### When routes revert * A required approval/permit is missing or too small. * Output is below the minimum after fees/slippage (“output insufficient”). * A venue quote is stale or liquidity moved before inclusion. * A route constraint fails (price impact, buffer, deadline, etc.). ### What to review before signing * Input/output tokens and amounts. * Venue sequence (which protocols/aggregators are used). * Min/Max constraints (slippage + buffers). * Approval scope (token + spending cap). ### What atomic execution does not guarantee * Guarantees: atomicity (all-or-nothing) and bounded authorization where supported. * Doesn’t guarantee: a specific price or fill if market conditions change; the route will revert instead.
# Permits, approvals & spending caps How Terminal 1 handles token authorization. Terminal 1 must be authorized to move tokens on your behalf in order to execute a route. Depending on the token and workflow, this authorization is provided either through an onchain approval (ERC‑20 approve) or a Permit-based signature flow (e.g., EIP‑2612 / Permit2) that can be bundled into the route. Where supported, Terminal 1 uses bounded spending caps so the authorization is limited to the token(s) and maximum amount(s) required for the route, rather than granting an unbounded allowance. ### Approvals vs permits * **Approval:** an onchain transaction that sets an allowance for a spender contract. * **Permit:** an offchain signature authorizing spend under specific parameters, typically executed onchain as part of the route. ### Spending caps (scope) Authorizations are scoped by **token**, **spender**, and **maximum amount**. If the cap is too low (because prices, fees, or buffers changed), execution will revert rather than over-spend. ### EOA vs Safe * **EOA (atomic execution):** permits and execution can often be bundled so the workflow completes with fewer distinct transactions. * **Safe mode (native Safe batch):** approvals and permits can be included as explicit batch steps, making authorization and execution steps visible in the Safe interface prior to signing. This does not change what is authorized, only how the steps are presented and executed. ### What to check before signing Users should review: * the token being authorized * the maximum spend amount * the spender being authorized # Fees, slippage & buffers Economic and market constraints that shape route construction and execution. Execution outcomes depend on both protocol economics and market conditions. Terminal 1 routes therefore distinguish between (i) fees that are deterministic once the route is defined, (ii) price movement and liquidity conditions that introduce slippage, and (iii) conservative buffers that make routes fail safely when conditions change. ### Fees (what gets paid) A route can include multiple fee sources, depending on the workflow and venues used: * **Term protocol fees** (see [Fees and Penalties](/protocol/fees-and-penalties)). * **Venue fees** (e.g., borrow/repay costs on external lending venues). * **Swap / aggregator costs** (DEX fees and any aggregator-specific costs). * **Flash loan premium** (only for routes that use flash liquidity). * **Network gas** (paid separately to execute the transaction(s)). Terminal 1 surfaces fees where it can, but the canonical source of truth is always the onchain execution and the underlying venue’s rules. ### Slippage (what can change) Slippage is the difference between an expected quote and the realized execution due to: * price movement between quote and inclusion, * limited liquidity / price impact, * partial liquidity availability at execution time, * path changes (if the route selects between eligible venues). Slippage risk is highest in routes that rely on large swaps or swaps of illiquid tokens, and for Safe workflows where signing latency can be longer. ### Buffers (UI-layer safety margins) Buffers are applied in the UI when constructing a route. They intentionally over‑provision certain amounts (or include small safety margins) to reduce avoidable reverts when fees or market conditions move slightly between preview and execution. Buffers do not change protocol rules or smart contract validation; they only affect the parameters the UI submits. ### Practical guidance * Use conservative slippage in deep markets. * Use wider buffers for long or liquidity-sensitive routes. * Recheck the net outcome before signing. # Workflows Position management workflows supported by Terminal 1. Terminal 1 workflows describe common position and intent operations—each expressed as a route (atomic execution) or, for Safe wallets where supported, as a native Safe batch. This section explains what each workflow does, when to use it, the required inputs, and the most common failure modes. Use this section for workflow-level guidance. * [Intents (Limit Orders)](/terminal-1-execution/workflows/intents-limit-orders) * [Refinance](/terminal-1-execution/workflows/refinance) * [Close / Loop-out](/terminal-1-execution/workflows/repay-loop-out) * [Rollover](/terminal-1-execution/workflows/one-click-rollover) * [Looping](/terminal-1-execution/workflows/looping) # Intents (Limit Orders) Limit orders scoped to a Term Repo market, with flexible funding sources and route-based settlement. Intents are limit orders that express what you want to do—borrow or lend—under explicit constraints. An intent is scoped to a specific **market (**[**Term Repo**](/protocol/term-repos)**)** and typically specifies the direction (borrow or lend), amount, and rate. If the market you want does not exist, you can deploy a new market via a factory deploy (see [**Deploy a new market**](/terminal-1-execution/workflows/deploy-a-new-market-factory)). Intents are not guaranteed to execute: they must remain valid and fillable, with the necessary funds, approvals, and authorizations in place, and they execute only when a taker matches them within their specified constraints. Intents may be partially filled, so execution can occur for less than the full stated amount. When an intent is matched, Terminal 1 can execute settlement and any dependent steps as a single route where supported. For details, see: * [Makers](/terminal-1-execution/workflows/intents-limit-orders/makers-creating-intents) * [Takers](/terminal-1-execution/workflows/intents-limit-orders/takers-filling-intents)
# Makers (creating intents) Create and manage intents by selecting a market, setting constraints, and ensuring funding and authorizations remain valid. ### When to use intents * You want to post a specific rate for a specific term, rather than taking the current best available fill immediately. * You want execution to occur only if constraints can be satisfied (market, rate, size, and validity conditions). ### What an intent is scoped to (Term Repo) Every intent targets a specific [**Term Repo**](/protocol/term-repos) **(market)**. The market defines the core parameters the intent must operate within, including: * **Maturity date** * **Loan token (purchase token)** * **Collateral token(s)** * **Collateral ratio / risk parameters** An intent cannot change these market parameters. If you want a different maturity or token pair, you must choose (or deploy) a different market. If the market you want does not exist, you can deploy a new one via a factory deploy (see [**Deploy a new market**](/terminal-1-execution/workflows/deploy-a-new-market-factory)). ### What an intent constrains * **Direction:** borrow or lend. * **Rate:** the minimum (for lending) or maximum (for borrowing) rate you are willing to accept. * **Size:** the amount you want to borrow or lend (and any minimum fill constraints, where applicable). * **Expiry:** how long the intent remains valid before it can no longer be matched. * **Optional taker:** if set, only the specified taker may fill the intent; otherwise anyone may fill it. * **Partial fills:** an intent may fill for less than the full size (until fully filled, expired, or cancelled) ### Intent types (onchain vs offchain) Terminal 1 supports two ways to express intents: * **Onchain intents:** created and stored onchain. * **Offchain intents (signature-based):** expressed as signed messages and submitted offchain. Both represent the same economic intent. The difference is how the intent is authorized and how it is surfaced for matching and execution. **If you are using a Safe, use onchain intents by default.** ### Maker Funding sources (wallet + deployed capital) When you create an intent, you choose where the funds will come from at execution time. This allows you to place an order using deployed capital rather than keeping idle tokens in your wallet. Supported funding source types include: * **Wallet (standard):** fund the intent from your wallet token balance. * **ERC‑4626 vaults:** fund the intent by withdrawing available assets from an ERC‑4626 vault. * **Aave:** fund the intent using Aave liquidity in either of two ways: * **Withdraw from Aave:** use assets you have already supplied to Aave. * **Borrow from Aave:** borrow against your available borrowing capacity on Aave. * **Morpho:** fund the intent using Morpho liquidity in either of two ways: * **Withdraw from Morpho:** use assets you have already supplied to the relevant Morpho market. * **Borrow from Morpho:** borrow against your available borrowing capacity in that Morpho market. The UI uses the selected funding source to estimate what is available and to construct the correct execution parameters for settlement. ### Preview vs execution * **When creating an intent:** the UI helps verify that the selected market, funding source, approvals, and authorizations are consistent with the intent. Creating an intent does not mean it will execute immediately. * **When a taker fills:** Terminal 1 checks validity at execution time. If the checks pass, Terminal 1 settles the matched amount and executes any dependent route steps where supported. ### Common reasons intents don't execute * No taker chooses to fill the intent at the specified market/rate/size. * The intent expires before a fill occurs * Funding source availability changed (wallet balance, Aave/Morpho capacity). * Approvals/authorizations were reduced or revoked ### Before you submit * Confirm the market (maturity, tokens, collateral parameters). * Confirm constraints (direction, rate, size, expiry, optional taker). * Confirm the funding source and that it can provide the intended size. * Confirm approvals/authorizations for the funding source. # Takers (filling intents) Evaluate and fill existing intents, with execution‑time validity checks and common failure modes. As a taker, you fill an existing intent by matching it within its constraints. If the required tokens are available and the necessary approvals, permits, and authorizations remain valid at execution time, the fill is guaranteed to execute according to those constraints. However, intents displayed in the UI may become stale as on-chain state changes. Terminal 1 revalidates each intent at execution and fails safely if its constraints can no longer be satisfied. ### When to fill an intent * You want to take the displayed rate in a specific market (Term Repo) and maturity. * You want a defined outcome (fixed term) without negotiating bilateral terms off-platform. * You want to fill immediately (or opportunistically) when liquidity is present. ### What you are filling (market scope) Every intent is scoped to a specific **Term Repo (market)**. The market defines: * Maturity date * Loan token (purchase token) * Collateral token(s) * Collateral ratio / risk parameters ### What the intent constrains * **Direction:** borrow or lend * **Rate:** minimum (for lender-side intents) or maximum (for borrower-side intents) * **Size:** requested size and any minimum fill constraints (if applicable) * **Expiry:** the intent must be unexpired * **Optional taker:** if set, only the specified taker can fill * **Partial fills:** you may fill less than the full remaining size if the intent and route allow it ### Preview vs execution * **Preview/UI display:** best-effort view of intents and estimated fillability under current conditions. * **Execution-time checks:** the onchain transaction is the source of truth. At execution time, Terminal 1 verifies the intent can be filled under its constraints and that the required funding/authorizations for settlement are available. A key implication: **intent validity is dynamic**. Funds can move, approvals can be changed or revoked, and what you see in the UI may be stale. ### Common reasons fills fail * The intent expired. * Optional taker restriction blocks your fill. * The remaining fillable size changed (already partially filled or cancelled). * Maker-side validity changed: * underlying funding source availability moved (wallet balance, ERC‑4626 withdrawable, Aave/Morpho capacity) * approvals/authorizations changed or were revoked * Route constraints fail at execution time (fees, slippage exposure, UI buffers, venue compatibility). * Venue-level revert (market paused, capacity unavailable, external venue conditions changed). ### What to review before executing * The market (maturity, tokens, collateral parameters) and the intent constraints (direction, rate, size, expiry, optional taker). * Whether the intent is likely to be fillable *now* (recent activity, remaining size, current liquidity). * The execution path and dependent steps (route sequence, venues used where visible). * Fees/slippage exposure if the fill relies on swaps or external venues. * Any warnings about validity or staleness surfaced by the UI. ### Notes Offchain signed intents are distributed through our current order store for discovery; fills are still enforced by onchain constraints. If an intent is fillable under its constraints, any eligible taker can attempt to fill it by submitting a transaction. # Refinance Replace an existing obligation by repaying the current leg and opening a new position through a single routed execution flow. Refinance lets a user close an existing obligation and reopen the position through a new venue or market. * **Refinance out:** move a Term obligation to another venue. * **Refinance in:** move an obligation from another venue into a Term market. Where supported, refinance executes as a single route that closes the current leg and opens the replacement leg without requiring the user to manually sequence intermediate steps. Terminal 1 currently supports refinance routes involving **Aave** and **Morpho**. Additional venues may be added over time.
### Refinance directions * **Refinance out (Term → Aave/Morpho):** repay a Term obligation and reopen the position on an external venue. * **Refinance in (Aave/Morpho → Term):** close an external obligation and reopen the position in a Term market. ### Typical use cases * Move to a more favorable fixed-term outcome or market. * Change venue or collateral composition. * Adjust position size or risk profile without manual unwinds. * Consolidate multiple steps (repay, swap, borrow, settle) into a single execution flow. ### What the route does (high level) A refinance route generally: * determines the current obligation to be closed, * sources required repayment assets (wallet, deployed capital, or swaps, depending on workflow), * repays the current leg, * opens the replacement leg under the new venue/market parameters, * enforces route constraints so execution fails safely if conditions change. ### Authorizations (EOA vs Safe) Refinance routes require token authorization to move assets during execution. EOAs may use permits where supported. Safe wallets typically provide approvals as explicit batched steps rather than offchain permit signatures. This changes how authorization is delivered, not what the route executes. ### What to review before signing * **Target venue/market:** for Term, confirm the market (maturity, loan token, collateral parameters). * **Position being refinanced:** confirm the obligation being moved and the destination venue or market. * **Loan and collateral pair:** refinance routes use the same loan token and collateral asset; confirm the pair matches the position you intend to move. * **Flash loan terms:** refinance routes use flash liquidity to repay the current obligation and establish the replacement obligation in one execution flow. Review any flash loan fees or route buffers. * **Execution environment:** atomic execution vs Safe batch (where supported). * **Authorization:** approvals/permits/spending caps required by the route. ### Common failure cases * Required approvals/permits are missing or insufficient. * Flash liquidity is unavailable or route buffers cannot be satisfied. * Route constraints fail (fees, buffers, deadlines, or venue constraints). * External venue conditions change (liquidity moved, borrowing capacity changed, quote expired). # Repay / Loop-out Repay debt and exit linked exposure through a single route. Repay / Loop-out is the Terminal 1 workflow for exiting an existing position by repaying debt and unwinding linked exposure using a **flash-loan-backed route**. Terminal 1 composes the required steps into a single atomic execution flow so users do not need to manually sequence repays, swaps, collateral movements, and venue interactions.
### When to use it * You want to exit a fixed-term position cleanly without manually unwinding intermediate steps. * You want to unwind looping exposure (repay + deleverage) in one execution flow. * You want to close without pre-funding all intermediate tokens in your wallet. ### What the route does (high level) A repay / loop-out route generally: * takes flash liquidity to source repayment funds, * repays the debt and releases the position’s collateral, * performs any required swaps to repay the flash loan, * unwinds linked exposure created by prior looping paths (where applicable), * returns remaining assets to the user per route outputs and constraints. ### Route selection (solver) Terminal 1 uses a solver to construct an optimal repay / loop-out route given your position and available venues. The solver searches supported routes (including swaps and ERC‑4626 withdrawals where applicable) to maximize net token returns and minimize unnecessary slippage, subject to route constraints and execution safety checks. ### What to review before signing * source repayment funds * repay debt * unlock or return collateral * swap or transfer released assets as needed ### Common failure cases * Required approvals/permits are missing or insufficient. * Swap execution is stale or worse than expected and the flash repayment cannot be satisfied. * Route constraints fail (fees, buffers, deadlines, or venue constraints). * External venue conditions change during execution (liquidity moved, quote expired). ### Notes Close / Loop-out is an execution workflow. It does not change core protocol mechanics, fees, or penalties; it changes how actions are composed into a single atomic route. # One-click rollover Extend a compatible position into a new term through Terminal 1. One-click rollover lets a user extend an existing Term loan by moving it from its current maturity into a compatible Term market with a later maturity. Unlike the original [**rollover auction**](/protocol/term-repos/rollovers) process, one-click rollover presents this as a single routed action in Terminal 1.
### How this differs from auction rollovers * **Protocol rollovers (auction):** depend on lender participation and auction clearing conditions. The rollover is not instant, and the fill may be partial or may not occur. * **Terminal 1 rollover (one‑click):** uses a route-based, flash-loan-backed execution flow. The rollover either completes in full or reverts. ### When to use rollover * You want to maintain exposure beyond the current maturity without fully exiting and re-entering manually. * You want to move to a later maturity while keeping the same market structure (loan/collateral parameters). * You want execution to be atomic (either the rollover completes or nothing changes). ### What the route does (high level) A one‑click rollover route generally: * takes flash liquidity to source repayment funds, * repays the current Term debt and unlocks collateral, * uses the unlocked collateral to open a new Term position in a compatible market (different maturity), * uses the new proceeds to repay the flash loan, * returns any remaining assets per route outputs and constraints. ### Eligibility (compatibility) One‑click rollover requires a compatible market with a later maturity. Compatibility is determined by market parameters (loan token, collateral token(s), and collateral/risk constraints) and the availability of liquidity in the target maturity. ### What to review before signing * Current position and the target market (especially the new maturity). * Expected borrow amount and resulting collateralization in the new position. * Fees and any UI buffers applied to reduce avoidable reverts. * Authorization scope (approvals/permits/spending caps required by the route). ### Common failure causes * No eligible target market (or insufficient liquidity in the target maturity). * Proceeds from the new position are insufficient to repay the flash loan after fees/buffers. * Required approvals/permits are missing or insufficient. * Market conditions changed between preview and execution. ### Notes One‑click rollover is an execution workflow. It does not change the protocol’s underlying repo mechanics; it changes how the close-and-reopen sequence is composed into a single route. For the auction-based mechanism, refer to the protocol [**Rollovers**](/protocol/term-repos/rollovers) documentation. # Looping Increase or restructure exposure by repeating borrow and asset conversion steps. Looping creates leveraged exposure by using borrowed assets to increase a position, similar to buying on margin or putting on a carry trade. In DeFi, this is commonly done by borrowing against collateral, converting the borrowed asset into more collateral, and redepositing it to support additional borrowing. Terminal 1 packages that workflow into a single routed execution flow, so users can achieve the same economic result without manually executing each step. Terminal 1 uses a solver to construct an optimal looping route given your inputs, available venues, and constraints. The solver searches supported transforms (including swaps and vault withdrawals where applicable) to maximize net token outcomes and minimize unnecessary slippage, subject to safety checks.
### Common looping strategies * **Leveraged exposure:** increase exposure to an asset while posting collateral in a different (uncorrelated) asset. * **Carry trades (correlated assets):** construct exposure designed to capture a spread between correlated assets (e.g., borrowing vs lending/yield differentials), subject to funding, liquidation, and basis risks. ### When to use looping * You want to increase exposure between uncorrelated assets without manually repeating borrow/swap steps. * You want to construct a carry trade between correlated assets (capture a spread) with a single execution flow. ### What the route does (high level) A looping route generally: * takes flash liquidity to fund intermediate steps, * borrows against collateral under the market’s parameters, * swaps proceeds as required by the loop structure, * establishes the final target exposure, * repays the flash loan within the same execution flow, * enforces route constraints so execution either completes fully or reverts. ### What to review before signing * The selected market and resulting collateralization / leverage implications. * The route path (venues and swaps included). * Flash loan leg (source asset and implied premium). * Fees, slippage exposure, and any UI buffers applied. * Authorization scope (approvals/permits/spending caps required by the route). ### Common failure cases * Insufficient available liquidity or borrowing capacity to complete the loop. * Swap execution worse than expected and flash repayment cannot be satisfied. * Required approvals/permits are missing or insufficient. ### Notes Looping is an execution workflow. It does not change underlying protocol risk parameters. Users remain responsible for monitoring collateralization and liquidation risk under the rules of the venue(s) used. # Deploy a new market (Factory) Factory deploy lets you create a new Term Repo when you need custom loan parameters that are not available in an existing market. Each Term Repo is defined by fixed parameters, including maturity, loan token, collateral token, LTV, and collateral/risk configuration. If no existing Term Repo matches the terms you need, you can deploy a new one. Factory deploy is constrained to assets supported by the protocol’s oracle configuration. The loan token and collateral token(s) must be onboarded into the oracle set; unsupported assets cannot be used to create a new market.
*Where to find factory deploy. In the Create Order flow, if you don’t see a market that matches your needs, use the “Deploy your own Term” link in the term picker.* ### When to use factory deploy * A required market (maturity or token pair) does not exist. * You need a distinct collateral/risk configuration for an existing token pair. ### Inputs * Chain * Maturity date * Loan token (purchase token) * Collateral token(s) * Collateral ratio / collateral-risk parameters * Any required deployment configuration surfaced by the UI ### What the route does (high level) A factory deploy route generally: * validates that the selected tokens are supported by the oracle, * deploys the Term Repo (market) contract set via the factory, * pairs/initializes the market so it is usable by the protocol and indexers, * returns the new market address (repo servicer) and associated contract addresses. ### Common failure cases * Token set is not oracle-onboarded. * Incompatible market parameters. * Required authorization for deployment is missing. * Market initialization/pairing fails due to protocol configuration or chain conditions. ### What to review before signing * Market definition (maturity, loan token, collateral token(s), collateral parameters). * Oracle support for the selected assets. * The resulting market address and where it will appear in the UI. # Risks & Failure Modes Common execution failures and user-facing risk disclosures. Terminal 1 workflows are executed through routed transactions that are designed to fail safely when conditions change. This section explains the most common reasons a workflow may revert (authorization issues, venue constraints, liquidity/price movement, and route parameter bounds), and what you can do to diagnose and resolve them. It also lists execution-layer disclosures—what Terminal 1 guarantees (all‑or‑nothing execution where applicable) and what it does not (a guaranteed fill, a guaranteed price, or availability of any external venue).
* [Common errors](/terminal-1-execution/risks-and-failure-modes/common-errors) * [Disclosures](/terminal-1-execution/risks-and-failure-modes/disclosures)
# Common errors Common execution failures users may encounter in Terminal 1. Most Terminal 1 failures fall into a small number of categories. In general, if a route cannot execute safely under current conditions, it will revert rather than partially complete. * **Missing or insufficient authorization:** required approvals/permits are missing, expired, or below the needed amount (including Safe batch approval steps that were not executed). * **Insufficient balance or available funds:** the selected funding source (wallet, ERC‑4626 vault, Aave, Morpho) cannot provide the required amount at execution time. * **Quote or liquidity changed:** swap quotes became stale or liquidity moved between preview and execution, causing the route to fall outside its bounds. * **Fees or buffers not covered:** fees or UI safety buffers increase required amounts and the route no longer satisfies downstream obligations. * **Venue-level revert:** an external venue rejects the action (capacity, collateral constraints, paused markets, market parameters changed). * **Market incompatibility:** the selected market/term/asset combination is not eligible for the workflow (e.g., rollover target market not compatible or not available). * **Execution timing issues:** deadlines expire, block conditions change, or Safe signing latency causes the route to become stale. When troubleshooting, start by confirming the position/market selection, then verify authorization scope, then re-run preview with current market conditions. ### Protocol-linked failures Some failures come from underlying product rules. Examples include maturity timing, collateral requirements, or incompatibility with the destination position. See [Rollovers](/protocol/term-repos/rollovers), [Maturity](/protocol/term-repos/maturity), and [Margin maintenance](/protocol/term-repos/margin-maintenance). {% hint style="warning" %} A failed route does not mean the quoted workflow is permanently unavailable. It often means execution conditions changed before confirmation. {% endhint %} # Disclosures Execution-specific disclosures for Terminal 1. Terminal 1 is an execution layer. It composes actions across Term and connected venues, but it does not change the underlying protocol rules, economic parameters, or risk characteristics of the venues used. * **No guarantee of execution or fill.** Routes may revert if required constraints cannot be satisfied at execution time. Intents may not match if liquidity is not available under your constraints. * **No guarantee of price.** Any workflow that depends on market liquidity (including swaps) is subject to price impact and changing quotes. Terminal 1 uses constraints and UI buffers to reduce avoidable failures, but does not guarantee a specific execution price. * **External venues can fail or be unavailable.** Routes may depend on third-party protocols, aggregators, and RPC infrastructure. Outages, paused markets, capacity limits, or integration changes can cause routes to fail. * **Authorization is scoped but still meaningful.** Terminal 1 requires token authorization (approvals, permits, or Safe batch steps). You should review which tokens are authorized, the maximum spend, and the spender contract before signing. * **UI previews are estimates.** Previews reflect current observable state and may differ from execution due to state changes, latency, or market movement. The onchain transaction result is the source of truth. * **Risk is not removed.** Collateralization, liquidation risk, and venue-specific rules still apply. Terminal 1 reduces operational sequencing risk, but does not eliminate market or protocol risk.
### Protocol disclosures still apply Users remain subject to the underlying product risks and legal terms. Review: * [Risk Disclosures](/protocol/risk-disclosures) * [Term Repo Risks](/protocol/risk-disclosures/term-repo-risks) * [Smart Contract Risk](/protocol/risk-disclosures/smart-contract-risk) * [Terms of Use](/legal/terms-of-use) {% hint style="info" %} Users are responsible for reviewing route parameters before signing. {% endhint %} # Integrations How Terminal 1 uses external venues and routing sources. Terminal 1 integrates with external venues and standards to compose multi-step execution workflows. Integrations fall into three categories: **lending venues** (e.g., Aave and Morpho), **DEX aggregators** (used for swaps where applicable), and **vault standards** (notably ERC‑4626 vaults). These integrations expand where routes can source funds, where obligations can be refinanced, and how intermediate steps are executed. Availability is workflow and chain dependent: a given integration may be supported only for certain assets, markets, or execution paths.
* [Aave](/terminal-1-execution/integrations/aave) * [Morpho](/terminal-1-execution/integrations/morpho) * [ERC4626](/terminal-1-execution/integrations/erc4626) * [Aggregators](/terminal-1-execution/integrations/aggregators) # Aave How Terminal 1 can interact with Aave in supported routes. Terminal 1 connects to Aave so users can use their Aave positions in routed transactions. Aave can serve as a source of liquidity, a source of collateral, or the destination for a refinanced position. Aave routes let users refinance between Aave and Term, use Aave borrowing capacity or withdrawable collateral to fund a Term loan, or unwind an Aave position through a single routed flow. If a route includes Aave, the preview will show the expected impact on your Aave position, including collateral, debt, borrowing capacity, and health factor where applicable. Execution depends on supported assets, available collateral, borrowing capacity, and Aave market constraints at execution time. If those requirements are not satisfied, the route reverts safely. {% hint style="info" %} **Important:** previews are informational only. Users should independently verify their resulting Aave position, including health factor and liquidation risk, before signing. Terminal 1 does not guarantee the accuracy of third-party venue data and will not prevent users from executing routes that result in dangerously low health factors or otherwise risky positions. {% endhint %} ### What to expect * If a route includes Aave, the preview will show the expected impact on your Aave position, including collateral, debt, borrowing capacity, and health factor where applicable. * Reverts will typically come from missing authorization, insufficient capacity, or Aave market constraints rather than partial execution.
### User considerations * **Resulting position:** review the expected impact on your Aave position, including collateral, debt, borrowing capacity, and health factor. * **Liquidation risk:** ensure the resulting health factor leaves enough buffer for price moves, interest accrual, and market volatility. * **Variable-rate risk:** Aave borrow and supply rates are variable and may change before or after execution. Review the current rate and understand that the resulting position may accrue interest at a different rate over time. * **Market availability:** Aave liquidity, caps, collateral parameters, and borrowing capacity can change before execution and may affect whether the route can be completed. * **Authorizations:** confirm that any required approvals, permits, or Safe authorizations are in place and use appropriate spending limits. * **Preview limitations:** previews are informational only. Users are responsible for independently verifying Aave data, route outputs, health factor, and liquidation risk before signing. Terminal 1 does not guarantee the accuracy of third-party venue data and does not prevent users from executing routes that may result in low health factors or otherwise risky positions. ### Related pages * [Refinance](/terminal-1-execution/workflows/refinance) * [Looping](/terminal-1-execution/workflows/looping) * [Disclosures](/terminal-1-execution/risks-and-failure-modes/disclosures) # Morpho How Terminal 1 can interact with Morpho in supported routes. Terminal 1 connects to Morpho so users can use their Morpho positions in routed transactions. Aave can serve as a source of liquidity, a source of collateral, or the destination for a refinanced position. Morpho routes let users refinance between Morpho and Term, use Morpho borrowing capacity or withdrawable collateral to fund a Term loan, or unwind an Morpho position through a single routed flow. If a route includes Morpho, the preview will show the expected impact on your Morpho position, including collateral, debt, borrowing capacity, and health factor where applicable. Execution depends on supported assets, available collateral, borrowing capacity, and Morpho market constraints at execution time. If those requirements are not satisfied, the route reverts safely. {% hint style="info" %} **Important:** Users should independently verify their resulting Morpho position, including health factor and liquidation risk, before signing. Terminal 1 does not guarantee the accuracy of third-party venue data and will not prevent users from executing routes that result in dangerously low health factors or otherwise risky positions. {% endhint %} ### What to expect * Routes that involve Morpho are scoped to a specific Morpho market configuration where applicable. * If a route includes Morpho, the preview will show the expected impact on your Morpho position, including collateral, debt, borrowing capacity, and health factor where applicable. * Reverts will typically come from missing authorization, insufficient capacity, or market-specific constraints.
### User considerations * **Resulting position:** review the expected impact on your Morpho position, including collateral, debt, borrowing capacity, and health factor. * **Liquidation risk:** ensure the resulting health factor leaves enough buffer for price moves, interest accrual, and market volatility. * **Variable-rate risk:** Morpho borrow and supply rates are variable and may change before or after execution. Review the current rate and understand that the resulting position may accrue interest at a different rate over time. * **Market availability:** Morpho liquidity, caps, collateral parameters, and borrowing capacity can change before execution and may affect whether the route can be completed. * **Authorizations:** confirm that any required approvals, permits, or Safe authorizations are in place and use appropriate spending limits. * **Preview limitations:** previews are informational only. Users are responsible for independently verifying Morpho data, route outputs, health factor, and liquidation risk before signing. Terminal 1 does not guarantee the accuracy of third-party venue data and does not prevent users from executing routes that may result in low health factors or otherwise risky positions. ### Related pages * [Refinance](/terminal-1-execution/workflows/refinance) * [Looping](/terminal-1-execution/workflows/looping) * [Common errors](/terminal-1-execution/risks-and-failure-modes/common-errors) # ERC4626 Terminal 1 supports ERC‑4626 vaults as a generic integration for sourcing funds from deployed capital. Where supported by a workflow, Terminal 1 can withdraw available assets from an ERC‑4626 vault and use those proceeds as inputs to a route (e.g., to fund an intent or satisfy a repayment leg), reducing the need to keep idle tokens in a wallet. ### What to expect * Vault interactions appear as explicit steps in the route (withdraw/redeem as applicable). * Available withdrawable amounts are determined at execution time and can change with vault conditions. * If a vault cannot satisfy the requested withdrawal, the route will revert rather than partially complete. ### User considerations * Vault liquidity and withdraw limits can change; previews may become stale. * Some vaults impose delays, limits, or non-standard behavior; route support depends on workflow compatibility. * Review the token that will be withdrawn and where proceeds will be routed next (swap, repayment, settlement). * Ensure the vault share token is authorized where needed for withdrawal/redeem operations. # Aggregators How Terminal 1 uses routing and swap aggregators in supported flows. Terminal 1 integrates with DEX aggregators to source swap liquidity when a route requires token conversions (e.g., repaying a debt in one token using proceeds in another). Aggregators are used to construct swap call data and execution paths that are compatible with the route’s constraints.
### What to expect * Aggregator steps appear in the route sequence when swaps are required. * Swap outcomes can differ from preview due to price movement and liquidity changes; constraints and UI buffers are used to reduce avoidable reverts. * If execution falls outside route bounds (fees, slippage, deadlines), the route will revert rather than partially complete. ### What users should watch * Slippage and price impact are the primary risk drivers for swap-dependent routes. * Quotes can become stale, especially with Safe signing latency; re-run preview if execution is delayed. * Swap availability is chain- and asset-dependent; a given aggregator may not support all routes or tokens. * Review which tokens are swapped, expected minimums/maximums, and any buffer settings shown by the UI. ### Related pages * [Routes & atomic execution](/terminal-1-execution/concepts/routes-and-atomic-execution) * [Fees, slippage & buffers](/terminal-1-execution/concepts/fees-slippage-and-buffers) * [Disclosures](/terminal-1-execution/risks-and-failure-modes/disclosures) # Blue Sheets (Simple-Earn) The Blue Sheets Simple-Earn product makes fixed-rates accessible to those who don't have capacity to participate in Term auctions, offering on-demand, single-click access to fixed rates on-chain. As a refresher, the Term Finance protocol enables the creation, servicing and monitoring of fixed-rate, fixed-term loans on-chain, backed by ERC-20 tokens ([Term Repos](/protocol/term-repos)). Lenders and borrowers are matched through weekly [Term Auctions](/protocol/term-auctions) at a single interest rate, or [clearing rate](/protocol/term-auctions/complete-auction/clearing-rate), and lenders who are successfully matched, receive ERC-20 receipt tokens ([Term Repo Tokens](/protocol/term-repo-tokens)). These Term Repo Tokens represent claims to repayment proceeds upon maturity of a loan -- similar to the "principal tokens" or "PT tokens" in various DeFi yield-stripping protocols. To protect lenders, Term Repo Loans and Term Repo Tokens are backed by collateral held in non-custodial contracts monitored by real-time price oracles, primarily [Chainlink](https://chain.link/). The Blue Sheets Simple-Earn product was created to make fixed-rate yields more accessible to the casual DeFi community who don't have time to monitor Term auctions, offering on-demand, single-click access to fixed rates on-chain.

Flow of the Blue Sheets (simple-earn) process

#### Process The Blue Sheets simple-earn contract serves as a listing platform where holders of Term Repo Tokens—typically acquired through a Term Auction—can offer them for resale. A typical flow follows the two-step process outlined below: 1. Primary auction -> Blue Sheets Participants who acquire Term Repo Tokens in the primary auction market transfer some or all of these tokens into the Blue Sheets simple-earn contract. The yield for these Term Repo Tokens is automatically set to match the clearing rate of the most recent auction, with a 0.25% annualized mark-up (Listing Rate). This mark-up incentivizes participants who acquired Term Repo Tokens in the primary auction market to make inventory available through the Blue Sheets simple-earn contract. $$ ListingRate(x) = AuctionRate(x)-0.25% $$ 2. Blue Sheets -> Blue Sheets earner As a Blue Sheets earner, you can explore available Term Repo Tokens listed in the Blue Sheets simple-earn contract and acquire them at a fixed yield (Listing Rate). There is no slippage and no additional fees beyond standard gas costs. The amount available for acquisition, however, is capped to the amount listed within the Blue Sheets contract. When an earn transaction is initiated, the smart contract transfers the specified amount of Term Repo Tokens and deducts purchase tokens (such as USDC or wETH) in an amount equal to the price per Repo Token multiplied by the desired quantity. The acquisition price of Term Repo Tokens is calculated using the formula below: $$ Price(x,t) = \frac{1} {(1+ListingRate(x) \* t/360)} $$ where $$ t = \text{Remaining time to maturity, in days} $$ This formula ensures that the price paid is always less than or equal to the amount redeemable upon maturity. The difference adjusted for the amount of time remaining until maturity is the "yield" earned by the user. #### Use Case The Blue Sheets Simple-Earn contract has no minimums and eliminates the complexities and time constraints of the primary market auction calendar and deadlines. Use the Blue Sheets Simple-Earn contract to build a portfolio or bond ladder that suits your needs, on your own timeline, with precise control and guaranteed fills up to the lending capacity. {% hint style="info" %} Users who earn through the Blue sheets simple-earn contract are in fact acquiring Term Repo Tokens. Term Repo Tokens are not automatically redeemed upon maturity. To redeem, simply navigate to the [Portfolio](https://app.term.finance/portfolio/positions) page on the main app to view, manage and redeem outstanding Term Repo Tokens. {% endhint %} {% hint style="info" %} All [Risk Disclosures](/protocol/risk-disclosures) for the Term Finance Protocol remain applicable. {% endhint %} # Security Audits Blue Sheets (Simple-Earn)
AuditorAudit TypeDateRelease
ChainLightInitial ReviewOctober 20240.1.0
# FAQ Quick answers to common questions about the Blue Sheets: Learn how yields work, understand fees and risks, and discover how to earn fixed rates from Term auctions. ## Q: What are the Blue Sheets? The Blue Sheets are designed for users who want access to fixed rates but don't have time to monitor Term auctions. Through the Blue Sheets, users can filter, search, and supply funds to earn fixed rates from past auctions with just a single click. There are no minimums, no slippage, and no hidden fees.
## Q: Where does the yield come from? Yields come from Term auctions, where borrowers compete to take out fixed-rate loans by bidding interest rates they're willing to pay. These borrower-paid interest rates become the fixed yields that lenders can earn through the Blue Sheets. All loans are over-collateralized, with borrowers' collateral tokens held in non-custodial smart contracts as security. ## Q: Are there any fees? No hidden fees - the rate you see is the rate you'll receive. Published rates are transparent and final (set at 0.25% below auction rates), with users responsible only for network gas fees. ## Q: What are the risks? Like all DeFi activities, lending through the Blue Sheets carries risks including smart contract vulnerabilities, oracle failures, network issues, and liquidation risks. During market volatility, there may not be enough liquidity to fully cover repayment through liquidations. Please review our detailed [Risk Disclosures](/protocol/risk-disclosures) before participating. # Security Audits #### Term Finance Protocol
AuditorAudit TypeDateRelease
Sigma PrimeInitial ReviewApril 20230.1.0
Runtime VerificationAlgorithm May 20230.1.0
Sigma PrimeChangesMay 20230.2.0
DedaubChangesJune 20230.4.0
Sigma PrimeChangesNovember 20230.6.0
\ Blue Sheets (Simple-Earn)
AuditorAudit TypeDateRelease
ChainLightInitial ReviewOctober 20240.1.0
# Terms of Use Last modified: June 16, 2026 These terms of use (the “Terms”), together with any documents and additional terms they expressly incorporate by reference, which includes any other terms and conditions or other agreement that Terminal 0 Ltd. and its affiliates (“Company,” “we,” “us,” and “our”) posts publicly or makes available to you or the company or other legal entity you represent (“you” or “your”), are entered into between Company and you concerning your use of, and access to: * The website term.finance (and their respective subdomains) and all associated sites linked thereto by Company, including, but not limited to [docs.term.finance](https://docs.term.finance/) (collectively with any materials and services available therein, the “Website”); * The user interface at [app.term.finance](https://app.term.finance/), which acts as a front-end only to access a decentralized permissionless non-custodial liquidity protocol on the Ethereum blockchain known as the Term Finance Protocol (the “Interface”); and * Any features and services related to the Website and the Interface provided by Company (together with the Website and the Interface, the “Services”). By accessing and making use of the Services, you agree to and accept to be bound by these Terms. Company may amend these Terms from time to time at its own discretion. By continuing to make use of the Services, you agree to and accept to be bound by the latest version of the Terms. The latest version of the Terms always applies between Company and you. You may not use the Services if you do not accept any of the Terms. Please also review our [Privacy Policy](/legal/privacy-policy), which is incorporated expressly into these Terms. **The Protocol** The Term Finance Protocol (the “Protocol”) is a collection of smart contracts that serves as infrastructure for on-chain fixed-rate fixed-term borrowing based on tripartite repurchase agreements that are common in traditional finance. Protocol smart contracts primarily provide administerial support for on-chain loans by recording repayment obligations between Protocol borrowers (“Protocol Borrowers”) and Protocol lenders (“Protocol Lenders,” and together with Protocol Borrowers, “Protocol Users”), monitoring compliance with margin requirements, and administering collateral liquidation processes. The Protocol operates exclusively on-chain and in a decentralized and non-custodial manner. The Protocol does not originate loans. This paragraph and these Terms are not intended to be a comprehensive description of the Protocol and its risks. YOU MUST REVIEW THE PROTOCOL’S DOCUMENTATION (THE “PROTOCOL DOCUMENTATION”), WHICH CONTAINS FURTHER DISCLOSURES (BUT ARE ALSO NOT INTENDED TO BE EXHAUSTIVE), AS A CONDITION OF USING ANY SERVICES. BY ACCESSING AND USING ANY SERVICES, YOU REPRESENT THAT YOU HAVE CAREFULLY REVIEWED THE PROTOCOL DOCUMENTATION AND ARE FINANCIALLY AND TECHNICALLY SOPHISTICATED ENOUGH TO UNDERSTAND THE INHERENT RISKS OF ACCESSING THE PROTOCOL, INCLUDING BUT NOT LIMITED TO THOSE SET FORTH BELOW IN THESE TERMS. IF YOU DO NOT, YOU MAY NOT USE ANY SERVICES, INCLUDING THE INTERFACE. **The Website** The Website provides informational resources about the Protocol. THE WEBSITE IS SOLELY AN INFORMATION SOURCE. THE COMPANY DOES NOT OWN OR CONTROL THE PROTOCOL OR ANY OF ITS SMART CONTRACTS. THE COMPANY DOES NOT HAVE POSSESSION, CUSTODY, OR CONTROL OVER ANY CRYPTOASSETS TRANSACTED BY USERS OF THE PROTOCOL. This information is not intended to be comprehensive or address all aspects of the Protocol. All information provided in connection with your access and use of the Website is for informational purposes only. You should not take, or refrain from taking, any action based on any information contained on the Website or any other information that we make available at any time, including blog posts, data, articles, links to third-party content, discord content, news feeds, tutorials, tweets, and videos. Before you make any financial, legal, technical, or other decisions involving the Services, you should seek independent professional advice from a licensed and qualified individual in the area for which such advice would be appropriate. The Services provide, or third parties may provide, links to other sites, applications, or resources. You acknowledge and agree that we are not responsible for the availability of such external sites, applications or resources, and do not endorse and are not responsible or liable for any content, advertising, products, or other materials on or available from such sites or resources. You further acknowledge and agree that we will not be responsible or liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with use of or reliance on any such content, goods, or services available on or through any such site or resource. **The Interface** The Interface provides access, and access only, to the Protocol. The Interface is not the only method of accessing the Protocol. THE INTERFACE AND RELATED SERVICES ARE INFORMATIONAL AND ARE NOT A SOLICITATION, RECOMMENDATION, OR OFFER TO BUY OR SELL ANY FINANCIAL PRODUCT OR INSTRUMENT, OR ENTER INTO ANY TRANSACTION. Company may, at its absolute and sole discretion, change, update, amend, remove, or discontinue any part of the Interface and the Services at any time without prior notice to you. **The Role of Company** Company provides the Services. Company: * Does NOT operate a digital asset or derivatives exchange platform or offer trade execution or clearing services; * Does NOT have any oversight, involvement, or control over your transactions using the Protocol; * Does NOT have any control over the Protocol and its smart contracts or Protocol Users; * Does NOT have any possession, custody, or control over any cryptoassets lent, borrowed, or pledged using the Protocol; * Does NOT administer any use of the Protocol by Protocol Users, including monitoring margin compliance for Protocol Borrowers; * Is NOT a party to any transactions among Protocol Users or between Protocol Users and the Protocol; * Is NOT a financial adviser, investment manager, lender, fiduciary, financial institution, broker dealer, custodian, creditor, intermediary and/or charity; and * Does NOT warrant the accuracy, correctness, and completeness of the information provided by the Protocol or Protocol Users and takes no responsibility for such information. Company has no control over the conduct of, or any information provided by, any Protocol Users and hereby disclaims all liability in this regard to the fullest extent permitted by applicable law. Company offers the Interface to help Protocol Users access the Protocol. Company makes no representations regarding the creditworthiness of any Protocol Borrower or their collateral. There is always the possibility that something unexpected may occur with regard to cryptoassets, which could cause a Protocol User’s cryptoassets to be lost. Company cannot be held liable in that regard. Company strongly recommends to every Protocol User to interact with only as many cryptoassets as he/she/it is willing to lose. Each Protocol User is solely responsible for any decisions. ALL INFORMATION AND CONTENT PROVIDED BY COMPANY RELATING TO THE SERVICES IS FOR INFORMATION PURPOSES ONLY AND COMPANY DOES NOT GUARANTEE THE ACCURACY, COMPLETENESS, TIMELINESS OR RELIABILITY OF ANY SUCH INFORMATION OR CONTENT. NO CONTENT IS INTENDED TO SERVE AS FINANCIAL, LEGAL, TAX OR OTHER PROFESSIONAL ADVICE. YOU ACKNOWLEDGE THAT ALL INFORMATION AND CONTENT ACCESSED BY YOU WHEN USING THE INTERFACE IS AT YOUR OWN RISK. **Eligibility; No Persons from Certain Jurisdictions** To access or use the Interface or any Services, you must be able to form a legally binding contract with us. Accordingly, you represent and warrant that you are at least 18 years old (or, where applicable, of an age that meets such other higher minimum age limit as required in the laws of your jurisdiction) and have the full right, power, and authority to enter into such contract and comply with these Terms on behalf of yourself and any company or legal entity for which you may act on behalf of or at the instruction of. AS A CONDITION OF USING ANY SERVICES, YOU REPRESENT THAT YOU HAVE CAREFULLY REVIEWED THE PROTOCOL DOCUMENTATION AND ARE FINANCIALLY AND TECHNICALLY SOPHISTICATED ENOUGH TO UNDERSTAND THE INHERENT RISKS OF ACCESSING THE PROTOCOL AND USING THE SERVICES, INCLUDING BUT NOT LIMITED TO THOSE SET FORTH BELOW IN THESE TERMS. IF YOU DO NOT, YOU MAY NOT USE ANY SERVICES. You further represent and warrant that you are not (a) the subject of asset freeze, travel ban, financial, economic, human rights, sectoral or trade sanctions administered or enforced by any governmental authority or otherwise designated on any list of prohibited or restricted parties or (b) a citizen, resident, or organized in a jurisdiction or territory that is the subject of comprehensive country-wide, territory-wide, or regional economic sanctions by the United Nations. Finally, you represent and warrant that your access and use of the Services will fully comply with all applicable laws and regulations, and that you will not access or use the Services to conduct, promote, or otherwise facilitate any illegal activity (including but not limited to activities which are prohibited by applicable AML and CTF regulations). It is your responsibility to assess whether you are prohibited from using the Services. We reserve the right to choose which markets and jurisdictions to conduct our business and may restrict or refuse, at our sole discretion, access to any Services in certain countries or regions. AT THIS TIME THE COMPANY DOES NOT PERMIT ACCESS TO THE INTERFACE FROM THE FOLLOWING JURISDICTIONS: MYANMAR (BURMA), BELARUS, CHINA, COTE D'IVOIRE (IVORY COAST), CUBA, CRIMEA AND SEVASTOPOL, DEMOCRATIC REPUBLIC OF CONGO, EQUATORIAL GUINEA, ERITREA, IRAN, IRAQ, LIBYA, MALI, NICARAGUA, DEMOCRATIC PEOPLE’S REPUBLIC OF KOREA (NORTH KOREA), RUSSIA, SOMALIA, SUDAN, SYRIA, YEMEN, AND ZIMBABWE, as well as any country or region that is subject to comprehensive country-wide or region-wide economic sanctions by the United States of America. You agree not to use a VPN or any other software to hide or modify your IP address. **Prohibited Conduct** You may not use the Services to engage in the following categories of activities (“Prohibited Conduct”), and by using any of the Services (including the Interface), you confirm that you will not engage in any of the following Prohibited Conduct: * Violate any applicable laws, including any relevant and applicable anti-money laundering and anti-terrorist financing laws and sanctions programs; * Engage in transactions involving items that infringe or violate any copyright, trademark, right of publicity or privacy, or any other proprietary right under applicable law, including sales, distribution or access to counterfeit music, movies, software or other licensed materials without the appropriate authorization from the rights holder; use of Company’s or our licensors’ intellectual property, name or logo, including use of Company’s trade, service or licensed marks, without express consent from Company or in a manner that otherwise harms Company; * Take any action that implies an untrue endorsement by or affiliation with Company; * Engage in improper or abusive trading practices, including, but not limited to, (a) any fraudulent act or scheme to defraud, deceive, trick or mislead; (b) fraudulent trading; (c) accommodation trading; (e) fictitious transactions; (f) pre-arranged or non-competitive transactions; (g) cornering, or attempted cornering, of any Protocol auctions; (h) manipulation (i.e., trading for the purposes of affecting the market price of a cryptosset and creating an artificial price); (k) any trading activity that is improper, abusive, or disruptive to the operation of the Interface or other Services or the Protocol; * Promote or facilitate illegal activity; * Use the Services in any manner that could interfere with, disrupt, negatively affect, or inhibit other users of the Services from fully enjoying the Services, or that could damage, disable, overburden, or impair the functioning of the Services or the Protocol in any manner; * Circumvent any content-filtering techniques, security measures, or access controls employed on the Interface or any Services, through the use of a VPN; * Use or access the Services or the Protocol to transact in digital assets that are the direct or indirect proceeds of any criminal or fraudulent activity, including terrorism or tax evasion; * Use the Services in any way that is, in our sole discretion, libelous, defamatory, profane, obscene, pornographic, sexually explicit, indecent, lewd, harassing, stalking, hateful, offensive, discriminatory, bigoted, abusive, inflammatory, fraudulent, deceptive, or otherwise objectionable; * Harass, abuse, or harm another person; * Impersonate another user of the Services or the Protocol or otherwise misrepresent yourself; or * Engage or attempt to engage, or encourage, induce, or assist any third party to engage or attempt to engage in any of the activities prohibited under this section or any other provision of these Terms. **Non-Custodial Protocol; No Fiduciary Duties** The Protocol is purely non-custodial, meaning when you transfer cryptoassets to any smart contract accessed through the Interface, you are not transferring such cryptoassets to Company. You are solely responsible for the custody of the cryptographic private keys to the cryptoasset wallets you hold. NEITHER THE COMPANY NOR ANY COMPANY PARTY (AS DEFINED BELOW) HAS POSSESSION, CUSTODY OR CONTROL OVER ANY CRYPTOASSETS APPEARING ON THE SERVICES OR ANY PROTOCOL USER’S CRYPTOASSETS. WE DO NOT GUARANTEE ANY REMEDY, REFUND OR OTHER FORMS OF COMPENSATION IN THE EVENT THAT THERE IS ANY LOSS OF YOUR CRYPTOASSETS (WHETHER IT IS DUE TO YOUR OWN ACTIONS / OMISSIONS OR THE ACTS OR OMISSIONS OF EXTERNAL PARTIES). “Company Party” means any of Company’s parents, subsidiaries, affiliates, related companies, officers, directors, employees, agents, representatives, contractors, partners, and licensors. These Terms are not intended to, and do not, create or impose any fiduciary duties on us. To the fullest extent permitted by law, you acknowledge and agree that we owe no fiduciary duties or liabilities to you or any other party, and that to the extent any such duties or liabilities may exist in law or in equity, those duties and liabilities are hereby irrevocably disclaimed, waived, and eliminated. You further agree that the only duties and obligations that we owe you are those set out expressly in these terms. **Rewards** In your use of the Services, you may be attributed certain reputation indicators, points, or other intangible rewards (“Rewards”). Rewards are not, and may never convert to, accrue to, be used as basis to calculate, or become any other tokens or virtual assets or distribution thereof. Rewards are virtual items with no monetary value.You do not own the Rewards. Rewards do not constitute any currency or property of any type and are not redeemable, refundable, or eligible for any fiat or virtual currency or anything else of value. Rewards are not transferable between users, and you may not attempt to sell, trade, or transfer any Rewards, or obtain any manner of credit using any Rewards. You are not allowed to sublicense, trade, sell or attempt to sell Rewards for money or other consideration, or exchange Rewards for value of any kind outside of the Services. Any attempt to sublicense, sell, trade, or transfer any Rewards or tokens redeemable for or representing any Rewards will be null and void and may cause the Rewards to be voided. Your Rewards may be modified, removed, or voided by us at our discretion for any reason (or no reason) whatsoever. Rewards are not redeemable, refundable or eligible for any currency or anything else of value. We may offer certain functions of the Services to users that have accumulated certain Rewards, but the availability of such functions is subject to change at any time in our sole discretion. We grant you a non-exclusive, non-transferable, non-sublicensable, limited license and right to use the Rewards in accordance with these Terms while we offer the Services. **Assumption of Risks** The risks described below and elsewhere in these Terms are not intended to be a comprehensive statement of all risks associated with using the Services (including the Interface) or the Protocol. BY ACCESSING AND USING THE INTERFACE OR ANY SERVICES, YOU REPRESENT THAT YOU ARE FINANCIALLY AND TECHNICALLY SOPHISTICATED ENOUGH TO UNDERSTAND THE INHERENT RISKS ASSOCIATED WITH: (A) USING CRYPTOGRAPHIC AND BLOCKCHAIN-BASED SYSTEMS, AND THAT YOU HAVE A WORKING KNOWLEDGE OF THE USAGE AND INTRICACIES OF DIGITAL ASSETS SUCH AS BITCOIN (BTC), ETHER (ETH), AND OTHER DIGITAL TOKENS SUCH AS THOSE FOLLOWING THE ETHEREUM TOKEN STANDARD (ERC-20); AND (B) THE LENDING AND BORROWING ACTIVITY ENABLED BY THE PROTOCOL AND YOUR USE OF THE PROTOCOL. YOU ALSO REPRESENT THAT YOU HAVE CONSULTED WITH YOUR INDEPENDENT FINANCIAL AND LEGAL ADVISORS REGARDING YOUR USE OF THE PROTOCOL AND ARE RELYING SOLELY ON YOUR INDEPENDENT JUDGMENT AND NO OTHER REPRESENTATIONS. IF YOU DO NOT OR CANNOT MAKE ANY OF THE FOREGOING REPRESENTATIONS, YOU MAY NOT USE THE INTERFACE OR ANY SERVICES. Blockchain, Smart Contracts. You represent that you understand that transactions on the Protocol rely on smart contracts stored on a blockchain, cryptographic tokens and other cryptoassets generated by the smart contracts, and other nascent software, applications and systems that interact with blockchain-based networks. These technologies are experimental, speculative, inherently risky, and subject to change. Among other risks, bugs, malfunctions, cyberattacks, or changes to the applicable blockchain (e.g., forks) could disrupt these technologies and even result in a total loss of cryptoassets, their market value, or digital funds. BY ACCESSING AND USING THE INTERFACE OR ANY SERVICES, YOU REPRESENT THAT YOU ARE FINANCIALLY AND TECHNICALLY SOPHISTICATED ENOUGH TO UNDERSTAND THE INHERENT RISKS ASSOCIATED WITH USING CRYPTOGRAPHIC AND BLOCKCHAIN-BASED SYSTEMS, AND THAT YOU HAVE A WORKING KNOWLEDGE OF THE USAGE AND INTRICACIES OF DIGITAL ASSETS SUCH AS BITCOIN (BTC), ETHER (ETH), AND OTHER DIGITAL TOKENS SUCH AS THOSE FOLLOWING THE ETHEREUM TOKEN STANDARD (ERC-20). In particular, one of the other defining features of blockchain technology is that its entries are immutable, which means, as a technical matter, they generally cannot be deleted or modified by anyone. This includes smart contracts and cryptoassets generated and programmed by smart contracts. THUS, TRANSACTIONS RECORDED ON THE BLOCKCHAIN, INCLUDING INTERACTIONS WITH THE PROTOCOL, TRANSFERS OF CRYPTOASSETS, AND DATA PROGRAMMED INTO THESE ASSETS (SUCH AS LIQUIDATION OF COLLATERAL, DETERMINATION OF DEFAULT, AND REVENUE AND INTEREST ALLOCATIONS), MUST BE TREATED AS PERMANENT AND CANNOT BE UNDONE BY US OR BY ANYONE. YOU MUST BE VERY CAREFUL WHEN YOU FINALIZE ANY TRANSACTION THAT WILL BE RECORDED ON THE BLOCKCHAIN. Code; Cryptography. You represent that you understand that if the source code or cryptography underlying the Protocol’s smart contracts or cryptoassets lent, borrowed, and pledged as collateral through the Protocol proves to be flawed or ineffective, malicious actors may be able to steal such assets. In the past, flaws in the source code of other crypto protocols and cryptoassets have been exposed and exploited. Several errors and defects have been publicly found and corrected, including those that disabled some functionality for users and exposed users’ personal information. Discovery of flaws in, or exploitations of, the source code that allow malicious actors to take or create additional cryptoassets in contravention of known network rules have occurred. In addition, the cryptography underlying a cryptoasset could prove to be flawed or ineffective, or developments in mathematics or technology, including advances in digital computing, algebraic geometry and quantum computing, could result in such cryptography becoming ineffective. Volatility. You represent that you understand that the markets for these digital assets are highly volatile due to factors including (but not limited to) adoption, speculation, technology, security, and regulation. You acknowledge and accept that the cost and speed of transacting with cryptographic and blockchain-based systems such as Ethereum are variable and may increase dramatically at any time. You further acknowledge and accept the risk that your digital assets may lose some or all of their value while they are supplied to the Protocol through the Interface, you may suffer loss due to the fluctuation of prices of tokens in a trading pair or liquidity pool, and, especially in expert modes, experience significant price slippage and cost. Oracles. You represent that you understand that like many decentralized finance (“DeFi”) protocols, the Protocol uses “oracles,” which refer to data points from outside the DeFi chain or environment that are used as base for certain calculations or operations. For instance, a DeFi lending protocol may rely on price oracles to determine whether loans are properly collateralized. If the oracle is compromised, the DeFi protocol using that oracle will no longer function correctly, and attacking the oracle can be used as a means to attack and manipulate a DeFi protocol, which may adversely affect Protocol Users. Fake Tokens. You represent that you understand that anyone can create a cryptoasset token, including fake versions of existing tokens and tokens that falsely claim to represent projects, and acknowledge and accept the risk that you may mistakenly transact with those or other tokens. Layer 1; Third Parties. You represent that you understand the underlying layer-1 blockchains on which the Protocol is deployed, including, for example, the Ethereum blockchain, are open source, which means that anyone can use, utilize, and build on top of it. By using the Services, you acknowledge and agree that (i) Company is not responsible for the operation of the layer-1 blockchains underlying the Protocol, (ii) there exists no guarantee of the functionality, security, or availability of the layer-1 blockchains, and (iii) the underlying layer-1 blockchains are subject to sudden changes in operating rules, such as those commonly referred to as “forks”. Company is not responsible for the content or services of any third-party, including, without limitation, any network, or apps like Discord, or MetaMask, and we make no representations regarding the content or accuracy of any third-party services or materials. Lack of Anonymity on the Blockchain. A widespread belief is that transactions involving blockchains are anonymous. In fact, a central feature of blockchains and thus, blockchain-based transactions, are that they are transparent. Your public key and your wallet address, which you need to transact on the blockchain, are visible to anyone. To the extent your public key or wallet address can be linked back to you, it would be possible for someone to determine your identity and the cryptoassets you own. Lending and Borrowing on the Protocol. BY ACCESSING AND USING THE INTERFACE OR ANY SERVICES, YOU REPRESENT THAT YOU HAVE CAREFULLY REVIEWED THE PROTOCOL DOCUMENTATION AND ARE FINANCIALLY AND TECHNICALLY SOPHISTICATED ENOUGH TO UNDERSTAND THE INHERENT RISKS OF INTERACTING WITH THE PROTOCOL AS WELL AS ENGAGING IN THE LENDING AND BORROWING ACTIVITIES ENABLED BY THE PROTOCOL. IF YOU DO NOT, YOU MAY NOT USE THE INTERFACE OR ANY SERVICES. These inherent risks include, but are not limited to the following: * Use of the Protocol not guaranteed: There is no guarantee that you will be able to use the Protocol as a Protocol Lender or Protocol Borrower, including because your bids and offers are rejected. * Smart contract administration: Protocol User transactions are administered entirely and automatically by smart contracts. This means that there is no way, for example, to prevent liquidation of collateral once the conditions for liquidation are met. * Credit risk: Protocol Lenders face the risk of default by Protocol Borrowers, which could lead to losses. * No representations regarding creditworthiness: Neither Company nor the Protocol makes any representations whatsoever regarding the creditworthiness of Protocol Borrowers or the sufficiency of their pledged collateral. * Immediate collateral liquidation: Protocol Borrower collateral is liquidated immediately and without notice upon breaching a maintenance margin requirement. * Collateral may be insufficient: There is no guarantee that liquidation of Protocol Borrower collateral will be sufficient to cover the Borrower’s repayment obligations. * Liquidity risk: Protocol Lenders cannot demand early repayment of lent cryptoassets. Protocol Borrowers may not be able to obtain return of their collateral prior to their repayment deadline. * Operational risk: Protocol Users are exposed to operational risks associated with the Protocol’s management of collateral and the settlement process. This can include code errors and bugs, as well as hacks by malicious third parties. User Error. You understand you are solely responsible for your use of the Protocol and the Services, including any transactions (erroneous or otherwise) you enter into as a result of the information provided by the Interface. Company will not take any action to resolve erroneous transactions, and in any event does not have the ability to modify or reverse transactions entered into using the Protocol. **Vault Risks** In connection with your use of the interface at vault.term.finance (the "Vault Interface") and your interaction with any smart contracts that form "Term Vaults" (whether through the Vault Interface or otherwise), you acknowledge and/or represent the following and warrant you understand the risks regarding the same: * Term Vaults are built on Yearn v3 smart contracts and you have carefully reviewed the documentation at [docs.yearn.fi](http://docs.yearn.fi) and the risk disclosures found at [docs.yearn.fi/developers/security/risks/](https://docs.yearn.fi/developers/security/risks/), including the subpages titled “Risk Scores,” “Protocol Risks,” “Strategy Risks,” and “Vault Risks”. * Past performance of any Term Vault is not indicative of future results. The value of your deposit can go down as well as up, and you may lose some or all of your deposited funds. Deposits are not insured or guaranteed by any government or private entity. You bear all risks of participation. * The strategies implemented by Term Vaults may not perform as intended due to market conditions, technical limitations, or other factors. Market volatility, liquidity constraints, or external events could negatively impact strategy performance. The effectiveness of strategies may deteriorate over time as market conditions change or other market participants adopt similar approaches. There may be deposit or withdrawal restrictions placed by the curators of Term Vaults. * Term Vaults interact with various decentralized finance (or “defi”) protocols and smart contracts. Issues with these protocols or contracts could result in trading losses or frozen funds. Smart contract technology is experimental and carries significant risks. Term Vaults may contain bugs, vulnerabilities, or other issues that could result in loss of funds. No guarantee is made regarding the security or functionality of the smart contracts. * Blockchain and defi, including the Term Vaults built on Yearn v3 smart contracts, are of a novel and experimental nature and are associated with a variety of risks, which you have familiarized yourself with and accepted. Those risks include those set forth in these Terms as well as Yearn’s documentation. * Unless stated expressly otherwise, no Company Indemnified Party (as defined below) is a curator of a Term Vault or exercises any control over the strategy implemented by said Vault. * The regulatory status of vaults implementing trading strategies like Term Vaults is uncertain and subject to change. Future regulatory actions could impact vault operation or require modifications to strategies. * Term Vaults are available “as is” and “as available” without any representation, warranties or guarantees whatsoever, and neither Terminal 0 Ltd. nor any other Company Indemnified Party (as defined below) makes any representation or guarantee whatsoever in connection with Term Vaults, including any representation or guarantee relating to yield, vault performance, vault curator, investment suitability, or the safety of funds in any Term Vault or strategy implemented by a Term Vault. The Term Parties shall have no liability whatsoever relating to your use of Term Vaults. **Acknowledgment and Assumption of Risks** YOU FURTHER ACKNOWLEDGE THAT WE ARE NOT RESPONSIBLE FOR ANY OF THESE VARIABLES OR RISKS (INCLUDING, BUT NOT LIMITED TO, THOSE DESCRIBED ABOVE), DO NOT OWN OR CONTROL THE PROTOCOL, AND CANNOT BE HELD LIABLE FOR ANY RESULTING LOSSES THAT YOU EXPERIENCE WHILE ACCESSING OR USING THE INTERFACE. ACCORDINGLY, YOU UNDERSTAND AND AGREE TO ASSUME FULL RESPONSIBILITY FOR ALL OF THE RISKS OF ACCESSING AND USING ANY SERVICES, INCLUDING USING THE INTERFACE TO INTERACT WITH THE PROTOCOL. The use and access of any third-party products or services, including through the Services, is at your own risk. **Access; Accessibility** We reserve the right to restrict your access from engaging with the Services to any extent (including completely barring you from the Services) for any reason at any time. You agree that we have the right to restrict your access to the Services via any technically available methods if we suspect, in our sole discretion, that (a) you are using the Services for money laundering or any illegal activity; (b) you have engaged in fraudulent activity; (c) you have acquired cryptoassets using inappropriate methods, including the use of stolen funds to purchase such assets; (d) you are the target of any sanctions administered or enforced by the U.S. Department of the Treasury’s Office of Foreign Assets Control (“OFAC”), the United Nations Security Council, the European Union, Her Majesty’s Treasury, or any other legal or regulatory authority in any applicable jurisdiction; (e) either you, as an individual or an entity, or your wallet address is listed on the Specially Designated Nationals and Blocked Persons List (“SDN List”), Consolidated Sanctions List (“Non-SDN Lists), or any other sanctions lists administered by OFAC; (f) you are located, organized, or resident in a country or territory that is, or whose government is, the subject of sanctions, including but not limited to Côte d’Ivoire, Cuba, Belarus, Iran, Iraq, Liberia, North Korea, Sudan, and Syria; or (g) you have otherwise acted in violation of these Terms. If we have a reasonable suspicion that you are utilizing the Site for illegal purposes, we reserve the right to take whatever action we deem appropriate. From time to time, the Services may be inaccessible or inoperable for any reason, including: (a) equipment or technology or other infrastructure delay, inaccessibility, or malfunctions; (b) periodic maintenance procedures or repairs; (c) disruptions and temporary or permanent unavailability of underlying blockchain infrastructure; or (d) unavailability of third-party service providers or external partners for any reason. Company has no responsibility or liability for any losses or other injuries resulting from any such events. In addition, the Services may change, which means that some or all of the Services or features of the Services may be changed, replaced, or discontinued (temporarily or permanently) at any time in Company’s sole discretion. Company has no responsibility or liability for any losses or other injuries resulting from any such changes. You acknowledge and agree that you will access and use the Services, including, without limitation, the Site at your own risk. You should not engage in blockchain-based transactions unless it is suitable given your circumstances and financial resources. By using the Services, you represent that you have been, are and will be solely responsible for conducting your own due diligence into the risks of a transaction and the underlying smart contracts and cryptoassets. **Fees** You may have to pay the Ethereum network what is known as “Gas” for certain interactions with the Protocol. For every transaction with the Protocol, a Gas fee is applicable that may vary based on your crypto wallet’s settings as well as market conditions. This fee is not charged by Company or the Protocol. At this time, Company does not charge you a fee in order to use the Interface. However, the Protocol charges Borrowers a servicing fee (the “Protocol Servicing Fee”). Please refer to the Protocol Documentation for more information. The Interface interacts with Protocol smart contracts that calculate and allocate the Protocol Servicing Fee to the entitled parties in an automated way pursuant to which Company has no possibility to interact. You herewith unconditionally and irrevocably agree to the automated collection and disbursement of fees, including but not limited to to the Protocol Servicing Fee by smart contracts. You further acknowledge and agree that the applicable Protocol smart contract will dictate how the fees are distributed. YOU ALSO ACKNOWLEDGE AND AGREE THAT COMPANY HAS NO CONTROL OVER ALLOCATION, COLLECTION, AND DISBURSEMENT OF THE PROTOCOL SERVICING FEE, WHICH IMPLEMENTED ENTIRELY BY SMART CONTRACTS, AND COMPANY CANNOT REVERSE, REFUND, OR MODIFY IN ANY OTHER WAY SUCH FEE. **Intellectual Property Rights** The Website, all content, and other materials contained therein, including, without limitation, the Company logo, and all designs, text graphics, pictures, information, data, software, and files relating to any Services (“Content”) are the proprietary property of Company and/or licensors, as applicable. The Company logo and any Interface or service names, logos, or slogans that may appear on the Interface or elsewhere are the proprietary property of Company and may not be copied, imitated or used, in whole or in part, without our prior written permission. Unless otherwise stated, you may not use any Content without our express written permission. We reserve the right to suspend or terminate your access to Services if we suspect that you have actually or allegedly infringed upon any person’s intellectual property rights. **Disclaimers; Limitations on Liability** We make no representations or warranties. THE SERVICES ARE PROVIDED ON AN “AS IS” AND “AS AVAILABLE” BASIS. WE AND OUR PARENTS, SUBSIDIARIES, AFFILIATES, RELATED COMPANIES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, REPRESENTATIVES, CONTRACTORS, PARTNERS, AND LICENSORS (COLLECTIVELY, THE “COMPANY INDEMNIFIED PARTIES”) MAKE NO GUARANTEES OF ANY KIND IN CONNECTION WITH THE SERVICES. TO THE MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW, THE COMPANY INDEMNIFIED PARTIES DISCLAIM ALL WARRANTIES AND CONDITIONS, WHETHER EXPRESS OR IMPLIED, OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT AND DISCLAIM ALL RESPONSIBILITY AND LIABILITY FOR: THE SERVICES BEING ACCURATE, COMPLETE, CURRENT, RELIABLE, UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE. INFORMATION (INCLUDING, WITHOUT LIMITATION, THE VALUE OR OUTCOME OF ANY TRANSACTION) AVAILABLE THROUGH THE SERVICE IS PROVIDED FOR GENERAL INFORMATION ONLY AND SHOULD NOT BE RELIED UPON OR USED AS THE SOLE BASIS FOR MAKING DECISIONS. ANY RELIANCE ON THE SERVICES IS AT YOUR OWN RISK. INJURY OR DAMAGE RESULTING FROM THE SERVICES. FOR EXAMPLE, YOU EXPRESSLY ACKNOWLEDGE, UNDERSTAND, AND AGREE THAT THE SERVICES MAY CONTAIN AUDIO-VISUAL EFFECTS, STROBE LIGHTS OR OTHER MATERIALS THAT MAY AFFECT YOUR PHYSICAL SENSES AND/OR PHYSICAL CONDITION. FURTHER, YOU EXPRESSLY ACKNOWLEDGE THAT THE COMPANY INDEMNIFIED PARTIES ARE NOT RESPONSIBLE FOR LOSS OR DAMAGE CAUSED BY ANOTHER USER’S CONDUCT, UNAUTHORIZED ACTORS, OR ANY UNAUTHORIZED ACCESS TO OR USE OF THE SERVICES. TO THE MAXIMUM EXTENT PERMITTED BY LAW, IN NO EVENT SHALL ANY COMPANY INDEMNIFIED PARTY BE LIABLE TO YOU FOR ANY LOSS, DAMAGE, OR INJURY OF ANY KIND INCLUDING ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, EXEMPLARY, CONSEQUENTIAL, OR PUNITIVE LOSSES OR DAMAGES, OR DAMAGES FOR SYSTEM FAILURE OR MALFUNCTION OR LOSS OF PROFITS, DATA, USE, BUSINESS OR GOOD-WILL OR OTHER INTANGIBLE LOSSES, ARISING OUT OF OR IN CONNECTION WITH: (A) THE SERVICES OR YOUR INABILITY TO USE OR ACCESS THE SERVICES; (B) MISUSE OF THE SERVICES (INCLUDING WITHOUT LIMITATION, UNAUTHORIZED ACCESS OF THE SERVICES); (C) ANY USER CONDUCT ON THE SERVICES; OR (D) TERMINATION, SUSPENSION OR RESTRICTION OF ACCESS TO ANY THE SERVICES. IN ADDITION TO THE FOREGOING, NO COMPANY INDEMNIFIED PARTY SHALL BE LIABLE FOR ANY DAMAGES CAUSED IN WHOLE OR IN PART BY: (A) USER ERROR, SUCH AS FORGOTTEN PASSWORDS OR INCORRECTLY CONSTRUCTED SMART CONTRACTS OR OTHER TRANSACTIONS; (B) SERVER FAILURE OR DATA LOSS; (C) THE MALFUNCTION, UNEXPECTED FUNCTION OR UNINTENDED FUNCTION OF THE BLOCKCHAIN, ANY COMPUTER OR CRYPTOASSET NETWORK (INCLUDING ANY WALLET PROVIDER), INCLUDING WITHOUT LIMITATION LOSSES ASSOCIATED WITH NETWORK FORKS, REPLAY ATTACKS, DOUBLE-SPEND ATTACKS, SYBIL ATTACKS, 51% ATTACKS, GOVERNANCE DISPUTES, MINING DIFFICULTY, CHANGES IN CRYPTOGRAPHY OR CONSENSUS RULES, HACKING, OR CYBERSECURITY BREACHES; (D) ANY CHANGE IN VALUE OF ANY CRYPTOASSET; (E) ANY CHANGE IN LAW, REGULATION, OR POLICY; (VI) EVENTS OF FORCE MAJEURE; OR (F) ANY THIRD PARTY. THIS LIMITATION OF LIABILITY IS INTENDED TO APPLY WITHOUT REGARD TO WHETHER OTHER PROVISIONS OF THESE TERMS HAVE BEEN BREACHED OR HAVE PROVEN INEFFECTIVE. THE LIMITATIONS SET FORTH IN THIS SECTION SHALL APPLY REGARDLESS OF THE FORM OF ACTION, WHETHER THE ASSERTED LIABILITY OR DAMAGES ARE BASED ON CONTRACT, INDEMNIFICATION, TORT, STRICT LIABILITY, STATUTE, OR ANY OTHER LEGAL OR EQUITABLE THEORY, AND WHETHER OR NOT THE COMPANY INDEMNIFIED PARTIES HAVE BEEN INFORMED OF THE POSSIBILITY OF ANY SUCH DAMAGE. IN NO EVENT WILL THE COMPANY INDEMNIFIED PARTIES’ CUMULATIVE LIABILITY TO YOU OR ANY USER OF SERVICES OR ANY PROTOCOL USER, FROM ALL CAUSES OF ACTION AND ALL THEORIES OF LIABILITY, EXCEED ONE THOUSAND U.S. DOLLARS (US$1,000.00). UNDER NO CIRCUMSTANCES SHALL ANY COMPANY INDEMNIFIED PARTY BE REQUIRED TO DELIVER TO YOU ANY VIRTUAL CURRENCY AS DAMAGES, MAKE SPECIFIC PERFORMANCE, OR ANY OTHER REMEDY. IF YOU WOULD BASE YOUR CALCULATIONS OF DAMAGES IN ANY WAY ON THE VALUE OF VIRTUAL CURRENCY, YOU AND WE AGREE THAT THE CALCULATION SHALL BE BASED ON THE LOWEST VALUE OF THE VIRTUAL CURRENCY DURING THE PERIOD BETWEEN THE ACCRUAL OF THE CLAIM AND THE AWARD OF DAMAGES. Some jurisdictions do not allow the exclusion or limitation of certain warranties and liabilities provided in this section; accordingly, some of the above limitations and disclaimers may not apply to you. To the extent applicable law does not permit Company Indemnified Parties to disclaim certain warranties or limit certain liabilities, the extent of Company Indemnified Parties’ liability and the scope of any such warranties will be as permitted under applicable law. Company is not licensed by or registered with any financial services or other regulator whether in the British Virgin Islands or otherwise. Accordingly, we do not have any duties under any British Virgin Islands financial services legislation to you, and nor do you have any recourse to any financial services regulator in the British Virgin Islands if you are dissatisfied with any aspect of the Interface or the Services. Furthermore, Company is not regulated or licensed in any other jurisdiction by any financial services or other regulator. There is no governmental or other compensation payable should you suffer any loss or damage. By using the Services you warrant that you understand and accept that you have no protections of this kind under applicable law. **Taxes** You are responsible for your taxes and duties. You bear sole responsibility for paying any and all taxes, duties, and assessments now or hereafter claimed or imposed by any governmental authority associated with their use of the Services, and/or payable as the result of using and/or exploiting any cryptoassets and interacting with smart contracts. Blockchain-based transactions are novel, and their tax treatment is uncertain. You are solely responsible for maintaining all relevant tax records and complying with any reporting requirements you may have as related to your use of the Interface and the Services. You are further solely responsible for independently maintaining the accuracy of any record submitted to any tax authority including any information derived from the Services and the Interface. **Indemnity** You agree to indemnify, defend, and hold harmless the Company Indemnified Parties from any claim or demand, including reasonable attorneys’ fees, made by any third party due to or arising out of: (a) your breach or alleged breach of these Terms; (b) anything you contribute to the Services; (c) your misuse of the Services, or any smart contract and/or script related thereto; (d) your violation of any laws, rules, regulations, codes, statutes, ordinances, or orders of any governmental or quasi-governmental authorities; (e) your violation of the rights of any third party, including any intellectual property right, publicity, confidentiality, property, or privacy right; (f) your use of a third-party product, service, and/or website; or (g) any misrepresentation made by you. We reserve the right to assume, at your expense, the exclusive defense and control of any matter subject to indemnification by you. You agree to cooperate with our defense of any claim. You will not in any event settle any claim without our prior written consent. **Amendment and Variation** These Terms may from time to time be updated or amended. We will post any such updates on the Interface or the Website. Such updated Terms as posted will take effect immediately unless otherwise indicated. You should regularly check the Interface to inform yourself of any such changes. In addition, we may at any time change, add or remove any feature or functionality of the Interface without prior notice. By continuing to use any Servicesafter any such changes have taken effect, you are indicating your acceptance of the updated or amended Terms. If you do not wish to be bound by any changes or amendments to these Terms then you should stop using the Services immediately. **Applicable Law** All matters relating to these Terms and any dispute or claim arising therefrom or related thereto (in each case, including non-contractual disputes or claims), shall be governed by and construed in accordance with the laws of the British Virgin Islands without giving effect to any choice or conflict of law provision or rule (whether of the British Virgin Islands or any other jurisdiction). **Arbitration Agreement and Waiver of Rights, Including Class Actions** PLEASE READ THIS SECTION CAREFULLY: IT MAY SIGNIFICANTLY AFFECT YOUR LEGAL RIGHTS, INCLUDING YOUR RIGHT TO FILE A LAWSUIT IN COURT AND TO HAVE A JURY HEAR YOUR CLAIMS. IT CONTAINS PROCEDURES FOR MANDATORY BINDING ARBITRATION AND A CLASS ACTION WAIVER. *Agreement to Attempt to Resolve Disputes Through Good Faith Negotiations* Prior to commencing any legal proceeding against us of any kind, including an arbitration as set forth below, you and we agree that we will attempt to resolve any dispute, claim, or controversy between us arising out of or relating to the Terms or the Services (each, a “Dispute” and, collectively, “Disputes”) by engaging in good faith negotiations. Such good faith negotiations require, at a minimum, that the aggrieved party provide a written notice to the other party specifying the nature and details of the Dispute. The party receiving such notice shall have thirty (30) days to respond to the notice. Within sixty (60) days after the aggrieved party sent the initial notice, the parties shall meet and confer in good faith by videoconference, or by telephone, to try to resolve the Dispute. If the parties are unable to resolve the Dispute within ninety (90) days after the aggrieved party sent the initial notice, the parties may agree to mediate their Dispute, or either party may submit the Dispute to arbitration as set forth below. *Agreement to Arbitrate* You and we agree that any Dispute that cannot be resolved through the procedures set forth above will be resolved through binding arbitration in accordance with the International Arbitration Rules of the International Centre for Dispute Resolution. The place of arbitration shall be the British Virgin Islands. The language of the arbitration shall be English. The arbitrator(s) shall have experience adjudicating matters involving Internet technology, software applications, financial transactions and, ideally, blockchain technology. The arbitrator’s award of damages must be consistent with limitations of liability set forth in these Terms, including the terms of the “Limitations on Liability” subsection of these Terms, as to the types and amounts of damages for which a party may be held liable. The prevailing party will be entitled to an award of their reasonable attorney’s fees and costs. Except as may be required by law, neither a party nor its representatives may disclose the existence, content, or results of any arbitration hereunder without the prior written consent of all parties. You agree that for any arbitration you initiate, you will pay the filing fee. For any arbitration we initiate, we will pay the filing fee. YOU ACKNOWLEDGE AND AGREE THAT YOU AND WE ARE EACH WAIVING THE RIGHT TO A TRIAL BY JURY OR TO PARTICIPATE AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS ACTION OR REPRESENTATIVE PROCEEDING. FURTHER, UNLESS BOTH YOU AND WE OTHERWISE AGREE IN WRITING, THE ARBITRATOR MAY NOT CONSOLIDATE MORE THAN ONE PERSON’S CLAIMS AND MAY NOT OTHERWISE PRESIDE OVER ANY FORM OF ANY CLASS OR REPRESENTATIVE PROCEEDING. Any Dispute must be filed within one (1) year after such claim arose; otherwise, the claim is permanently barred. *Changes* By rejecting any changes to these Terms, you agree that you will arbitrate any Dispute between you and us in accordance with the provisions of this section as of the date you first accepted these Terms (or accepted any subsequent changes to these Terms). *Judicial Actions* Any Dispute that is not arbitrable for any reason shall be instituted exclusively in the British Virgin Islands, although we retain the right to bring any suit, action or proceeding against you for breach of these Terms of Use in your country of residence or any other relevant country. You waive any and all objections to the exercise of jurisdiction over you by such courts and to venue in such courts. If you have not provided contact details to us, you agree that we may serve any notice or court documents on you to your wallet and you warrant and agree that this constitutes good service. *Severability* If any provision of the Terms is determined to be unlawful, void, or unenforceable, such provision shall nonetheless be enforceable to the fullest extent permitted by applicable law, and the unenforceable portion shall be deemed to be severed from the Terms. Such determination shall not affect the validity and enforceability of any other remaining provisions. *Assignment* The Terms may be assigned without your prior consent to any Company Indemnified Party, or to its successors in the interest of any business associated with the Services provided by us. You may not assign or transfer any rights or obligations under the Terms or any without our prior written consent. *Entire Agreement* These Terms and any policies or operating rules posted by us on the Services constitute the entire agreement and understanding between you and us and govern your use of the Services, superseding any prior or contemporaneous agreements, communications, and proposals, whether oral or written, between you and us (including, but not limited to, any prior versions of these Terms). Any failure by us to exercise or enforce any right or provision of any of the agreements set forth above (including, without limitation, these Terms) shall not constitute a waiver of such right or provision. \
# Privacy Policy Last modified: July 31, 2023 This privacy policy (the “Policy”) of Terminal 0 Ltd. (“Company” or “our” or "we" or “us”) describes how we and our affiliates collect, use, and disclose information, and your choices regarding this information. Please read this policy carefully and contact us with questions at \[TBD]. **Applicability of This Policy** This Policy applies to the Services (as defined in the Terms of Use (the "Terms")), including the Interface. If you do not agree with the terms of this Policy, do not access or use any Services. **What We Collect** When you interact with the Services, we may collect: * Contact information, such as your name, email address, physical address and country information. * Financial information, such as your Ethereum network address, cryptocurrency wallet information, transaction history, trading data and associated fees paid. * Transaction information, such as information about the transactions you make on our Services, such as the type of transaction, transaction amount, and timestamp. * Correspondence, such as your feedback, questionnaire and other survey responses, and information you provide to our support teams, including via our help chat or social media messaging channels. * Online identifiers, such as username, geo location or tracking details, browser fingerprint, operating system, browser name and version, and IP addresses. * Usage and diagnostics data, such as conversion events, user preferences, crash logs, device information and other data collected via cookies and similar technologies. * Information we get from others. We may get about you from other sources as required or as permitted by applicable law, including public databases. We may combine the information collected from these sources with the information we get from your use of Services in order to comply with our legal obligations and limit the use of our Services in connection with fraudulent or other illicit activities. * Information from cookies and other tracking technologies. We, and third parties we authorize, may use cookies, web beacons, and similar technologies to record your preferences, track the use of the Services, including our mobile applications, and collect information about the use of the Services, as well with other information we collect about you. You may choose to set your web browser to refuse cookies, or to alert you when cookies are being sent. If you do so, please note that some parts of the Services may not function properly. **How We Use Information** We use your information in accordance with your instructions, including any applicable terms in the Terms, and as required by applicable law. We may also use the information we collect for: * Providing Services and Features. We may use the information we collect to provide, personalize, maintain, and improve our products and Services. This includes using information to: 1. Operate, maintain, customize, measure, and improve Services, and manage our business; 2. Create and update user accounts; 3. Process transactions; 4. Send information, including confirmations, notices, updates, security alerts, and support and administrative messages; and 5. To create de-identified or aggregated data. * Safety and Security. We may use your information to help maintain the safety, security, and integrity of you and our Services, including to: 1. Protect, investigate, and deter against fraudulent, unauthorized, or illegal activity; 2. Monitor and verify identity or service access, combat spam, malware or security risks; 3. Perform internal operations necessary to provide Services, including to troubleshoot software bugs and operational problems; 4. Enforce our agreements with third parties, and address violations of Terms or agreements for other products or services; and 5. Comply with applicable security laws and regulations. * Customer Support. We may use information we collect to provide customer support, including to: 1. Direct questions to the appropriate customer support person; 2. Investigate and address user concerns; and 3. Monitor and improve our customer support responses and processes. * Research and Development. We may use the information we collect for testing, research, analysis, and product development to improve your experience. This helps us to improve and enhance the safety and security of Services, improve our ability to prevent the use of Services for illegal or improper purposes, and develop new features and products relating to Services.
* Direct Marketing. We may use the information we collect to market Services to you. This may include sending you communications about Services, features, promotions, surveys, news, updates, and events. If you do not want us to send you marketing communications, please unsubscribe using the link provided in such communications. Notwithstanding the above, we may use information that does not identify you (including information that has been aggregated or de-identified) for any purpose except as prohibited by applicable law. **How We Share and Disclose Information** We may share your information in the following circumstances: * With Your Consent. For example, you may let us share personal information with others for their own marketing uses. Those uses will be subiect to their privacy policies. * To Comply with Our Legal Obligations. We may share your information: (a) to cooperate with government investigations; (b) when we are compelled to do so by a subpoena, court order, or similar legal procedure; (c) when we believe in good faith that the disclosure of personal information is necessary to prevent harm to another person; (d) to report suspected illegal activity; or (e) to investigate violations of Terms, agreements for other products or services, or any other applicable policies. * With Professional Advisors. We share information with our professional advisors for purposes of audits and compliance with our legal obligations. * With Service Providers or Other Third Parties. We may share your information with service providers or other third parties who help facilitate business and compliance operations, such as marketing and technology services. * With Affiliates. We share information with our affiliates and related entities, including where they act as our service providers or for their own internal purposes. * During a Change to Our Business. If we engage in a merger, acquisition, bankruptcy, dissolution, reorganization, sale of some or all of our assets or stock, financing, public offering of securities, acquisition of all or a portion of our business, a similar transaction or proceeding, or steps in contemplation of such activities, some or all of your information may be shared or transferred, subject to standard confidentiality arrangements. * Aggregated or De-identified Data. We may share aggregated or anonymized data with other persons for their own uses. **Data Retention** To view or update your information, contact us at . We store your information throughout the life of your use of Services and thereafter. **Security** We maintain administrative, technical and physical safeguards designed to protect the personal information we maintain against unauthorized access or disclosure and require our third-party service providers to have appropriate safeguards. No system can be completely secure. Therefore, although we take steps to secure your information, we cannot guarantee that your information, searches, or other communication will remain secure against unauthorized access or disclosure. You are responsible for all use of Services relating to any of your Ethereum network addresses or cryptocurrency wallets. **Age Limitations** We do not allow use of Services by anyone younger than 18 years old. If you learn that anyone younger than 18 years old has unlawfully provided us with personal data, please contact us at and we will takes steps to delete such information, close any such accounts, and, to the extent possible, prevent the user from continuing to use Services. **Changes to This Policy** If we make any changes, we will change the Last Updated date above. We encourage you to review this Policy to stay informed. **Online Tracking Opt-Out Guide** Like many companies online, we may use services provided by companies that use tracking technology. These services rely on tracking technologies—such as cookies and web beacons—to collect directly from your device information about your browsing activities, your interactions with websites, and the device you are using to connect to the Internet. There are a number of ways to opt out of having your online activity and device data collected through these services, which we have summarized below: * Blocking cookies in your browser. Most browsers let you remove or reject cookies, including cookies used for internet-based advertising. To do this, follow the instructions in your browser settings. Many browsers accept cookies by default until you change your settings. For more information about cookies, including how to see what cookies have been set on your device and how to manage and delete them, visit [www.allaboutcookies.org](http://www.allaboutcookies.org). * Blocking advertising ID use in your mobile settings. Your mobile device settings may provide functionality to limit use of the advertising ID associated with your mobile device for interest-based advertising purposes. * Using privacy plug-ins or browsers. You can block our websites from setting cookies used for interest-based ads by using a browser with privacy features, like Brave, or installing browser plugins like Privacy Badger, Ghostery or uBlock Origin, and configuring them to block third-party cookies or trackers. * Platform opt-outs. The following advertising partner offers opt-out features that let you opt-out of use of your information for interest—based advertising: * Google: * Advertising industry opt-out tools. You can also use the opt-out options set forth below to limit use of your information for interest-based advertising by participating companies. Note that because these opt-out mechanisms are specific to the device or browser on which they are exercised, you will need to opt out on every browser and device that you use. * Digital Advertising Alliance: * Network Advertising Initiative: **Additional Disclosures for Data Subjects in the European Economic Area and the United Kingdom** A. Roles. The General Data Protection Regulations in the European Economic Area and the United Kingdom (“GDPR”) distinguish between organizations that process personal data for their own purposes (known as “controllers”) and organizations that process personal data on behalf of other organizations (known as “processors”). We act as a controller with respect to personal data collected as you interact with the Services. B. Lawful Basis for Processing. The GDPR requires a “lawful basis” for processing personal data. Our lawful bases include where: (i) you have given consent to the processing for one or more specific purposes, either to us or to our service providers or partners; (ii) processing is necessary for the performance of a contract with you; (iii) processing is necessary for compliance with a legal obligation; or (iv) processing is necessary for the purposes of the legitimate interests pursued by us or a third party, and your interests and fundamental rights and freedoms do not override those interests. Where applicable, we will transfer your personal data to third parties subject to appropriate or suitable safeguards, such as standard contractual clauses. C. Your Data Subject Rights If you are a user in the European Economic Area or the United Kingdom, you maintain certain rights under the GDPR. These rights include the right to (i) request access and obtain a copy of your personal data; (ii) request rectification or erasure of your personal data; (iii) object to or restrict the processing of your personal data; and (iv) request portability of your personal data. Additionally, if we have collected and processed your personal data with your consent, you have the right to withdraw your consent at any time. Notwithstanding the foregoing, we cannot edit or delete information that is stored on a particular blockchain. This information may include transaction data (i.e., purchases, sales, and transfers) related to your blockchain wallet address and any NFTs held by your wallet address. To exercise any of these rights, please contact us via . We will respond to your request within thirty (30) days. We may require specific information from you to help us confirm your identity and process your request. Please note that we retain information as necessary to fulfill the purpose for which it was collected and may continue to retain and use information even after a data subject request in accordance with our legitimate interests, including as necessary to comply with our legal obligations, resolve disputes, prevent fraud, and enforce our agreements. If you have any issues with our compliance, please contact us as set out in the “Contact Us” section above. You also reserve the right to lodge a complaint with the data protection regulator in your jurisdiction. Additional Disclosures for California Residents These additional disclosures apply only to California residents. The California Consumer Privacy Act of 2018 (“CCPA”) provides additional rights to know, delete, and opt-out, and requires businesses collecting or disclosing personal information to provide notices and the means to exercise consumer rights. A. Notice of Collection. We collect the following categories of personal information enumerated in the CCPA: * Internet activity, including information on visitors to the Website and their interactions with the Services. * Geolocation data of Website visitors. For further details on the information we may collect, including the sources from which we receive information, review the “What We Collect” section above. We may collect and use these categories of personal information for the business purposes described in the “Use of Information” section above, including to manage the Services. We do not “sell” personal information as defined under the CCPA. Please review the “How We Use Information” section above for further details about the categories of parties with whom we share information. B. Right to Know and Delete. You have the right to know certain details about our data practices within the past twelve (12) months. In particular, you may request the following from us * The categories of personal information we have collected about you. * The categories of sources from which the personal information was collected; * The categories of personal information about you we disclosed for a business purpose; * The categories of third parties to whom the personal information was disclosed for a business purpose; * The business or commercial purpose for collecting or selling the personal information; and * The specific pieces of personal information we have collected about you In addition, you have the right to delete the personal information we have collected from you. To exercise any of these rights, please submit a request by emailing us at . In the request, please specify which right you are seeking to exercise and the scope of the request. We will confirm receipt of your request within ten (10) days. We may require specific information from you to help us verify your identity and process your request. If we are unable to verify your identity, we may deny your requests to know or delete. C. Authorized Agent. You may designate an authorized agent to submit requests on your behalf; however, we may require written proof of the agent’s permission to act on your behalf and verify your identity directly D. Right of Non-Discrimination. You have a right of non-discrimination for the exercise of any of your privacy rights guaranteed by law, such as the right to access, delete, or opt-out of the sale of your personal information. E. Shine the Light. Residents of California who are permitted users of Services may request (i) a list of the categories of personal information disclosed by us to third parties during the immediately preceding calendar year for those third parties’ own direct marketing purposes; and (ii) a list of the categories of third parties to whom we disclosed such information. To exercise a request, please write to us at the email above and specify that you are making a “California Shine the Light Request.” We may require additional information from you to allow us to verify your identity and are only required to respond to requests once per calendar year. Additional Disclosures Regarding the Interface This section governs our collection, use, and sharing of personal information provided by users of the Interface. To the extent there are conflicting provisions between this section and other sections of this Policy, this section will govern. The types of personal information we collect and share can include: * Cryptoasset balances and wallets * IP addresses * Transaction history Notwithstanding anything to the contrary in this Policy, when you are no Ionger a user of Services, we continue to share your information as described in this section. Reasons We Can Share Your Personal Information We need to share users’ personal information to operate certain aspects of our business. Whether we share your personal information, the reasons for which we share your personal information, and whether you can limit this sharing include the following: * We share users’ personal information for our everyday business purposes, such as to respond to court orders and legal investigations. You cannot limit our sharing of this information. * We share users’ personal information for our marketing purposes, such as to offer Services to you. You cannot limit our sharing of this information. * We do not share users’ personal information for joint marketing with financial companies. * We do not share users’ personal information for our affiliates’ everyday business purposes. * We do not share users’ personal information for our affiliates to market to you. * We share users’ personal information for nonaffiliates to market to you. Contact Us If you have any questions or comments about this Policy, our data practices, or our compliance with applicable law, please contact us: By email: ****