# Tenderize

## Table Of Contents

1. [**Introduction**](#1-Introduction)
2. [**Glossary**](#2-Glossary)
3. [**TenderTokens**](#3-TenderTokens---Permissionless-Derivatives)
1. [Abstract](#31-Abstract)
2. [Existing Approaches](#32-Drawbacks-of-existing-approaches)
3. [Motivation](#33-Motivation)
4. [Solution](#34-Solution)
1.[Delegation Pools](#341-Delegation-Pools)
2.[Liquid Unstaking](#342-Liquid-Unstaking)
3.[Elastic Supply](#343-Elastic-Supply)
4.[Protocol Fees](#344-Protocol-Fees)
5. [Protocol Risks](#35-Protocol-Risks)
1.[Slashing Risk](#351-Slashing-Risk)
2.[Smart Contract Security](#352-Smart-Contract-Security)
3.[Arbitrary Node Commissions](#353-Arbitrary-Node-Commisions)
5. [**TenderSwap**](#4-TenderSwap---Efficient-Liquidity)
1. [Abstract](#41-Abstract)
2. [Motivation](#42-Motivation)
3. [Solution](#43-Solution)
1.[TenderPools](#431-TenderPools)
2.[Debt Ratio](#432-Debt-Ratio)
3.[Price Function](#433-Price-Function)
4.[Slippage](#434-Slippage)
7. [**Protocol Owned Liquidity**](#5-Protocol-Owned-Liquidity---Ensuring-Stability)
1. [Abstract](#31-Abstract)
2. [Motivation](#32-Motivation)
3. [Solution](#33-Solution)

## 1. Introduction

Tenderize (🥩,🔨) is a liquid staking protocol that connects web3 protocols and their economics with DeFi. It allows you to earn rewards on your staked assets without lockups and use them across the DeFi ecosystem.

Liquid staking through the Tenderize protocol is an alternative to locking up a user’s stake: it allows for users to stake any amount of collateral tokens and effectively retain access to their assets even though they are staked and locked up for several days or weeks in a smart contract. This is done through the issuance of a tokenized version of the staked funds — a sort of derivative — which can be transferred, stored, collateralized, spent or traded as one would a regular token. The design goals for the Tenderize protocol is to be trust minimized, decentralised and self-sustainable.

Our approach to Liquid Staking is that of a middleware protocol that acts as a proxy to existing staking protocols while minimizing obstructions to existing workflows, protocol dynamics and mechanics. Through Tenderize node operators and their delegators will be able to have distinct liquid staking derivatives.

The goal of Tenderize is to make staked assets for web3 protocols more accessible and capital efficient for all stakeholders of a network; node operators, token holders and the demand side. Tenderize has a heavy focus on web3 protocols because of their revenue potentials rather than purely relying on inflationairy token emissions.

To make this possible the Tenderize protocol consists out of three high-level components:

- **TenderTokens** - derivative tokens that represent staked assets 1:1 and act as delegation pools

- **TenderSwap** - an automated market maker specifically designed for liquid staking derivatives and shared collateral liquidity

- **Protocol Owned Liquidity** - a mechanism ensuring that the liquidity acquired is permanently allocated as part of the treasury

## 2. Glossary

- **Collateral**: the underlying asset which is deposited in return for tenderTokens
- **TenderToken**: liquid staking derivative that represent a 1:1 claim to collateral
- **TenderSwap / Liquidity Pool (LP)**: automated market maker mechanism for being able to trade TenderTokens with their collateral
- **Liquidity**: the collateral and TenderTokens in a TenderSwap liquidity pool
- **Protocol Controlled Value (PCV)**: the amount of collateral the protocol controls from deposits, this is a combination of staked collateral and collateral pending to be staked/unstaked
- **Protocol Owned Liquidity (POL)**: The amount of liquidity held by the protocol for a certain tenderToken
- **Risk Free Value (RFV)**: The nominal value of liquidity held by the protocol versus the outstanding supply of tenderToken
- **Reserve Ratio**: The ratio between POL and PCV
- **Target Reserve Ratio**: The target value for how much liquidity reserves the protocol should hold (as decided by governance)
- **Treasury**: all funds that are owned by the DAO (PCV is not owned by the DAO)

## 3. TenderTokens - Permissionless Derivatives

### 3.1 Abstract

The Tenderize protocol takes a novel approach to liquid staking. Instead of acting as an aggregator it aims to be unopinionated, trustless and permisionless. There are no validator queues or permisionned whitelisting, no manual intervention or off-chain oracles to update staked amounts. Instant liquidity through TenderSwap is always optional as TenderTokens retain the behaviour of unstaking.

TenderTokens are a tokenized version of staked, locked assets and are 1:1 equivalent to collateral. They are bound to a node operator, their yield is directly tied to the performance of this node. Any node on a network can have its own TenderToken which can be used by the node operator and token holders to allocate stake towards this node. Effectively allowing any network stakeholder to collateralise or get access to instant liquidity.

We believe that a liquid staking protocol should be neutral. It should act as a proxy to the underlying staking protocol and add value for staked assets while minimizing obstructions to existing mechanics and workflows. An additional benefit of Tenderize's neutral approach is that regardless of how much market share the Tenderize protocol gains, it does not increase centralisation of stake towards a few node operators.

### 3.2 Drawbacks of existing approaches

The current general approach to liquid staking is to act as a yield aggregator. User deposits are aggregated into a smart contract, an IOU derivative is issued to the user and then the protocol or DAO allocates aggregated deposits to various node operators on the network they operator on. Regularly the DAO will (through manual intervention of an agent) process any staking rewards which updates the balances for the derivative token.

More often than not this process is (semi-)custodial and current liquid staking protocols are opinionated on where funds are allocated. They act as yield aggregators where profits and losses by different node operators are socialized across everyone.

There's clear negative side effects to this approach in terms of trustlessness and centralisation, a DAO or multisig is responsible for allocating user deposits, processing staking rewards on a regular basis and determining to which nodes stake is allocated.

The other big problem is that it leaves out one of the most important stakeholders, the actual node operators. Since stake is split among a set of nodes which might not include them. This leads to cartelisation and centralisation of stake risk and leaves node operators on the sidelines even though they are major stakeholders who likely own a lot of tokens and have the highest cash flows through actually running nodes.

### 3.3 Motivation

At Tenderize we believe in core web3 principles, which does not only involve ownership of protocols you use but also trust minimization, permisionlessness and inclusion. Our opinion is that we should not sacrifice these principles when designing a liquid staking protocol. Furthermore we believe that a liquid staking protocol should be created in such a way that it is unopinonated, it should not significantly alter existing mechanics or favor "signed-up" node operators over others, a liquid staking protocol should merely act as a proxy for instant liquidity and collateralisation of locked up assets.

### 3.4 Solution

#### 3.4.1 Delegation Pools
TenderTokens represent staked assets 1:1. TenderTokens are ERC-20 based tokens for EVM based networks and are rooted on the chain their underlying protocol also lives (e.g. Livepeer is on Arbitrum so tLPT is rooted on Arbitrum).

For any collateral token there can be as many TenderTokens as there are node operators on that network, each TenderTokens acts as a delegation pool towards a node operator. A delegation pool acts a proxy for delegators to stake towards a node operator while gaining the full benefits provided by Tenderize. By doing this instead of aggregating stake towards a basket of node operators we ensure that Tenderize doesn't cause centralisation risks to the underlying protocol. This design takes a bottom-up approach as it still allows anyone to easily build liquid staking pools and aggregators by combining different TenderTokens from different delegation pools.

Each delegation pool has a stake ratio $r$ based on how much collateral is staked $c_i$ in it relative to the collateral in all delegation pools $C$ for a specific collateral token $r_i = \frac{c_i}{C}$ .


When collateral is deposited in Tenderize towards a node operator the amount of TenderTokens minted in return is equal to the effective amount of collateral that will be staked through Tenderize in the underlying protocol.

#### 3.4.2 Liquid Unstaking
As a delegation pool, Tenderize uses the primary staking markets to the fullest. We already mentioned that collateral is staked through Tenderize, but also unstaking from the underlying protocol is possible. This is done by burning an amount of TenderTokens and unstaking an equivalent amount of collateral in return. Once the unstaking period in the underlying protocol finishes the funds can be withdrawn. This is very much desirable such that a liquidity pool isn't the only exit option.

To take this a step further, pending withdrawals are represented as non-fungible assets under the ERC-721 standard. The owner of the NFT will be eligible to execute the withdrawal once the unbonding period completes, upon withdrawal the NFT is burnt. This enables trading (e.g. OTC) of pending withdrawals to acquire instant liquidity, even when unstaking.


#### 3.4.3 Elastic Supply

TenderToken supply is elastic and can grow or shrink based on whether the node operator for a delegation pool earns staking rewards for providing valuable work, or is being slashed due to bad behaviour. Elastic supply tokens are useful because user balances grow or shrink automatically.

This is done effectively through share based accounting so that user balances wouldn't have to be updated individually. A user's TenderToken balance is equal to the user's equity share of the delegation pool's staked collateral.

$balance_u = collateral_i * \frac{shares_u}{totalShares_i}$

When a user deposits collateral or unstakes TenderTokens the shares received or burnt is calculated according to the actual exchange rate.

$fx = \frac{totalShares}{collateral}$

$shares = amount * fx = amount * \frac{totalShares_i}{collateral_i}$

Here's an example where Alice and Bob both hold differend equity shares of a TenderTokens delegation pool. Initially the total amount of collateral is 300 tokens for 150 total shares. As 100 rewards come in the collateral changes to 400 and the calculated balance for Alice and Bob is automatically updated.


#### 3.4.4 Protocol Fee

To support growth of the Tenderize protocol a configurable fee can be charged on staking rewards that go to the Tenderize treasury.

### 3.5 Protocol Risks

#### 3.5.1 Slashing Risk

Node operators and its delegators in various web3 protocols are often subject to staking penalties and slashing when behaving misconducting (e.g. long down-time, performing bad work, ...). While Tenderize doesn't mitigate the risk as derivatives are bound to their node operator, the fees charged by the Tenderize protocol could be used as insurance and the node operator blacklisted in case of consistent misconduct.

#### 3.5.2 Smart Contract Security

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 its releases should have underwent security audits.

#### 3.5.3 Arbitrary Node Commissions

Node operators on the network can arbitrarily change their commission rates to draw rewards from delegations through Tenderize. This problem already exists for delegators in the underlying protocols as is however, Tenderize acts as another delegator. However should this happen, it would likely cause staked assets to move towards different node operators offering more favorable rates. The risk for users can be mitigated by providing the necessary UX and tooling to offer an optimal and informed experience.

### 3.6 Conclusion

Liquid staking has recently seen a big rise in adoption thanks to stETH, but existing designs come with a few shortcomings and don't create much utility for node operators themselves. We described a design for liquid staking as a middleware protocol rather than an aggregator. By retaining the existing workflows of the underlying protocols we can achieve a protocol that unlocks new use cases and capabilities for staked assets while remaining neutral, permisionless and avoiding centralisation risks.

## 4. TenderSwap - Efficient Liquidity

### 4.1 Abstract

Automated Market Makers (AMMs) as popularized by Uniswap have completely changed the way in which digital assets are exchanged by removing the need for intermediaries (active makers and takers which exchange buy/sell orders in an exchange). Instead it relies on a reserve pool of two or more assets and an invariant curve to determine the relationships of the tokens in a pool. The larger a trade relative to the total size of the reserves, the more price slippage will occur. A later iteration by Curve.fi saw the birth of StableSwap, an iteration of AMMs that provides more capital efficiency for stablecoins by using a different mathematical curve.

### 4.2 Motivation

While these AMMs have revolutionized the world of DeFi each in their own regard, neither is a particular great fit for Liquid Staking Derivatives. One characteristic of most Liquid Staking Derivatives is that they have an elastic supply which provides usability challenges when wanting to use existing solutions.

Furthermore, permissionless staking derivates were previously deemed impossible because of non-fungability of staked assets between validators, TenderSwap solves this problem in a way that doesn't result in fractionalized liquidity. Tenderize achieves high capital efficiency by effectively sharing collateral liquidity among different derivates.

### 4.3 Solution

TenderSwap provides instant liquidity between TenderTokens and collateral with minimal slippage and high capital efficiency.

TenderSwap pools work natively with tokens that have an elastic supply as many liquid staking derivatives do, which eliminates many usability challenges for these tokens in existing AMM protocols.

It's biggest game-changer however is that despite the possiblity of there being multiple TenderTokens (one per node) for a single collateral token and that these TenderTokens are non-fungible among eachother (nodes perform differently), TenderSwap is able to effectively share collateral liquidity among TenderTokens rather than having separate liquidity pools for each TenderToken.

#### 4.3.1 TenderPools

In TenderSwap each collateral token is connected to a number of registered derivatives to make up a **TenderPool**. The collateral asset acts as the root asset through which trades between derivatives, or from derivative to collateral and vice versa can happen.


#### 4.3.2 Debt Ratio

Each token inside a TenderPool exists as a balance sheet statement. A balance sheet contains **assets**, the pool balance of a particular token, and **liabilities**, the amount of debt outstanding to liquidity providers.

The ratio between assets $A$ and liabilities $L$ is the **debt ratio** $d$ and is calculated as $d=\frac{L}{A}$.

If the debt ratio is greater than 1 there is an outstanding debt to liquidity providers. This debt is covered by allowing liquidity providers to withdraw from a token inside a single TenderPool of which the debt ratio is smaller than 1.


When a swap happens from e.g. tLPT_1 to LPT, the assets of tLPT_1 would increase and those of LPT would decrease, as tLPT_1 tokens are added and LPT is removed. The liabilities would remain the same. Thus the debt ratio of LPT would decrease and that of tLPT_1 increase.

#### 4.3.3 Stake Ratio

The stake ratio $r$ is a value between 0 and 1 that represents how much collateral is staked for a TenderToken relative to all the amount of a particular collateral staked across all its derivatives.

It is used to determine the fractional amount of assets of collateral a particular TenderToken is able to use when swapping to or from it. While this doesn't affect the debt ratio for collateral directly, it does affect the impact a swap has on its delta, based on the amount of collateral assets that can be used. This means that TenderTokens that have less value locked will incur a bit more slippage in order to fairly share collateral among derivatives in a TenderPool.

The *effective* assets and liabilities for collateral that can be used during a swap are defined as

$A_c = A_c * r$

$L_c = L_c * r$

The stake ratio is fetched through an on-chain oracle, in the case of Tenderize from the Tenderizer contract for the collateral.


#### 4.3.5 Debt Ratio Decay

Instead of recalculating the debt ratio after a swap there should be a decay from the effective debt ratio after the swap back to the newly calculated available assets in underlying tokens according to the stake ratio. This acts like a gradual dutch auction (GDA) whereby slippage decreases over time capped at it's max effective debt ratio until a buyer steps in.

#### 4.3.5 Price Function

TenderTokens are exchangeable 1:1 for their collateral and vice versa so we consider the exchange rate to be fixed. Instead the execution price is totally determined by slippage.

For swapping an amount of $a_i$ from token $i$ to $j$ the amount received $y$ is calculated as the input amount minus the slippage $S_{i_{}\rightarrow{j}}$ :

$f(y_{i}{_\rightarrow}{_j}) = a_i - a_i * S_{i_{}\rightarrow{j}}$

This can be done because on one hand collateral is always depositable in the Tenderizer to receive TenderTokens 1:1.

On the other hand TenderTokens themselves can be unstaked on the primary staking market for their collateral which only carries a time value of money risk. This negative carry offsets any possible premium from TenderTokens being a productive asset.

#### 4.3.6 Slippage

As determined earlier, the amount of tokens you receive when you swap an amount $a_i$ is determined by slippage.

In TenderSwap slippage is calculated differently than in a constant product market maker. Slippage is calculated in function of the change in debt ratios between tokens in a TenderPool when making a swap.This encourages convergence of debt ratios towards equilibrium

Since a swap consists out of the debt ratio changing for two tokens, the total slippage $S_{i_{}\rightarrow{j}}$ on a trade is calculated as the difference of the slippage that occurs for token $i$ and $j$ :

$S_{i_{}\rightarrow{j}} = S_i - S_j$

Actions that converge the debt ratios for the two tokens will be given a reward ($S_{i_{}\rightarrow{j}}$ is negative). On the other hand, actions that move the debt ratio of the two tokens further from equilibrium will be charged a penalty ($S_{i_{}\rightarrow{j}}$ is positive).

##### Slippage Function

The slippage function is a sigmoid function $s(d)$ that maps a tokens debt ratio $d$ to a slippage value between 0 and 1 for its balance sheet. We want to define $s(d)$ so that slippage increases in function of the debt ratio increasing, i.e. higher debt ratio means higher slippage.

$s(d) = \frac{1}{1+ke^{-nx}}$

Here is an example of such function:


*$k$ and $n$ are constants, this function is not final merely acts as a representation for a sigmoid function.

##### Calculating slippage

With the slippage function we can solve for the slippage on each tokens balance sheet by solving the following equation where $d$ is the debt ratio before the swap and $d'$ after the swap:

$S = \frac{s(d') - s(d)}{\triangle{d}}$

$S_{i_{}\rightarrow{j}} = S_i - S_j = \frac{s(d_i') - s(d_i)}{\triangle{d_i}} - \frac{s(d_j') - s(d_j)}{\triangle{d_j}}$

#### 4.5.4 Swap Fee

A configurable swap fee is charged on the output amount of the swap which is split to liquidity providers proportional to the liquidity provided.

#### 4.5.5 Protocol Fee

## 5. Liquid Basket

A liquid basket is made up of several of the individual derivatives tied to a node operator.

## 6. Protocol Owned Liquidity - Ensuring Stability

### 6.1 Abstract

*Protocol owned liquidity (POL)* is a new approach to create liquidity on decentralised exchanges (e.g. Uniswap), pioneered by OlympusDAO. Instead of relying on constant token emissions to market participants for providing liquidity for assets, the protocol owned liquidity model instead utilises a *“bonding”* mechanism.

Bonding essentially involves the protocol selling its native tokens ($TENDER) at a discount to buyers, who in exchange will provide another token (collateral or liquidity), which forms part of the protocol’s treasury. The treasury can then be deployed to provide liquidity directly to DEXs (earning trading fees), facilitate market operations like arbitrage and can be invested to generate returns.

### 6.2 Motivation

*Protocoled Owned Liquidity* is an innovative solution to the mercenary capital problem, whereby protocols engage in a so-called “race to the bottom” to provide higher and higher incentives from token emissions to attract liquidity providers, in-turn diluting the value of the protocols through the high issuance of tokens. Once incentives decrease, mercenary capital can easily reallocate to where it is most profitable, leaving you with no liquidity and a heavily diluted value for the protocol.

Instead *POL* ensures that the liquidity acquired is permanently allocated as part of the treasury. This in turns acts as value accrual for the token ($TENDER) rather than dilution.

Liquid Staking Protocols are required to maintain a healthy amount of liquidity to operate effectively. This protects TenderToken holders and ensures there is always locked exit liquidity available and sufficient market depth for price oracles to work securely.

By owning a sufficient amount of liquidity the protocol can also engage in facilitating market operations such as arbitrage to maintain price stability for TenderTokens.

### 6.3 Solution

TenderSwap liquidity pools act like a fractional reserve for staked assets but utilising a price curve, they allow for instant liquidity between TenderTokens and collateral in both ways. To achieve sufficient reserves at all times, the Tenderize protocol will acquire liquidity by selling its native $TENDER token at a discount as long as a target reserve ratio isn't reached.

#### Reserve Ratio

The amount of *Protocol Owned Liquidity (POL)* should be in function of the amount of *Protocol Controlled Value (PCV)* and the *Target Reserve Ratio*. This ensures that the protocol always strives to maintain a specific amount of liquidity.

#### Bonding

Bonding allows Tenderize to acquire liquidity for TenderTokens by selling $TENDER at a discount in exchange for these assets (collateral and liquidity), with a preference for collateral.

When a Bond is purchased, the purchaser is quoted with the amount of $TENDER tokens received for the given assets as well as a vesting term and bond price.

##### Bond Pricing

A bond price is the price paid for the $TENDER tokens compared to the provided assets (collateral or liquidity). It determined by the market price of assets with a discount or premium applied to it

###### Discount / Premium

The protocol will charge a discount on the bond price (the buyer pays less than the market price for $TENDER) when the Reserve Ratio is smaller than the Target Reserve Ratio.

Bond purchasers will pay a premium (more than the market price for $TENDER) in case the Reserve Ratio is greater than the Target Reserve Ratio.

The greater the divergence between Reserve Ratio and Target Reserve Ratio, the greater the premium and discounts are.

###### Bond Pricing for Collateral

Bond pricing for collateral will be based on the market price for the collateral vs $TENDER with the addition of a discount or premium

###### Bond Pricing for Liquidity

Because liquidity bears more risk than collateral it will be priced lower than collateral. The price for TenderToken part of the liquidity provided will be adjusted based on market conditions and a discounter for the time-risk involved in case they need to be unstaked

#### Collateral Bonds

#### Liquidity Bonds

### Permissionless Liquid Staking Design Goals

- Liquid staking derivatives for any validator, rather than aggregation

- Efficiently share collateral liquidity among derivatives to avoid liquidity fractionalisation

- Allow for easy modular addition of new types of collateral by DAO approval

- Allow for TenderTokens to easily integrate with other protocols to provide utility, adhere to existing standards (e.g. ERC-20)

- Minimal trust assumptions, no DAO interventions needed for individual tenderTokens at the very least