Whitepaper

Search…
Whitepaper
Abstract
The DeFi ecosystem is evolving daily with constant emergence of innovative products. In the highly volatile crypto world, users are increasingly seeing the importance of having proper DeFi products that minimize their risk. There is an increasing demand for innovative and robustly designed asset management protocols that cater to different users with varying risk appetites.
Tranchess is a yield enhancing asset tracker with varied risk-return solutions. Inspired by tranche funds’ ability to satisfy users’ varying risk appetites, Tranchess aims to provide a different risk/return matrix out of a single main fund that tracks a specific underlying asset (e.g. BTC). The main tranche can be split into two sub-tranches with their own distinct risk-return profile.
Tranchess Protocol is not just a standalone asset management ecosystem, but encompasses many features one can require in the DeFi space. It is a one-stop centre for those that want to enjoy a full suite of DeFi features such as single-asset yield farming, borrowing & lending, trading, etc.
Tranchess aims to provide long-term solutions in the DeFi space. Asset management has long been an integral and crucial part of the financial sector. Whereas there are interesting protocols in the DeFi space, Tranchess is the first of its kind product that hopes to act as a benchmark asset management solution and a trading ecosystem with innovative tools to cater to both amateur and professional trading.

Introduction
Overview of Defi
2020 was a great year for DeFi, with Compound kicking off the yield-farming craze in June via the launch of its $COMP token. Currently, over $118B are locked in DeFi protocols, with about $26B on Binance Smart Chain (BSC).
Source: https://defillama.com
  Source: https://www.defistation.io/
Decentralized Exchanges (DEX) such as Uniswap have also seen tremendous growth averaging above $1B in volume from August 2020 and also saw the monthly trade volume exceeding Coinbase in September 2020. Uniswap revolutionized the DEX space with its Automated Market Maker (AMM) model, using mathematical formulas to derive the price of a token. With the AMM model, users could provide liquidity and market make for a fee (0.3%), while buyers were able to get their bids filled at the current price. Since then, there have been further innovations in the space - such as Curve’s more sophisticated formula for stable coins, or Dodo’s Proactive Market Maker (PMM) model. 
In 2021, PancakeSwap, a new AMM on BSC, saw tremendous growth. With Ethereum’s ongoing congestion and high gas price, many users turned to for the significantly lower transaction fees. Currently, PancakeSwap has overtaken Uniswap in terms of trading volume and daily number of users.
https://insights.deribit.com/market-research/pancakeswap-the-amm-eating-everyone-elses-breakfast/
https://insights.deribit.com/market-research/pancakeswap-the-amm-eating-everyone-elses-breakfast/
In the Decentralized Margin Exchange space - dYdX, 0x and Derivadex have released products that offer up to 10x leverage. Without the need for KYC, users can now trade on the platforms running on smart contracts with no intermediaries. 
Asset Management
Before the rise of DeFi asset management protocols, traditional asset management tools could have been perceived as confusing, mysterious, or even intimidating due to their complex designs and structures. DeFi protocols attempt to break down some of these complexities and rebuild them with the efficiency and transparency of blockchain contracts, allowing anyone to participate and reap the benefits of well-designed asset management tools and customize portfolios to best suit their needs.
In the Defi space, projects such as Yearn Finance (YFI) sought to be the asset manager or robo-advisor of Defi. Users would deposit into their vaults which would seek and optimize for the best yield across the Defi ecosystem. Currently, YFI has over $4B AU M across 14 different vaults. In the past months, YFI went on an acquiring spree, merging with protocols that have synergies with YFI such as Pickle, Cover, Sushi, Cream and Akropolis. This allowed Yearn to expand their product offerings and in turn achieve greater yield. 
Whilst many issues within the DeFi space have been tackled, there remain many more to be addressed. Upon entering the market, the Tranchess team spotted some issues that have previously been ignored, hence leading to the development of the Tranchess Protocol. The goal of the protocol is to resolve some of these pain points, and hopefully provide all the missing pieces to the complete DeFi that had been observed in the current asset management sector of the DeFi market.

Pain Points
Crypto Asset Holder vs. Index Enhanced Yield: A significant number of users in the market, mainly institutional, hold long-term positions in major crypto assets like BTC. Their needs are:
1.Flexible and convenient primary market redemption, with high redemption frequency, and short or zero lock-in period.
2.Convenient secondary market trading with high liquidity.
3.Preferably with stable enhanced returns, so that investors can get both the β return as price goes up and the improved return known as α.
Steady Return Yield vs. Uncompensated Loss/Impermanent Loss: A risk-averse user usually prefers stable investment returns with little or no investment loss. However, there aren't many investment options in the current DeFi market that suits those needs, and the existing ones all come with noticeable vulnerabilities. Most mainstream liquidity mining products currently available on DeFi exchanges are subject to uncompensated losses from price volatility, magnified as actual volatility increases, hence putting investors at risk of realizing their impermanent loss. Low fund efficiency can also be a concern as, for most AMMs, users need to put in equal value of two assets to generate LP tokens, which are then staked into farming pools. Lending protocols can be considered as single asset yielding, but returns are generally low and unstable. Of course, we’ve seen increasing solutions of debt aggregators trying to optimize the returns for risk-averse investors while maintaining its stability, which is normally achieved by partially sacrificing the underlying yield.
​
Leveraged Positions vs. High Margins: Aggressive investors are committed to maximizing their investment returns by using leverage in a one-sided market. Still, in the DeFi world, leveraged futures products cannot do real-time price matching, settlement, or forced liquidation like centralized exchanges can due to reasons such as high gas fees and congestion on the chain during extreme market situations. And to reduce the risk of forced liquidations, they must increase the margin, which greatly sacrifices the capital utilization rate and profitability of the investors. A leveraged derivative with high capital utilization, low cost, and no risk of liquidity loss is the primary demand of this group of investors.
​
Oracle Attacks vs. TWAP: Many Defi Protocols have a reliance on trusted price feeds, and most protocols take an isolated tick price from the oracle’s price feed which is updated frequently. This is highly vulnerable to oracle attacks and exploits, especially during times of extreme market volatility.
The Tranchess Protocol
Overview
Tranchess, in simple terms, is a tokenized structured fund protocol. The protocol is inspired by structured funds that cater to users with varying risk appetite. Tranchess consists of three tranche tokens (QUEEN, BISHOP, and ROOK) and its governance token CHESS. Each of the three tranches is designed to accede the needs of different group of users: stable return yielding (Tranche BISHOP), leveraged crypto asset trading (Tranche ROOK), and long-term crypto asset holding (Main Tranche QUEEN).
Tranchess 1.0 will be a fund that tracks BTC's performance directly. In theory, Tranchess can track any single crypto asset or basket of crypto assets.
Main Tranche and Token QUEEN
The main fund, or token QUEEN, is a BTC-tracking token with yield farming feature. QUEEN’s Net Asset Value (NAV) tracks the BTC price on a fully correlated basis (with deduction of management fees).
Rather than holding BTC passively, investors can now swap their BTC for token QUEEN via a ‘creation process’ or buy from the “Exchange” with USDC. In doing so, they will have the exact same BTC exposure and benefit from the additional ability to farm Tranchess’s CHESS tokens for further yield enhancement. CHESS is also vital to receiving additional rebates in the form of BTCB to encourage veCHESS holders to participate in the activities and development of the protocol. Upon any intention to exit, investors can simply swap their token QUEEN back to BTC via the redemption process.
Token QUEEN can be further split into/merged from two sub-tranches, Token BISHOP and Token ROOK.
APY of QUEEN
Tranchess defines the QUEEN’s APY as the estimated annualized percentage yield of CHESS rewards, compounded manually on a daily basis. The basic daily yield is calculated following the formulas below:
BaseDailyYield(QUEEN)=RC×PC×WQUEENWOS×NAVQUEEN×WQUEEN BaseDailyYield\big(QUEEN\big) = \frac{ R_{C}  \times  P_{C}  \times  W_{QUEEN} }{ WO_{S}  \times  NAV_{QUEEN}  \times  W_{QUEEN} } BaseDailyYield(QUEEN)=WOS​×NAVQUEEN​×WQUEEN​RC​×PC​×WQUEEN​​
DailyYieldRange=[BaseDailyYield,BaseDailyYield×3]Daily YieldRange=[BaseDailyYield, BaseDailyYield\times3]DailyYieldRange=[BaseDailyYield,BaseDailyYield×3]
UDYQUEEN=BaseDailyYield(QUEEN)×WOQ/WEQ UDY_{QUEEN} =BaseDailyYield \big(QUEEN\big)  \times  WO_{Q}  /   WE_{Q} UDYQUEEN​=BaseDailyYield(QUEEN)×WOQ​/WEQ​
Tranche BISHOP and Token BISHOP
Tranche BISHOP is a sub-fund of the main fund. BISHOP token holders provide liquidity to Tranche ROOK holders and earn a stable interest income on a daily basis. Since the nature of BISHOP is market neutral, i.e delta = 0, Bishop collects a fixed return that is not affected by market volatility. The APR is a predetermined number, protecting the returns from market exposure and price changes of BTC. In other words, Tranche BISHOP acts like a high yield savings account. On a weekly basis, the protocol uses Venus’s Borrow rate from the previous week to calculate a weekly average. This weekly average also has an additional premium which is determined by community voting - This is taken into account as part of the interest rate formula established by the Tranchess team. The total weekly yield is then set as BISHOP's fixed APR for the next week. There is NO lock-up period. 
Users can get BISHOP by:
1) Splitting QUEEN into 0.5 BISHOP and 0.5 ROOK and selling ROOK on Tranchess Swap or
2) Buying BISHOP directly on Tranchess Swap.
APY of BISHOP
Tranchess defines BISHOP’s APY as the estimated annualized percentage yield of both CHESS rewards & lending returns earned from ROOK, compounded manually on a daily basis. By definition, BISHOP’s APY constitutes two parts: 
​APYBISHOP=[(UDYBISHOP+1)365−1]+APYInterestRateTop−UpAPY_{BISHOP} = [(UDY_{BISHOP} +1) ^{365} -1]+APY_{InterestRateTop-Up}APYBISHOP​=[(UDYBISHOP​+1)365−1]+APYInterestRateTop−Up​
 
​APYInterestRateTop−Up=(DailyInterestRate+1)365−1APY_{InterestRateTop-Up}=(Daily InterestRate +1) ^{365}-1APYInterestRateTop−Up​=(DailyInterestRate+1)365−1
 
BaseDailyYield(BISHOP)=RC×PC×WBISHOPWOS×NAVBISHOP×WQUEENBaseDailyYield\big(BISHOP\big) = \frac{ R_{C}  \times  P_{C}  \times  W_{BISHOP} }{ WO_{S}  \times  NAV_{BISHOP}  \times  W_{QUEEN} } BaseDailyYield(BISHOP)=WOS​×NAVBISHOP​×WQUEEN​RC​×PC​×WBISHOP​​
DailyYieldRange=[BaseDailyYield,BaseDailyYield×3]Daily YieldRange=[BaseDailyYield, BaseDailyYield\times3]DailyYieldRange=[BaseDailyYield,BaseDailyYield×3]
UDYBISHOP=BaseDailyYield(BISHOP)×WOBR/WEBR UDY_{BISHOP} =BaseDailyYield \big(BISHOP\big)  \times  WO_{BR}  /   WE_{BR} UDYBISHOP​=BaseDailyYield(BISHOP)×WOBR​/WEBR​
Daily Interest Rate = VENUS Borrow Rate/7 + Interest Rate Ballot Result/365
Tranche ROOK and Token ROOK
Tranche ROOK is the other half of the split main tranche (half ROOK, half BISHOP). This is a leveraged product with no forced liquidation. ROOK holders borrow daily from BISHOP holders to gain leveraged exposure to the main fund tracking BTC. ROOK holders receive all gains and losses of the main fund, i.e., ROOK's return = the profits and losses of the main fund - the interest paid to BISHOP holders. Tranche ROOK realizes a leveraged portfolio by borrowing equity from Tranche BISHOP. Tranche ROOK does not run the risk of forced liquidation, unlike leveraged products currently on the market, because it is borrowing from within the main tranche.
APR of ROOK Staking
Tranchess defines the staking APR as the estimated annualized percentage return of CHESS rewards. The basic daily yield is calculated following the formulas below:
BaseDailyYield(ROOK)=RC×PC×WROOKWOS×NAVROOK×WQUEENBaseDailyYield\big(ROOK\big) = \frac{ R_{C}  \times  P_{C}  \times  W_{ROOK} }{ WO_{S}  \times  NAV_{ROOK}  \times  W_{QUEEN} } BaseDailyYield(ROOK)=WOS​×NAVROOK​×WQUEEN​RC​×PC​×WROOK​​
DailyYieldRange=[BaseDailyYield,BaseDailyYield×3]Daily YieldRange=[BaseDailyYield, BaseDailyYield\times3]DailyYieldRange=[BaseDailyYield,BaseDailyYield×3]
UDYROOK=BaseDailyYield(ROOK)×WOBR/WEBR UDY_{ROOK} =BaseDailyYield \big(ROOK\big)  \times  WO_{BR}  /   WE_{BR} UDYROOK​=BaseDailyYield(ROOK)×WOBR​/WEBR​
Tranchess Mechanisms and Protocol
Tranchess Primary Market
The Primary market is where creation/redemption and split/merge transactions happen.
Creation and Redemption of QUEEN
Creation is when a user exchanges BTC for QUEEN while redemption, on the other hand, is when a user exchanges QUEEN for BTC. Creation and Redemption requests can be submitted anytime and will be processed at a pre-determined time once daily. The daily settlement time for creation and redemption requests is currently preset at 14:00 UTC.
Pending Requests Cycle: The new cycle of submitting Creation/Redemption requests starts from 14:15 UTC to 14:00 UTC the next day.
Cancelling Requests: Submitted requests cannot be cancelled.
Requests Settlement and Delivery: After 14:00 UTC every day, Tranchess will automatically calculate the NAV (Net Asset Value) of the main fund based on the oracle’s price feed. The amount of QUEEN that can be created with BTCB, or the amount of BTCB that can be redeemed with QUEEN, is determined by a specific conversion ratio. The conversion ratio is calculated by the formula below: 
ConversionRatioT=NOST−QBTCBT−ConversionRatio_{T} =  \frac{ NOS_{T-} }{ QBTCB_{T-} } ConversionRatioT​=QBTCBT−​NOST−​​
Creation and Redemption Fee: No fee for Creation. Redemption fee is 0.2% of the principal amount.
Split and Merge
At any time, except during the settlement of Creation/Redemption requests or Rebalancing (outlined in the later section), users can convert QUEEN into BISHOP and ROOK, and vice versa. The specific conversion formula is:
NOSQU,t=NOSBU,t+NOSRU,t2NOSQ_{U,t} = \frac{ NOSB_{U,t} + NOSR_{U,t} }{2} NOSQU,t​=2NOSBU,t​+NOSRU,t​​
Split: the process of QUEEN holders exchanging QUEEN for half BISHOP and half ROOK.
Merge: the process of exchanging half of BISHOP and half of ROOK for one portion of QUEEN.
Split/Merge Request Submit Time: Split and merge requests can be submitted at anytime.
Split/Merge Request Settlement: When the protocol receives a request, the smart contract will automatically transfer the converted tokens to the requestor in the next block.
Split/Merge Fee: 0.05% of the principal amount.
Settlement
Normally, the daily settlement lasts for 15 minutes every day from 14:00 UTC to 14:15pm UTC, during which the Create/Redeem and Split/Merge functions are temporarily suspended.
When a Rebalance (refer to 3.3 for a detailed explanation) takes place, the settlement will take 12 hours. Primary Market functions, both Create & Redeem and Split & Merge, will be suspended from 14:00 pm UTC till 02:00 UTC on the next day.
Tranchess Swap
Tranchess Swap is the secondary market where users purchase QUEEN, BISHOP and ROOK directly with USDC. In Tranchess 2.0 and later versions, as we list more new funds, tokens listed on Tranchess Swap might be differentiated by the underlying asset they track, i.e. QUEENBTCQUEEN_{BTC}QUEENBTC​
, QUEENETHQUEEN_{ETH}QUEENETH​
,BISHOPBTCBISHOP_{BTC}BISHOPBTC​
, BISHOPETHBISHOP_{ETH}BISHOPETH​
,ROOKBSCROOK_{BSC}ROOKBSC​
, etc..
How to Trade
Tranchess Swap adopts a Premium-Discount Orderbook system. So rather than trading the live prices of tokens, the premiums or discounts of a forward-starting 30-minute TWAP (Time Weighted Average Price) are traded. Tranchess defines each 30-minute trading window as one epoch, and users can place orders within each epoch at the premium or discount of the NAV calculated from the TWAP of the next epoch’s price. For instance, at 9:45 am, Alice buys QUEEN from Bob on the order book at +25bps premium. This transaction's reference price will be the NAV for the next 30-min window, i.e., 10 am – 10:30 am, released at 10:45am.
Tranchess provides 81 prices, 40 premiums and 40 discounts, at a 0.25% interval, with max/min set at ±10%, listed in the order book mode. That is, users can place orders at -9.5%, -0.25%, 0, 2.75%, etc. During each epoch, Tranchess matches orders with orderbook mode, and the filled discount and premium orders will be used to calculate the final price. For example, Alice buys Token QUEEN at +25bps in the current epoch and the order is filled, the final price of Alice’s order will be: NAVQ,e×1.0025NAV_{Q,e}  \times 1.0025NAVQ,e​×1.0025
 
Post-Only Enabled
Checking the Post-Only box puts users in “Maker Mode”. Orders placed as post-only will enter the order book and list under Pending Orders. It won’t be executed immediately. Users cannot place cross trade orders.
Post-Only Disabled
When Post-Only is disabled, users enter the “Taker Mode”. All orders are filled or cancelled immediately against the existing orders listed on the order book. Completed orders are listed under Filled Trades.
In general, all users can always place Post-Only Orders. However, the swap function will be suspended for “takers” every day from 13:00 UTC to 14:30 UTC.
NAV Calculation
Tranchess uses the following formulas to calculate the NAV of each Tranche.
Latest NAV, Main Fund, Tranche QUEEN:
NAVQ,e=NAVQ,T−1×TWAPBTC,eTWAPBTC,T−1×(1−MRe,T−1)NAV_{Q,e} = NAV_{Q,T-1}  \times  \frac{ TWAP_{BTC,e} }{ TWAP_{BTC,T-1} }  \times(1- MR_{e,T-1} )  NAVQ,e​=NAVQ,T−1​×TWAPBTC,T−1​TWAPBTC,e​​×(1−MRe,T−1​)
Latest NAV, Tranche BISHOP:
NAVB,e=NAVB,T−1×max{1,(1−MRe,T−1)×(1+IRe,T−1)}NAV_{B,e} = NAV_{B
,T-1} \times max\big\{1,( 1-MR_{e,T-1} ) \times (1+ IR_{e,T-1} )\big\}NAVB,e​=NAVB,T−1​×max{1,(1−MRe,T−1​)×(1+IRe,T−1​)}
Latest NAV, Tranche ROOK:
NAVR,e=2×NAVQ,e−NAVB,eNAV_{R,e} =2 \times  NAV_{Q,e} - NAV_{B,e} NAVR,e​=2×NAVQ,e​−NAVB,e​
Premium-Discount Orderbook
In our approach, trading activities are divided into 30-minute epochs. Since the price oracle for the current epoch is still subject to change, both makers and takers are trading on premium-discount levels of the future net asset values.
Note that since the locked amount still belongs to the maker, it will collect rewards for the maker until finding a match. By locking the transfer of tokens, the Swap guarantees daily trade settlements under the assumption that the price oracles from N-2 and N epoch should not fluctuate much. However, when the price does rise or drop significantly, the deposit acts as a stop-loss mechanism, so that no matter how bad things get, the maker’s loss is limited to the amount paid upfront.
Similar to traditional Price-Time priority orderbooks, the smart contract arranges orders in Level-Time priority. Takers specify a certain percentage as the lowest or highest acceptable premium-discount level and match up with maker orders in the orderbook until either the order is filled or there are no more available orders within the allowed premium-discount levels.
Reference Price for TWAP Oracle
Since the Oracle is primarily used by Tranchess Swap, the oracle feeds are also divided into 30-minute epochs. To ensure that the 30-minute XXX/USDC (current option is BTCB) average price is fair, the Oracle currently adopts price feeds from Coinbase as the primary data source, because Coinbase exchange has relatively more liquid markets and is among the few that publicly support Open Oracle Protocol.
Empirically, the price feeds could suffer from service hiccups, resulting in missing data points during TWAP calculation. In addition, although message signatures should prevent malicious agents from twisting the TWAP to any values, it is still possible to gain advantage by deliberately excluding some of the data points. Hence, to make the oracle more robust, the contract does the following:
1.Allows up to 15 ticks missing within one epoch;
2.Interpolates the missing data points;
3.Allows data with better quality to be re-submitted in a limited timeframe before making the result official;
4.Adopts OKEx price feeds as the secondary data source after one hour without better data source feed
Oracle Gas Optimization
Maintaining the Oracle would require relatively more frequent on-chain operations, as a batch of 20-30 messages and signatures would be submitted to the smart contract every 30 minutes. To minimize gas usage:
1.Only prices are passed to the contract, and later encoded to messages within the contract.
2.Split signatures to lists of r, s, and v before passing to the contract.
3.In-memory operations within loops
Service during Rebalance
If a Rebalance was triggered at 14:00 UTC, the trading function for takers will be suspended until 02:00 am UTC on the next day. The same occurs on the Primary Market.
Users can continue to place Post-Only orders during this time. All orders placed before the Rebalance will be cleared from the order book and will no longer be filled. Users will find the Status of such orders changed into “Expired” under Pending Orders. Users can cancel the pending orders at any time.
Rebalance
Rebalance is designed to maintain a stable leverage rate, and is rarely triggered. Two things happen after Rebalance:
1.The NAVs of Tranche BISHOP and Tranche ROOK will be recalculated from 1 again. NAVB,T=NAVR,T=1NAV_{B,T} = NAV_{R,T} =1NAVB,T​=NAVR,T​=1
 
2.SplitRatio will be re-adjusted. newSplitRatio = oldSplitRatio* (NAVBpre−rebalanceNAVB _{pre-rebalance}NAVBpre−rebalance​
+NAVRpre−rebalanceNAVR_{pre-rebalance}NAVRpre−rebalance​
)/2
3.The amount of tokens changes to reflect the adjusted value.
Rebalance is triggered when NAVRook/NAVBishopNAV_{Rook} / NAV_{Bishop}NAVRook​/NAVBishop​
 is less than 0.5 or is more than 2. Here’s how the amount changes specifically.
When NAVROOKNAVBISHOP<0.5\frac{ NAV_{ROOK} }{ NAV_{BISHOP} }  < 0.5NAVBISHOP​NAVROOK​​<0.5
 
For Token ROOK holders, amount of Token ROOK after Rebalance:=
NOSRROOK,T=max{0,NOSRROOK,T−×NAVROOK,T−}NOSR_{ROOK,T} =max \big\{0, NOSR_{ROOK,T-}  \times  NAV_{ROOK,T-} \big\} NOSRROOK,T​=max{0,NOSRROOK,T−​×NAVROOK,T−​}
For Token BISHOP holders, amount of Token BISHOP after Rebalance:
NOSBBISHOP,T=max{0,NOSBBISHOP,T−×NAVROOK,T−}NOSB_{BISHOP,T} =max \big\{0, NOSB_{BISHOP,T-}  \times  NAV_{ROOK,T-} \big\} NOSBBISHOP,T​=max{0,NOSBBISHOP,T−​×NAVROOK,T−​}
Token BISHOP holders also receive extra token QUEEN:
NOSQBISHOP,T=NOSBBISHOP,T−×(NAVQUEEN,T−−max{0,NAVROOK,T−})×2NOSQ_{BISHOP,T} = NOSB_{BISHOP,T-}  \times (NAV_{QUEEN,T-} -max \big\{0,NAV_{ROOK,T-}\big\} ) \times 2NOSQBISHOP,T​=NOSBBISHOP,T−​×(NAVQUEEN,T−​−max{0,NAVROOK,T−​})×2
For Token QUEEN holders, amount of Token QUEEN after Rebalance:
NOSQQUEEN,T=NOSQQUEEN,T−×NAVQUEEN,T−NOSQ_{QUEEN,T} = NOSQ_{QUEEN,T-}  \times  NAV_{QUEEN,T-} NOSQQUEEN,T​=NOSQQUEEN,T−​×NAVQUEEN,T−​
When NAVROOKNAVBISHOP>2\frac{ NAV_{ROOK} }{ NAV_{BISHOP} }  > 2NAVBISHOP​NAVROOK​​>2
 
For Token ROOK holders, amount of Token ROOK after Rebalance:
NOSRROOK,T=NOSRROOK,T−NOSR_{ROOK,T} = NOSR_{ROOK,T-} NOSRROOK,T​=NOSRROOK,T−​
Token ROOK holders also receive extra Token QUEEN:
NOSQROOK,T=NOSRROOK,T−×NAVROOK,T−−NOSRROOK,TNOSQ_{ROOK,T} = NOSR_{ROOK,T-}  \times  NAV_{ROOK,T-} - NOSR_{ROOK,T}NOSQROOK,T​=NOSRROOK,T−​×NAVROOK,T−​−NOSRROOK,T​
For Token BISHOP holders, amount of Token BISHOP after Rebalance:
NOSBBISHOP,T=NOSBBISHOP,T−NOSB_{BISHOP,T} = NOSB_{BISHOP,T-} NOSBBISHOP,T​=NOSBBISHOP,T−​
Token BISHOP holders also receive extra token QUEEN:
NOSQBISHOP,T=NOSBBISHOP,T−×NAVBISHOP,T−−NOSBBISHOP,TNOSQ_{BISHOP,T} = NOSB_{BISHOP,T-}  \times  NAV_{BISHOP,T-} - NOSB_{BISHOP,T}NOSQBISHOP,T​=NOSBBISHOP,T−​×NAVBISHOP,T−​−NOSBBISHOP,T​
For Token QUEEN holders, amount of Token QUEEN after Rebalance:
NOSQQUEEN,T=NOSQQUEEN,T−×NAVQUEEN,T−NOSQ_{QUEEN,T} = NOSQ_{QUEEN,T-}  \times  NAV_{QUEEN,T-} NOSQQUEEN,T​=NOSQQUEEN,T−​×NAVQUEEN,T−​
A Deeper Dive into the Rebalance Protocols
Rebalances are essentially linear transformations across all accounts and upon three tranche balances. The Fund protocol is responsible for managing balances of Token QUEEN, BISHOP, and ROOK altogether, triggering a new rebalance, and archiving every rebalance as a matrix. Since the Fund is the first to know if there is a new rebalance, total supplies and the Fund’s balances of Token QUEEN/BISHOP/ROOK are always up to date. Unfortunately, it is impossible to do the same for individual balances, nor is it possible to notify every other contract about the rebalance. As a result, the general mechanism is to delay per-user rebalances until the next user operation. Furthermore, contracts other than Fund must keep track of per-user last rebalance IDs and update the local data to more recent versions by consulting the historical data from the Fund. The application of delayed rebalance could be seen in token transfer, allowances, staking, trade settlements, etc.
The smart contracts are optimized to jump to the latest rebalance ID if the account balances are previously empty. In addition, it is unlikely that delays for a user would ramp up too much to fit in a single transaction, but when it does happen, all Tranchess contracts have implemented batch rebalance methods to unblock the user.
Architecture and Specs
Tranchess Protocol is a yield enhancing asset tracker with varied risk-return solutions that provide different risk/return matrices out of a single main fund that tracks a specific underlying asset (e.g.BTC). Below is the general architecture of Tranchess Protocol. Each module consists of several contracts to realize the needed functionalities. Everything is inhouse-developed except for the two contracts under “Asset”, which we derived from other protocols.
Note: The two functions under Secondary Market, Staking and Swap, are realized by one single contract.
Primary Market
Tranchess Fund Protocol is the set of contracts representing the primary market. In the primary market, the underlying asset can be used to create tokenized shares in the corresponding Main Tranche (Token QUEEN). Token QUEEN could be further split into tokenized shares in Tranche BISHOP (Token BISHOP) and Tranche ROOK (Token ROOK) for different investment agenda. Holding Token BISHOP leads to interest earnings with a weekly floating yield determined by market performance and governance, whereas holding Token ROOK facilitates 2x leverage with no liquidation risk and maximal capital efficiency. The Fund would perform periodic evaluation of the net asset values (NAVs) per share, and when NAVROOK/NAVBISHOP is above 2 or below 0.5 , it triggers rebalances to universally and proportionally rebases shares across every address.
Tranchess Swap
Tranchess Swap Protocol is the set of contracts representing the secondary market. Since the tokenized shares could experience rebalances, which are essentially linear transformations upon all account balances, no existing swaps or centralized exchanges are readily available for trading such fund shares. Tranchess sets off from the onset to design its exchange for maximum liquidity. In the secondary market, both the stablecoins such as USDC and tokenized shares (token QUEEN, BISHOP and ROOK) could be exchanged using a matching mechanism we refer to as Premium-Discount Orderbook.
In our approach, trade activities are divided into the same 30-minutes period as the Oracle Protocol The exact trading price could not be determined at the trading time, because the price oracles are still subjected to change. Instead of a fixed price, the makers need only to specify a certain percentage off from the next fixing for an order. The percentage offset is relative to the net asset values calculated in the future, with a positive percentage known as Premium and a negative percentage known as Discount. Similar to a traditional exchange order book, the smart contracts also arrange orders in order books from the highest to the lowest percentage for bidding order, and lowest to highest for asking order. We've achieved a few goals with this design:
Rebalances do not affect trading activities
Low cost for liquidity providers to interact with the blockchain
No impermanent loss, because it is not using AMM
No high-frequency order submission and cancellation, because premiums and discounts fluctuate with the price
The Swap operates completely on-chain
Tranchess Token Model
Chess is the sole governance token of Tranchess Protocol, currently issued on BSC but following the ERC-20 standard. It’s widely used in the Tranchess ecosystem for voting, fee rebate, etc.
CHESS tokens will be released over 4 years with a decaying schedule. There will be a total of 300 million CHESS tokens, with the distribution as follows:
20% of the token supply will be allocated to the Core Team with a vesting schedule
5% of the token supply will be for Seed Investors with a vesting schedule
15% of the token supply will be reserved for future investors in subsequent funding rounds
50% of the token supply will be allocated for liquidity mining of CHESS tokens.
10% of token supply is reserved for the ecosystem/treasury of Tranchess – including but not limited to partnerships, 3rd party services, listing fees.
The CHESS token distribution is designed to slowly reduce issuance over the course of 4 years, with a long tail of fixed weekly emissions. The 50% community incentives will be distributed on Pancake and Tranchess App.
On Tranchess App, week 1 will start with distributing 300,000 tokens, and from week 2 to 4, each week distributes an additional 300,000 on top of the previous week. By the end of week 4, the accumulated distribution will be 3,000,000. The detailed distribution schedule is as below:
Each week, the distributed CHESS tokens are allocated to the staked BTC, ETH and BNB funds at a certain percentage. The detailed split between the two funds are as below:
From (Week)
To (Week)
# of Weeks
Specific Percentage
20 (Nov. 4)
20 (Nov. 11)
1
ETH: 5%, BTCB: 95%
21 (Nov. 11)
21 (Nov. 18)
1
ETH: 10%, BTCB: 90%
22 (Nov. 18)
22 (Nov. 25)
1
ETH: 15%, BTCB: 85%
23 (Nov. 25)
23 (Dec. 2)
1
ETH: 20%, BTCB: 80%
24 (Dec. 2)
Onwards
-
Calculated explained below*
*: For week 24 onwards, the split between BTCB and ETH is calculated using the following formula:
ETH% = (TVLETH/TVLTOTALTVL_{ETH}/ TVL_{TOTAL}TVLETH​/TVLTOTAL​
 + Last Week's ETH% )/2
BTCB% =  (TVLBTCB/TVLTOTALTVL_{BTCB}/ TVL_{TOTAL}TVLBTCB​/TVLTOTAL​
 + Last Week's BTCB% )/2
For example, at the beginning of a certain week, the total TVL of Tranchess is 2 billion, with 1.5 billion of BTCB and 0.5 billion of ETH. Also, the previous week's allocation split was 80% for BTCB and 20% for ETH. 
(0.5/2+0.2)/2=22.5% ==> 22.5% of this week's total weekly CHESS emission will be allocated to the ETH staking pool;
(1.5/2+0.8)/2=77.5% ==> 77.5% of this week's total weekly CHESS emission will be allocated to the BTCB staking pool.
How to earn CHESS
Users harvest Chess when staking their tokens in Tranchess.
Token Utility
To participate in Governance, one needs to lock their CHESS token to gain veChess as voting power. CHESS can be locked for up to 4 years. The number of veChess you receive depends on the time you lock your CHESS for. The minimum locking time is 1 week, and for every CHESS locked, veChess increases linearly from 0 to 1 as you increase your locking time from 0 to 4 years.
For example:
1 CHESS locked for 1 year = 0.25 veChess.
1 CHESS locked for 2 year = 0.5 veChess.
1 CHESS locked for 3 year = 0.75 veChess.
1 CHESS locked for 4 year = 1 veChess.
Without increasing the locking time or the number of CHESS, veChess voting power decreases linearly as time lapses. For example:
Alice locked 1 CHESS for 1 year and received 0.25 veChess. She didn’t extend the locking time or locked more CHESS afterwards. After 6 months, Alice would have 0.125 veChess.
Tranche BISHOP interest rate voting
On a weekly basis, Tranchess protocol averages the USDC borrow rate on VENUS for the last 7 days. The averaged result becomes the base for the following week’s interest rate received by Tranche BISHOP, which is effectively the base cost of borrowing from Tranche BISHOP to ROOK. The base will then add a community premium, voted by all veCHESS holders. The weight of the vote is proportional to the veCHESS allotment each wallet held. The result of the vote would be taken into account as part of the interest rate formula established by the Tranchess team.
Weekly Fee Rebate ( in the form of underlying assets, i.e. BTCB, ETH, etc.)
Weekly Fee Rebate is a mechanism designed to incentivize user participation in the Tranchess protocol by awarding all CHESS lockers a weekly reward. Weekly Fee Rebate settles on a weekly basis. Enrolled users (i.e. veCHESS holders) are entitled to a protocol rebate in the form of the underlying cryptocurrency asset (i.e. BTCB, ETH), calculated as a percentage of transaction fees collected by the protocol (excluding gas fee). Users enroll by registering their veChess on the Tranchess platform.
On Week 0, Thur 14:00 UTC, Tranchess registers individual's as well as the total amount of veChess enrolled for rebate. The recorded veChess will be eligible for the following week's fee rebate.
On Week 1, Thur 14:00 UTC, Tranchess sums up the total fees accumulated throughout the week and divides proportionally 50% of the total fees amongst the recorded veChess enrolled. The fee rebate will be claimable thereafter.
For example,
On Week 0, before Thurs 14:00 UTC: Alice enrolls 100 veChess whilst the total rebate pool is 10,000.
Between Week 0, Thurs 14:00 UTC to Week 1, Thurs 14:00 UTC: If Tranchess collected 1 BTCB and 1 ETH as fees for the week, the fee rebate allocated to Alice would be 100/10000*1*50% = 0.005 BTC and 0.005 ETH. Alice can claim this fee any time post Week 1, Thurs 14:00 UTC
Note: Any new veChess gained during the week (Week 0, Thurs 14:00 UTC to Week 1, Thurs 14:00 UTC) can be enrolled but will only receive rebates post Week 2, Thurs 14:00 UTC.
Boosting
Boosting enhances the efficiency of earning the staking reward, CHESS.
Boost factor ranges from 1~3 and is calculated based on the user's weighted share of the staking pool and user's share of the veCHESS pool.
There are two boost factors: the actual boost factor applied to users' accounts and the potential max boost factor. The potential max boost factor is a theoretical number derived purely from the user's share in the staking pool. The actual boost factor also considers the share of the veCHESS pool. In practice, users can adjust their share of the veCHESS pool by locking more CHESS or extending their lock duration to reach their potential max boost factor.
Below are the specific calculations. 
Definitions:
​BoostingPower=WES∗vePBoostingPower = WE_{S} * vePBoostingPower=WES​∗veP
 
​WEBR=(NOSTBISHOP,k∗4+NOSTROOK,k∗2)/3WE_{BR} = (NOST_{BISHOP, k} *4+NOST_{ROOK,k}*2)/3WEBR​=(NOSTBISHOP,k​∗4+NOSTROOK,k​∗2)/3
 
​WOBR=MIN(WEBR+BoostingPower∗2,WEBR∗3)WO_{BR} = MIN(WE_{BR}+BoostingPower*2, WE_{BR}*3)WOBR​=MIN(WEBR​+BoostingPower∗2,WEBR​∗3)
 
​WOQ=MIN[NOSTQUEEN,k+clamp(BoostingPower−WEBR,0,BoostingPower/2),NOSTQUEEN,k∗3]WO_{Q} = MIN[NOST_{QUEEN,k}+clamp(BoostingPower-WE_{BR},0,BoostingPower/2), NOST_{QUEEN,k}*3]WOQ​=MIN[NOSTQUEEN,k​+clamp(BoostingPower−WEBR​,0,BoostingPower/2),NOSTQUEEN,k​∗3]
​
​WOBa=WOBR+WOQWO_{Ba} = WO_{BR}+WO_{Q}WOBa​=WOBR​+WOQ​
 
​WEBa=(NOSTQUEEN,k∗3+NOSTBISHOP,k∗4+NOSTROOK,k∗2)/3WE_{Ba} = (NOST_{QUEEN,k}*3+NOST_{BISHOP,k}*4+NOST_{ROOK,k}*2)/3WEBa​=(NOSTQUEEN,k​∗3+NOSTBISHOP,k​∗4+NOSTROOK,k​∗2)/3
 
​WES=SUM[WEBa]WE_{S} = SUM[WE_{Ba}]WES​=SUM[WEBa​]
 
​WOS=SUM[WOBa]WO_{S} = SUM[WO_{Ba}]WOS​=SUM[WOBa​]
 
Formulas:
ActualBoostFactor=WOBa/WOSWEBa/(WOS−WOBa+WEBa)ActualBoostFactor =  \frac{WO_{Ba}/WO_{S}}{WE_{Ba}/(WO_{S}-WO_{Ba}+WE_{Ba})} ActualBoostFactor=WEBa​/(WOS​−WOBa​+WEBa​)WOBa​/WOS​​
PotentialMaxBoostFactor=WEBa∗3/(WOS−WOBa+WEBa∗3)WEBa/(WOS−WOBa+WEBa)PotentialMaxBoostFactor =  \frac{WE_{Ba}*3/(WO_{S}-WO_{Ba}+WE_{Ba}*3)}{WE_{Ba}/(WO_{S}-WO_{Ba}+WE_{Ba})} PotentialMaxBoostFactor=WEBa​/(WOS​−WOBa​+WEBa​)WEBa​∗3/(WOS​−WOBa​+WEBa​∗3)​
Variable Definitions
Variable
Definition
t
Intraday trading timestamp. Current timestamp within intraday trading windows
e
Intraday epoch timestamp. TWAP calculation timestamp of the current 30 minutes intraday trading window
T
Post-daily settlement timestamp. Timestamp right after settlements of subscription/redemption/rebalance at 22:00pm GMT+8 each day
T-
Pre-daily settlement timestamp. Timestamp right before settlements of subscription/redemption/rebalance at 22:00pm GMT+8 each day
T-1
Last post-daily settlement timestamp. Timestamp for the previous post-daily settlement timestamp
​NOSkNOS_{k}NOSk​
 
Fund number of shares. Net number of shares of main fund issued by Tranchess by timestamp k
​QBTCBkQBTCB_{k}QBTCBk​
​
Fund quantity of BTCB. Net quantity of BTCB held in main fund by timestamp k
​NOSQU,kNOSQ_{U,k}NOSQU,k​
​
Number of main fund shares. Number of shares held by a user or corresponding portion targeted for operation, U, at timestamp k
​NOSBU,tNOSB_{U,t}NOSBU,t​
​
Number of Tranche BISHOP fund shares. Number of shares held by a user, or corresponding portion targeted for operation, U, at timestamp k
​NOSRU,tNOSR_{U,t}NOSRU,t​
​
Number of Tranche ROOK fund shares. Number of shares held by a user, or corresponding portion targeted for operation, U, at timestamp k
​NAVQ,kNAV_{Q,k}NAVQ,k​
​
Net asset value of shares. Net asset value of Main Tranche QUEEN/Tranche BISHOP/Tranche ROOK fund shares at timestamp k
​TWAPBTC,kTWAP_{BTC,k}TWAPBTC,k​
​
Time weighted average price of underlying asset. Time weighted average price of BTC calculated for timestamp k, k can be an epoch timestamp or a settlement timestamp
​MRk,T−1MR_{k,T-1}MRk,T−1​
​
Unsettled management rate. Management rate arithmetically cumulated since last settlement T-1, to timestamp k
​IRk,T−1IR_{k,T-1}IRk,T−1​
​
Unsettled interest rate. Interest rate arithmetically cumulated since last settlement T-1, to timestamp k
​PCP_{C}PC​
 
CHESS price
​RCR_{C}RC​
 
CHESS daily release rate
​UDYNUDY_{N}UDYN​
 
User's daily yield on a specific tranche N. N can be QUEEN, BISHOP, or ROOK.
​NOSTN,kNOST_{N,k}NOSTN,k​
 
Number of staked token N of a specific account at timestamp k. N can be QUEEN, BISHOP or ROOK.
​WNW_{N}WN​
 
CHESS distribution weight of a certain tranche N. N can be QUEEN, BISHOP or ROOK.
​vePvePveP
 
The share of the veCHESS pool of an individual account
​WESWE_{S}WES​
 
The sum of all individual accounts' weighted balance
​WEBaWE_{Ba}WEBa​
 
WeightedBalance. The weighted Q/B/R balance of a particular account calculated based on Chess distribution weight
​WEQWE_{Q}WEQ​
 
The weighted Q balance of a specific account calculated base on Chess distribution weight
​WEBRWE_{BR}WEBR​
 
The weighted A&B balance (combined) of a specific account calculated based on Chess distribution weight
​WOSWO_{S}WOS​
 
The sum of all individual accounts' working balance
​WOBaWO_{Ba}WOBa​
 
WorkingBalance. The total actual boosted balance of Q/B/R of an individual's account
​WOQWO_{Q}WOQ​
 
The actual boosted QUEEN balance of an individual account
​WOBRWO_{BR}WOBR​
 
The actual boosted BISHOP and ROOK balance (combined) of a particular account
Tranchess Team
Tranchess Team is a group of blockchain and financial experts with diverse backgrounds and experiences across the globe, covering across multiple time zones. Most of the Tranchess team members are from investment banks, asset management firms and hedge funds, whilst our tech team is particularly experienced with cyber security in centralized crypto exchanges and DeFi protocols. We believe that the synergy from this diversity is what allows us to present to you today, a new class of DeFI - The Tranchess Protocol.
How To Guides - Previous
How to Lock CHESS
DISCLAIMERS
Last modified 3mo ago
Copy link
On this page
Abstract
Introduction
Overview of Defi
Asset Management
Pain Points
The Tranchess Protocol
Overview
Main Tranche and Token QUEEN
Tranche BISHOP and Token BISHOP
Tranche ROOK and Token ROOK
Tranchess Mechanisms and Protocol
Tranchess Primary Market
Tranchess Swap
Rebalance
Architecture and Specs
Tranchess Token Model
How to earn CHESS
Token Utility
Variable Definitions
Tranchess Team