# Tenderize - Liquid Staking 2.0

Tenderize brings an end-to-end Liquid Staking and DeFi solution to various PoS networks, creating better ways for you to stake and earn yield.

<figure><img src="/files/hyPpeUZ3FOoNho18CMqN" alt=""><figcaption></figcaption></figure>

## What is Tenderize?

Tenderize isn't just another liquid staking project. It is \*THE\* liquidity ecosystem for staked assets and features a variety of products.&#x20;

* **Liquid Delegation:** Liquid stake with the validators you trust and prefer at **zero fees.** This is ideal for advances users  and institutionswanting to decide their own allocation strategies and who possess the time and tools to effectively to monitor validator performance. Developers can easily combine these single-validator LSTs into new multi-validator staking pools.
* **TenderTokens**: Staking pools that automatically stake and rebalance across multiple high performing validators curated by the Tenderize protocol and $WAGYU governance. The bread-and-butter liquid staking tokens for user seeking easy accessible staking yields and DeFi strategies.
* **TenderSwap**: The liquidity layer that makes this all possible. Instantly unstake your LSTs for a small fee, no more unstaking periods ! It is a novel decentralised exchange, specifically tailored for LSTs and LRTs, that unifies liquidity for various derivatives of the same base token,&#x20;
* BeefyBank: Borrow stablecoins using your TenderTokens or Liquid Delegations as collateral. Lenders can supply stablecoins and earn a combined interest rate from various LST markets, creating attractive yields.&#x20;

<figure><img src="/files/gCM4rqXmI3ch483MPBDZ" alt=""><figcaption></figcaption></figure>

### Why Tenderize?

* **Validator Choice**: Stake with validators you trust while maintaining liquidity
* **Enhanced Liquidity**: Use tTokens across DeFi while earning staking rewards
* **True Decentralization**: Permissionless access for validators and delegators
* **Capital Efficiency**: Reduced fragmentation through shared liquidity pools

With Tenderize the diversity and decentralisation of liquid staking is ensured. Together we create a better liquid staking ecosystem

<figure><img src="/files/Ap4mSWWyM1F2YMaY72pR" alt=""><figcaption></figcaption></figure>

### Supported Networks

Currently, Tenderize supports staking for:

* MATIC (Polygon)
* GRT (The Graph)
* LPT (Livepeer)
* SEI (Sei Network)\
  \
  **Coming soon**: Hyperliquid, Bittensor, Binance Chain

TenderSwap is currently live for&#x20;

* ETH (<https://lpeth.xyz>)
* MATIC (Polygon)
* GRT (The Graph)
* LPT (Livepeer)
* SEI (Sei Network)\
  \
  **Coming soon**: Hyperliquid, Bittensor, Binance Chain


# Liquid Delegation

**Liquid Delegations** are liquid staked tokens that represent your staked position with a specific validator. Think of them as extension of the native staking experience, you retain the freedom to pick and choose your validators of choice, but as a liquid staking experience instead..

### How Liquid Delegations Work

#### Minting Liquid Delegations

* When you stake assets (e.g., MATIC, GRT, or LPT), Tenderize mints an LST at a 1:1 ratio
* Each of these LSTs is specific to your chosen validator (e.g., tMATIC-ValidatorA)
* The amount of LSTs you receive corresponds to your staked amount

#### Validator Relationship

* Each validator specific LST maintains transparency about its associated validator
* You can track validator performance and rewards directly
* Validator-specific risks and rewards are reflected in the LSTs.

#### Reward Accrual

* Staking rewards automatically increase the value of your LSTs.
* Your LST balance grows with your staking rewards, making rewards very intuitive.

#### Instant unstaking & DeFi Integration

LSTs can be instantly unstaked for a small fee using [TenderSwap](/introduction/tenderswap-efficient-lst-liquidity).&#x20;

They could also be used across various DeFi applications:

* As collateral in lending protocols
* In yield farming strategies
* For trading on decentralized exchanges
* In liquidity pools

<figure><img src="/files/gXtbT66op8BWUy8AstuA" alt=""><figcaption></figcaption></figure>


# Tender Tokens

**Tender Tokens** are liquid staked tokens that automatically stake to a diverse set of high-performing validators, managed and curated by the Tenderize protocol and $WAGYU token holders. They allow users to easily stake and diversify without having to keep track of validator performance. \
\
Tender Tokens take into account network health and have rules to ensure healthy stake distribution across PoS networks. The rebalancing happens automatically on a smart contract level. New deposits are staked to the most underallocated validators, while withdrawals are processed from the most overallocated validators.

Similar to Liquid Delegations, Tender Tokens can still be unstaked regularly at no fee while waiting for the unstaking period of the underlying PoS network. But you can also instantly unstake them for a small fee. \
\
**A major difference** with liquid delegations is that Tender Tokens are **non-rebasing**, and instead use a floating exchange rate to indicate how much tokens the LST is worth (e.g. 1 tLPT = 1.20 LPT).\
\
These new LSTs are a perfect example of composability, creating a staking pool that uses various [Liquid Delegations](/introduction/liquid-delegation) under the hood with a set of allocation rules. Theoretically, anyone can create Tender Tokens with their own composition and rules, as the Tenderize protocol is fulle open for anyone to build on.<br>

<figure><img src="/files/XoYATVnk09dR4BNvDbac" alt=""><figcaption></figcaption></figure>


# TenderSwap - Efficient LST Liquidity

TenderSwap is Tenderize’s decentralized exchange tailored for liquid staked tokens (LSTs). By leveraging a shared liquidity model, it optimizes liquidity for validator-specific tTokens while reducing capital inefficiencies.

### **Why TenderSwap?**

1. **Shared Liquidity Pools:**
   * Unlike traditional DEXs like Uniswap or Curve, TenderSwap consolidates liquidity for homogenous assets.
   * All tTokens for the same underlying asset (e.g., tLPT) share a single pool, enabling efficient swaps and eliminating liquidity fragmentation.
2. **Capital Efficiency:**
   * No separate liquidity provision is required for new tTokens.
   * New tTokens automatically use the existing pool, ensuring instant liquidity without additional capital.
3. **Low Slippage and Dynamic Fees:**
   * Swaps incur fees that adjust dynamically based on pool utilization and specific tToken demand, ensuring fair access and incentivizing balanced liquidity.
4. **Applications Beyond Tenderize:**
   * **Staking Service Providers:** Offer liquid staking without managing liquidity in-house.
   * **Solo Stakers:** Gain liquidity or lend staked assets while continuing to validate networks.
   * **Indexes and ETFs:** Easily rebalance or sell individual tTokens.
   * **Borrowing and Lending Protocols:** Use TenderSwap’s deep liquidity for routing and liquidations.

### **Comparison to Traditional DEXs:**

* **Uniswap/Curve Challenges:**
  * Require separate pools for each LST, leading to inefficiencies and fragmented liquidity.
  * Capital is locked in pools instead of being used productively elsewhere.
* **TenderSwap Solution:**
  * Shares liquidity across all like-assets, maximizing efficiency and decentralization while reducing costs for users.

### **Expanding Beyond Tenderize LSTs:**

TenderSwap’s innovative liquidity model can also support protocol-specific LSTs beyond Tenderize, fostering a broader ecosystem for liquid staking.

The Tenderize team has brought this novel approach to Ethereum with lpETH.&#x20;

<figure><img src="/files/rdMhyqAPEjOA2EZSPkLm" alt=""><figcaption></figcaption></figure>

{% embed url="<https://www.lpeth.xyz/>" %}

<figure><img src="/files/Vn5acnfuNAfyFSoShAPX" alt=""><figcaption></figcaption></figure>


# BeefyBank (soon)

Borrow stablecoins using your TenderTokens or Liquid Delegations as collateral

BeefyBank is Tenderize’s native lending market purpose-built for liquid staking tokens (LSTs). Lenders supply stable liquidity to earn competitive, utilization-driven yields, while borrowers unlock working capital against their Tenderize collateral with transparent costs and predictable access. The system is anchored by robust oracle design, conservative risk parameters, and permissionless liquidations that minimize bad debt and keep markets healthy.

\
For Tenderize’s multi-validator LSTs, BeefyBank isolates risk by asset while concentrating liquidity for efficient price discovery. Each market carries its own caps, collateral factors, and interest curves, enabling fine-grained risk control without sacrificing capital efficiency. The result is deep, programmatic liquidity for high-quality borrowing demand and consistently attractive returns for liquidity providers.<br>

BeefyBank also supports borrowing for Tenderize’s single-validator LSTs through a unified market shared across all single-validator assets. This shared market inherits a common set of parameters and a global cap, while each single-validator LST accrues its own interest-rate spread that adjusts with its relative utilization of the pool (and naturally accounts for LST size). It mirrors TenderSwap’s pricing—combining a base fee with a per-LST spread—so rates reflect validator-specific demand without fragmenting liquidity.<br>

This shared-liquidity plus per-LST spread model delivers the best of both worlds: pooled depth for superior execution and capital efficiency, with precise pricing that internalizes validator-level risk and demand. Long-tail validators gain access to meaningful liquidity, larger validators scale naturally, and depositors capture diversified yield streams—all within a safety-first architecture.


# Liquid Delegation

#### Overview

Liquid Delegations are ERC-20 compliant Liquid Staked Tokens (LSTs) implementing an elastic supply model that automatically reflects staking positions and rewards. Each liquid delegation represents a stake with a specific validator, creating a direct relationship between token holders and validator performance.

#### Technical Implementation

Liquid Delegations utilize an elastic supply model that automatically adjusts to reflect changes in the underlying staking position. The supply increases as staking rewards accumulate and decreases in response to slashing events or when users unstake their positions. This dynamic supply mechanism ensures transparent and automatic reward distribution among all token holders.

#### Price Mechanics

One of the key innovations of liquid delegations is their ability to maintain natural price parity with their underlying assets. This is achieved through arbitrage mechanisms and direct unstaking capabilities, eliminating the need for complex price oracles, external price feeds, or specialized pricing mechanisms in DeFi integrations.

#### Practical Example

Consider a user staking 100 LPT tokens to validator Alice. Initially, they receive 100 tLPT-Alice tokens in return. As their chosen validator earns rewards, their tLPT-Alice balance automatically reflects these earnings. If the validator earns 10% in rewards, the user's 100 tLPT-Alice becomes redeemable for 110 LPT, without any manual claim process.

### Delegation Architecture

#### Delegation Vaults

At the heart of Tenderize's architecture are delegation vaults, unique to each validator on the network. These vaults serve as sophisticated staking proxies, maintaining separate accounting for each validator while managing the issuance and burning of validator-specific liquid delegation tokens.

#### Operational Flow

The staking process begins when a user deposits tokens into a delegation vault, which mints equivalent liquid delegations and delegates the stake to their specified validator. For unstaking, users burn their liquid delegations, triggering the delegation vault to initiate the unstaking process and issue an NFT receipt for the future claim.

#### NFT-Based Unstaking Claims

Tenderize implements an innovative NFT-based system for unstaking claims using the ERC-721 standard. These NFTs represent unstaking positions during the lockup period and contain crucial information about maturity dates and amounts. Users can transfer or trade these NFTs on secondary markets, providing liquidity options during the unstaking period.

### Risk Factors

#### Validator-Related Risks

Validator performance directly impacts corresponding liquid delegations, with slashing events and commission changes reflected in token value. The protocol actively monitors validator behavior and notifies users of significant changes or events that might affect their staked positions.

#### Technical Risks

While smart contract risk is inherent in any blockchain protocol, Tenderize prioritizes security through comprehensive audits, open-source code, and continuous monitoring. The protocol's use of standard ERC-20 and ERC-721 implementations helps minimize integration risks.\
\
The Tenderize protocol is audited by Halborn And Trust Audits.

### Security Measures

#### Protocol Safety

Security stands as a cornerstone of the Tenderize protocol, maintained through regular audits, open-source code verification, and transparent operations. The protocol employs continuous monitoring systems to ensure early detection of any anomalies.

#### User Protection

Tenderize implements comprehensive user protection measures, including automated notifications for slashing events and commission changes. The protocol maintains transparent validator metrics and provides clear documentation of all associated risks, ensuring users can make informed decisions about their staking positions.


# Technical documentation

Technical documentation for TenderTokens

### Liquid Delegation Implementation

#### Overview

Liquid Delegation Tokens (LDTs) are elastic supply ERC-20 tokens that represent staked positions with specific validators. They implement both standard ERC-20 functionality and EIP-2612 for permits, with additional features for handling staking rewards and slashing events.

***

### Core Functions

**Staking**&#x20;

```solidity
function deposit(address receiver, uint256 assets) external returns (uint256)
```

* **Purpose:** Deposits assets and mints tTokens.
* **Returns:** Amount of tTokens minted.
* **Additional Details:** Triggers a rebase before the operation.

**Unstaking**&#x20;

```solidity
unlock(uint256 assets) external returns (uint256 unlockID)
```

* **Purpose:** Initiates the unstaking process.
* **Details:**
  * Burns tTokens.
  * Creates an unlock position.
* **Returns:** Unique unlock identifier.

**Withdraw**

```solidity
withdraw(address receiver, uint256 unlockID) external returns (uint256 amount)
```

* **Purpose:** Completes the unstaking process.
* **Details:**
  * Transfers underlying assets to the specified receiver.
  * Requires the unlock position to mature.

**Conversion Functions**

```solidity
convertToAssets(uint256 shares) public view returns (uint256)
function convertToShares(uint256 assets) public view returns (uint256)
```

* **Purpose:** Handle conversion between shares (tTokens) and assets (underlying tokens).
* **Details:** Accounts for changes in the elastic supply.

***

### Integration Guide **For DeFi Protocols**

**Token Implementation**

* Implements the standard ERC-20 interface.
* Includes an additional rebase mechanism.
* Use `convertToAssets()` for accurate balance calculations.

**Handling Rebases**

* Rebases occur automatically before token transfers.
* External calls should account for supply changes.
* Monitor `Rebase` events for updates to supply.

**Safety Considerations**

* Always check return values for all operations.
* Account for potential slashing events that may affect balances.
* Handle failed operations gracefully to ensure robust integrations.


# White paper

Homogenous Liquidity for LSTs

### Introduction

TenderSwap is a cost-effective, **application-specific DEX** that offers instant liquidity for holders of Tenderize’s liquid staked tokens (tTokens). It is designed specifically to be a capital-efficient liquidity pool for homogenous liquid staked assets, like tToken LSTs. TenderSwap uses a novel **shared liquidity design** to enable low slippage with low capital requirements.

Upon exchange of a tToken LST, the user will receive an equivalent amount of the underlying assets, minus a fee based on both the current utilisation of total liquidity, as well as the amount of outstanding liquidity usage for a specific tToken.

TenderSwap is designed to efficiently share liquidity in a fair, efficient way for an underlying asset between various tTokens representing it. Charging an increasingly higher fee when utilisation increases and/or one specific tToken sees a lot of volume in a short period of time.

### **Instant Liquidity**

Since liquidity is shared between similar-asset tTokens, newly created tTokens **don’t require separate liquidity provision**. New tTokens use already existing liquidity in Tenderswap, allowing for Tenderize users to enjoy liquidity without capital requirements for new tTokens.

* **Staking Service Providers**: Offer liquid staking to your clients without worrying about in-house liquidity management or on-chain liquidity financing.
* **Solo Stakers:** Continue validating the network from home while enjoying exit liquidity or lending of your stake.
* **Index/ETF Products**: Deep liquidity for selling individual tTokens in an index, for rebalancing.
* **Borrowing**/**Lending Protocols**: Deep on-chain liquidity for tToken routing/liquidations.

While Uniswap and Curve have both revolutionized the world of finance, neither are optimized specifically for LSTs. Tenderize’s shared liquidity approach works thanks to the homogenous nature of liquid staked derivatives. Each tToken can be unstaked, each of the tTokens can then be treated as a the same asset, sharing one liquidity pool.

When using Uniswap, each LSD requires its own liquidity pool, which is comprised of 50% LSD and 50% liquid, unstaked counterpart. This introduces three problems:

* **Inefficient Capital Allocation**: By having to incentivize both staked assets and unstaked assets in a pool, capital is stuck in the pool which could be utilized elsewhere.
* **Liquidity Fragmentation:** Without the ability to share one liquidity pool, traders end up paying more money for swaps due to the inability to access idle capital in like-asset pools.
* **Centralization**: As DeFi builders adopt the most liquid product, this funnels stake to the preferred validator cartel of that liquid staked product’s team/community.

TenderSwaps’s shared-liquidity approach can be the most liquid solution on the market while eliminating capital requirements for new tTokens. Ultimately this approach isn’t confined to Tenderize’s tTokens and could also be used by protocol enshrined LSTs to have liquidity.<br>

<figure><img src="/files/GsXH1Qihh0rTWFIwEH5m" alt=""><figcaption></figcaption></figure>

### Glossary

* **LST**: Liquid Staked Token
* **Underlying asset**: tokens used in staking protocols (e.g. ETH, LPT, GRT, MATIC, …), representing the original asset
* **tTokens**: tenderize’s validator specific LSTs. One underlying asset can have multiple tTokens representing assets staked towards different validators
* **Unlock NFT**: a receipt as ERC-721 token, representing an amount tTokens that have been unlocked and are being unstaked
* **Maturity**: time at which an unlock NFT can be withdrawn

### Participants

* **tTokens holders** looking to exchange their LSTs for the underlying asset instantly, at the cost of a dynamic fee based on the amount of available liquidity
* **Liquidity providers (LPs)** looking to provide liquidity in the form of the underlying asset in exchange for a portion of the fees charged by the protocol
* **Sophisticated traders** looking to purchase unlock NFTs for a discount based on the fee paid and the time to maturity of the unlock
* **Relayers** processing unlocks that have reached maturity in return for a redemption reward, in order to replenish the assets in the pool with available unlocks

### Overview

When exchanging tTokens, users receive an equivalent amount of the underlying asset minus a fee based on the available liquidity versus the total liquidity, expressed as assets (cash on hand) and liabilities (what is owed to LPs).

Upon receiving the tTokens, the protocol will unlock them, starting a timer until they become available for withdrawal. This timer is based upon the thawing period in the underlying’s token own staking system. The unlock receipt, represented as an NFT, is held in the TenderSwap’s inventory until maturity.

<figure><img src="/files/W0y5Zov5nT8vErxv5x9K" alt=""><figcaption></figcaption></figure>

**Time-Risk Arbitrage**

Up until maturity is reached, market actors can purchase these unlock NFTs at a discount based on the slippage fee charged. The discount decays linearly to 0 as time to maturity approaches. By doing this these actors instantly replenish the capital in the pool for an additional bonus, but take on the effective time-risk remaining for the unlock. Unlock NFTs available for purchase are arranged according to the First In, Last Out (FIFO) principle. Since these should normally have the highest relative payout. Under normal utilisation of the liquidity, it’s unlikely the rates offered would be sufficient for a market maker to take on the risk. However should utilisation, and thus fees, rapidly increase the rates offered to instantly replenish capital would be attractive enough to prevent liquidity crunches.

<figure><img src="/files/m1WUx0sAb0QIt8XMQah1" alt=""><figcaption></figcaption></figure>

**Relayer Redemptions**

Once time to maturity has been reached a redemption reward is given to any actor redeeming the unlock NFT on behalf of the protocol, withdrawing the unlocked tokens and replenishing the pool. Unlocks at maturity are ordered according to the First in, First out principle. This ensures that each unlock is withdrawn and not only unlocks that are most profitable, though in practice every redemption should be profitable.

<figure><img src="/files/DeVwnDZ19R62qFMOjXGQ" alt=""><figcaption></figcaption></figure>

### Unlock Queue

The list of unlocks is implemented as an expandable data structure, called a *double-ended queue* or ***deque*** in short. This data type combines methods from a conventional queue and stack.

Stacks and queues are similar types of data structures used to temporarily hold data items (elements) until needed. When elements are needed, they are removed from the top of the data structure. The basic difference between a stack and a queue is where elements are added, elements are added to the top of a stack and to the bottom of a queue.

Using a deque elements can be removed from either the front or back, and it can easily be appended to. The queue will be ordered by time to maturity, where the front of the list are older items, and thus closer to maturity.

* Relayers can only take Unlocks from the front of the deque, if they have reached maturity
* Market makers can only take Unlocks from the back of the dequeue, if they haven’t reached maturity

Using multiple unlocks in batches is allowed for both user types, but only when sequentially traversing the list of unlocks starting from their respective starting point (front or back).

<figure><img src="/files/uSYWCR5PWD5X1r4ckxeo" alt=""><figcaption></figcaption></figure>

### TenderSwap Model

TenderSwap is not a traditional AMM where token exchange and pricing occurs based on an invariant curve mapping the relation between two assets. Instead, TenderSwap acts more like a fractional reserve. Where exchange of homogenous assets occurs at a 1:1 price, but a fee is charged depending on the amount of utilised one-sided liquidity.

Utilisation of liquidity can be seen as a **stochastic process** where two types of events can occur:

* **Exchange event**: a user exchanges tTokens for the underlying asset
* **Redemption event**: An Unlock NFT is either bought by a market maker, or redeemed by a relayer after maturity

An exchange event at time $$t$$, will increase the utilisation of the liquidity compared to the last event at $$t-1$$, increase the fee charged. A redemption event at time $$t$$, will decrease the utilisation of the liquidity compared to the last event at $$t-1$$, decreasing the fee for future exchange events.

<figure><img src="/files/1EvHCElXTAlwm7RJVYs4" alt=""><figcaption></figcaption></figure>

#### Utilisation Rate

The utilisation rate measures the current general amount of liquidity used, i.e. pending withdrawal, versus the total amount of liquidity available. In the system this is represented as total unlocks $$U$$, divided by liabilities (what is owed to LPs) $$L$$, giving us the general utilisation rate $$r$$ as a number between 0 and 1.

$$r \in \[0,1] = \frac{U}{L} \rightarrow U \leq L$$

#### Utilisation Spread

Each tToken has its own utilisation spread based on the amount of withdrawals it has outstanding versus its supply, the resulting value is then normalised against the pool average to acquire a relative weight. This spread acts as an amplifier to the utilisation fee when one particular tToken sees a lot of sale volume in a short period of time.

We must first calculate the denormalised weight for a token $$i$$ by dividing the amount of unlocks it is using $$u\_i$$ by its supply $$s\_i$$. We can then normalise the resulting values by dividing it by the average of all tokens with outstanding unlocks.

$$w\_i = \frac{u\_i}{s\_i + u\_i} \times \frac{\sum\_{j=1}^{n} s\_j + u\_j }{\sum\_{j=1}^{n} u\_j}$$

The final result is a relative weight that takes into account both the number of withdrawals pending for a specific tToken and the supply of the specific tToken. This relative weight can be used to determine how much of a fee a specific tToken should be charged when it is redeemed.

#### Fee Model

The utilisation fee for a particular tToken is based upon its utilisation spread and the current general utilisation.

**Base Fee**

A base fee of 5 basis points (0.05%) is charged on every exchange to ensure that there is a minimum incentive for redemptions of unlocks to take place.

**Utilisation Fee**

We want the utilisation fee to be low when utilisation is low, and rapidly increase when utilisation is very high and might result in a liquidity crunch. To achieve this we express the fee $$f(r)$$ as a polynomial in function of the utilisation rate $$r$$, resulting in a ratio. between 0 and 1.

$$f(r) = {r^k} \rightarrow r^k \in \[0,1]$$

<figure><img src="/files/2lnPq4zVV3Ut7QKLCPaY" alt=""><figcaption></figcaption></figure>

**Spread**

A  $$i$$ has a spread $$w\_i$$, which is a relative weight based on its liquidity usage versus the average liquidity usage for all tTokens. This weight acts as a multiplier on the base fee. tTokens with a high impact on liquidity will pay significantly more than the base fee, while tTokens with a small impact compared to their relative size will pay less.

**Marginal Fee**

To calculate the marginal fee, we look at the amount, the weight after the hypothetical trade and the ratio after the trade.

If an amount of $$x$$ is swapped for a tToken $$i$$, the weight $$w\_i$$ and ratio $$r$$ after the swap would be

$$w\_i = \frac{u\_i + x}{s\_i - x + u\_i +x} \cdot \frac{x - x + \sum\_{j=1}^n (s\_j + u\_j)}{x + \sum\_{j=1}^n u\_j} = \frac{u\_i + x}{s\_i + u\_i} \cdot \frac{U+S}{U+x}$$

$$\r\_i = \left(\frac{x + \sum\_{j=1} u\_j}{L}\right)^k = \left(\frac{U+x}{L}\right)^k$$

This motivates us to define the main fee function as follows

$$f(x) = x \cdot \frac{u\_i + x}{s\_i + u\_i} \cdot \frac{U+S}{U+x} \cdot \left(\frac{U+x}{L}\right)^k$$

This is not our final formula however to calculate the fee, as there is an issue. When swapping an amount $$x$$ the user pays $$f(x) = y$$ fees. However,  if the user were to partition the swapped amount $$x$$ into multiple swaps $$x\_1, x\_2, \dots, x\_n$$, such that $$x\_1 + x\_2 + \dots + x\_n = x$$, then it's often true that the sum of the resulting fees $$f\_1(x\_1) = y\_1, f\_2(x\_2) = y\_2, \dots, f\_n(x\_n) = y\_n$$would be lower $$(y\_1 + y\_2 + \dots + y\_n < y$$ ) than if the swap were not partioned.&#x20;

It always holds that $$y\_1 + y\_2 + \dots + y\_n \leq y$$, a fact that is proven in the yellow paper, given the constrictions of the parameters:

$$0 \leq x \leq \min(s\_i, L-U)\0\leq s \leq S\ 0 \leq u \leq U\ 0 \leq L$$

Also, note the subscript of $$f$$. This is done, because after unlocking an amount of $$x\_1$$, $$u\_i$$ and $$s\_i$$ will change, and hence the fee function changes.

Below is an example illustrating this behaviour, as well as our solution to make sure that $$(y\_1 + y\_2 + \dots + y\_n = y$$. Let the system state have the following parameters

$$u\_i=10, s\_i=30,U=90, S=200,L=200,k=2$$

A user comes in and swaps 10 tokens ($$x=10$$). For this swap the fee paid is $$f(x) = 3.625$$

If the user were to partition this swap into $$x\_1=2$$ and  $$x\_2=8$$, the fee would be lower and instead be $$f\_1(2) + f\_2(8) \approx 3.3$$

If we change the order the swap is partitioned in, the resulting fee will be even lower $$f\_1(8)+f\_2(2) \approx 3.2828$$

This requires us to create a function which conceptually would express what the least amount of fee paid by a user, regardless of if and how a swap is partitioned. This brings us to the partitioned fee function, which forms the lower bound of every possible way of partitioning a swap. The partitioned fee function is found to be:

$$\phi(x) = \frac{(S+U) \cdot \left(\left((u+x)\cdot k - U + u\right)\cdot\left(\frac{U+x}{L}\right)^k-\left(u \cdot k - U + u\right)\cdot\left(\frac{U}{L}\right)^k\right)}{k \cdot (k+1) \cdot (u+s)}$$

The derivation of this formula is far from trivial and outside of the scope of this paper. If one is interested in the derivation, and the proof that this function forms the lower bound of all possible partitions, please refer to the yellow paper.

Using this function in our example, we can indeed see that:

$$\phi(10) = \phi\_1(8) + \phi\_2(2) = \phi\_1(2)+\phi\_2(8) \approx 2.598$$

Even though this is only one example, in the yellow paper it is proven that regardless of how a swap is partitioned, the result for the sum of parts will always be equal to the whole. Analogous, the following example yields an identical result as well:

$$\phi\_1(1)+\phi\_2(2)+\phi\_3(3)+\phi\_4(4) = \phi\_1(4)+\phi\_2(3)+\phi\_3(2)+\phi\_4(1) \approx 2.598$$

That concludes our motivation to choose the partitioned fee function, $$\phi$$, as the fee function that is used in Tenderswap.

### Fee Distribution

Fee distribution is flexible, and are redistributed to incentives where they are most needed. Fees charged for utilisation for a pool are handled two ways depending on whether an unlock has reached maturity.

Under normal operations, when liquidity utilisation is considered healthy, the bulk of the fees is distributed to liquidity providers and relayers (for processing withdrawals). The protocol could also retain a portion of the fees to create additional ecosystem incentives, or build up a treasury of protocol owned liquidity.

However under high load, the fee charged for an exchange is used as an incentive for sophisticated traders or market makers to purchase the unlock NFT created during the exchange. Hereby market makers take over the time risk until maturity from the protocol, in return for instantly replenishing the underlying assets that would otherwise be replenished at maturity. Since risk decreases as time to maturity decreases, the possible reward linearly decreases to 0 as it approaches. The remainder of the reward not paid out is then distributed to liquidity providers. The possible reward at any point in time $$t$$, is calculated by multiplying the original fee by the decay rate $$d(t)$$ at point $$t$$.

$$reward(t) = fee \times d(t)$$

The decay rate $$d(t)$$is calculated by taking the remaining time to unlock divided by the total unlock time.

Once an unlock reaches maturity its fee (or reward) is no longer isolated, but enters in a bucket of matured unlocks. This bucket is then used to pay relayers to redeem matured unlock NFTs and complete the withdrawal on behalf of the pool. The amount received by a relayer equals the pro-rata share of the bucket based on the size of the unlock.

### Providing Liquidity

Liquidity providers can deposit their tokens to earn a pro-rate portion of the fees generated by exchange events. While in theory there is no impermanent loss in this model, LPs must be aware that they might be forgoing instant access to their capital, depending on the utilisation rate of the pool. If not enough assets are available to provision the withdrawal of an LP, the LP will enter in a priority queue to be able to withdraw the assets as redemption events occur.

Given that fee distribution is deferred until a redemption event occurs, new LPs will only start earning rewards after one duration of the unlock window has elapsed. Otherwise an attack vector to earn a risk-free reward could occur where a redemption event is sandwiched between a LP deposit and withdraw.

### Recovery Mode

Under very extreme conditions (e.g. slashing) it is possible that the amount exchanged is less than the amount eventually unlocked and redeemed by TenderSwap. This would result in a haircut loss for liquidity providers, which isn’t ideal. To prevent this risk we will enter ‘recovery’ mode when TenderSwap detects that a slash occurred on one of the unlocks held in its inventory.

During recovery mode, market makers can no longer buy up NFTs at a discount. All unlocks much reach their maturity and be redeemed by relayers at this point. The fees from the unlocks will replenish the assets that are missing to make liquidity providers whole. The tToken that incurred the slash will see an increased spread, until its debt is paid off.


# Yellow Paper

## Abstract

In the [White paper](/tenderswap/white-paper) section, the marginal fee function, called the base fee function in the paper, is introduced to calculate the fee. It was then noted that the base fee function presented a problem where splitting the swap into multiple smaller swaps would reduce the total amount of fees paid by a user. This necessitated the formulation of the partitioned fee function.

The partitioned fee function is a reconstruction of the base fee function that represents the lowest possible fee that could be paid by a user, regardless of how the swap is partitioned by the user. The partitioned fee function is found to be

$$
\phi(x) = \frac{\alpha  \left(S+U\right) \left(U^{\kappa} \left(-\kappa  u+U-u\right)-\left(\left(-u-x\right) \kappa +U-u\right) \left(U+x\right)^{\kappa}\right)}{\kappa  \left(\kappa +1\right) \left(s+u\right) L^{\kappa}}
$$

&#x20;where

* $$x$$ denotes the amount swapped.
* $$u$$ denotes the utilisation of the token that is currently being swapped.
* $$U$$ denotes the sum of the utilisations of all the tokens that are participating in the protocol.
* $$s$$ denotes the supply of the token that is currently being swapped.
* $$S$$ denotes the sum of the supplies of all the tokens that are participating in the protocol.
* $$L$$ denotes the liabilities of the protocol.
* $$\kappa$$, also known as the k-factor in the whitepaper, is a fixed variable that influences the shape of the graph.
* $$\alpha$$, also known as the alpha-factor, is a multiplier of the fee. In the absence of a multiplier, $$\alpha$$ may be set to one.

The proof that the mentioned function is indeed the lowest possible fee a user is not trivial. In this page, we describe the problem in more details. We also give an intuition on why the formula is correct. However, the rigorous proofs are longer and more complicated. That is why we have a whole paper dedicated to that, which can be found at the bottom of this page in the [#full-paper](#full-paper "mention") section.

## Introduction

### The base fee function and the shortcomings thereof

In the tenderswap section of the whitepaper of Tenderize, it is discussed that when a user wants to use Tenderswap to swap their liquid staking tokens for the underlying tokens, a fee is charged. The system has assets that can be used for this. The amount of assets that the system has if no swaps have happened are called the liabilities. Because the assets used for Tenderswap are limited and using Tenderswap removes from the amount of assets, this operation temporarily makes the system less solvent. To compensate for this, a swap fee is charged.\
In the whitepaper, a marginal fee function is given. As discussed in the whitepaper, the marginal fee functions takes different properties of the system into account to calculate the amount of fee. In this paper, we refer to the marginal fee function as the base fee function. In the whitepaper, it was motivated that the base fee function had to be

$$
\widehat{\phi}(x) = x \left(\frac{u+x}{u+s}\right) \left(\frac{U+S}{U+x}\right) \left(\frac{U+x}{L}\right)^\kappa
$$

&#x20; Here, the parameters represent different things:

* $$x$$ is the amount swapped.
* $$u$$ is the utilisation of the token that is currently being swapped.
* $$U$$U is the sum of the utilisations of all the tokens that are participating in the protocol.
* $$s$$ is the supply of the token that is currently being swapped.
* $$S$$ is the sum of the supplies of all the tokens that are participating in the protocol.
* $$L$$are the liabilities of the protocol.
* $$\kappa$$, also known as the k-factor in the whitepaper, is a fixed variable that influences the shape of the graph. In this paper we use the greek letter $$\kappa$$ (kappa), as the letter $$k$$ will be used often for indexes in sums.

As said earlier, this function has an important shortcoming. If a user comes in and wants to swap an amount of $$x$$, let us say for example $$x = 10$$, then he would need to pay a certain amount of fees. However, assume if he would split the amount swapped in two parts such that the two parts sum up his initial swap. For example he first swaps an amount of $$x\_1 = 2$$ after which he swaps an amount of $$x\_2 = 8$$ such that $$x\_1 + x\_2 = x$$. It turns out that sum of the amounts of fee he would pay for the two swaps is less than what he would have payed if he were to swap in one go. The full example can be found in the Tenderswap section in the whitepaper. Conceptually, the reason for this problem is that after a swap, the values of the token supply and token utilisation, and hence the total supply and total utilisation, are changed.\
This paper examines the base fee function and investigates how a user can split and rearrange a swap, and how this affects the total fees paid. We will come up with the partitioned fee function, a formula that represents what the least amount of fee would be payed by a user if he were to split and rearrange the swap, no matter how the splitting and rearrangement are done.

### Conventions about the parameters in the system

Before we delve deeper into the problem, we first have to agree on some conventions that are going to be assumed later on in this paper. When calculating fees, several parameters are taken into account. However, these parameters have certain constraints. In this subsection, we discuss what the constraints are and what the motivations are for each of these constraints.

#### Non active validators

Every validator could potentially have their own LST-token. However, this does not necessarily mean that every validator uses the protocol. We will shortly discuss the total supply and the total utilisation, which are the sums of the supplies and utilisations of the different type of tokens. However, only the validators that use the protocol are taken into account when talking about the total supply and total utilisation.

#### The liabilities

The liabilities, denoted by $$L$$, is the amount of assets the liquidity providers have made available for the protocol to use in Tenderswap. If no liquidity has ever been provided, then Tenderswap can not be used, as there is no liquidity available for the users that want to swap, which theoretically is equivalent to Tenderswap not even existing. The system only makes sense if liquidity has been provided. This motivates us to make the convention that it always holds that $$L>0$$.

#### The token utilisation and the total utilisation

When a user swaps LSTs for the underlying token, a part of the assets, which was provided by the liquidity providers, becomes temporarily unavailable. It becomes available again when someone buys the unlock NFT or if a relayer eventually processes the unlock when it has reached it's maturity date. However, until then, the assets are unavailable. We then say that an LST is utilising the liquidity in Tenderswap. The amount of assets that are not available, because an LST is utilising them, is called a token's utilisation and is denoted by $$u$$. The sum of the utilisation of all the tokens that are using the protocol is denoted by $$U$$. Because it is not possible for a token to utilise in a negative way, as this would mean that the system is getting more available assets when a swap happens, we always assume that $$u \geq 0$$. However, this also implicates that $$U \geq 0$$, as $$U$$ is the sum of non-negative terms. However, there is one final constriction on $$U$$. There can never be more total utilisation than the amount of assets the liquidity providers have made available in the first place, as otherwise a swapper would need to use non-existing assets to complete their swap. This hence means that $$U \leq L$$. We could abbreviate all of this by stating that $$0 \leq u \leq U \leq L$$.

#### The token supply and total supply

Every LST has a finite amount circulating. An LST is either using the system or not. If it is not using the system, we disregard it, until it possibly joins the system. As there can not be a negative amount of token circulating, we know for a fact that it always holds that $$s \geq 0$$. However, practically, if someone wants to swap LSTs, it also means that there were tokens circulating in the first place. If $$s = 0$$, then no swap could have happened. That is why we go a step further and always assume that $$s > 0$$. Again, as $$S$$ is the sum of the circulating supplies of the LSTs that are using the system, it also holds that $$S \geq s$$.

#### Fee amount

When a user comes in to swap an amount, this amount is commonly represented by the variable $$x$$. The amount $$x$$ is always assumed to be between $$0$$ and the minimum of $$L-U$$ and $$s$$, excluding $$0$$. Or more formally, it always holds that $$x \in (0, \min{s, L-U}]$$. The motivation behind the lower bound is that practically, it does not make sense to swap an amount of $$0$$, as this would be equivalent to no swap having happened at all. The upper bound is bounded by the minimum of $$s$$, the token supply, and $$L-U$$, the liabilities minus the total utilisation. The reason why $$x$$ can never be bigger than $$s$$ was just discussed. To understand why $$x$$ can never be bigger than $$L - U$$, we first have to understand what $$L-U$$ means in practice. Remember, $$L$$ denotes the amount of assets made available by the liquidity providers and $$U$$ denotes the amount of those assets that are being used. This means that $$L - U$$ represent the amount of assets that are yet available for the swaps. If $$x > L -U$$, this would mean that the user is swapping more than there is available. Hence, it always holds that $$x \leq L-U$$.

#### Kappa factor

The kappa factor, also known as the k-value or k-factor, is a fixed and predetermined parameter in the system that might vary from LST to LST. The kappa factor changes the shape of the graph in a specific way. If plenty of assets are available, the protocol should not be asking for a lot of fees. However, if the system is starting to get a high utilisation or if there were not a lot of assets made available by the liquidity providers in the first place, we want the fees to become higher. More simply said, the higher the utilisation rate or in other words, the higher $$\frac{U}{L}$$, the more harsh the fees should become. Conceptually, if the system is solvent, we want the fee function to be behaving like an almost flat function. However, at a certain point, we want the fees to grow rapidly. The kappa factor influences this. A low kappa factor means that the fee starts to grow rapidly early on. However, the rate of growth does not change a lot. In the most extreme case, when $$\kappa = 1$$, then the function is even linear. A high kappa factor means that the fee function first almost behaves like a flat function. However, at a certain point, the fee grows very rapidly, even more rapidly than if the function were to have a low kappa factor. Because letting $$\kappa<1$$ makes the fee grow less and less the more is swapped, it does not make sense to let $$\kappa<1$$. This motivates us to always assume that $$\kappa\geq1$$

#### Alpha factor

The alpha factor will only appear again at the end of this paper. We will eventually see that the partitioned fee function can become significantly less than the base fee function. If we somehow want to make this effect less severe, we can multiply the final fee result by a factor $$\alpha \geq 1$$. However, if this is not needed, one can just assume that $$\alpha = 1$$. Furthermore, as $$\alpha$$ does not dominate the theorems and can be easily added afterwards, we will not be discussing $$\alpha$$ until the end.

### Fee partitioning

We are now going to focus more in-depth on what the problem with the base fee function is and how we can formally address it. First, let us assume someone comes in and wants to swap $$10$$ tokens. As the parameters will change after the swap, we are going to subscript the parameters that change after the swap, which are $$u, s, U$$ and $$S$$. We thus obtain $$\widehat{\phi\_1}(10) = 10 \left(\frac{u\_1+10}{u\_1 + s\_1}\right) \left(\frac{U\_1 + S\_1}{U\_1+10}\right)\left(\frac{U\_1+10}{L}\right)^\kappa$$. However, let us assume that the user wants to pay fewer fees and decides to split the swap into two parts. First, he swaps an amount of $$2$$. The second time, he swaps an amount of $$8$$. The first swap, he pays for fees: $$\widehat{\phi\_1}(2) = 2 \left(\frac{u\_1+2}{u\_1 + s\_1}\right) \left(\frac{U\_1 + S\_1}{U\_1+2}\right)\left(\frac{U\_1+2}{L}\right)^\kappa$$ Now an important fact comes up. When the user wants to swap an amount of $$8$$ afterward, the function is no longer the same. This is also why we subscripted the $$\hat\phi$$ function. When the user swaps an amount of $$2$$, it results in changes to some parameters. Consequently, the fee paid for the second swap is calculated using a different function: $$\widehat{\phi\_2}(8) = 8 \left(\frac{u\_2+8}{u\_2 + s\_2}\right) \left(\frac{U\_2 + S\_2}{U\_2+8}\right)\left(\frac{U\_2+8}{L}\right)^\kappa$$ It would be beneficial to eliminate $$u\_2, s\_2, U\_2$$, and $$S\_2$$ so we can more easily investigate the issue. Let us examine each one of these in turn:

1. After swapping an amount of $$2$$, the LST utilises an amount of $$2$$ more. This means that $$u\_2 = u\_1 + 2$$.
2. As $$U$$ is the sum of the utilisation of every token, it holds that $$U\_2 = U\_1 + 2$$.
3. When the user swapped an amount of $$2$$, an amount of $$2$$ vanishes from the circulating supply. That is, $$s\_2 = s\_1 - 2$$.
4. As $$S$$ is the sum of all the circulating supply of the token that are using the protocol, it holds that $$S\_2 = S\_1 - 2$$.

We can hence write the second swap as $$\widehat{\phi\_2}(8) = 8 \left(\frac{u\_1 + 2+8}{u\_1 \cancel{+2} + s\_1 \cancel{- 2}}\right) \left(\frac{U\_1 \cancel{+2} + S\_1 \cancel{-2}}{U\_1+2+8}\right)\left(\frac{U\_1+2+8}{L}\right)^\kappa$$ Let us formalize this concept. Let there be a user that first wants to swap an amount of $$x > 0$$. Instead, he decides to try to reduce the fees and splits up the amount $$x$$ in $$x\_1, x\_2, \dots, x\_n > 0 \backepsilon x\_1 + x\_2 + \dots + x\_n = x$$. The amount of fee that is paid in the second case can then be written as

$$
\begin{align\*}
&\widehat{\phi\_1}(x\_1) + \widehat{\phi\_2}(x\_2)  + \dots + \widehat{\phi\_n}(x\_n) \\
\=\&x\_1 \left(\frac{u\_1+x\_1}{u\_1 + s\_1}\right) \left(\frac{U\_1 + S\_1}{U\_1+x\_1}\right)\left(\frac{U\_1+x\_1}{L}\right)^\kappa \\
+& x\_2 \left(\frac{u\_2+x\_2}{u\_2 + s\_2}\right) \left(\frac{U\_2 + S\_2}{U\_2+x\_2}\right)\left(\frac{U\_2+x\_2}{L}\right)^\kappa\\
+&\dots\\
+& x\_n \left(\frac{u\_n+x\_n}{u\_n + s\_n}\right) \left(\frac{U\_n + S\_n}{U\_n+x\_n}\right)\left(\frac{U\_n+x\_n}{L}\right)^\kappa\\
\=\&x\_1 \left(\frac{u\_1+x\_1}{u\_1 + s\_1}\right) \left(\frac{U\_1 + S\_1}{U\_1+x\_1}\right)\left(\frac{U\_1+x\_1}{L}\right)^\kappa \\
+& x\_2 \left(\frac{u\_1 + x\_1+x\_2}{u\_1 + s\_1}\right) \left(\frac{U\_1 + S\_1}{U\_1 + x\_1+x\_2}\right)\left(\frac{U\_1+x\_1+x\_2}{L}\right)^\kappa\\
+&\dots\\
+& x\_n \left(\frac{u\_1 + x\_1 + x\_2 + \dots+x\_n}{u\_1+ s\_1}\right) \left(\frac{U\_1+ S\_1}{U\_1 + x\_1 + x\_2 + \dots+x\_n}\right)\left(\frac{U\_1+x\_1+x\_2+\dots+x\_n}{L}\right)^\kappa\\
\=&\sum\_{i=1}^n x\_i \left(\frac{u\_1 + \sum\_{j=1}^i x\_j}{u\_1+ s\_1}\right) \left(\frac{U\_1+ S\_1}{U\_1+ \sum\_{j=1}^i x\_j}\right)\left(\frac{U\_1+\sum\_{j=1}^i x\_j}{L}\right)^\kappa\\
\end{align\*}
$$

This equation could be cumbersome to work with. That is why we instead use a slightly different approach. Conceptually, we were looking at the ordered set $${x\_1, x\_2, \dots, x\_n} \backepsilon x\_1 + x\_2 + \dots + x\_n = x$$ and performing the base fee function on every element with the updated parameters. What we will do now is consider the cumulative values. To illustrate, we define $$P$$ as $${x\_1, x\_1 + x\_2, \dots, x\_1 + x\_2 + \dots, x\_n}$$. We first note that $$x\_i = p\_i - p\_{i-1}$$. Furthermore,&#x20;

$$
\begin{align\*}
&\widehat{\phi\_1}(x\_1) + \widehat{\phi\_2}(x\_2)  + \dots + \widehat{\phi\_n}(x\_n) \\
\=&\sum\_{i=1}^n x\_i \left(\frac{u\_1 + \sum\_{j=1}^i x\_j}{u\_1+ s\_1}\right) \left(\frac{U\_1+ S\_1}{U\_1+ \sum\_{j=1}^i x\_j}\right)\left(\frac{U\_1+\sum\_{j=1}^i x\_j}{L}\right)^\kappa\\
\=&\sum\_{i=1}^n x\_i \left(\frac{u\_1 + p\_i}{u\_1+ s\_1}\right) \left(\frac{U\_1+ S\_1}{U\_1+ p\_i}\right)\left(\frac{U\_1+p\_i}{L}\right)^\kappa		\\
\=&\sum\_{i=1}^n \left(\frac{u\_1 + p\_i}{u\_1+ s\_1}\right) \left(\frac{U\_1+ S\_1}{U\_1+ p\_i}\right)\left(\frac{U\_1+p\_i}{L}\right)^\kappa \cdot (p\_i - p\_{i-1}) 
\end{align\*}
$$

&#x20;This knowledge will be used shortly in the next subsection.

### The partitioned fee function and the temporary fee function

As previously discussed, when a user partitions a swap amount $$x$$ into the amounts $$x\_1, x\_2, \dots, x\_n$$, we can also use the numbers $$x\_1, x\_1 + x\_2, \dots, x\_1 + x\_2 + \dots + x\_n$$. As in the first term, we multiply by $$(x\_1 - (x\_{1-1}))$$, and $$x\_0$$ is not defined, we have a problem here. However, based on the earlier formula, it should be noted that $$x\_1 - x\_0 = x\_1$$ which implies that $$x\_0 = 0$$. Hence, the above number can also be seen as the interval $$\[0, x]$$ being cut into pieces. This brings us to the first definition of the paper:

**Definition 1** (Swap partition). Let $$x > 0$$ be given. A set $$P$$ is called a swap partition if it is in the form $$P = {p\_0, p\_1, p\_2, \dots, p\_{n-1}, p\_n} = {0, p\_1, p\_2, \dots, p\_{n-1}, x}$$ where $$i > j \implies p\_i > p\_j$$. The set of all possible partitions for a given $$x>0$$ is denoted by $$\mathscr{P}\_x$$&#x20;

Because, as we have seen, $$u, s, U$$ and $$S$$ do not change using the new approach to calculating the fee when being partitioned, we can leave the subscript away. Given a swap of an amount of $$x$$ and a possible partition of the swap $$P \in \mathscr{P}*x$$, we can thus calculate the total amount of fee with the partition function $$\Phi$$ defined as $$\Phi(P) = \sum*{i=1}^{#P-1} \left(\frac{u + p\_i}{u+ s}\right) \left(\frac{U+ S}{U+ p\_i}\right)\left(\frac{U+p\_i}{L}\right)^\kappa \cdot (p\_i - p\_{i-1})$$

It will turn out that we will encounter this form a lot during this paper. That is why we introduce the temporary fee function $$\tau$$, which represent the terms, except for the $$(p\_i - p\_{i-1})$$ term.

**Definition 2** (Temporary fee function). The temporary fee function is defined as&#x20;

$$
\begin{align\*}
\tau(x) = 
\begin{cases}
\left(\frac{u + x}{u+ s}\right) (U+S)\frac{(U+x)^{\kappa - 1}}{L^\kappa} &\text{ if } \kappa > 1\\
\left(\frac{u + x}{u+ s}\right) (U+S)\frac{1}{L^\kappa} & \text { if } \kappa = 1
\end{cases}
\end{align\*}
$$

The reason for providing a different definition when $$\kappa = 1$$ may not be immediately apparent. However, later in the paper, we will encounter cases where we need to calculate $$\tau(0)$$. If $$U = 0$$, we get a $$0^0$$ term, which is problematic. However, if $$U>0$$, then we get a $$(U+x)^0 =1$$ term. Hence, giving a slightly different definition for when $$\kappa = 1$$ gives the same result but removes the propblems.\
Now, we can write the partition function very briefly as $$\Phi(P) = \sum\_{i=1}^{#P-1} \tau(p\_i) \cdot (p\_i - p\_{i-1})$$ and we are finally able to define what the partitioned fee function must be. Conceptually, our goal is for the formula to return the minimum fee a user would pay for a swap, regardless of how it is split and rearranged. Or in other words, given an amount of $$x$$, the function should return the greatest lower bound, or infimum, of all the possible $$\Phi$$ values of the partitions that adhere to $$\mathscr{P}\_x$$.

**Definition 3** (The partitioned fee function). Let $$0 < x \leq \min{s, L-U}$$ be given. The partitioned fee function is defined as $$\phi(x) = \inf\left{\Phi(P) \backepsilon P \in \mathscr{P}\_x\right}$$&#x20;

This paper is dedicated to finding a concrete formula for $$\phi$$ and proving why this formula is, in fact, the greatest lower bound.

### Plan of approach

We will discuss our approach to this problem. This subsection provides an overview of the lemmas, propositions, and theorems we will prove in the paper, and how they contribute to deriving a concrete formula for $$\phi$$.

#### Fee refinements

First, we will be investigating some important properties about the partitioned fee functions. Two important properties will be proven in lemmas:

1. Fees are always strictly positive, no matter how a fee is partitioned. This concept is proven in the positive fee lemma.
2. When a user refines the partition he uses to swap, the fees will always become lower. That is, if a user swaps an amount of $$x$$ and uses partitions $$P, Q \in \mathscr{P}\_x$$ such that $$P \subset Q$$, then $$\Phi(P) < \Phi(Q)$$.

These properties are important to know. Firstly, because it will be proven that refining a partition will always lower the fee, we know that we can never point to a concrete partition that would give us the value of the partitioned fee function immediately. Or in other words $$\not \exists P \in \mathscr{P}\_x \backepsilon\Phi(P) = \phi(x)$$. This, however, raises the question of whether we can refine a partition indefinitely until we have a fee of zero or even negative. Fortunately, the positive fee lemma tells us that this will never be the case and we will always be left with a strictly positive fee.

#### Power partitions

This subsection introduces the concept of index shifting and power partitions. Power partitions are a special type of partitions. Conceptually, if one has an interval $$\[0, x]$$, and keeps splitting the intervals in half, we get power partitions. They are often denoted as $$X^n\_x \subset \mathscr{P}\_x$$, such that&#x20;

$$
\begin{align\*}
X^0\_x &= {0, x}\\
X^1\_x &= \left{0, \frac{1}{2^1} x, x\right} \\
X^2\_x &= \left{0, \frac{1}{2^2} x,\frac{2}{2^2} x, \frac{3}{2^2} x,x\right} \\
\dots&\\
X^n\_x &= \left{0, \frac{1}{2^n} x, \frac{2}{2^n} x, \dots, \frac{2^n-1}{2^n} x, x\right}
\end{align\*}
$$

&#x20;It would be beneficial to investigate whether $$\phi(x) = \lim\_{n\to\infty} \Phi(X^n\_x)$$. However, how do we know this? Maybe we can find a partition $$P \in \mathscr{P}*x \backepsilon \Phi(P) < \lim*{n\to\infty} \Phi(X^n\_x)$$. Here, one of the most important theorem in the paper, the power partition theorem, states that no matter which partition we have, we can find a power partition that results in a lower fee. Or in other words $$\forall P \in \mathscr{P}\_x \exists N \backepsilon n > N \implies \Phi(X^n\_x) < \Phi(P)$$. This theorem is actually far from trivial. The reason is that if one would for example come with a partition $$P = {0, \frac{1}{3} x, \frac{2}{3}x, x}$$, then now matter how much we refine the power partitions, they will never overlap. Fortunately, before proving this theorem, we prove the lemma that states that shifting elements in the partition is continuous. In a simplified form, it means that although we can never make $$P$$ a subset of some power set, we can shift their elements a little bit such that they do become elements of some power set. The lemma than states that although the value of $$\Phi$$ then changes, it changes in a continuous and thus predictable way, a fact that we will use in the power partition theorem.

#### Fundamental fee theorems

In the last part of the paper, the results are showcased. Again, we will simplify things quite a bit here, but we will have seen by this point that $$\tau$$ is a continuous function and also integrable. This means that for any partition $$P \in \mathscr{P}*x$$, when we have a term $$\tau(p\_i) \cdot (p\_i - p{i-1})$$, the Lagrange mean value theorem states that we can find a $$t\_i\in \[p*{i-1}, p\_i]$$ such that $$\tau(t\_i) \cdot (p\_i - p\_{i-1}) = T(p\_i) - T(p\_{i-1})$$, where $$T$$ is the antiderivative of $$\tau$$. Because of the increasing nature of $$\tau$$, another fact we would have encountered by now, we know that $$\tau(p\_{i-1}) \cdot (p\_{i} - p\_{i-1}) \leq \tau(t\_i) \cdot (p\_i - p\_{i-1}) \leq \tau(p\_i) \cdot (p\_i - p\_{i-1})$$. If we take the power partitions, we will see that conceptually taking the limit $$X = \lim\_{n \to \infty} X^n\_x$$ will result in $$\sum\_{i=1}^{2^n} \tau(X\_{i-1}) \cdot (X\_{i}-X\_{i-1}) = \sum\_{i=1}^{2^n} \tau(X\_{i}) \cdot (X\_{i}-X\_{i-1})$$. This conceptually means that the middle term $$\tau(t\_i) \cdot (p\_i - p\_{i-1})$$ gets squeezed between those two. However, we see that&#x20;

$$
\begin{align\*}
\sum\_{i=1}^{#P-1} \tau(p\_{i-1}) \cdot (p\_i - p\_{i-1})&\leq\sum\_{i=1}^{#P-1} \tau(t\_i) \cdot (p\_i - p\_{i-1}) \\&= \sum\_{i=1}^n T(p\_i) - T(p\_{i-1})\\
&= -T(0) + T(p\_1) - T(p\_1) + \dots -T(p\_{#P-1}) + T(p\_{#P-1}) + T(x)\\
&= T(x) - T(0) = \int\_0^x\tau(x) \text{ d} x \leq \sum\_{i=1}^{#P-1} \tau(p\_i) \cdot (p\_i - p\_{i-1})
\end{align\*}
$$

As the first and last term are equal, and the last term is taken with the limit of the power set, of which the $$\Phi$$ value is smaller than the $$\Phi$$ value of any partition, it is equal to the partitioned fee function. That is the sketch of the proof that the partitioned fee function is equal to $$\phi(x) = \int\_0^x \tau(x) \text{ d} x$$

#### Fee concat theorem and alpha factor

The fee concat theorem states that if we were to partition a swap and use the partitioned fee function, than the sum of the fees would be equal to the fee that would be paid if the swap were to happen in one go. That was the whole purpose of this paper. The proof is quite simple, as it just involves showing that splitting a swap somewhere and performing the partitioned fee function on this new partition gives the same result. More complex refinements can then be achieved by repeatedly applying this operation. Finally, we end the paper with the remark that if the partitioned fee function returns too small values, then we can multiply the result easily with the $$\alpha \geq 1$$ factor.

## Full paper

If one wishes to read the rigorous proofs on the correctness of the partition fee function, they can read the full paper about it, which can be found here:

{% file src="/files/0grWtCtGKNB0kb6Faj0e" %}
Full paper on the partitioned fee function
{% endfile %}


# technical documentation

This page provides developer documentation for the most important endpoints of the TenderSwap contract. TenderSwap facilitates trading of validator-specific tTokens using a shared liquidity pool, allowing users to deposit underlying tokens, receive LP tokens, and participate in the protocol's liquidity mechanisms.

### Table of Contents

* Swap
* Quote
* Deposit
* Withdraw
* Buy Unlock
* Redeem Unlock
* Claim Relayer Rewards
* Events
* Notes
* Disclaimer

### Swap

```solidity
swap(address asset, uint256 amount, uint256 minOut) external returns (uint256 out, uint256 fee)
```

**Parameters:**

* `asset` (address): The address of the tToken to swap
* `amount` (uint256): The amount of tTokens to swap
* `minOut` (uint256): The minimum amount of underlying tokens expected to receive

**Returns:**

* `out` (uint256): The amount of underlying tokens received
* `fee` (uint256): The fee charged for the swap

**Description:**

* Transfers the specified tTokens from the user to the contract
* Calculates the dynamic fee based on pool utilization
* Creates an unlock position for the swapped tokens
* Transfers the underlying tokens to the user

**Events:**

* `Swap(address indexed caller, address indexed asset, uint256 amountIn, uint256 fee, uint256 unlockId)`

**Errors:**

* `ErrorInvalidAsset(address asset)`: Thrown if the tToken is not supported
* `ErrorSlippage(uint256 out, uint256 minOut)`: Thrown if the output amount is less than minOut

### Quote

```solidity
quote(address asset, uint256 amount) external view returns (uint256 out, uint256 fee)
```

**Parameters:**

* `asset` (address): The address of the tToken to swap
* `amount` (uint256): The amount of tTokens to swap

**Returns:**

* `out` (uint256): The estimated amount of underlying tokens to receive
* `fee` (uint256): The estimated fee for the swap

**Description:**

* Simulates a swap to provide price information
* Calculates fees based on current pool state
* Does not modify state

**Errors:**

* `ErrorInvalidAsset(address asset)`: Thrown if the tToken is not supported

### Deposit

```solidity
deposit(uint256 amount, uint256 minLpShares) external returns (uint256 lpShares)
```

**Parameters:**

* `amount` (uint256): The amount of underlying tokens to deposit
* `minLpShares` (uint256): The minimum amount of LP tokens expected to receive

**Returns:**

* `lpShares` (uint256): The number of LP tokens minted

**Description:**

* Transfers underlying tokens from the user to the contract
* Calculates LP tokens based on pool's current state
* Mints LP tokens to the user
* Updates pool liabilities

**Events:**

* `Deposit(address indexed from, uint256 amount, uint256 lpSharesMinted)`

**Errors:**

* `ErrorSlippage(uint256 shares, uint256 minLpShares)`: Thrown if LP shares are less than minimum
* `ErrorCalculateLPShares()`: Thrown if share calculation fails

### Withdraw

```solidity
withdraw(uint256 amount, uint256 maxLpSharesBurnt) external
```

**Parameters:**

* `amount` (uint256): The amount of underlying tokens to withdraw
* `maxLpSharesBurnt` (uint256): Maximum LP tokens willing to burn

**Description:**

* Checks available liquidity
* Burns LP tokens from user
* Transfers underlying tokens to user
* Updates pool liabilities

**Events:**

* `Withdraw(address indexed to, uint256 amount, uint256 lpSharesBurnt)`

**Errors:**

* `ErrorInsufficientAssets(uint256 requested, uint256 available)`
* `ErrorSlippage(uint256 shares, uint256 maxLpSharesBurnt)`

\[Continue with remaining sections in same format...]

### Notes

* **Fee Structure**: Implements dynamic fees based on pool utilization with BASE\_FEE and variable component
* **Liquidity Management**: Uses elastic LP tokens with automatic rebalancing
* **Safety Features**: Includes slippage protection and recovery mode
* **Mathematical Precision**: Uses UD60x18 for precise calculations

### Disclaimer

This documentation provides a high-level overview of TenderSwap's core functionality. Developers should thoroughly review the contract code and conduct comprehensive testing before integration.


# Introduction

Learn how to create your own LSTs using Tenderize

Users can combine multiple validator-specific tTokens into composite LSTs, which enhances their flexibility and usability in decentralized finance (DeFi).

* **Composite LSTs:**\
  Validator-specific LSTs (tTokens) can be aggregated into a single composite LST. This allows users to diversify their staked positions across multiple validators while managing their assets as a unified token.
* **Rebalancing with TenderSwap:**\
  TenderSwap, the decentralized exchange introduced by Tenderize, supports seamless rebalancing of validator-specific tTokens. Users can rebalance their holdings to optimize rewards or adjust their risk exposure with minimal slippage and reduced capital requirements.
* **Simplified Withdrawals:**\
  Composite LSTs can be decomposed into their validator-specific components. Using TenderSwap, users can easily swap their composite tokens back into the original tTokens or withdraw the underlying assets directly from the protocol.


# Create your Composite LST

A comprehensive guide to creating, managing, and optimizing validator-diversified liquid staking positions and tokens using Tenderize.

**COMING SOON \*⏳**

{% hint style="info" %}
If you are familiar with Solidity, you can check the technical documentation for [tTokens](/staking/technical-documentation) and [TenderSwap](/tenderswap/technical-documentation) already get started. Pick your allocation and rebalancing strategies and create a smart contract wrapper around various tTokens.&#x20;
{% endhint %}

### Prerequisites

* Understanding of basic staking concepts
* Supported wallet (MetaMask, etc.)
* Native tokens for staking
* Basic understanding of DeFi operations

### Step-by-Step Guide

#### 1. Acquiring tTokens

* How to stake with different validators
* Getting validator-specific tTokens
* Understanding tToken properties

#### 2. Creating a Composite LST

* Using TenderSwap to combine positions
* Validator distribution of your choice
* Risk management considerations of your choice

#### 3. Managing Your Composite LST

* Monitoring validator performance
* Rebalancing strategies
* Fee considerations

#### 4. Rebalancing Your Position

* When to rebalance
* Using TenderSwap efficiently
* Minimizing slippage

#### 5. Withdrawing and Decomposing

* Full withdrawal process
* Partial withdrawals
* Emergency procedures


# WAGYU Token

{% hint style="info" %}
**WAGYU is not yet live, to keep updated join our discord.**
{% endhint %}

**$WAGYU** will be the governance token of the Tenderize ecosystem. This includes goverance over:

* Core protocol upgrades
* TenderSwap upgrades
* Composite tTokens
* lpETH
* any future related Tenderize products

A portion of the revenue from TenderSwap and multi-validator LSTs will be used to buy back $WAGYU and distribute as incentives across governance and various ecosystem incentives such as liquidity.\
\
$WAGYU can be locked for $veWAGYU to participate in governance.


# Overview

{% hint style="info" %}
At its core, a liquid staking protocol needs three key components: a mechanism to mint tokenized version of staked assets, a liquid market to trade these tokenized assets, and a mechanism to collateralize the tokenized assets.
{% endhint %}

In Tenderize V2, these core components are:

* **TenderVault -** Liquid staking vault that accepts user deposits, staking them to a the validator chosen by the user, minting and burning tTokens.
* **TenderSwap** - A decentralized exchange featuring shared, fractional liquidity which can be accessed by any TenderToken holder.
* **BeefBank** - A borrowing facility to deposit tTokens as collaterl to mint SteaksDollar, a stablecoin pegged to the US dollar.&#x20;

Additional components include:

* **TenderTokens (tTokens)** - Elastic supply ERC-20 tokens which represent staked assets and earned rewards 1:1. Price is pegged to the underlying, unstaked asset.&#x20;
* **Productive Treasury** - Protocol revenue is directed to the on-chain treasury, once there, it is compounded by providing liquidity on TenderSwap.


# TenderVault / tTokens

Liquid staking vault that accepts user deposits, staking them to a the validator chosen by the user, minting and burning tTokens.

## tTokens (TenderTokens)

TenderTokens are ERC-20 tokens with an elastic supply model like aTokens in the Aave protocol. These types of tokens work by updating the total supply to map 1:1 with the amount of underlying tokens staked. Supply changes upward as staking rewards are earned and downward when slashing occurs and/or tokens are removed from the node. As staking service providers conducts business, staking rewards and/or slashing losses are distributed among all tToken holders of that node.

**Price Parity**

Thanks to the ability to unstake through Tenderize, the exchange rate of tTokens is at parity to the liquid version. Holders of tTokens don’t have to worry about the asset depegging from the underlying market value of the liquid asset. This also means that protocols don’t have to use custom price oracles to track the price of tTokens when using them in other Defi protocols.

💡 ***Example**: Alice stakes 10 LPT to Bob’s Livepeer node using Tenderize and receives 10 tLPT in return. After some time passes, she earns 2 LPT because Bob’s node earned staking rewards. Alice’s wallet balance is now 12 tLPT. She can sell the 2 tLPT on TenderSwap or unstake the 12 LPT.*

#### Delegation Vaults

For any underlying token, there can be as many unique TenderTokens as there are node operators on that network. Each TenderToken represents a separate delegation vault that acts as a proxy to allocate stake to the node operator. Each tToken has yield tied to the node’s performance and parameters.

Delegation vaults execute the logic which would be done by a user when natively staking on the underlying protocol. Both staking and unstaking capabilities are fully available. Unstaking is time is determined by the underlying network’s rules. No additional unstaking time is added when using Tenderize v2.

When a user stakes underlying tokens in a delegation vault, an equivalent amount of TenderTokens (tTokens) are minted for the user. When unstaking, TenderTokens are removed from the supply and burnt. After a tToken is burnt, an unstaking request is sent to the underlying protocol. A receipt is issued for the user which can be redeemed for underlying tokens when the unstaking period ends (specific to each protocol supported).

#### Liquid Unstaking (NFTs)

When a user in in the middle of an unstaking period, assets are still exposed to market volatility. To address this issue, receipts are given to the user when unstaking are tokenized and represented as NFTs using the ERC-721 standard. A receipt contains the amount of tokens to be received and can be redeemed by the holder at its maturity date. Tokenized receipts are transferrable and can be sold on the secondary market or over-the-counter when a user requires liquidity during the unstaking period

#### tToken Indexes

While Tenderize’s delegation vaults take liquid staking to a much more granular level than traditional designs, not every user is an advanced user that wants to stake to specific validators. Some users simply want to stake as an investment. For these users, there will be a liquid staking pool for each supported network that is made up of tTokens for various node operators on that network.

A liquid staking pool in Tenderize is not managed by a subjective governance process or whitelist. Rather, users stake Tenderize’s native token, WAGYU, to determine the weight of each node in the index.

*Indexes are peripheral to the Tenderize core protocol and will not be available at launch. More specifications will follow in the future.*

#### Fees

The Tenderize Protocol charges a small fee on the staking rewards before they are distributed. These fees are fully contributed towards the protocol treasury and its protocol-owned liquidity. No fees are charged on the principal when staking or unstaking to or from Tenderize, however the underlying protocol might implement fees or taxes that the Tenderize protocol also takes into account (e.g. The Graph 5% delegation tax).

At launch, this fee will be set to the hardcoded maximum in the protocol of 0.50%. As the protocol grows over time and the treasury builds up additional revenue sources and sufficient liquidity, a dynamic fee system could be installed.

## Risks

**Slashing Risk**

Node operators and its delegators in various web3 protocols are often subject to staking penalties and slashing when misbehaving (e.g. long down-time, performing bad work, etc.). Tenderize does not aim to mitigate this risk as it merely acts as middleware for staking.

If validator A is slashed, only tToken A will suffer the penalty.

**Node Operator Misbehaviour**

Due to the design of the native staking experience, node operators on the network can arbitrarily increase their commission rates to draw more rewards from delegations. This problem already exists for delegators before Tenderize, the problem will continue as Tenderize v2 is a delegator in the ecosystem. However, should this happen, it would likely cause staked assets to move towards different node operators offering more favorable rates. Tenderize will notify users if rates are changed by the validator.

**Smart Contract Risk**

There is an inherent risk that any piece of software could contain vulnerabilities or bugs. However, security is a top priority for the Tenderize protocol. Therefore, the smart contract code is fully open source for anyone to verify and battle test. Before launch, the code will undergo security audits.


# BeefBank

Freeze your steak, borrow Steak Dollars

Steaks Dollar is an over-collateralised, LST-backed stablecoin, that allows borrowing a USD-pegged token (”Steaks Dollar or SD”) by collateralising staked assets in the form of Tenderize’s LSTs. It is the first of a kind decentralised stablecoin backed by a basket of various liquid staked assets.

USD is generated by locking in collateral to create a Collateralised Debt Position (CDP), the value of the collateral in a CDP must always exceed the value of the debt to prevent liquidation. The benefit is that there is no dependence on external liquidity providers to act as lenders. Rather, creating new debt positions increases the USD supply, whereas repayment of debt contracts the USD supply.

The yield generated by the LSTs provided as collateral is isolated to their debt position where it automatically accrues. The owner of the debt then has the option to program the yield.

### Collateralised Debt Positions

Users can deposit tTokens into BeefBank as collateral to mint SD. Once minted, the user created a Collateralised Debt Position which is owned by the user. The SD has to be paid back at some point in the future to unlock the collateral. The debt needs to be repaid either by the user that opened the debt position, or a liquidator once a position drops below its  minimum collateral ratio.

#### **Collateral Ratio**

SD is over-collateralised, meaning for each 1$ of SD borrowed a user must put up more than $1 worth of tTokens. The SD value of the collateral divided by the amount of borrowed SD is known as the collateral ratio.

Each collateral asset will have a different minimum collateral ratio (MCR) greater than 100%, e.g. 125%. Once the collateral ratio of a CDP position falls below this minimum it can be liquidated, as otherwise it has the risk of becoming bad debt within the system.

The minimum collateral ratio for each asset is adjustable by governance. This ratio can vary depending on the asset because of various reasons such as market depth, price volatility and oracle health of the underlying asset.

#### Programmable LST Yield

While collateralised, the deposited LST tokens still generate yield. The generated yield is automatically added to the collateral and will increase the collateral ratio of the position. This effectively deleverages the position as yield is earned. This allows the user to create various automated strategies such as:

* Auto-Yield stablecoin (fund yield via tToken - paid as tToken)
* Auto-Yield stablecoin (funded yield by minting SD as collateral value rises- paid in SD)
* Auto-Repaying loan (Yield is sold for SD, paying back the loan)
* Leveraged long (post collateral, mint SD, buy more collateral)&#x20;

By maintaining a specified collateral ratio according to the risk appetite, a user can use the excess collateral above it to mint more USD. This resembles the workings of an yield-bearing stablecoin where the yield and risk is isolated on the underlying debt position.

Alternatively, users can use the yield to partially repay the loan in installments. This can be done very efficiently using “flash repay” described below. This lets the user mint an amount of USD upfront to unlock some of the collateral, which can then be sold in the same transaction to repay the minted USD within the same transaction.

#### **Fees**

Our system does not charge an annual percentage rate interest on the outstanding capital. Rather a one-time borrow- and redemption fee is used.

### Liquidations

Liquidations are performed by liquidators who are incentivised to acquire collateral at a discount by repaying the borrowed USD of the position. The profit obtainable by a liquidator depends on collateral ratio the loan is liquidated at. Given a sufficient minimum collateral ratio liquidations should always be profitable even under severe market conditions.

#### Flash Repay

To facilitate liquidations we use a technique called “flash repay” instead of the traditional stability pool found in common lending protocols such as Liquity. Using flash repay, a user is able to borrow an amount of USD equal to at most the debt of a position. The borrowed amount has to be paid back within the same atomic transaction, after which it is burnt again.

Liquidators can use flash repay to access the necessary USD tokens to repay a borrower's debt without requiring large amounts of upfront capital. Subsequently, they can utilize the received collateral to swap back into USD and repay the flashed tokens, all within a single transaction. This process allows liquidators to arbitrage the market for risk-free profits

Flash Repay can also be used to (de)leverage positions.

**Deleverage**

1. Flash USD equal to amount to reduce debt with
2. Repay debt to unlock collateral
3. Swap collateral for USD
4. Repay flashed USD

**Leverage**

1. Flash USD up to the initial debt
2. Swap flashed USD to the preferred tToken
3. Borrow additional collateral against the acquired tToken
4. Repay flashed USD


# Autonomic Liquidity Provision

Liquidity backstop for Tenderize Ecosystem

Autonomous Liquidity Provision (ALP) allocates fees earned by Tenderize to a an on-chain treasury, where they are used to provision liquidity for the underlying tokens. It is a more automated version of **Protocol Owned Liquidity (POL),** as pioneered by Olympus DAO. TenderSwap ALP doesn’t solely depend on external market participants selling their liquidity at a premium to the treasury but rather utilizes the constant stream of revenue produced by the protocol.

Protocol Owned Liquidity is an innovative solution to the mercenary capital problem. Protocols which give tokens in exchange for depositing assets engage in a “race to the bottom” to provide more and more incentives. The incentive tokens attract liquidity providers but in-turn, dilute the value of the protocol via high issuance of tokens. Instead, TenderSwap’s Protocol Owned Liquidity ensures that the liquidity acquired is permanently allocated as part of the treasury. The assets in the treasury are yield-bearing and can provide intrinsic value to a protocol’s token.

**👉 With Autonomous Provisioned Liquidity, protocol fees are used to permanently provision liquidity as part of the treasury**

Legacy liquid staking protocols require a deep on-chain liquidity to maintain price parity and offer liquidity for the staked position. Tenderize does this in a cost-efficient way by permanently provisioning liquidity from the treasury so that a minimum amount of liquidity will always exist, regardless of market conditions.

This can greatly reduce liquidity risk, which is important for third-party protocols to build upon tTokens and Tenderswap. Borrowing and lending protocols are able to offer better liquidation thresholds with reduced liquidity risk.

#### Target Liquidity Ratio

The liquidity ratio indicates whether there is sufficient liquidity in underlying tokens for its TenderTokens in circulation. The liquidity ratio is the result of dividing the amount of underlying tokens for a particular asset in TenderSwap by the amount that is staked in Tenderize for that token.

<figure><img src="/files/pVAyZl17RaVlciYRFbv3" alt="" width="375"><figcaption></figcaption></figure>

**👉 Example: If TenderSwap contains 100 LPT of unstaked liquidity and there is 500 LPT staked for tLPT, the liquidity ratio equals 100/500 or 0.20.**

A liquidity ratio of one would mean that each underlying token staked through Tenderize is paired 1:1 with a liquid token in TenderSwap. This is the model adopted by Uniswap and Curve, which isn’t capital efficient.

Thanks to the ability to unstake, it’s unlikely that all users would want to sell their assets all at the same time, which would create a bank run. Instead, we can assume that liquidity only needs to be a fraction portion of what is staked in total. This fractional portion is called the **target liquidity ratio**. This target is set by WAGYU holders and is adjusted depending on market behavior. Generally, 20% during low velocity conditions and 50% during high velocity conditions is an ideal starting point. At genesis, the target liquidity ratio will be 25%.

If the current liquidity ratio for an underlying token is higher than the target liquidity ratio, fees will be retained in the treasury under the form of TenderTokens. Once there, they earn staking rewards and more resources are built up for when liquidity needs to be acquired.

#### Bonding

Bonding is the process of a protocol selling a particular asset out of its treasury at a discount, in return for another asset it would like to add liquidity for. In most cases, a protocol would sell its native token at a discount to acquire an asset to pair it with (e.g. USD). At Tenderize, however, TenderTokens will be sold at a discount in return for their underlying counterpart, which can then be added as liquidity for the underlying tokens in TenderSwap.

If existing fees in the treasury aren’t sufficient to bring liquidity to desired levels, then Tenderize’s native token could also be bonded to users in exchange for tokens needed by TenderSwap. Such an incentive structure distributes only the minimal required amount of WAGYU to incentivize liquidity. Bonds mature over time through vesting and pay out a fixed rate over time until maturity.

#### **Bond Pricing**

The bond price is expressed as the price paid for the assets that are received from bonding and is determined by taking the market price for the asset and applying a discount or premium. If liquidity is needed in the system, then bonds will be offered to the public at a discount. This happens when liquidity ratio is less than the target.

In the case of a discounted bond, more tTokens + WAGYU would be received from the bond compared to staking tokens or buying on the secondary market. This results in users selling assets to the protocol to bring the liquidity ratio up to target.

When there is no liquidity needed and the liquidity ratio is above target, bonds trade at a premium. When trading at a premium, the user will elect to buy assets on the open market instead, not buying the bond.

#### Inverse Bonding

Inverse bonding, as the name says, is the reverse of bonding. In the event of the liquidity ratio being significantly over the target ratio, the native token, WAGYU, will be redeemable for assets in the protocol’s treasury. This mechanism allows for WAGYU holders to extract value from the treasury without having to pay protocol dividends.


# Conclusion

Tenderize is optimized to be the base layer of liquid staked token and liquid staked defi movement. The liquidity approach utilized by the liquid staked protocols of today actively centralize the underlying netowork and must be redisgned. Thanks to Tenderize and the shared liquidity approach of TenderSwap, the crypto community can prioritize decentralization of the validator set without compromising on liquidity of their LST ecosystem.