# Welcome to Tranchess Who we are and how we help you earn more with less hassle. ## What is Tranchess? Tranchess is a yield-enhancing asset tracker protocol with varied risk-return solutions. The concept of Tranchess was first incepted in early 2020 and was developed quickly into its current state. 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, ETH, BNB) or a basket of crypto assets. {% embed url="" %} As described in the video, Tranchess’ ecosystem constitutes four different tokens: QUEEN, BISHOP, ROOK, and CHESS. * ***QUEEN***: QUEEN is created by depositing BTCB, ETH or BNB via the Primary Market of Tranchess. QUEEN is designed for long-term HODLERS of the underlying crypto assets and provides an additional yield that ranges between 2% to 16%, depending on the fund. * ***BISHOP***: BISHOP is created by splitting QUEEN in the Primary Market of Tranchess. Every QUEEN token can be split evenly into 0.5 BISHOP and 0.5 ROOK. BISHOP is designed for investors who want to receive higher yields on their stable coins. BISHOP currently provides an APY between 7% to 22%, depending on the fund. * ***ROOK***: ROOK is created by splitting QUEEN in the Primary Market of Tranchess. Every QUEEN token can be split evenly into 0.5 BISHOP and 0.5 ROOK. ROOK is designed for aggressive investors who want to take a leveraged position on a certain crypto asset. ROOK protects investors from forced liquidation and earns an additional yield between 1.5% to 10% on top of the 1.7\~2.2 times leveraged position. * ***CHESS***: After users stake their QUEEN, BISHOP or ROOK tokens on Tranchess, they start farming CHESS, the governance and utility token of Tranchess. Users can also obtain CHESS on Binance or Pancake Swap. ## What is CHESS? CHESS is the governance token of the Tranchess protocol. Users farm CHESS by staking their QUEEN, BISHOP and/or ROOK tokens. CHESS is also available on Binance and Pancake Swap. Lock CHESS creates veChess, which enables users to participate in Tranchess’s weekly rebate and governance votings. More on CHESS and veCHESS can be found here: {% content-ref url="/pages/-MjmdptBpxcG6jiVphGe" %} [CHESS](/faq/chess) {% endcontent-ref %} {% content-ref url="/pages/-MhCI1tLjR0cAInHtOZM" %} [veChess](/faq/vechess) {% endcontent-ref %} ## What's New in Tranchess V2? {% embed url="" %} In addition to the exciting features Tranchess originally encompasses, users can now swap between BISHOP, ROOK and BUSD instantly with the brand new instant swap AMM pools. Creation and redemption of QUEEN tokens are now instantaneous. Weekly Rebate pools increased to FOUR: BTCB, ETH, BNB and BUSD. For more features and updates, [visit us](https://docs.tranchess.com/www.tranchess.com) and explore! ## Why Tranchess? Tranchess hopes to empower users of DeFi with asset allocation flexibilities. Tranchess team would continuously expand the protocol to encompass more product and fund offerings for users; At the same time improve our accessibility to users by exploring new chains and crypto assets as underlying. ## Useful Links Tranchess: Tranchess Governance Forum: Twitter: Telegram: (Eng); (Chinese) Discord: Medium: GitHub: # Turbo and Stable Built on top of our classic QUEEN-BISHOP-ROOK structure, the Turbo & Stable series is customized for points earning and rewards. Get the most out of your points-earning assets with Turbo & Stable, even if you are just here for fixed-interest earning. Specifically: * [**QUEEN**](/faq/turbo-and-stable/queen): The QUEEN token swaps 1:1 with the underlying assets from day one till the fund reaches maturity. The ratio will always stay at 1:1. * [**Turbo**](/faq/turbo-and-stable/turbo): An enhanced version of ROOK, customized for maximum points earning. Leverage the leverage for points earnings at a cost. * [**Stable**](/faq/turbo-and-stable/stable): Enhanced BISHOP. Fixed and competitive interest earning with no lock-up period. *** Tranchess Turbo and Stable structure for points-earning are now on Scroll and BNB Chain. ### Live Funds (click on the asset names for a full user guide of the fund):
Underlying AssetContract DeploymentStarting DateMaturity Date
brBTC (Fund 4)Oct. 24, 2025Oct. 28, 2025January 27, 2026
uniBTC (Fund 4)Oct. 24, 2025Oct. 28, 2025January 27, 2026
{% hint style="info" %} Use the Contract Deployment dates to calculate fair values. More details can be found [here](/faq/turbo-and-stable/upon-maturity). {% endhint %} ### Matured Funds: | Underlying Assets | Maturity Date | | -------------------- | ------------------ | | asBNB (Fund 2) | December 15, 2025 | | brBTC (Fund 3) | September 25, 2025 | | uniBTC (Fund 3) | September 25, 2025 | | brBTC (Fund 2) | June 26, 2025 | | uniBTC (Fund 2) | June 26, 2025 | | asBNB | June 6, 2025 | | brBTC | March 31, 2025 | | uniBTC | March 31, 2025 | | slisBNB (Fund 2) | March 27,2025 | | SolvBTC.BBN (Fund 2) | March 5, 2025 | | STONE (Fund 2) | February 13,2025 | | weETH | December 15, 2024 | | SolvBTC.BBN | December 7, 2024 | | STONE | October 8, 2024 | | slisBNB | September 30,2024 | | SolvBTC | September 10, 2024 | *** ## Fees and costs Creation/Redemption: 0 Split/Merge: 0 Trading fee: 0.05% Protocol fee: [Depends on each Fund. ](/faq/turbo-and-stable/turbo#points-rebate) # QUEEN

QUEEN

QUEEN Token swaps 1:1 with the underlying. Every 1 QUEEN token can be split into 0.1 Turbo and 0.9 Stable. Similarly, every 1 Turbo and 9 Stable can be merged into 10 QUEEN. The ratio is always 1⇌0.1+0.9. There is no fee for splitting/merging or creating/redeeming. Since QUEEN swaps 1:1 with the underlying, it usually earns 1X points as the underlying asset as well. However, certain projects might design their points system differently, so we encourage our users to always check the specific user guide of the funds for exact information. #### Current QUEEN tokens and what they are earning:
Fund underlyingToken nameYield
brBTCbrBTCQUEEN4
  • 2X Bedrock for Tranchess
  • 50x Bedrock on BNB Chain

---> 100X total

uniBTCuniBTCQUEEN4
  • 2X Bedrock
  • 50x Bedrock on BNB Chain

---> 100X total

## How does splitting change the points-earning multiplier? This applies to the funds that QUEEN earns 1X or no points on. We'll use STONE fund 1 for example here, but you can use this calculation to cross-check any Tranchess Turbo & Stable fund. #### The calculation stoneQUEEN earns 1x StakeStone points. 1 stoneQUEEN = 0.1 turPSTONE and 0.9 staYSTONE. While staYSTONE does not earn any points, turPSTONE earns 20x StakeStone points. If 1 stoneQUEEN earned 1 point, splitting it up will give you $$0.1 *20+0.9*0=2$$ points. (We haven't even started counting in the fixed yield from staYSTONE yet.) You can always merge turPSTONE and staYSTONE back into stoneQUEEN and redeem it back into STONE. There is **no** lockup period, **no** creation/redemption fee, and **no** split/merge fee. {% hint style="success" %} Splitting is a slippage-free, hassle-free option to quickly boost your points earning. Because the split and merge ratio (1⇌0.1+0.9) is consistent and all tokens will be redeemed by their fair values upon maturity, if you convert the underlying asset into QUEEN, split QUEEN, and hold both till maturity, you will find that the total underlying asset you can redeem from Stable and Turbo is the same as the amount you initially used to create QUEEN. {% endhint %} #### Here is how you can ***double*** your QUEEN point earnings (using stoneQUEEN for example): 1. go to Primary Market. You will find the link under "Turbo & Stable".
2. Connect your wallet and put in the stoneQUEEN amount you want to split. (Our advice for maximized earnings is to ***split them all*** until you need to redeem them back to STONE.)
3. **And that's it!** The only cost during the process is the gas fee to approve the transaction. **No extra action is needed.** The turPSTONE and staYSTONE combo you get from splitting is generating a 2x-point earning for you now. 4. You can hold them till maturity or merge them back into stoneQUEEN and redeem them for STONE anytime you want to. # Turbo

Turbo

Turbo token symbols start with turP, which is short for "Turbo Points". Turbo is designed to turbocharge your speed of earning points for the underlying assets. With an innate leverage of 10 and a bonus multiplier from the underlying asset, Turbo can boost points earning to the max. Turbo gets all the point shares allocated to Stable, in return, it pays Stable a fixed interest rate as cost. You can swap Turbo back to underlying assets anytime via our Swap function or hold it until the fund ends, when all Turbo tokens will be converted back to the underlying assets based on their fair value. #### Points rebate Tranchess rebates 3% of Turbo points to veCHESS holders. Tranchess receives the 3% in two different ways based on the feedback of the collaborating project teams: 1. Tranchess would receive points equivalent to 3% of all Turbo points rewards from the project team. The 3% is additional to points allocated to Turbo holders. * This applies to slisBNB Fund 2 and SolvBTC.BBN Fund. 2. Tranchess would charge 3% of all Turbo points allocated to Turbo holders as a protocol fee. * This applies to STONE Fund 2 and weETH Fund. All points will be rebated 100% to all veCHESS holders on the corresponding chain of the fund in a similar manner to the regular weekly protocol rebate. (i.e., STONE Fund 2 is on Scroll; thus, the 3% STONE points Tranchess charges will be rebated to all veCHESS holders on Scroll.) The exact date and schedule are subject to each project team's own points distribution plan. Tranchess will announce the details respectively when they are clear. {% hint style="danger" %} ***Check the price you are swapping at.*** Turbo could be trading at a premium or discount, depending on market demand. However, you will always redeem your Turbos at fair value when the fund reaches maturity, ***NOT*** the market price. [Check here for a full explanation of Fair Value v.s. Traded Price.](/faq/turbo-and-stable/swap-and-lps#trading-fee-split) {% endhint %} #### Current Turbo tokens and their total points multiplier
Fund underlyingToken nameMultiplier
brBTCturPbrBTC41000X
uniBTCturPuniBTC41000X
# Stable

Stable

Stable token symbols start with staY, which is short for "Stable Yield". Stable is designed to provide the comfort of fixed interest earnings for those who are not into points earning but are looking for fixed interest that is generally higher than the market average. Don't confuse the fixed APR with the staking yield of the underlying liquid staking token itself. The staking yield paid to the liquid staking tokens is separate from the fixed yield and will not be affected. Stable does not earn any points. You can swap Stable back to underlying assets anytime via our Swap function or hold it until the fund ends, when all Stable tokens will be converted back to the underlying assets based on their fair values. {% hint style="danger" %} ***Check the price you are swapping at.*** Stable could be trading at a premium or discount, depending on market demand. However, you will always redeem your Stables at fair value when the fund reaches maturity, ***NOT*** the market price. [Check here for a full explanation of Fair Value v.s. Traded Price.](/faq/turbo-and-stable/swap-and-lps#trading-fee-split) {% endhint %} #### Current Stable tokens and their interest rates:
Fund underlyingToken nameAPR
brBTCstaYbrBTC48%
uniBTCstaYuniBTC48%
# Swap and LPs ### LP: Points, yield, CHESS incentives and trading fees Each fund comes with an AMM pool of the Stable token and its underlying asset. Users receive LP tokens by providing liquidity to the pool. The LP token holders collect a basket of yield including four parts: * CHESS rewards: Weekly CHESS emissions decided by weekly governance voting. {% hint style="success" %} Depending on the projects and the nature of the collaboration, some LP pools might receive additional weekly CHESS incentives. ***Currently, the LPs of STONE Fund 2 receive an additional weekly CHESS incentive of 150,000.*** {% endhint %} * Trading fee: 0.05%. ***Note: the % shown under “Yield details” beside “Trading fee” is the yield percentage, not the fee itself.*** * Interest: Partial interest from Stable. Example: If one LP token consists of 0.6 Stable and the Stable has an APR of 6%, the LP token would earn 0.6\* 6 = 3.6% interest. * Multiplier of the underlying: In LP, the underlying receives a multiplier of points. The value of the underlying is calculated based on its notional value. * #### Current LP tokens and their multipliers of the underlying:
Fund underlyingToken nameMultipliers
brBTCstaYbrBTC4-brBTC100X
uniBTCstaYuniBTC4-uniBTC100X
You can add or withdraw liquidity anytime in pairs or single assets. ### :bulb:**How do Tranchess achieve instant swap for Turbo without a Turbo AMM pool?** #### *Buying Turbo* Tranchess borrows the underlying from the AMM pool. These underlyings, together with the ones users paid, are used in the Primary Market to create QUEEN, which is then split into Stable and Turbo. The Stable is returned to the AMM pool and Turbo to the users. *When most users are swapping for Turbo, Stable could be trading at a discount in the AMM pool.* #### *Selling Turbo* Tranchess borrows Stable from the AMM pool. Combining it with the Turbo that the user is selling, these assets are merged into QUEEN, which is redeemed in the Primary Market for the underlyings. After sending the user their amount of the underlying tokens, the remainder is returned to the AMM pool. *When most users are selling Turbo for the underlying asset, Stable could be trading at a premium in the AMM pool.* ### Trading Fee Split 0.05%, of which 80% goes to liquidity providers, 10% to treasury, and 10% to veCHESS holders in the form of rebates. *** {% hint style="info" %} ### **"Fair Value" vs. "Traded Price"** {% endhint %} The prices on the website for Turbo and Stable are the current traded prices, which means that for anyone who wants to swap between the underlying asset and Turbo/Stable, this is the price that will be applied to their trades (not taking into account the potential slippage and price impact of the AMM pool). Turbo and Stable have another set of "pricing systems": the Fair Values. Fair value **only** calculates the interest earned/paid over time. You will see how much the current traded price deviates from its fair value when you place the order:

STONE Fund one image for illustration

***When the fund reaches maturity, you will be redeeming your tokens by its fair values and fair values only.*** Let's use the STONE fund for example. With an interest rate of 6%, when the fund ends, each Stable will have a fair value of around 1.03. When Stable is trading at a discount (i.e., its traded price is lower than its current fair value), its actual yield will be higher than 6%. For example: Assume on day 1, the price of Stable is 0.9 STONE, the actual yield (calculated in simple interest) will be (assume the fund lasts for 180 days exactly): $$ \frac{（1.03 / 0.9 - 1）}{180} \* 365 \approx29.29% $$ At any time before the fund is over, Stable's implied yield is: $$ \frac{（FinalFairValue /currentTradedPrice - 1）}{FundRemainingDays} \* 365 $$ *** # Upon maturity The conversion when the fund ends All tokens will be converted back to the underlying assets based on their fair values, specifically: * QUEEN: QUEEN always swaps 1:1 with the underlying. * Turbo and Stable: * The fair values of Turbos and Stables don't calculate their points; they only consider their yield and cost on the platform. * The calculation starts with the contract deployment dates and ends when the fund reaches maturity. * Stable's fair value calculates its fixed interest earning, generating a fair value of about 1+`dailyRate`\*(`settlementPeriod/86400).`If a Stable has a fair value of 1.03 upon maturity, it means that every Stable of that fund can be redeemed into 1.03 underlying asset tokens. * *86400 is the seconds/day.* * Turbo's fair value calculates its cost of holding all Stable's point-earning shares, generating a fair value of about 10-StableFairValue\*9. Using the Stable's example above, if the Turbo's corresponding Stable ends with a fair value of 1.03, Turbo will have a fair value of about $$10-1.03\*9=0.73$$ . This means that every Turbo of the fund can be redeemed into 0.73 underlying asset tokens. * You can find all data, including the deployment date, `settlementPeriod` and `dailyRate` under the `Fund` [contract of each fund](/tech-support/contracts). We will also provide the links of the relevant data as well as the rough numbers of the fair values based on the calculation in the User Guides of each fund. You can find all user guides on [TranchessWiki](https://tranchess.notion.site/TranchessWiki-169c59d39c554c7d98971ae1c2c2c649). {% hint style="info" %} Redemption upon maturity is not a Swap. ***There’s no slippage regardless of the size you redeem for***. Whether you are redeeming for 1 underlying asset token or 100k tokens, ***you will always be converted with the fair values shown on the website.*** {% endhint %} # Staked ETH Yield Enhancement Put your staked ETH to work with Tranchess V3. > #### :information\_source: This is the first fund utilizing our Turbo & Stable structure. However, it's not a points-leverage trading fund, thus we put it separately for better differentiation from the current standard Turbo & Stable structure. As a liquid staking protocol on Ethereum, Tranchess is always looking for ways to utilize its structured design to benefit the ETH liquid staking community further. V3 is the first step of our LSDFi narrative. Tranchess V3 aims to optimize the yield of staked ETH tokens, starting with stETH/wstETH. In 2024, we will continue to bring in more interesting LSDFi product designs to cater to the needs of the liquid staking token holders. Join us as we embark on this new and exciting journey. # Primary Market Swap stETH/wstETH into wstQUEEN or vice versa. Split wstQUEEN into staYETH and turYETH, or merge turYETH and staYETH into wstQUEEN. ## Swapping between stETH/wstETH and wstQUEEN wstQUEEN can be exchanged for wstETH at a 1:1 ratio. The exchange rate between stETH and wstQUEEN aligns with the one you find [between stETH and wstETH](https://stake.lido.fi/wrap). Assume right now 1 wstETH = 1.2 stETH. Then 1 wstETH = wstQUEEN, 1.2 stETH = 1 wstQUEEN. You can also find the exchange rate as "fair value" on the page:
## Split and Merge
wstQUEEN can be split proportionally into [staYETH and turYETH](/faq/turbo-and-stable/staked-eth-yield-enhancement/primary-market#turyeth-and-stayeth-turbo-and-stable). When splitting, 1/10 of wstQUEEN would become turYETH and 9/10 of wstQUEEN would become staYETH. Similarly, to merge wstQUEEN would require users to put in both turYETH and staYETH at a 1:9 ratio. Let's use the exchange ratio above as an example: Assume right now 1 wstETH = 1.2 stETH, which means 1 wstQUEEN = 1.2 stETH = 1.2 ETH. When splitting, 1 wstQUEEN would become 1.2/10\*9= 1.08 staYETH and 1.2/10\*1=0.12 turYETH. ## Fees **0**. No fee for creating/redeeming wstQUEEN, nor for split and merge. ## Are you splitting wstQUEEN into the principle and the yield? **Nope.** As the name shows, both staYETH and turYETH are yield tokens. One provides a stable yield, and the other provides a leveraged upside. # turYETH and staYETH (Turbo and Stable) In Tranchess V3, we define a new category of product: Yield ETH, or YETH for short. Both staYETH and turYETH are Yield ETHs. *staYETH stands for "Stable Yield ETH", and turYETH stands for "Turbo Yield ETH"*. ## staYETH (Stable Yield ETH) staYETH allows you to fix your yield 365 days ahead without worrying about the fluctuation of ETH staking APR. staYETH has no lock-up period, and users can swap it back to wstETH or stETH anytime. ## turYETH (Turbo Yield ETH) In short, turYETH earns everything that is above the fixed yield staYETH gets. We all know that when the Ethereum network is active, and transaction volumes increase, the staking APR will also increase. turYETH allows users to long and earn a leveraged staking yield when ETH staking APR rises. Some might say turYETH allows you to leverage "the Ethereum gas fees." Like staYETH, users can swap turYETH back to wstETH or stETH anytime. ## APR Calculation Let’s say the YETH holders (that is both staYETH and turYETH) agree to a locked-in interest of 3.5% for staYETH. Assume by year-end, the actual APR for staked ETH is 4.5%, and 10 stETH= 9 staYETH + 1 turYETH. 10 staked ETH earns 10\*4.5%=0.45 ETH, of which 93.5%=0.315 ETH is paid to staYETH holders. turYETH holder would receive 0.45-0.315=0.135 ETH, giving turYETH an actual APR of 0.135/1\*100%=13.5%. :bulb:Under the same assumptions, here's what the APRs of staYETH and turYETH would be as the APR of stETH changes:
{% hint style="info" %} We used annual return rates in the calculation above just for ease of understanding. Don't forget, ***there's no lock-up period for staYETH or turYETH***. You can swap them for stETH/wstETH anytime you want, and the APR follows the same calculation, factoring in the time length. {% endhint %} {% hint style="info" %} Provide liquidity to the [staYETH-wstETH AMM Pool](/faq/turbo-and-stable/staked-eth-yield-enhancement/swap#stayeth-wsteth-amm-pool) with your staYETH tokens and earn ***an additional CHESS reward***! Providing liquidity **does not** hinder staYETH's ability to collect stable APR earnings. {% endhint %} ## Rebalance (?) Many of our long-term users would ask: does V3 has rebalance? If yes, how often would it be? staYETH and turYETH rebalance every 365 days, after which their fair values will be reset back to one. Since the APR for staYETH is fixed for 365 days, you can also think of the rebalance as we close the old pair of staYETH and turYETH, and start a new round with the new ones. # Swap with the staYETH-wstETH AMM pool. We adopt a similar "Instant Swap" structure as what we currently have on the BNB Chain and Ethereum, and use one AMM pool to satisfy the need for both staYETH and turYETH swaps. ## staYETH-wstETH AMM Pool
For liquidity providers, we support providing liquidity in single assets and pairs. When removing liquidity, ***make sure to tick the box of "Receive in stETH" if you want to withdraw in the form of stETH***, otherwise the default staked ETH token would be wstETH:
{% hint style="info" %} staYETH in the liquidity pool still collects the fixed APR. LPs receive ***additional*** CHESS emissions allocated to the pool. The weekly governance voting decides the specific allocation percentage. {% endhint %} ## Instant swap for turYETH
Put in the desired amount of turYETH you want to buy or sell, and let us do the rest for you. To complete the swap without the turYETH AMM pool, this is what's happening behind the scenes: ### Buying turYETH Tranchess collects the wstETH user pays and borrows wstETH from the staYETH-wstETH pool. These wstETH are used in the Primary Market to create wstQUEEN, which is then split into staYETH and turYETH. The staYETH is returned to the staYETH-wstETH pool and turYETH to the user's wallet. Under extreme circumstances, when everyone's swapping for turYETH, staYETH could be trading at a discount in the AMM pool. ### Selling turYETH Tranchess borrows staYETH from the staYETH-wstETH pool. Combining with the turYETH that the user is selling, these assets are merged into wstQUEEN, which is redeemed in the Primary Market for wstETH. After sending to the user their amount of wstETH, the remainder would be returned to the staYETH-wstETH pool. Under extreme circumstances, when everyone's selling turYETH for wstETH/stETH, staYETH could be trading at a premium in the AMM pool. ## Trading Fee 0.05%, of which 80% goes to liquidity providers, 10% to treasury, and 10% to veCHESS holders in the form of rebates. # Asset-Tracking and Liquid Staking Where we started. (And still improving) Tranchess started on the BNB Chain as a yield-enhancing asset tracker platform combining finance and blockchain technology elements. It is designed to provide users with diversified risk-return solutions by dividing assets into multiple tranches, each catering to the specific risk preferences of investors. With Tranchess, users can benefit from the yields of underlying blockchain assets, such as BTC, ETH and BNB. The platform's innovative approach leverages smart contracts to emulate traditional fund management strategies, aiming to maximize returns and minimize risks for participants in the DeFi space. *** **Key Features of Tranchess:** * **Tokenized Risk Tranches:** By splitting assets into different tranches, users can choose the level of risk they are willing to take. * **BNB Staking:** As one of the 21 cabinet nodes on the BNB Chain, we provide additional BNB staking rewards to all users who put their BNBs with us. * **Yield Optimization:** Aims to provide an optimized yield from the underlying blockchain assets. For more information, visit the [Tranchess official website](https://tranchess.com/). # General ## Why developing Tranchess? We developed Tranchess because we saw the market's need and wanted to use such a protocol to help better manage our portfolios while making crypto investments. ## Why launch on BNB Chain? BNB Chain has been booming with activities. It’s EVM compatible and has a block time of around 3 seconds. We believe launching on BNB Chain can decrease users’ cost of gas fee and the waiting period between each transaction. ## What's the relationship between different underlying assets? Each underlying asset has its own fund/asset pool. Right now Tranchess has launched three separate funds, a BTCB tracking fund, an ETH tracking fund, and a Alpha-enhanced BNB tracking fund. The three funds operate separately, following the same mechanism. Each fund has its own set of QUEEN/BISHOP/ROOK tokens and NAV values. The Rebalance of one fund would not affect the others. Your share of veChess applies to all funds. ## What is Token QUEEN? Token QUEEN is the token for the main tranche, or main fund, as the old-school financial industry might call it. Each Token QUEEN represents one share of the main fund. The main fund is an asset tracking index fund. QUEEN’s Net Asset Value (NAV) tracks the underlying asset's price on a fully correlated basis\*. Right now Tranchess has three main funds, the BTCB fund, the ETH fund and the BNB fund, thus three QUEEN tokens, bQUEEN, eQUEEN and nQUEEN+. Rather than holding the underlying assets passively, investors can now swap their assets for token QUEEN via a ‘creation process’. In doing so, they will have the same underlying asset exposure and, alongside the ability to farm Tranchess’s CHESS tokens for further yield enhancement. CHESS is also key to receiving an additional rebate from fees collected within Tranchess. (\* with deduction of protocol fees.) ## What is Token BISHOP? You can think of Token BISHOP as a BUSD-yielding product. Token BISHOP holders collect interest at a specific interest rate that changes every week. Every day, the protocol reads the premium determined by governance voting and adds the premium to the 7-day averaged BUSD interest rate from Venus, which the protocol collects and updates every Thursday. The total becomes BISHOP's interest rate. ## What is Token ROOK? Tranche ROOK is the other half of the split main tranche. It is a leveraged product with no forced liquidation. Token ROOK holder borrows daily from Token BISHOP holder to buy the main fund that tracks the underlying assets. Token ROOK holder receives all gains and losses of the main fund, i.e., Token ROOK's return = the profits and losses of the main fund - the interest paid to Token BISHOP. 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. ## What’s the relationship between QUEEN, BISHOP, ROOK, and Tranchess in general? Tranchess is the protocol with which one can create many different funds, each tracking a different set of crypto assets. Token QUEEN is the token for the main fund. The number of token QUEEN is equivalent to the number of underlying BTCB/ETH/BNB a user holds in their account. Token QUEEN can be further split into/merge from two sub-tranches, Token BISHOP and Token ROOK. ## What are the fees?
## How are the fees calculated for different asset pools? Each underlying asset pool charges its own fees separately. The rates are the same. For detailed rates please refer to the previous FAQ question. # Create & Redeem To create or redeem your nQUEEN, bQUEEN, eQUEEN or qETH, go to "Liquid Staking" and choose the chain.
Choose the token you want to create or redeem:
To create, put in the desired amount, approve the token and confirm your transaction:
For redemption, you will need to unstake the staked tokens first:
You will find your staked assets under "Portfolio" - "Tranche tokens":
Stake your QBR tokens here to start earning CHESS, or unstake them before redemption. For BISHOP and ROOK tokens, you can either merge them proportionally into QUEEN and redeem, or directly swap them back to USDC. All can be found under "Tranche":
After unstaking the QUEEN tokens, you can now redeem them back to the underlying assets:
{% hint style="info" %} For BNB creation/redemption, we support two methods: direct swap from the LP pool or delegation/undelegation from the staking node. The latter requires more time as it involves on-chain node operation. {% endhint %} # Liquid Staking aka "Primary Market" in previous versions.
> Many of Tranchess' old users might remember this section as the "Primary Market". > > With the steady upgrade of Tranchess V2 and Tranchess-Ethereum, Tranchess recategorized the tokens and replaced the "Primary Market" as "Liquid Staking" for a more convenient UI and UX experience. > > The "Liquid Staking" section will continue to support the creation and redemption of QUEEN tokens for Tranchess on both chain (BNB Chain and Ethereum), while "Split and Merge" is now under "Tranche". ## How long do I have to wait for my creation and redemption requests? As one of the major improvements in Tranchess V2, creation and redemption requests are now settled IMMEDIATELY. However, please note, in order to achieve max Alpha benefit for the BNB fund, most of the BNBs are delegated to Tranchess' validator node. If users' redemption request for BNB exceeded the buffer amount (which is usually a very small percentage of all BNB fund) left in the Tranchess protocol, the redemption requests for BNB could take longer. Please refer to the real-time notice on Tranchess website when redeeming for BNB. ## Why can't I redeem my assets back? Make sure to always "Unstake" your QUEEN tokens from the staking page into your wallet before redeeming. ## How many QUEEN tokens do I get for every BTCB, ETH, BNB I deposit in? In Tranchess V2, the amount of QUEEN tokens users now receive is roughly EQUIVALENT to the actual amount of BTCB, ETH, and BNB they have in their account. At the very beginning, the ratio (or price as shown on the website) is exactly 1:1, that is, 1 BTCB=1 bQUEEN, 1 ETH=1 eQUEEN, 1 BNB=1 nQUEEN+. Protocol fees will be deducted gradually from the total pool. Alpha for BNB fund would also be added into the pool gradually. For the exact fees, please refer to "What are the fees?" in FAQ under "General". When users create QUEEN with underlying assets, the amount of QUEEN they would get follows the following formula: $$ QUEEN\_{amount} = price (QUEEN) \* UnderlyingAsset\_{deposited} $$ $$ price (QUEEN) = Equivalent TotalQueen/TotalUnderlying $$ {% hint style="info" %} Equivalent Total Queen: the amount of QUEEN currently in the corresponding underlying asset's fund + the sum of its corresponding BISHOP and ROOK. {% endhint %} The real-time price of each QUEEN can be found under "Summary" in the "Create" tab: ![Here is an example for bQUEEN, the QUEEN token of the BTCB fund.](/files/80NAtnVDDDREobFnGsqy) ## What is Fair Value? In order to differentiate between the current trading price and the real value of BISHOP and ROOK, instead of NAV, Tranchess now uses the terms “fair value” and “price” when describing the values of QUEEN, BISHOP and ROOK tokens. For BISHOP and ROOK tokens, If you are familiar with the previous version of Tranchess, think of “Fair Value” as the old “NAV” for easy understanding. The “Fair Value” of QUEEN is the current market price of its corresponding underlying assets over price(QUEEN). For example, if the current market price of BNB is 270, and the price of nQUEEN, as explained in the previous question, is 0.9956, then the Fair Value of nQUEEN would be 270/0.9956, which is roughly 271.19. ## How many BISHOP and ROOK tokens would I get when splitting one QUEEN? Because now 1 QUEEN represents a much larger value than it used to be in Tranchess V1, we introduced a new parameter called "Split Ratio". Split Ratio is the amount of BISHOP and ROOK users would get when splitting one QUEEN. $$ CurrentSplitRatio = QUEEN\_{FairValue}/FairValue\_{BISHOP+ROOK} $$ ​After special events such as Rebalance, the new split ratio will be: $$ NewSplitRatio = OldSplitRatio \* FairValueSum\_{OldBISHOP+OldROOK}/2 $$ A split ratio of 200 for bQUEEN means that for every bQUEEN split, users would get 200 bBISHOP and 200 bROOK. ## Can I buy Token QUEEN, BISHOP, and ROOK on some other exchanges? Why? Right now, you can only trade Token QUEEN, BISHOP, and ROOK on Tranchess. In the future, these three tokens might become available on other exchanges as soon as there’s enough technical support from them. # Liquid Staking - Ethereum Liquid staking on Ethereum with Tranchess ## What is liquid staking? Liquid staking function allows users to earn staking rewards without locking assets, self-maintaining staking infrastructures or meeting the minimum staking requirements which can be high for retail users. Users can deposit tokens and receive tradable liquid tokens in return. The smart contract stakes these tokens using elected staking providers, and distributes the staking rewards back to users in the form of tradable liquid tokens or an increase of fair value of the liquid tokens. ## What is qETH? qETH is the liquid token of Tranchess liquid staking. After users stake their ETH with Tranchess, they receive qETH as the liquid token. The amount of qETH is constant unless users stake/unstake more ETH. The staking rewards will be accumulated as fair value of qETH and eventually reflected as an changed amount of ETH when users swap their qETH to ETH. In addition to collecting the Beacon Chain staking rewards, users can also provide liquidity in the Tranchess qETH/ETH pool on Balancer, where LP providers receive CHESS rewards and veBAL incentives. qETH can also be used in the greater Ethereum ecosystem for different DeFi protocol collaborations. Tranchess would soon release more joint-collaboration features in the coming weeks. Stay tuned! ## Do I receive CHESS as a liquidity provider for the qETH/ETH pool? The qETH/ETH pool will be allocated with a certain amount of CHESS emission on a weekly basis, the specific percentage depends on weekly[ governance voting on Tranchess](https://tranchess.com/governance). The allocated CHESS would NOT be distributed directly to LP holders, instead, in order to maximize LP holders' benefit, the allocated CHESS will act as incentives for auraBAL holders and join the weekly bribing mechanism on [Hiddenhand](https://hiddenhand.finance/aura). Bribing with CHESS incentivizes auraBAL holders and gains a higher BAL allocation to the qETH/ETH pool, which will be distirbuted to all liquidity providers of the pool. ## Is there a minimum amount of ETH required for liquid staking? There is no minimum amount of ETH required to stake with Tranchess. However, given it's an on-chain transaction, we would advise our users to check the relevant transaction fee to make sure it can be covered by the staking rewards. ## How can I convert my qETH back to ETH? After clicking Unstake ETH, you will see two ways to convert qETH back to ETH:
1. Withdraw. Withdrawing from the validator staking node might take a few days depending on the waiting time of the exit queue on the Beacon chain and the demand of staking and unstaking qETH amount. A detailed explanation can be found here in this [medium article](https://medium.com/@tranchess/ethereum-withdrawal-overview-frequently-asked-questions-faq-c46ce715f612). 2. Swap their qETH back to ETH on the [Balancer liquidity pool](https://app.balancer.fi/#/ethereum/pool/0xC9C5FF67BB2FAE526AE2467C359609D6BCB4C5320000000000000000000003CC), where users will be redirected to Balancer to complete the swap. ## Why is there congestion on the Ethereum network to activate new validators? After the successful Shanghai Upgrade, the Ethereum chain is currently experiencing another round of high demand for ETH staking, with new validator nodes created every day. The Ethereum chain produces 225 epochs every 24 hours, and each epoch processes a limited amount of new validators, depending on various factors such as the status of the chain, the total number of pending validators, and so on. Currently, each Epoch processes around 8\~9 validators, and there are over 90k pending validators waiting in the queue at the moment; Not including the validators that are newly created as you are reading this, resulting in an extended waiting time of over 40 days for new validators to be activated. {% hint style="info" %} Most of the figures above represent only the current situation and are subject to change in the future. {% endhint %} ## Can I self-stake my ETH without using any liquid staking protocols? You certainly can. However, staking on Beacon chain requires technical expertise, complex and expensive infrastructures and regular maintenance. Fail to meet the above requirements could result in slashing penalties, offseting the staking rewards one collects. Additionally, it requires a minimum of 32 ETH deposit to run a self-staking node, which would be locked on Beacon chain and cannot be withdrawed until further ugrades take place on Ethereum, which might take indefinite time. Staking with Tranchess effectively avoids the above hassle. Users can stake any amount of ETH they prefer and receive the staking rewards without worrying about the lock-up period of Beacon chain or setting up the complex technical node operation. ## Is there any fees associated with liquid staking on Tranchess? There's a 10% fee on users staking rewards which is split among node operators, Tranchess treasury and weekly rebate for veCHESS holders. # BNB Fund on BNB Chain ## How does the BNB fund work and how is it different from the previous two? Besides the yield-enhancing single-asset farming feature, BNB fund has an additional Alpha generating layer. The BNB fund stakes all underlying BNBs into Tranchess's validator node on BSC. By being an active validator node on BSC, the staked BNBs earn an APR of 8%\~16%, which is distributed back to all nQUEEN+ and nROOK+ holders. (net the protocol fee) ## What does "Alpha” mean? Alpha (α) is a term commonly used in TradFi or investment in general. Simply put, it basically means "active excess return". Here's a more comprehensive explanation on the term from an external website: emission {% embed url="." %} ## Where does the alpha return come from? Tranchess will host a validator node on BSC and actively manage the staked BNB level on the node. The goal is to collect a sustainable reward from the BSC network as an active validator. The reward collected from the BSC network becomes the alpha return for Tranchess's BNB Fund. ## During the first few days after the BNB fund launched and before the BNBs in the fund were delegated into the validator nodes and started generating APR, where did the Alpha come from? Tranchess incentivizes all created nQUEEN+ with an 8% Alpha return from its treasury until all the BNBs in the fund are staked into the validator node and the actual alpha starts to appear. ## When can I claim my requests for creation and redemption? Create requests for nQUEEN+ are claimable **right after** the daily settlement at 14:00 UTC. The redemption process for nQUEEN+ is a little different from the other two funds. *Redemption requests are still settled daily at 14:00 UTC.* All settled BNB requests would be claimable as soon as there are “floating” BNBs in the fund, that is, BNBs from other users’ creations, or BNBs from the last undelegated transaction. **Whenever there are "floating" BNBs, the *****settled***** redemption requests would be claimable immediately. That is, users don't have to wait for another 14:00 UTC.** Though Tranchess's website shows an upper limit of 14 days with regards to redemption waiting time, most redemption requests should be claimable in a much shorter time span, as compared to the default seven days based on BSC’s standard “unbonding period”. ## After I put in the redemption requests, do I still earn any alpha return? Users still earn the alpha return until the daily settlement at 14:00 UTC, but the CHESS rewards will stop as soon as users request for redemption. ## Do I have to stake the Q/B/R tokens for the alpha return? Honestly, you don't. Holding nQUEEN+, nBISHOP and/or nROOK+ is enough for you to collect the alpha return. However, the BNB fund also comes with the single-asset farming feature, and staking Q/B/R tokens gives you extra CHESS on top of the alpha return. To understand how to stake your Q/B/R tokens: {% content-ref url="/pages/E5p5cUpwMeg347Ih1yLp" %} [Create & Redeem](/faq/asset-tracking-and-liquid-staking/general/create-and-redeem) {% endcontent-ref %} ## Does the added alpha affect the interest rate nBISHOP receives? No. nBISHOP+ collects the same level of interest as eBISHOP and bBISHOP. ## What exactly will nQUEEN+ earn? nQUEEN+ receives the following two types of gains: * Validator node rewards **in the form of BNB tokens**. This is reflected in nQUEEN+'s NAV and will be collected together with users' deposited BNBs when they redeem. * Staking rewards **in the form of CHESS tokens**. This is Tranchess's own single-asset farming feature which allows users to farm CHESS by staking any or all of their QUEEN/BISHOP/ROOK tokens. The farmed CHESS is reflected in users' accounts under the "Staking" page and can be harvested anytime. {% hint style="info" %} If users locked the CHESS they harvested from staking nQUEEN+, they can enroll their veCHESS for the weekly rebate. By doing so, nQUEEN+ holders will earn the third type of return - the weekly rebate. This will be distributed to enrolled users **in the form of BTCB, ETH and BNB tokens.** {% endhint %} ## Is there a CHESS bonus with the launch of the BNB fund? Yes. For the first five weeks after the BNB fund launches, there would be an additional amount of CHESS distributed to all Tranchess users besides the regular emission. Detailed schedule as below: ![The split will stay as 20% BNB until further adjustment](/files/XTWGN44yJfuf8Lkj6KhB) ## Where does the CHESS bonus come from? From the "Community Incentives" pool that constitutes 50% of the total CHESS supply. ## Why aren't I given an estimated number for nQUEEN+ when creating (like what I would receive when creating eQUEEN or bQUEEN)? ![](/files/49Ebz88MebZuELsj4d89) In fact, we use the same formula in the calculation for all three funds. For the exact formula, please refer to this question: {% embed url="" %} What is the formula used when determining the amount of QUEEN a user can receive when creating? {% endembed %} However, since the BNB fund is an alpha-generating fund that collects validator rewards in the form of BNB from the BSC network every day, the "total BNB amount" used in calculation could be quite different at the time of creation compared to the actual number when requests are settled. We took out the estimated nQUEEN+ figure to avoid possible misunderstandings and confusion. ## Is there a place for me to spot the status of the BNB fund? Yes. Users would be able to see more information about the BNB fund through the BNB Fund Fact Sheet. Here's how you can access it:
## What exactly does each section on the BNB Fund Fact Sheet mean?
**Fund Capacity**: * **Total BNB Deposited**: The amount of BNBs that are already enjoying the APR reward through Tranchess's BNB fund by creating nQUEEN+ with their BNBs. * **Deposit Cap**: Cap of the current BNB fund. (now set at 800k BNB tokens) **Delegation rewards distribution**: The distribution split of the staking rewards collected from the BSC network. **Performance History**: The specific daily delegation reward split. {% hint style="info" %} Due to potentially frequent creation and redemption requests, the fund utilization rate might not stay at 100%. {% endhint %} ### For a more comprehensive backstory, check out the medium article below: {% embed url="" %} # Instant Swap The design of Tranchess Swap, now known as Instant Swap, has gone through many phases of remodeling, from the very first on-chain orderbook matching to AMM pools. This section includes the FAQs for the current model on both Ethereum and BNB Chain, as well as the FAQs of the original Tranchess Swap, archived for research purposes. # Instant Swap - Ethereum AMM pools for BISHOP, ROOK, qETH and CHESS. ## How many AMM pools are there in the ecosystem of Tranchess Ethereum? There are three AMM pools and one instant swap for ROOK. Two on the Tranchess platform: eBISHOP-USDC; eROOK-USDC; One on Balancer: qETH-WETH One on Uniswap V3: CHESS-USDC ## Does BISHOP and ROOK still follow the NAVs when trading in Tranchess pools? Some might have noticed, Tranchess provides two sets of prices under BISHOP & ROOK Swaps for users' references: Fair Value and Price. "Fair Value" is the NAV of BISHOP and ROOK, calculated and updated real time. "Price" is the actual price level the BISHOP/ROOK token is trading in the specific AMM pools. "Fair Value”, or the two tokens' NAVs, act as a reference in the swaps. ## What's the transaction cost of AMM pools? AMM pools charge 0.1% transaction costs in the form of USDC for every swap. 80% of the transaction cost goes directly to the liquidity providers, while the other 20% goes to the Tranchess treasury and joins Tranchess' weekly rebate program for all veChess holders who have enrolled. ## Without ROOK AMM pools, how do you achieve instant swap for eROOK tokens? Tranchess automatically chooses the optimal route between Uniswap V2 and Uniswap V3 for the most cost-effective transaction route. * Buying eROOK. Alice wants to swap for 1 eROOK. She enters the amount and approves the transaction, the corresponding amount of USDC then gets deducted from her account and she receives the eROOK token instantly. Behind the transaction, one of the two scenarios could happen depending on the route the transaction takes: * Uniswap V2: Tranchess automatically borrows a corresponding amount of eBISHOP from the eBISHOP-USDC pool and swaps it into USDC. The USDC, together with the USDC deducted from user's wallet, swaps WETH from Uniswap V2 (or other external AMMs in the future). The WETH is created from Tranchess' primary market or swaped via Balancer V2 into qETH, and then split into eBISHOP and eROOK. eROOK is what Alice would receive in this transaction, and eBISHOP would be returned back into the eBISHOP-USDC pool. * Uniswap V3: with the design of Flash Swap, Tranchess is able to first "borrow" a certain amount of USDC, which together with user's USDC, swaps into WETH from Uniswap V3. The WETH goes through the same process as illustrated above. While users receive their desired amount of eROOK, eBISHOP is swapped into USDC via Tranchess' own BISHOP swap. The USDC is then "returned" into Uniswap V3.
Under extreme circumstances when everyone's swapping for ROOK in a bullish market, the corresponding BISHOP could be trading at a discount in its AMM pool. * Selling eROOK. Bob wants to sell 1 eROOK. After he approves the transaction, the 1 eROOK is deducted from his account with the corresponding USDC added to his balance. Behind this one click of approval: * Uniswap V2: Tranchess automatically swaps for eBISHOP from the BISHOP pool and merges with Bob's eROOK token to form qETH. It then redeems the qETH or swaps from the Balancer pool and swap the WETH in Uniswap V2 for USDC. Some of the USDC is added to Bob's balance based on eROOK's market price, which is what Bob saw in his account at the beginning of this example. The rest of the USDC is added back to the eBISHOP-USDC AMM pool. * Uniswap V3: with the design of Flash Swap, Tranchess is able to first "borrow" a certain amount of WETH and swaps into USDC from Uniswap V3. Some of the USDC is added to Bob's balance based on eROOK's market price. The rest of the USDC swaps for eBISHOP from the eBISHOP-USDC AMM pool. The eBISHOP is then merged with Bob's eROOK into qETH. The qETH is redeemed or swaped from Balancer's pool back to WETH and eventually "returned" into Uniswap V3.
Under extreme circumstances when everyone's selling ROOK for USDC in a bearish market, the corresponding BISHOP could be trading at a premium in its AMM pool. # Instant Swap - BNB Chain AMM pools for BISHOPs, ROOKs and nQUEEN on BNB Chain. ## How many AMM pools are there on Tranchess? Right now there are 4 AMM pools: nBISHOP-BUSD; bBISHOP-BUSD; eBISHOP-BUSD; nQUEEN-BNB. ## Does BISHOP still follow the NAVs when trading in AMM pools? Some might have noticed, Tranchess provides two sets of prices under BISHOP Swap for users' references: Fair Value and Price. "Fair Value" is the NAV of BISHOP, calculated and updated real time. "Price" is the actual price level the BISHOP token is trading in the specific AMM pools. "Fair Value”, or BISHOP's NAV, acts as a reference in the AMM pools. ## What's the transaction cost of AMM pools? AMM pools charge 0.1% transaction costs in the form of BUSD for every swap. 80% of the transaction cost goes directly to the liquidity providers, while the other 20% goes to the Tranchess treasury and joins Tranchess' weekly rebate program for all veChess holders who have enrolled. ## Without ROOK AMM pools, how do you achieve instant swap for ROOK tokens? Let's use bROOK, the ROOK token of our BTCB fund as an example. The same route applies to the buy and sell of all three ROOK tokens. Tranchess automatically chooses the optimal route between PancakeSwap and Biswap for the most cost-effective transaction route. * Buying bROOK. Alice wants to swap for 1 bROOK. She enters the amount and approves the transaction, the corresponding amount of BUSD then gets deducted from her account and she receives the bROOK token instantly. Behind the transaction, Tranchess automatically transfers from the bBISHOP-BUSD pool, enough BUSD to purchase 1 bBISHOP. It then uses the BUSD from the AMM pool and the BUSD from Alice to swap for BTCB from PancakeSwap. The BTCB is created into bQUEEN, split, with bROOK returns to Alice's account, and bBISHOP being put back into the bBISHOP-BUSD pool. Under extreme circumstances when everyone's swapping for ROOK in a bullish market, the corresponding BISHOP could be trading at a discount in its AMM pool. * Selling bROOK. Bob wants to sell 1 bROOK. After he approves the transaction, the 1 bROOK is deducted from his account with the corresponding BUSD added to his balance. Behind this one click of approval, Tranchess automatically transfers 1 bBISHOP from the bBISHOP-BUSD pool and merges with Bob's 1 bROOK token to form bQUEEN. It then redeems the bQUEEN back into BTCB and swaps BTCB for BUSD on PancakeSwap. Some of the BUSD is added to Bob's balance based on bROOK's market price, which is what Bob saw in his account at the beginning of this example. The rest of the BUSD is added to the bBISHOP-BUSD AMM pool. Under extreme circumstances when everyone's selling ROOK for BUSD in a bearish market, the corresponding BISHOP could be trading at a premium in its AMM pool. # Tranchess Swap (V1） A temporary archive for those that are interested to understand Tranchess Swap 1.0. ## Why can't I trade my Q/B/R tokens? If you cannot sell your Q/B/R tokens, check first to see if you have already **STAKED** your Q/B/R tokens! *Q/B/R tokens need to be claimed and staked first before they can be traded on Tranchess Swap.* So if the Q/B/R tokens are in your wallet, please stake them so they can be traded. For "takers", the swap function would be paused every day from 13:00 UTC to 14:30 UTC. ## What do you mean by "taker"? Taker, as opposed to maker, is a frequently used term in trading. On Tranchess Swap, users enter into the "taker mode" when they disable Post-Only. Under taker mode, all orders placed are filled or cancelled immediately against the existing orders listed on the order book. On the other hand, 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. Here are two external links if you want to learn further on the term: {% embed url="" %} {% embed url="" %} ## Is there a trading fee? No, there is **no** trading fee on Tranchess Swap. The only fee you would face is the BSC gas fee for transactions. ## Will Tranchess Swap support other tokens in the future, or just the Tranchess tokens? Right now Tranchess Swap has listed 6 tokens, which are the QUEEN/BISHOP/ROOK tokens of BTCB fund and ETH fund. As we continue to issue new asset tracking fund, the list will also grow. Tranchess Swap is a function designed specifically for the Tranchess mechanism, at this point, we do not have plans for listing tokens outside the Tranchess ecosystem. ## Why would anyone buy Token QUEEN from an exchange instead of creating it from the primary market? This depends on one’s starting point. If you have BTCB/ETH with you and decide to hold it for a long time, you might want to mint it into Token QUEEN for the extra earning. However, for those without BTCB/ETH, using USDC to buy Token QUEEN will be a more straightforward method. ## How is QUEEN’s APY determined? QUEEN’s APY is calculated based on the annualized amount of CHESS tokens QUEEN can collect and the price of CHESS. ## Where do I find the daily interest rate of Token BISHOP? You can find the daily interest rate of Token BISHOP in Compare Tokens page, which you can enter from the front page or the Swap page. ![](/files/qHFyb3u8G18fbZBYdPGR) ![](/files/9BYGbBp7pbIBHzxd38LS) Scroll down and you will find BISHOP's daily interest rate right under its NAV. The value updates once every seven days. ![](/files/MjT1RS0RemoiDEAtYg9s) ## How is BISHOP’s interest rate determined? On a weekly basis, the protocol uses Venus’s Borrow rate of USDC from the previous week and calculate a weekly average, it then adds a premium on top which is determined by community voting. The total becomes BISHOP's next week's fixed APR. ## How is Rook’s leverage rate determined? The leverage rate is calculated by the following formula: $$ Leverage Ratio = ( NAV\_{BISHOP}+ NAV\_{ROOK} ) \div NAV\_{ROOK} $$ ## Why does it take so long (>30) to settle a trade in the Swap? Tranchess uses a 30-minute TWAP price oracle instead of instant price to prevent price manipulation by oracle attacks. ## What does it mean to set a “premium or discount” when I submit a trade order? Tranchess Swap adopts a Premium-Discount Orderbook system, which means that 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 token 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, and Alice’s final purchasing price will be (the NAV of 10am-10:30am) \* (1+25bps). One bps = 0.01% ## What is an Epoch? Tranchess defines each 30-minute window as one Epoch. ## Where are oracles used? For the underlying fixing price, our oracle extends the Open Oracle standard by Compound, accepts price data signed by two Reporters (Coinbase and OKEX) and computes time-weighted average price (TWAP) in every 30-minute epoch. We also use oracle to obtain the borrow rate of USDC from VENUS and calculate a weekly average for Token BISHOP’s interest rate calculation. ## What is TWAP? TWAP is short for Time Weighted Average Price. Comparing to using the price of a single timestamp, using the average price over a period of time greatly reduces the chance of price manipulation. In Tranchess, TWAP is used for calculating the NAVs on Tranchess Swap and for calculating the next-week’s base interest rate of Token BISHOP. ## Why can't I know the exact amount of tokens when I buy or sell (e.g. when I buy QUEEN tokens) Because the actual transaction is filled based on a future price, Tranchess can only provide an estimate based on the current market. ## Why is there a small amount of token left unexecuted after my post-only order is already filled and claimable? Since the transaction is filled based on a future price, to make sure the taker's order can be fully filled, the protocol reserves a small percentage of the maker's order as a buffer to counter potential price movement in the next Epoch window, which will be returned to the maker once the order is settled after the next Epoch. ## Is there any precautions taken to protect the platform from flash loan attacks/exploits? Our TWAP oracles, both for interest rates and underlying fixing prices, are designed to prevent short term manipulations from the get-go. The smart contracts on interest rate do not rely on prices from other smart contracts and thus are immune to price manipulation by flash loan. The underlying fixing price oracle uses 30-minute TWAP instead of instant price, in another word, attacker has to manipulate the price oracle for a consecutive 30mins window, making the attack virtually impossible. ## What difference does it make if I check the Post-Only box before placing orders? ![](/files/-Mdw6ceHuIw7YftJ_ERx) Checking the Post-Only box (make sure to choose "Advanced first!) 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. ![](/files/-Mdw6xjFQZqA5bmWH3m6) 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. ![](/files/-Mdw77kQLbctSNVVs2FF) The swap function will be suspended for “takers”, i.e. post-only disabled users, everyday from 13:00 UTC to 14:30 UTC. However, users can always place Post-Only Orders. ## What happens if Rebalanced? If a Rebalance was triggered at 14:00 UTC, the trading function for takers will be suspended until 02:00 UTC on the next day, same as 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 to “Expired” under Pending Orders. Users can cancel the pending orders at anytime. # Rebalance ## What is Rebalance? Rebalance is the action of resetting the Fair Values of Token BISHOP and ROOK back to 1. The amount of [your tokens](#user-content-fn-1)[^1] under each address might also change to reflect the adjustment. Rebalance is triggered when $$FairValue\_{Rook} / FairValue\_{Bishop}$$ is below 0.5 or over 2. ## Will the Rebalance of one underlying asset affect the others? No. BTCB, ETH and BNB are three separate funds. Although they follow similar mechanism, the NAVs of bQ/B/R, eQ/B/R and nQ/B/R are calculated separately, so is the Rebalance. ## Why Rebalance? Rebalance is designed for the following reasons: * During extreme events when market drops drastically, the earnings of BISHOP might be threatened. To protect the earning of BISHOP, Rebalance is triggered. * During extreme events when market drops drastically, ROOK's Fair Value would experience an expedited drop as the leverage ratio increases sharply. To stop the sharp depreciation of ROOK and restore the proper leverage ratio, Rebalance is triggered. * When the market price of the underlying asset rises, the leverage ratio of ROOK decreases. To restore a proper leverage rate for ROOK, Rebalance is triggered. ## Does Rebalance happen immediately after the Fair Value ratio hits the thresholds? No. Rebalance happens only during daily settlement time. That is to say, if the Fair Value ratio hit the thresholds during the day but was within the range of 0.5\~2 when the protocol conducted daily settlement, there will be no Rebalance. ## How exactly would my token amounts change? {% hint style="info" %} The calculation below applies to both Tranchess on BNB Chain and Tranchess on Ethereum. {% endhint %} **When** $$FairValue\_{ROOK}/FairValue\_{BISHOP} >2$$ After Rebalance: * Fair Values of BISHOP and ROOK are readjusted back to 1. * Fair Value of QUEEN remains unchanged. QUEEN holders would not be affected by Rebalance. * BISHOP holders would receive extra QUEEN tokens to ensure their total asset value is the same as pre-Rebalance. * ROOK holders would receive extra QUEEN tokens to ensure their total asset value is the same as pre-Rebalance. * For LP token holders, the BISHOPs in their LP tokens go through the same Rebalance process as individual BISHOP tokens, and thus, LP holders would also receive extra QUEEN tokens. * Fair Value of BISHOP-BUSD post-Rebalance = (BISHOP Balance + BUSD Balance)/Total LP Amount. Therefore, the post-Rebalance Fair Value of LP might not be exactly 1. ![](/files/by9BgYtcoZtCuSv1wNOo) Specifically: The extra amount of QUEEN token BISHOP holders would receive is: $$ QUEEN\_{Amount} =\[ \big( BISHOP\_{FairValuePre-Rebalance}-1 \big)/ SplitRatio\_{post-Rebalance} /2 ]\* BISHOP\_{Amount} $$ The extra amount of QUEEN token ROOK holders would receive is: $$ QUEEN\_{Amount} =\[ \big( ROOK\_{FairValuePre-Rebalance}-1 \big)/ SplitRatio\_{post-Rebalance} /2 ]\* ROOK\_{Amount} $$ The extra amount of QUEEN token LP holders would receive is: $$ QUEEN\_{Amount} =\[ \big( BISHOP\_{FairValuePre-Rebalance}-1 \big)/ SplitRatio\_{post-Rebalance} /2 ]\* LP\_{Amount} \*Ratio\_{BISHOP/LP} $$ {% hint style="info" %} QUEEN tokens are not affected by Rebalance. Similarly, nQUEEN-BNB LP tokens holders would not be affected by Rebalance. {% endhint %} **When** $$FairValue\_{ROOK}/FairValue\_{BISHOP} <0.5$$​ After Rebalance: * Fair Values of BISHOP and ROOK are readjusted back to 1. * Fair Value of QUEEN remains unchanged. QUEEN holders would not be affected by Rebalance. * BISHOP holders will see a decrease in the amount of BISHOP tokens they have. Meanwhile, they would receive extra QUEEN tokens to ensure their total asset value is the same as pre-Rebalance. * ROOK holders will see a decrease in the amount of ROOK tokens they have. The total value of ROOK tokens remains the same as pre-Rebalance. * For LP token holders: 1. BISHOPs in their LP tokens go through the same Rebalance process as individual BISHOP tokens, and thus receives extra QUEEN. 2. The QUEEN tokens would be automatically split into BISHOP and ROOK. 3. ROOK tokens are distributed to all LP holders. 4. BISHOP tokens are put back into the AMM pool. 5. If after the extra BISHOPs were put into the AMM pool, the total BISHOP balance in the pool was less than its pre-Rebalance amount, the protocol would extract excess BUSDs from the pool and distribute to all LP holders proportionally. 6. After Rebalance, LP holders are likely to receive both extra ROOK and extra BUSDs. * Fair Value of BISHOP-BUSD post-Rebalance = (BISHOP Balance + BUSD Balance)/Total LP Amount. Therefore, the post-Rebalance Fair Value of LP would be less than 1. ![](/files/HXeUJA3uNa4XB5nE65SA) Specifically: The amount of ROOK tokens after Rebalance is: $$ ROOK\_{Amount} =max \big{ FairValueROOK\_{pre-rebalance},0 \big} \* ROOK\_{AmountPre-Rebalance} $$ The amount of BISHOP tokens after Rebalance is: $$ BISHOP\_{Amount} =max \big{ FairValueROOK\_{pre-rebalance},0 \big} \* BISHOP\_{AmountPre-Rebalance} $$ {% hint style="warning" %} This is not a typo: in this scenario, we also refer to the pre-Rebalance fair value of ROOK when calculating BISHOP's post-rebalance amount. {% endhint %} The amount of extra QUEEN tokens BISHOP holders would receive is: $$ \[\big( FairValueBISHOP\_{pre-Rebalance} + FairValueROOK\_{pre-Rebalance} \big) / 2- max\big{ FairValueROOK\_{pre-Rebalance} ,0\big}]/ SplitRatio\_{post-Rebalance}\* BISHOP\_{AmountPre-Rebalance} $$ For LP tokens: * The amount of extra ROOK follows the same logic as the QUEEN calculation above because ROOK is the result of spliting the extra QUEEN. * The amount of extra BUSD contains both the provided BUSD liquidity and trading fees in the pool. BUSDs are distributed proportionally to all LP holders. If users want to know how much their LP holdings account for in the entire pool, they can obtain the total LP amount by reading "totalSupply" under the contract "LiquidityGauge" through BSCScan. All contract addresses can be found under [Contracts](/tech-support/contracts) ## Will Rebalance change the amount of CHESS tokens in my account? No. The CHESS tokens in your wallet will not be affected by Rebalance. ## When can I transfer my QUEEN, BISHOP and ROOK tokens between addresses after Rebalance? Users can transfer their QUEEN tokens immediately after Rebalance. BISHOP and ROOK tokens will be transferable 30 minutes after Rebalance. ## When will Tranchess functions resume after Rebalance? All functions are running as normal immediately after Rebalance in Tranchess V2, including staking/unstaking, AMM swapping and so on. ## Can I transfer my CHESS tokens between wallets during Rebalance? Yes. ## If all functions are working as normal right after Rebalance, why do I have to wait for 30 minutes for BISHOP and ROOK transfer? In Tranchess V2's fund contracts, there's a parameter called activityDelayTimeAfterRebalance, which is set to 1800 seconds. This parameter is there mainly for one particular scenario: if a user would like to transfer BISHOP and ROOK from his/her WALLET address. As we all know, for all on chain transactions there's always a gap between a user sending out a transaction request and the request finally got confirmed on chain. The waiting time could be very short or very long, depending on how congested the chain is at the time. If a user sent out a transfer request(from a wallet address) before Rebalance and the request was confirmed post-rebalance, the final transferred amount is likely to be different from the desired amount when the request was initially sent. In order to protect our users from such trouble, we set the activityDelayTimeAfterRebalance to 30 minutes so that, if a transfer request was sent out pre-rebalance and confirmed post-rebalance within the 30-minute window, the request would be reverted so users don't receive confusing amount of tokens. QUEEN token transfers are not limited by the activityDelayTimeAfterRebalance setting. Users can transfer their QUEEN tokens between wallets immediately after Rebalance. This 1800-second lock is ONLY for BISHOP and ROOK token transfers from **wallet** addresses, because wallet apps follow typical erc20 standards and there's not much "customized" adjustments we can do to cater the Rebalance design. {% hint style="info" %} In the Fund contract, there are two functions "trancheTransfer" and "trancheTransferFrom" that can also be used to transfer QUEEN, BISHOP or ROOK tokens. These two functions have an additional "version" parameter and make sure its value equals to the number of historical Rebalances. With this additional check, the senario with a standard ERC-20 transfer mentioned above will not happen, and these two functions are not affected by Rebalance. All Tranchess smart contracts use these two functions to transfer QUEEN, BISHOP and ROOK tokens. Therefore, the Tranchess website and all contracts work as normal immediately after Rebalance. {% endhint %} ## Is there anything I need to do after Rebalance is triggered? Boosting. Go to the Staking page and enroll again to keep your boosting momentum going. [^1]: This includes QUEEN, BISHOP and ROOK of the corresponding rebalanced assets, as well as BISHOP LP tokens, if you have any. # History Rebalance Record ## Complete Record of All Rebalance Events
{% hint style="info" %} In Tranchess V1, the NAVs recorded are pre-Rebalance NAVs. All NAVs would be adjusted back to 1 after Rebalance. {% endhint %} {% hint style="info" %} In Tranchess V2 and after, the fair value of QUEEN would remain the same before and after the Rebalance, while fair values of BISHOP and ROOK would be adjusted to 1. {% endhint %} ## Specific Token Adjustments for Each Rebalance {% hint style="success" %} ETH Rebalance, Mar. 5, 2024 (on BNB Chain. Tranchess on Ethereum ***was not affected***.) {% endhint %}
{% hint style="success" %} ETH Rebalance, Dec. 8, 2023 (on BNB Chain. Tranchess on Ethereum ***was not affected***.) {% endhint %}
{% hint style="success" %} BTCB Rebalance, Dec. 6, 2023 (on BNB Chain. Tranchess on Ethereum ***was not affected***.) {% endhint %}
{% hint style="success" %} BNB Rebalance, Oct. 12, 2023 (on BNB Chain. Tranchess on Ethereum ***was not affected***.) {% endhint %}
{% hint style="success" %} ETH Rebalance, Mar. 18, 2023 (on Ethereum. The ETH fund on BNB Chain ***did not*** rebalance.) {% endhint %}
{% hint style="success" %} BTCB Rebalance, Mar. 18, 2023 {% endhint %}
{% hint style="success" %} BTCB Rebalance, Nov. 9, 2022 {% endhint %}
{% hint style="success" %} ETH Rebalance, Sep. 17 2022 {% endhint %}
{% hint style="success" %} ETH Rebalance, Aug. 11 2022 {% endhint %} ![](/files/iep2FmyKyvTrVKGJR0ZI) ## Past Rebalances during Tranchess V1. ***(June 24, 2021 \~ June 9, 2022)*** {% hint style="success" %} BTCB Rebalance, Oct. 6 2021 {% endhint %} ![](/files/XjJlJUN2592b12pYHitg) {% hint style="success" %} ETH Rebalance, Jan. 6, 2022 {% endhint %} ![](/files/LMjBRyOf07umxXQOCLrp) {% hint style="success" %} BTCB Rebalance, Jan. 7, 2022 {% endhint %} ![](/files/ngx9WSnLo5ggJ9u8z8Tn) {% hint style="success" %} ETH Rebalance, Jan. 22, 2022 {% endhint %} ![](/files/oHyuFiAm0iTfvRdXrCZz) {% hint style="success" %} BNB Rebalance, Jan. 24, 2022 {% endhint %} ![](/files/S2IZgpRDn9JKYHeqe1Cp) {% hint style="success" %} BTCB Rebalance, May 10, 2022 {% endhint %} ![](/files/B5VOLriqfQS8VXkw8X7c) {% hint style="success" %} ETH Rebalance, May 26, 2022 {% endhint %} ![](/files/ntwfwJwRjXkZGKPBlvHW) {% hint style="success" %} BTCB Rebalance, June 13, 2022 {% endhint %} ![](/files/Xsw8vEahVqT1I85DYV09) {% hint style="success" %} ETH Rebalance, June 13, 2022 {% endhint %} ![](/files/SyWDP33nwdX5AwgDx8mB) {% hint style="success" %} BNB Rebalance, June 13, 2022 {% endhint %} ![](/files/F7Ci1XqLpQYoU4C1SpZT) # CHESS CHESS token and its tokenomics. CHESS is the governance token of the Tranchess community. ## How do I earn CHESS? You can harvest CHESS by staking Token QUEEN, BISHOP, and/or ROOK in the protocol. ## What is the total supply of CHESS tokens? The total supply of CHESS tokens is 300M. ## What is the CHESS token's contract address? 0x20de22029ab63cf9A7Cf5fEB2b737Ca1eE4c82A6 ## What is the token allocation of total supply? ![Token Allocation of CHESS](/files/-Mchvtsr9_XK50Zf7LiD) ## How long is the vesting schedule? Currently, the community incentives are planned to vest throughout a 207-week time period, that is around 4 years. ## How many tokens are released every week? Out of the 300Mn total supply of CHESS, 50% will be used for community distribution and incentives, of which 120Mn will be released on Tranchess. On Tranchess, CHESS distribution started on June 24th. The week from June 24th to July 1st is defined as "week 1". Week 1 started 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 was 3,000,000. CHESS staking reward for ETH starts on 14:00 UTC, November 4th, 2021. CHESS staking reward for BNB starts on 14:00 UTC, January 13th, 2022. The detailed emission schedule for all staked assets is as below:
{% hint style="success" %} By September 25, 2025, all CHESS tokens allocated for community incentives have been fully distributed, marking the completion of CHESS emission. {% endhint %} {% hint style="info" %} For the first four weeks after the ETH fund launched, the distributed CHESS tokens were allocated to the staked BTC and ETH funds at a certain percentage. The detailed split between the two funds are as below: {% endhint %} ![](/files/Q9FsensUoUufR6RFQmLg) \*: For week 24 onwards, the split between BTCB and ETH is calculated using the following formula: ETH% = ($$TVL\_{ETH}/ TVL\_{TOTAL}$$ + Last Week's ETH% )/2 BTCB% = ($$TVL\_{BTCB}/ TVL\_{TOTAL}$$ + 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. {% hint style="info" %} For the first five weeks after the BNB fund launched, there would be an additional amount of CHESS distributed to all Tranchess users besides the regular emission. Detailed schedule as below: {% endhint %} ![The split will stay as 20% BNB until further adjustment.](/files/XTWGN44yJfuf8Lkj6KhB) {% hint style="info" %} The split among all three funds is currently decided by 50% TVL ratio and 50% community voting result. {% endhint %} ## How many CHESS does a Token QUEEN/BISHOP/ROOK holder get every day? The weight for Token QUEEN, Token BISHOP, and Token ROOK is set at 3:4:2, which means that IF 1 QUEEN received 3 CHESS tokens in a certain week, then *during the same time period*, 1 BISHOP would receive 4 CHESS tokens, and 1 ROOK would receive 2 CHESS tokens. For example: Suppose that Tranchess distributed 300,000 CHESS in total during a certain week and had an average total number of 30,000 QUEEN, 15,000 BISHOP, and 15,000 ROOK staked in the protocol during that week. The average number of CHESS that each QUEEN could get during this period would be 5, each BISHOP would get 5\*(1+33%) ≈ 6.67, and each ROOK would get 5\*(1-33%) ≈ 3.33.
The weight for Q/B/R of the ETH fund is the same as the BTCB fund, thus follows the same calculation as the example above. # veChess veChess and its utility. veChess is obtained by locking CHESS. ## What’s the utility of the CHESS token? Currently, there are three main utilities for CHESS token, all require veChess: 1. To vote for the Alpha split between BISHOP and ROOK holders on a weekly basis. 2. To receive a weekly BTCB rebate, which totals 50% of the fees collected (gas fee excluded) within Tranchess. 3. To receive a boost on CHESS earning through staking. ## How does veCHESS voting determine the Alpha earning split between BISHOP and ROOK? Tranchess' BNB fund on the BNB Chain and the soon-to-come ETH liquid staking fund on Ethereum both generate staking rewards from the validator nodes, . The staking rewards are generated from users' staked BNBs and ETHs, and users receive nQUEEN and/or qETH based on the amount of BNB/ETH they've staked. Every week, Tranchess calculates and distributes the staking rewards to all QUEEN proportionally based on the total amount of QUEEN tokens in the fund. The total amount **includes** the sum of BISHOP and ROOK tokens since BISHOP and ROOK are split from QUEEN. Every week, Tranchess community vote and decides the split% of staking rewards distributed to BISHOP and ROOK. For easy understanding, let's look at an extreme example: Assuming that the current BNB fund has 2 staked BNBs, which created 2 nQUEEN tokens. The current split ratio is 100. Both BNBs are staked into the validator node for staking reward, and one of the two nQUEENs is split into 100 nBISHOP and 100 nROOK. Assuming that during week 0, the 2 staked BNBs received 1 BNB as the staking reward. (**Note: These are pure hypothetical figures for illustration purposes only**. For the actual staking APR, please refer to the [Tranchess BNB Fact Sheet](https://tranchess.com/fact-sheet#bnb).) Each nQUEEN would receive 0.5 BNB, which means there will be 0.5 BNB distributed to 100 nBISHOP and 100 nROOK tokens. If during week 0, the earning split voting result is BISHOP 30% and ROOK 70%, then at the beginning of week 1, 0.15 BNB will be distributed evenly to 100 nBISHOP and 0.35 BNB will be distributed evenly to 100 nROOK. Currently, Tranchess uses the following formula to calculate the PoS staking reward yield of BISHOP: $$ StakingYield\_{BISHOP}= Alpha\_{QUEEN} \* NAV\_{BISHOP+ROOK} / NAV\_{BISHOP} \* Weight\_{BISHOP} $$ $$ Alpha\_{QUEEN} = Alpha\_{total} -Protocol Fee $$ When the Alpha earning is less than the protocol fee (usually due to network issues), the protocol fee would be deducted directly from ROOK's Fair Value. ## How is veChess calculated? 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. 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, your veChess decreases linearly as the end date of the locking period approach. ## Do I need to gain veCHESS separately for ETH benefits? No you don't! For the CHESS already locked and the veCHESS already in your account, they would also enable you to enjoy the voting, fee rebate and boosting in the ETH pool. You need to enroll once to activate the reward, but there's no other actions needed. ## Why is my veCHESS in ETH pool slightly different from the number in BTCB pool? Once enroll veCHESS in ETH pool, the amount you would see is **the most recent** number, or the actual veCHESS figure. The veCHESS amount used for your BTCB pool might not be exactly the same because the protocol uses an older veCHESS number until user interacts with it, despite the actual depreciation of veCHESS that happens in the background. The two veCHESS number will gradually become the same as you continue to use the protocol. To understand more about how the protocol records and treats veCHESS, check out these two questions: {% embed url="" %} How often does my boost factor change? {% endembed %} {% embed url="" %} Why did my boost factor decrease after I lock more CHESS? {% endembed %} ## How do I participate in the weekly rebates? Lock CHESS and enroll your veChess in BTCB and ETH rebate. You will only need to enroll once to activate ETH rebate. In the future, enroll when there's a rebalance for the underlying assets. Detailed rules: On **Week 0, Thur 14:00 UTC**, Tranchess registers individual's and 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 as fees for the week, the BTCB rebate allocated to Alice would be 100/10000\*1\*50% = 0.005 BTC. Alice can claim this 0.005 BTC 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. ## What exactly is included in the weekly rebate pool? The weekly rebate pool contains 50% of all protocol income during the week. The other 50% is kept in the treasury for further collaboration with other protocols or improving the Tranchess ecosystem. For a full list of all protocol income, check out the following question： {% embed url="" %} What are the fees? {% endembed %} ## If I staked one of the underlying assets only, do I get weekly rebates from all pools? Weekly Rebate is determined by the recorded veChess amount. Your veChess grants you the benefit of weekly rebate. Even if you staked only one of the underlying assets, whichever it is, you would receive the weekly fee rebate from all asset fee rebate pools as long as you have valid veChess. ## Why didn't I receive any BNBs from this week's rebate? Users might occasionally find that they didn't receive any BNBs from a weekly rebate. And that is because, unlike the other two funds, the BNB fund does not always collect protocol income every day. When the redemption delay is longer than 1 day, BNB from all new creations is used to cover old redemptions and protocol income is accumulated instead of transferred to the rebate pool. Once there are enough BNBs to complete all waiting redemptions (by either new creations or completed undelegation from the validator), all accumulated protocol income is collected in a single transaction and you will see a BNB record with a larger amount on [this page](< https://tranchess.com/fact-sheet#general>). So don't worry, if you didn't get any BNB rebate in this week, rest assured that we've kept it on record. And you should be able to receive BOTH the old BNB rebate and the new ones in the coming week. ## How to calculate the APY for locking CHESS? The APY is calculated based on the last 7-day's rebate pool and the average lock duration. Below are the exact formulas: $$ APY = \big(1+WeeklyYield\big) ^{52} -1 $$ $$ Weekly Yield = \frac{(Last 7-day's ASSET\_{Reward} ) \times ASSET\_{Price} }{Total CHESSLocked \times CHESS\_{Price} } $$ ## What is Boosting? Boosting increases the rate in which you earn staking rewards. A boost factor of up to 3x is possible to increase your chess rewards anytime. For example, if you are currently earning 1000 CHESS per day by staking token QUEEN, BISHOP, and ROOK, a boost factor of 3x allows you to earn 3000 CHESS per day. ## When does Boosting start? Boosting will start on September 20th, 2021, at around 2 pm UTC. ## How can I activate Boosting? First, stake your QUEEN, BISHOP, and ROOK tokens. Second, ensure that you have veCHESS. Click “Enroll” after the Boosting feature goes live if you already have veCHESS before the feature launched. You only need to enroll once. If you don’t have any veCHESS yet, start locking CHESS and you will soon see the boost factor displayed as shown below: ![Testnet image, demonstration purpose only.](/files/-MjmDGuYSn8MkfP7LF46) Check out how to stake QUEEN, BISHOP, and ROOK here: {% content-ref url="/pages/-Mcih3otDcYltfhi8-zj" %} [Broken mention](broken://pages/-Mcih3otDcYltfhi8-zj) {% endcontent-ref %} Check out how to lock CHESS and earn veCHESS here: {% content-ref url="/pages/-Mfm2FC-lxem9vmDMum7" %} [Broken mention](broken://pages/-Mfm2FC-lxem9vmDMum7) {% endcontent-ref %} ## Do I need to lock more CHESS to enjoy the separate ETH boosting? No you don't. Make sure to have E-Q/B/R tokens staked and enroll for ETH boosting to activate the function, and you are good to go! ## How do I know if I am given a boost now? If you can see the Boost factor being displayed under CHESS rewards, then you are enjoying a boost now. If Boost factor is 1x or if you see a notice as below, then it would imply that you are earning CHESS at regular speed: ![Testnet image, demonstration purpose only.](/files/-MjmE1cC99bHeEog2dGA) {% hint style="info" %} If your account page looks exactly like the demo image shown above, CHESS locking is not the only action you are missing. Stake some QUEEN, BISHOP and ROOK tokens to activate CHESS mining first! {% endhint %} Lock CHESS now to boost: {% content-ref url="/pages/-Mfm2FC-lxem9vmDMum7" %} [Broken mention](broken://pages/-Mfm2FC-lxem9vmDMum7) {% endcontent-ref %} ## Will my boost factor change after I harvest CHESS? No. However, if you locked some of the harvested CHESS, it would affect your veChess, which would then change your boost factor. ## How often does my boost factor change? Your boost factor changes under two scenarios: 1. **Whenever the general staking pool changes**. That is, whenever there are more tokens staked or unstaked into the pool, or whenever you stake or unstake some tokens, your boost factor could change in tandem. 2. **Whenever you adjust your veCHESS amount.** By definition, veChess decreases linearly and continuously unless users increase their locked CHESS amount or extend the locking duration. This default decrease does not affect your boost factor. Locking more CHESS, extending the CHESS locking duration, or an expiration of the CHESS locking period would affect the boost factor. ## **Why did my boost factor decrease after I lock more CHESS?** As mentioned before, your veCHESS decreases linearly over time, however your boost factor will only take notice of your decreasing voting power when your action requires interaction with certain contract, like enroll, locking, unlocking, etc.. Until such interaction happens, your boost factor is calculated using the last recorded veCHESS amount, which might be much higher than the current actual veCHESS number. If the veCHESS proportion you obtain after locking more CHESS is less than the previous veCHESS proportion when your boost factor was calculated, the new boost factor might be updated to a smaller number. ## Do I get more fee rebates from Boosting? Boosting impacts the rate at which you earn CHESS. It does not directly increase the amount of BTCB or ETH rebate you get. However, your boost factor is partially influenced by the share of veCHESS, and the share of veCHESS decides your share of the rebate pool. So if you increased your share of veCHESS to increase your boost factor, you would have increased your share of the rebate pool at the same time. ## Will I get more boost by just holding any of the tokens? For QUEEN, BISHOP and ROOK, stake those tokens first to start the basic CHESS reward mining. Once the basic mining started, lock CHESS for boosting. Holding and locking CHESS tokens alone without staking Q/B/R does not activate boosting. ## How is the boost factor calculated? Tranchess considers multiple parameters when calculating the Boost factor. Check out the formula in our [Whitepaper](/whitepaper#boosting). There are two boost factors. The actual one applied to users' accounts and the potential max boost factor which is derived purely from the staking proportion of individual accounts. 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. To illustrate, we prepared two scenarios. Please note, since the boost factor can be affected by other users' activities (staking more tokens or increase veChess share), the examples shown below are for demonstration purposes only. In practice, the actual numbers might vary. **General Assumptions:** * The total staking pool has 17503 staked QUEEN, 756 staked BISHOP, and 682 staked ROOK. * Some of the staked tokens in other accounts are already boosted. * Total locked CHESS: 58859.5, average lock duration: 5 months. * In both scenarios, the three users' behaviors should be considered as isolated events. That is, the boost factors are results of only one user's behavior, not three concurrently. **Scenario 1:** Assume after staking the desired token, the user locked *1500 CHESS for 1 week*. ![](/files/-MjsedcYdoJHI7eX_e6Q) **Scenario 2:** Assume after staking the desired token, the user locked *1500 CHESS for 25 weeks (6 months)*. ![](/files/-MjsexqgM1grM18GXRkd) # Governance The Tranchess Governance Forum ## What is Tranchess Forum? Tranchess Forum is where community governance starts. While the full DAO UI is still under development, Tranchess Forum would be the place where all community members can participate in the development of Tranchess protocol. ## What can I find on Tranchess Forum? Right now the forum contains four different categories: Announcement, Proposal, General Discussion and Technical Support. **Proposal**: the main category of Tranchess Forum, where proposals regarding the new features, products, technical updates of Tranchess are released. The idea would be explained by the proposal, accompanied by a Snapshot voting. Announcement: where the Tranchess development team releases notifications and updates regarding the project. These announcements would usually also be released through other Tranchess official channels concurrently. General Discussion: just like its name, this is a category open to all topics (please keep them Tranchess-related). Technical Support: where you can ask questions and find answers regarding any technical difficulties and confusions that you've encountered while using Tranchess. ## How to participate in governance? * Join the discussion and provide insights by replying to the topics on the forum; * Read the proposals and cast your vote on Snapshot! ## What is Snapshot and how do I vote there? Snapshot is a tool that allows users to sign a transaction and express their preference without paying gas fees. Every proposal is required to include a specific Snapshot link, through which users can connect their wallet and vote for the option they like. ## What do I need to vote? Your voting power would be counted according to your veChess amount at a certain moment (which will usually be specified in the proposal). Hence, in order to vote, lock your CHESS first for veChess. To read more about veChess: {% content-ref url="/pages/-MhCI1tLjR0cAInHtOZM" %} [veChess](/faq/vechess) {% endcontent-ref %} To understand how to lock CHESS and obtain veChess: {% content-ref url="/pages/-Mfm2FC-lxem9vmDMum7" %} [Broken mention](broken://pages/-Mfm2FC-lxem9vmDMum7) {% endcontent-ref %} ## Where can I find more about Tranchess governance? Please visit the Tranchess Forum for more details [here](https://forum.tranchess.com). # Roadmap Or a to-do list, really. Tranchess we believe nothing is more rewarding than a good timing, and that's why instead of a roadmap we keep both a to-do list and a close watch on the market. Please note **the below tasks are not arranged in the order of sequence nor importance**. ## Product Offering * [x] Track more underlying crypto asset. * [ ] Offer a variety of fund structures through innovative synthetic derivatives. * [ ] Implement more use cases for CHESS token. ## Business Development * [x] Collaborate with other protocols in the ecosystem. * [x] Conduct ongoing functional upgrade with regular audits. * [x] Expand multichain. * [x] Build a full-fledged team, focusing on the tech/marketing field. # Milestone Timeline Continuous update as we move forward
# Media Kit In png formats for downloads {% file src="/files/oYxpOmIbtzYHr7W2IJmq" %} {% file src="/files/yzpHMbqXAed9YkNsgYtD" %} {% file src="/files/k7Y3oDPjewtYHoSOQAYx" %} {% file src="/files/j94X06inptLWNH2Ofomz" %} {% file src="/files/2liTje5Xi0gqP1Fh2wI5" %} {% file src="/files/VmJhAUs38Tyq7KEe98fq" %} {% file src="/files/zc74G0nGCMNEt43Zcjq1" %} {% file src="/files/OQOzZYatWvoGZvp5MuGS" %} # Intro: Transition Updates Information on the retirement process of qETH and eQUEEN funds. This is the **Transition Updates** page, your central hub for tracking the retirement process of the two products we are phasing out. Here, you will find the latest information, key milestones, and updates regarding the transition. This section aims to keep you informed every step of the way, ensuring a smooth and transparent process for all users. Whether you're looking for timelines, progress updates, or guidance on next steps, this is where you’ll find everything you need to stay up to date. Thank you for your understanding and support as we make these changes to better align our offerings with future opportunities. *** ### Background and past proposal: #### Which funds are we retiring: qETH and eQUEEN. #### Why: Resource optimization, market alignment, cost efficiency, and focused innovation. #### Past proposal: [TranchessDAO #10 - Streamlining Product Offerings for Operation Optimization](https://forum.tranchess.com/t/tranchessdao-10-streamlining-product-offerings-for-operation-optimization/304) #### Length of the process: The discontinuation process would take about 3\~4 months to finish. We will detail the steps and guidelines under this section. # Timeline & Milestones What will happen and where are we at now. We will list the steps to discontinue qETH and eQUEEN funds here. The checked ones are the ones that have been completed. *** ### qETH Fund * [x] Close the creation function for qETH. * [x] Remove the qETH-ETH Balancer pool CHESS emission voting option from the governance page. * [x] Close all existing validator nodes. This will take about 5\~10 days to complete. * [x] Upgrade the current smart contract for instant withdrawal support once all ETHs in the validator nodes are redeemed. The upgrade will take 1\~2 weeks. * [ ] We will keep the qETH redemption page up for approximately 3\~4 months, with the exact duration depending on the progress of ETH redemptions. **(In progress)** *** ### eQUEEN Fund * [x] Remove the redemption fee. * [x] Remove the merge fee. * [x] Remove the CHESS emission voting option for “ETH on BNB Chain” from the governance page. * [x] A three-month window: for eBISHOP and eROOK holders to swap back to QUEEN and redeem. During this window, any and all rebalances will be processed as usual. **(In progress)** * [ ] After the 3-month window, change the interest rate to 0 and the t-wap oracle to a constant. This will stop the fair values of eBISHOP and eROOK from changing, preventing future rebalances. * [ ] Close the creation function for eQUEEN. * [ ] Remove the CHESS emission voting option for the eBISHOP-USDC pool from the governance page. * [ ] We will to keep the eQUEEN redemption page up for approximately 3\~4 months. The exact duration depends on the progress of ETH redemptions. # User Guides Most of the processes are backend jobs on our side. But if you need to do anything, you will find the guides for required actions and FAQs here. *** ## Current Phase We are now: * Entering into the 3-month period for users to withdraw their assets from the qETH and eQUEEN funds. Both now support instant withdrawal. We have: * Closed the creation function for qETH; * Removed the redemption fee & merge fee for eQUEEN; * Removed both the "qETH-ETH Balancer pool" and “ETH on BNB Chain” CHESS emission voting option from the governance page:
{% hint style="info" %} As of this update (Jan. 20), users can still view the CHESS emission allocation for the ETH Fund on the BNB Chain at the bottom of the Tranchess homepage. This update reflects the outcome of last week's governance vote. However, starting Jan. 23, 14:00 UTC, the ETH Fund on the BNB Chain will not be listed on the front page under "This week's emission schedule." {% endhint %} * Upgraded the smart contract of the qETH fund for instant withdrawal. *** ## Required User Action You can withdraw your assets from qETH fund on Ethereum or WETH fund on BNB Chain now. *** ## Questions You Might Have ### Why are we keeping the creation function for eQUEEN? We need eQUEEN's creation function for swapping its BISHOP and ROOK tokens. Disabling the creation function too early will prevent users with only eBISHOP and/or eROOK from swapping back to eQUEEN. ### I cast my votes for this week's CHESS emission. Will it be affected? Nope. This week's CHESS emission for the two pools will be distributed as the voting results. However, as you can see, when you cast your vote this week (Jan. 16-Jan. 23) for next week's CHESS emission, the voting option for qETH and ETH on the BNB Chain no longer exists. # Protocol Overview Smart Contracts Explained ### # Fund ## Getting Fund Info #### `Fund.tokenUnderlying() → address` The address of the underlying asset. ```shell >>> fund.tokenUnderlying() '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2' ``` #### `Fund.tokenShare(uint256 tranche) → address` Getter for one of the addresses of `tranche`: QUEEN (0), BISHOP (1) or ROOK (2). ```bash >>> fund.tokenShare(0) '0x93ef1Ea305D11A9b2a3EbB9bB4FCc34695292E7d' ``` #### `Fund.primaryMarket() → address` The address of the primary market contract. ```bash >>> fund.primaryMarket() '0xcD0B4D35cc6Ec86d1D52b8Eb07b5d029e39bA70E' ``` #### `Fund.primaryMarketUpdateProposal() → address, uint256` Getter for the upcoming primary market upgrade, if any. #### `Fund.twapOracle() → ITwapOracleV2` The TWAP Oracle of the underlying asset. ```bash >>> fund.twapOracle() '0x2BaC57D29570Fe56B60216c26dA3C5B5c804B916' ``` #### `Fund.feeCollector() → address` The address of the fee collector of the fund. ```bash >>> fund.feeCollector() '0xbc428f6573827Db9773F9e4bC1f5C899c884842c' ``` #### `Fund.endOfDay(uint256 timestamp) → uint256` It calculates the trading day end timestamp of the given `timestamp`. A trading day starts at UTC time `SETTLEMENT_TIME` of a day (inclusive) and ends at the same time of the next day (exclusive). ```bash >>> fund.endOfDay(1604214000) '1604239200' ``` #### `Fund.trancheTotalSupply(uint256 tranche) → uint256` Getter for the total supply of `tranche`. ```bash >>> fund.trancheTotalSupply(0) '144207156642170957094' ``` #### `Fund.getRebalanceSize() → uint256` Getter for the number of historical rebalances. ```bash >>> fund.getRebalanceSize() '1' ``` #### `Fund.getRebalance(uint256 index) → Rebalance` Getter for the Rebalance parameters of a given rebalance version. ```bash >>> fund.getRebalance(0) ratioB2Q: '442549502169234' ratioR2Q: '0' ratioBR: '474988241234265736' timestamp: '1668702923' ``` #### `Fund.currentDay() → uint256` The end timestamp of the current trading day. ```bash >>> fund.currentDay() '1670248800' ``` #### `Fund.splitRatio() → uint256` The amount of BISHOP received by splitting one QUEEN. This ratio changes on every rebalance. ```bash >>> fund.splitRatio() '594418130555555555274' ``` #### `Fund.historicalSplitRatio(uint256 version) → uint256` Getter for past split ratio of a given rebalance version. ```bash >>> fund.historicalSplitRatio(0) '805392577500508333333' ``` #### `Fund.fundActivityStartTime() → uint256` Getter for the start timestamp of the current activity window of the fund. ```bash >>> fund.fundActivityStartTime() '1670162400' ``` #### `Fund.isFundActive(uint256 timestamp) → bool` Check if the fund is currently active. #### `Fund.getEquivalentTotalB() → uint256` Getter for the equivalent amount of BISHOP supply if all QUEEN are split. ```bash >>> fund.getEquivalentTotalB() '85719348463971426438951' ``` #### `Fund.getEquivalentTotalQ() → uint256` Getter for the equivalent amount of QUEEN supply if all BISHOP and ROOK are merged. ```bash >>> fund.getEquivalentTotalQ() '144207156642170957094' ``` #### `Fund.historicalEquivalentTotalB(uint256 day) → uint256` Getter for the past equivalent total amount of BISHOP on a given `day`. ```bash >>> fund.historicalEquivalentTotalB(1669903200) '85717176424199353954085' ``` #### `Fund.historicalNavs(uint256 day) → uint256, uint256` Getter for the past net asset values on a given `day`. ```bash >>> fund.historicalNavs(1669903200) navB: '1002161928302678888' navR: '1159606682688588925' ``` #### `Fund.extrapolateNav(uint256 price) → uint256` It estimates the current net asset values of all tranches, considering the current underlying `price`, the accrued protocol fee and interest since the previous settlement. #### `Fund.historicalUnderlying(uint256 day) → uint256` Getter for the past underlying amount on a given `day`. ```bash >>> fund.historicalUnderlying(1669903200) '144402940283113283926' ``` #### `Fund.getTotalUnderlying() → uint256` Getter for the current total underlying amount. ```bash >>> fund.getTotalUnderlying() '144439536988113283926' ``` #### `Fund.getStrategyUnderlying() → uint256` Getter for the current total underlying amount in strategy contract. ```bash >>> fund.historicalUnderlying() '128181515724000000000' ``` #### `Fund.getTotalDebt() → uint256` Getter for the amount of underlying that the fund owes the primary market for redemption. ```shell >>> fund.getTotalDebt() '0' ``` ## Handling Rebalances #### `Fund.doRebalance(uint256 amountQ, uint256 amountB, uint256 amountR, uint256 index) → uint256, uint256, uint256` Get the results of share amounts `amountQ`, `amountB`, `amountR` after performing the rebalance at `index`. * Note that this function performs no bounds checking on the given index; the transformation of a non-existent rebalance will result in undefined behavior. ```bash >>> fund.doRebalance(1000000000000000000, 1000000000000000000, 1000000000000000000, 0) newAmountQ: '1000442549502169234' newAmountB: '474988241234265736' newAmountR: '474988241234265736' ``` #### `Fund.batchRebalance(uint256 amountQ, uint256 amountB, uint256 amountR, uint256 fromIndex, uint256 toIndex) → uint256, uint256, uint256` Get the results of share amounts `amountQ`, `amountB`, `amountR` after performing the rebalances from `fromIndex` to `toIndex`. * Note that this function performs no bounds checking on the given indices. The original amounts are returned if `fromIndex` is no less than `toIndex`. A zero vector is returned if `toIndex` is greater than the number of existing rebalances. #### `Fund.refreshBalance(address account, uint256 targetVersion)` Transform share balances of `account`to a given `targetVersion`. * Note that setting `targetVersion` to zero transforms the share balances to the latest version. #### `Fund.refreshAllowance(address owner, address spender, uint256 targetVersion)` Transform share allowances of `spender` approved by `owner` to a given `targetVersion`. * Note that setting `targetVersion` to zero transforms the share allowances to the latest version. ## Transferring Tranche Tokens #### `Fund.trancheBalanceOf(uint256 tranch, address account) → uint256` Get the balance of `tranche` for the `account`. #### `Fund.trancheAllBalanceOf(address account) → uint256, uint256, uint256` Get the balances of all tranches for the `account`. #### `Fund.trancheBalanceVersion(address account) → uint256` Get the last rebalance version for the `account`. #### `Fund.trancheAllowance(uint256 tranch, address owner, address spender) → uint256` Get the allowance approved to `spender` of `tranche` by the `owner`. #### `Fund.trancheAllowanceVersion(address owner, address spender) → uint256` Get the last rebalance version of `spender`'s allowance by the `owner`. #### `Fund.trancheTransfer(uint256 tranche, address recipient, uint256 amount, uint256 version)` Refresh the balances of `msg.sender` and `recipient`, then transfer `amount` of `tranche` from `msg.sender` to `recipient`. It enforces the `version` to be the current rebalance version. #### `Fund.trancheTransferFrom(uint256 tranche, address sender, address recipient, uint256 amount, uint256 version)` Refresh the balances of `sender` and `recipient` and the allowances of `msg.sender` approved by `sender`, then transfer `amount` of `tranche` from `sender` to `recipient`. It enforces the `version` to be the current rebalance version. #### `Fund.trancheApprove(uint256 tranche, address spender, uint256 amount, uint256 version)` Sets `amount` as the allowance of `spender` over `tranche`. It enforces the `version` to be the current rebalance version. # Primary Market ## Getting PrimaryMarket Info #### `PrimaryMarket.fund() → address` The address of the fund contract. ```bash >>> primaryMarket.fund() '0x69c53679EC1C06f3275b64C428e8Cd069a2d3966' ``` ## Creating/Redeeming Tranches #### `PrimaryMarket.getCreation(uint256 underlying) → uint256` Get the amount of QUEEN created by `underlying` amount of the underlying asset. ```bash >>> primaryMarket.getCreation(1000000000000000000) '998239992407933623' ``` #### `PrimaryMarket.getCreationForQ(uint256 minOutQ) → uint256` Get the amount of the underlying asset to create at least `minOutQ` amount of QUEEN. * Note that this only works with non-empty fund for simplicity. ```bash >>> primaryMarket.getCreationForQ(1000000000000000000) '1001763110680249269' >>> primaryMarket.getCreation(1001763110680249269) '1000000000000000000' ``` #### `PrimaryMarket.getRedemption(uint256 inQ) → uint256, uint256` Get the amount of the underlying asset redeemed by `inQ` amount of QUEEN. ```bash >>> primaryMarket.getRedemption(1000000000000000000) underlying: '1001763110680249268' feeQ: '0' ``` #### `PrimaryMarket.getRedemptionForUnderlying(uint256 minUnderlying) → uint256` Get the amount of QUEEN to redeem at least `minUnderlying` amount of the underlying asset. ```bash >>> primaryMarket.getRedemptionForUnderlying(1000000000000000000) '998239992407933624' >>> primaryMarket.getRedemption(998239992407933624) underlying: '1000000000000000000' feeQ: '0' ``` #### `PrimaryMarket.redeem(address recipient, uint256 inQ, uint256 minUnderlying, uint256 version) → uint256` Redeem `inQ` amount of QUEEN and transfer the resulting underlying asset to `recipient`. It enforces the resulting underlying asset to be at least `minUnderlying` and the `version` to be the current rebalance version. * Note that the function would revert if there were queued redemptions that cannot be claimed at the moment. #### `PrimaryMarket.redeemAndUnwrap(address recipient, uint256 inQ, uint256 minUnderlying, uint256 version) → uint256` Redeem `inQ` amount of QUEEN, unwrap the underlying asset to its native currency, and transfer the resulting underlying asset to `recipient`. It enforces the resulting underlying asset to be at least `minUnderlying` and the `version` to be the current rebalance version. The underlying asset must be a wrapped token of the native currency. * Note that the function would revert if there were queued redemptions that cannot be claimed at the moment. #### `PrimaryMarket.queueRedemption(address recipient, uint256 inQ, uint256 minUnderlying, uint256 version) → uint256, uint256` Submit a redemption request for `inQ` amount of QUEEN. The resulting underlying asset will be claimable when the fund has enough balance to pay this redemption and all the previous ones in the queue. It enforces the resulting underlying asset to be at least `minUnderlying` and the `version` to be the current rebalance version. #### `PrimaryMarket.claimRedemptions(address account, uint256[] calldata indices) → uint256` Claim the underlying asset of an array of queued redemption requests by `account` and transfer the underlying asset to `account`. #### `PrimaryMarket.claimRedemptionsAndUnwrap(address account, uint256[] calldata indices) → uint256` Claim the underlying asset of an array of queued redemption requests by `account`, unwrap the underlying asset to its native currency, and transfer the underlying asset to `account`. The underlying asset must be a wrapped token of the native currency. ## Splitting/Merging Tranches #### `PrimaryMarket.getSplit(uint256 inQ) → uint256` Get the amount of BISHOP and ROOK split from `inQ` amount of QUEEN. ```bash >>> primaryMarket.getSplit(1000000000000000000) '594418130555555555274' ``` #### `PrimaryMarket.getSplitForB(uint256 minOutB) → uint256` Get the amount of QUEEN to split at least `minOutB` amount of BISHOP and ROOK. ```bash >>> primaryMarket.getSplitForB(1000000000000000000) '1682317460716381' >>> primaryMarket.getSplit(1682317460716381) '000000000000000465' ``` #### `PrimaryMarket.getMerge(uint256 inB) → uint256, uint256` Get the amount of QUEEN merged from `inB` amount of BISHOP and ROOK. ```bash >>> primaryMarket.getMerge(1000000000000000000) outQ: '1680635143255664' feeQ: '1682317460716' ``` #### `PrimaryMarket.getMergeForQ(uint256 minOutQ) → uint256` Get the amount of BISHOP and ROOK to merge into at least `minOutQ` amount of QUEEN. ```bash >>> primaryMarket.getMergeForQ(1000000000000000000) '595013143699254810084' >>> primaryMarket.getMerge(595013143699254810084) outQ: '1000000000000000000' feeQ: '1001001001001001' ``` #### `PrimaryMarket.split(address recipient, uint256 inQ, uint256 version) → uint256` Split `inQ` amount of QUEEN into BISHOP and ROOK and send the resulting shares to `recipient`. It enforces the `version` to be the current rebalance version. #### `PrimaryMarket.merge(address recipient, uint256 inB, uint256 version) → uint256` Merge `inB` amount of BISHOP and ROOK into QUEEN and send the resulting shares to `recipient`. It enforces the `version` to be the current rebalance version. # PrimaryMarket Router ## Creating/Splitting/Staking Tranches #### `PrimaryMarketRouter.create(address recipient, uint256 underlying, uint256 minOutQ, uint256 version) → uint256` Create QUEEN with `underlying` amount of underlying asset for `recipient`. It enforces the resulting QUEEN to be at least `minOutQ` and the `version` to be the current rebalance version. #### `PrimaryMarketRouter.createAndStake(uint256 underlying, uint256 minOutQ, address staking, uint256 version)` Create QUEEN with `underlying` amount of underlying asset and stake the QUEEN to `staking` contract for `msg.sender`. It enforces the resulting QUEEN to be at least `minOutQ` and the `version` to be the current rebalance version. #### `PrimaryMarketRouter.createSplitAndStake(uint256 underlying, uint256 minOutQ, address router, address quoteAddress, uint256 minLpOut, address staking, uint256 version)` Create QUEEN with `underlying` amount of underlying asset, split QUEEN into BISHOP and ROOK, stake the resulting BISHOP to StableSwap (found by querying `router` contract with BISHOP address and `quoteAddress`) for LP tokens. If `staking` is non-zero address, it further stakes the resulting ROOK to `staking` contract for `msg.sender`. It enforces the resulting LP token to be at least `minLpOut` and the `version` to be the current rebalance version. #### `PrimaryMarketRouter.splitAndStake(uint256 inQ, address router, address quoteAddress, uint256 minLpOut, address staking, uint256 version)` Split `inQ` amount of QUEEN into BISHOP and ROOK, stake the resulting BISHOP to StableSwap (found by querying `router` contract with BISHOP address and `quoteAddress`) for LP tokens. If `staking` is non-zero address, it further stakes the resulting ROOK to `staking` contract for `msg.sender`. It enforces the resulting LP token to be at least `minLpOut` and the `version` to be the current rebalance version. # StableSwap Router ## Getting StableSwap Info #### `SwapRouter.getSwap(address baseToken, address quoteToken) → IStableSwap` Getter for the swap instance for the given token pair. ```bash >>> swapRouter.getSwap() outQ: '1680635143255664' feeQ: '1682317460716' ``` #### `SwapRouter.getAmountsOut(uint256 amount, address[] path) → uint256[], IStableSwap[], bool[]` Calculate all subsequent maximum output amounts of the asset given reserves following the `path` of token addresses given an input asset `amount`. #### `SwapRouter.getAmountsIn(uint256 amount, address[] path) → uint256[], IStableSwap[], bool[]` Calculate all subsequent minimum input amounts of the asset given reserves following the `path` of token addresses given an output asset `amount`. ## Making Exchanges #### `SwapRouter.addLiquidity(address baseAddress, address quoteAddress, uint256 baseIn, uint256 quoteIn, uint256 minLpOut, uint256 version, uint256 deadline)` Deposit `baseIn` amount of `baseAddress` and `quoteIn` amount of `quoteAddress` to StableSwap pool of `baseAddress` and `quoteAddress`. It enforces the resulting LP token to be at least `minLpOut`, the `version` to be the current rebalance version, and the Unix timestamp `deadline` after which the transaction will revert. #### `SwapRouter.swapExactTokensForTokens(uint256 amountIn, uint256 minAmountOut, address[] path, address recipient, address staking, uint256[] versions, uint256 deadline) → uint256[]` Swap the exact `amountIn` of input tokens for as many output tokens as possible for `recipient`, along the route determined by `path`. The first element of `path` is the input token, the last is the output token, and any intermediate elements represent intermediate pairs to trade through. If `staking` is non-zero address, it further stakes the resulting output token to `staking` contract for `recipient`. It enforces the resulting output token to be at least `minAmountOut`, every `versions` to be the current rebalance version, and the Unix timestamp `deadline` after which the transaction will revert. #### `SwapRouter.swapTokensForExactTokens(uint256 amountOut, uint256 maxAmountIn, address[] path, address recipient, address staking, uint256[] versions, uint256 deadline) → uint256[]` Receive the exact `amountOut` of output tokens for as few input tokens as possible for `recipient`, along the route determined by `path`. The first element of `path` is the input token, the last is the output token, and any intermediate elements represent intermediate pairs to trade through. If `staking` is non-zero address, it further stakes the resulting output token to `staking` contract for `recipient`. It enforces the resulting input token to be at most `maxAmountIn`, every `versions` to be the current rebalance version, and the Unix timestamp `deadline` after which the transaction will revert. #### `SwapRouter.swapExactTokensForTokensUnwrap(uint256 amountIn, uint256 minAmountOut, address[] path, address recipient, uint256[] versions, uint256 deadline) → uint256[]` Swap the exact `amountIn` of input tokens for as many output tokens as possible andunwrap the output tokens for `recipient`, along the route determined by `path`. The first element of `path` is the input token, the last is the output token, and any intermediate elements represent intermediate pairs to trade through. It enforces the resulting output token to be at least `minAmountOut`, every `versions` to be the current rebalance version, and the Unix timestamp `deadline` after which the transaction will revert. #### `SwapRouter.swapTokensForExactTokensUnwrap(uint256 amountOut, uint256 maxAmountIn, address[] path, address recipient, uint256[] versions, uint256 deadline) → uint256[]` Receive the exact `amountOut` of output tokens for as few input tokens as possible and unwrap the output tokens for for `recipient`, along the route determined by `path`. The first element of `path` is the input token, the last is the output token, and any intermediate elements represent intermediate pairs to trade through. It enforces the resulting input token to be at most `maxAmountIn`, every `versions` to be the current rebalance version, and the Unix timestamp `deadline` after which the transaction will revert. # Node Operator Registry ## Getting Node Operator Info ```solidity /// @notice Node operator parameters and internal state /// @param operatorOwner Admin address of the node operator /// @param name Human-readable name /// @param rewardAddress Address receiving performance rewards /// @param withdrawalAddress Address receiving withdrawals and execution layer rewards struct Operator { address operatorOwner; string name; address rewardAddress; address withdrawalAddress; KeyStat keyStat; } /// @notice Statistics of validator pubkeys from a node operator. /// @param totalCount Total number of validator pubkeys uploaded to this contract /// @param usedCount Number of validator pubkeys that are already used /// @param verifiedCount Number of validator pubkeys that are verified by the contract owner /// @param depositLimit Maximum number of usable validator pubkeys, set by the node operator struct KeyStat { uint64 totalCount; uint64 usedCount; uint64 verifiedCount; uint64 depositLimit; } ``` #### `NodeOperatorRegistry.getOperator(uint256 id) → Operator` Getter for the operator record of the given `id`. ```sh >>> nodeOperatorRegistry.getOperator(0) operatorOwner: '0xe2F8CeFcDee51F48e3CE5c4Deea3095c43369b36' name: 'InfStones' rewardAddress: '0xe2F8CeFcDee51F48e3CE5c4Deea3095c43369b36' withdrawalAddress: '0xbF4Db410a07b3864A45074313150779b5b99889E' totalCount: '10' usedCount: '2' verifiedCount: '10' depositLimit: '320' ``` #### `NodeOperatorRegistry.getOperators() → Operator[]` Getter for an array of all existing operators’ records. #### `NodeOperatorRegistry.getRewardAddress(uint256 id) → address` Getter for the reward address of the given `id`. ```bash >>> nodeOperatorRegistry.getRewardAddress(0) '0xe2F8CeFcDee51F48e3CE5c4Deea3095c43369b36' ``` #### `NodeOperatorRegistry.getRewardAddresses() → address[]` Getter for an array of all existing reward addresses. #### `NodeOperatorRegistry.getWithdrawalAddress(uint256 id) → address` Getter for the withdrawal manager address of the given `id`. ```bash >>> nodeOperatorRegistry.getWithdrawalAddress(0) '0xbF4Db410a07b3864A45074313150779b5b99889E' ``` #### `NodeOperatorRegistry.getWithdrawalAddresses() → address[]` Getter for an array of all existing withdrawal managers’ addresses. #### `NodeOperatorRegistry.getWithdrawalCredential(uint256 id) → bytes32` Getter for the withdrawal credential of the given `id`. Unlike the withdrawal address, withdrawal credential is a piece of `bytes32` data including the withdrawal prefix (currently all Tranchess operators adopt **`ETH1_ADDRESS_WITHDRAWAL_PREFIX`**) and the withdrawal manager address. ```bash >>> nodeOperatorRegistry.getWithdrawalCredential(0) '0x010000000000000000000000bf4db410a07b3864a45074313150779b5b99889e' ``` #### `NodeOperatorRegistry.getKeyStat(uint256 id) → KeyStat` Getter for the validator key status of the given `id`. ```bash >>> nodeOperatorRegistry.getKeyStat(0) totalCount: '10' usedCount: '2' verifiedCount: '10' depositLimit: '320' ``` #### `NodeOperatorRegistry.getKeyStats() → KeyStat[]` Getter for an array of all existing validator key status. ## Getting Validator Key Info ```solidity /// @notice Storage for pubkey (48 bytes) and signature (96 bytes) /// @param pubkey0 [0-32) bytes of the pubkey /// @param pubkey1 [32-48) bytes of the pubkey /// @param signature0 [0-32) bytes of the signature /// @param signature1 [32-64) bytes of the signature /// @param signature2 [64-96) bytes of the signature struct Key { bytes32 pubkey0; bytes32 pubkey1; // Only the higher 16 bytes of the second slot are used bytes32 signature0; bytes32 signature1; bytes32 signature2; } ``` #### `NodeOperatorRegistry.getKey(uint256 id, uint256 index) → Key` Getter for the validator key struct of the given `id` and `index`. ```bash >>> nodeOperatorRegistry.getKey(0, 0) pubkey0: '0xb1b620b54b1909fdf1defc96e60350040cf7fef3dbdfa75099f977c835331201' pubkey1: '0x644fe9caa6d028dcef5c6d953cdc0d5900000000000000000000000000000000' signature0: '0x9295c7c1e51c224999192156e0af16ed06a251fd6c90dcce88819642f5109486' signature1: '0x4fe852dd979a1ec27ccab8dd704cd6170a361d5362d210cbba89a30c3ccda7ba' signature2: '0x0fcfe368e52ee1a3551145c0a30dfcc21d2ffccd0525e725ed5543dbb34ce92e' ``` #### `NodeOperatorRegistry.getKeys(uint256 id, uint256 start, uint256 count) → Key[]` Batch getter for the validator key struct of the given `id` and the range starting at `start` spanning `count` length. #### `NodeOperatorRegistry.getPubkeys(uint256 id, uint256 start, uint256 count) → bytes[]` Batch getter for the reconstructed validator keys of the given `id` and the range starting at `start` spanning `count` length. ```bash >>> nodeOperatorRegistry.getPubkeys(0, 2, 3) [ '0xb9deda6df019981189155383b54ec08de0f2ee73f696900a487d3dddc0876e366134bd76c6153f37f1dcd27fcbfd8697', '0xb1b620b54b1909fdf1defc96e60350040cf7fef3dbdfa75099f977c835331201644fe9caa6d028dcef5c6d953cdc0d59', '0xa105b2b7c4212b10a62389fae02f58f49c1f1570ec3e5e0a41c46691ec2de464519d9c234b9bc1d834107a7644b570ec' ] ``` #### `NodeOperatorRegistry.getSignatures(uint256 id, uint256 start, uint256 count) → bytes[]` Batch getter for the reconstructed validator signatures of the given `id` and the range starting at `start` spanning `count` length. ```bash >>> nodeOperatorRegistry.getSignatures(0, 2, 3) [ '0x846dceeac17a53b49373c68166dbd2dfb5fa4a89ada44d4fdfa054f73b087beb6bc01bb31e89b06d8b88a724110ceb9f033c9d1bee995b74a79f7dae42dad5a584dc01a3f33b80a20ee2451490ae9b2203f1fdb1430f3a8502747cb821d4b05f', '0x9295c7c1e51c224999192156e0af16ed06a251fd6c90dcce88819642f51094864fe852dd979a1ec27ccab8dd704cd6170a361d5362d210cbba89a30c3ccda7ba0fcfe368e52ee1a3551145c0a30dfcc21d2ffccd0525e725ed5543dbb34ce92e', '0xa6b177f3e9787049caa502959be8d07409fd80b4e93b81f27c262b586eba471845e995d8fac26b705de97aadd19c02390be6a88cdeed5e4ed1a0225843d9e5c7bbdb79cb6dc3912f58ef498f78c1e63895c9cda3651e06c63e1080c0ee78b97c' ] ``` ## Operating nodes #### `NodeOperatorRegistry.addKeys(uint256 id, bytes calldata pubkeys, bytes calldata signatures)` Batch add validator keys for `id`. `pubkeys` and `signatures` are the concatenated public keys and signatures without padding. `Id` node operator’s owner only. #### `NodeOperatorRegistry.truncateUnusedKeys(uint256 id)` Truncate all unused validator keys previously submitted for `id`. `Id` node operator’s owner only. #### `NodeOperatorRegistry.updateRewardAddress(uint256 id, address newRewardAddress)` Update the `operator.rewardAddress` to `newRewardAddress` for `id`. By default, the reward address is the same as `operator.operatorOwner`. `Id` node operator’s owner only. #### `NodeOperatorRegistry.updateDepositLimit(uint256 id, uint64 newDepositLimit)` Update the `operator.depositLimit` to `newDepositLimit` for `id`, which is the new maximal number of active validators the operator could get assigned. We recommend it to be the current total number of validator keys, but it could go beyond the current validator key total number. `Id` node operator’s owner only. # Governance & Crosschain ## InterestRate Ballot #### `InterestRateBallot.cast(uint256 weight)` Cast vote for the numerical value of the relative income percentage in Bishop NAV. `weight` is a number that should not exceed 1e18, representing 100%. To calculate the voting power the user, the function will synchronize its lock position with `VotingEscrow` contract. ## Controller Ballot #### `ControllerBallot.cast(uint256[] weights)` Cast a distribution of the user’s current voting power across all valid Tranchess funds, liquidity pools. and other eligible reward receivers. `weights` is an array of numbers that should sum up to 1e18, representing 100%. To calculate the voting power the user, the function will synchronize its lock position with `VotingEscrow` contract. ## VotingEscrow This contract handles the main logic for creation, redemption and balance calculation of the vote-lock CHESS token `veCHESS`. `vecCHESS` is the governance token in Tranchess ecosystem. Users should lock up their CHESS token for a specified period of time in exchange for `veCHESS`. The balance of `veCHESS` diminishes linearly with respect to time for all users alike. ### Depositing/withdrawing veCHESS #### `VotingEscrow.createLock(uint256 amount, uint256 unlockTime)` Create a vote-lock position of `amount` CHESS expired at `unlockTime`. Note that the `unlockTime` must be at the end of a future week but cannot exceed the maximal allowed lock time `maxTimeAllowed`. #### `VotingEscrow.increaseAmount(address account, uint256 amount)` Increase the number of CHESS of an existing vote-lock position. Note that you cannot call `increaseAmount` upon an expired position; you will have to `withdraw` the previous position and use `createLock` to create a new position. #### `VotingEscrow.increaseUnlockTime(uint256 unlockTime)` Extend the expiration date of an existing vote-lock position. Note that you cannot call `increaseAmount` upon an expired position; you will have to `withdraw` the previous position and use `createLock` to create a new position. #### `VotingEscrow.withdraw()` Withdraw CHESS locked in expired positions. ### veCHESS Crosschain #### `VotingEscrow.veChessCrossChain(uint256 amount, uint256 toChainID)` Transfer `veCHESS` to the `VotingEscrow` on another chain specified by `toChainID` using Multichain’s AnyCall infrastructure. User should pay cross-chain fee in native currency (e.g. ETH on Ethereum) when calling this function. Exact fee amount can be queried from the AnyCall proxy contract, i.e. `IAnyCallV6Proxy(thisContract.anyCallProxy()).calcSrcFees(thisContract, toChainID, 96)`. # Node Operator Everything a Tranchess node operator might want to know # The Mechanics of qETH A fundamental explanation of qETH qETH represents the time and quantity of ETH a user deposited in a fund. Users interact with Tranchess Fund to deposit ETH and create the equivalent US dollar worth of new qETH. qETH holders could swap qETH with ETH, provide liquidity for the qETH-ETH stable swap, or split into BISHOP and ROOK for more risk options. Furthermore, Tranchess Fund will stake the ETH into the ETH2 Deposit contract. Every 32 Ethers deposited would activate a new validator created by one of the node operators and earn stable ETH2 staking rewards. Note that since the rewards for a functional validator node are always positive and will constantly grow, the net asset value of qETH/ETH will almost always increase. Unlike Lido’s stETH, the balances of qETH does not get rebased on daily basis; what’s getting recalculated regularly is the net asset value of qETH. The staking rewards will be reflected on the increase in the net asset value (qETH/ETH). Therefore, qETH is naturally compatible with existing DeFi infrastructures. Fund would distribute fee rebates to node operators and veCHESS holders in qETH, which could be directly traded in the qETH/ETH pool from Balancer directly. Due to the illiquidity of the staked ETH, there is no way to collect the ETH rewards at the current Phase. Therefore, the fund would distribute qETH as the performance fee so that veCHESS holders and node operators could collect and participate in other activities with qETH at will. The strategy relies on trusted reporters to summarize individual node operators' current performance and update the fund's total underlying without actually receiving the ETH. In the short term, an off-chain reporter microservice will retrieve the total summation of all staked assets, but we will eventually update it into an on-chain oracle with quorum restriction. Most of the qETH performance fee get distributed among veCHESS holders, and a fraction of the fees go to each node operator. The overall operator fee rate is one of the parameters controlled by Tranchess Timelock. The community could always propose and vote to apply a new distribution ratio between node operators and veCHESS holders. For individual node operators, the strategy contract will distribute the qETH rewards based on performance. Namely, the greater the net profit a node operator made, the higher percentage of the qETH it would receive. **Step 1: User Creates qETH**
To get started, users deposit ETH to create qETH with Tranchess Fund. **Step 2: Strategy Assigns the Next Validators**
Strategy collects ready validator addresses from node operators. Strategy will continue to match up the validator address with the ETH deposit until either unused funds or idle validators run out. **Step 3: Operators Receive Rewards**
Once validators start earning rewards, Tranchess will deploy Reporter oracles to capture the per-operator performance and report the profit (or loss) to Strategy, which would further distribute rewards to the corresponding operator. # An example for Node Operators * Node Operator A and B are added to the `NodeOperatorRegistry` contract by Tranchess * Node Operator A calls this contract to adds 100 validator pub keys * Node Operator B calls this contract to adds 20 validator pub keys * Alice creates 200 qETH by depositing 200 ETH into the `Fund` contract * Bob creates 300 qETH by depositing 300 ETH into the `Fund` contract * The `EthStakingStrategy` contract fetches 480 ETH from the `Fund` contract and deposits to the ETH2 Deposit Contract. * The contract’s operator selection algorithm decides to use 5 pub keys from Node Operator A and 10 pub keys from Node Operator B. * Some days later, the validators are active and have gained some rewards. * Node Operator A’s 5 validators gain 0.2 ETH on the consensus layer. * Node Operator B’s 10 validators gain 0.3 ETH on the consensus layer. * A reporter reports all Node Operators’ total balance on the consensus layer to the `EthStakingStrategy` contract: A=160.2 ETH, B=320.3 ETH * 90% of the total rewards are added to the Fund and therefore increases the value of qETH * qETH’s total supply is still 500 and corresponds to 500 + 90% \* (0.2 + 0.3) = 500.45 ETH * Each qETH worths 1.0009 ETH now. * The rest of the total rewards are used to create new qETH tokens and distributed to Node Operators, veCHESS holders and Tranchess treasury. * Creation follows the current value of qETH. Each created qETH consumes 1.0009 ETH. * Each Node Operator gets a to-be-decided fraction x% of rewards from its validators. * Node Operator A gets (0.2 \* x% / 1.0009) qETH * Node Operator B gets (0.3 \* x% / 1.0009) qETH * The rest of created qETH tokens are transferred to the `FeeDistributor` contract, which then distributes them to veCHESS holders and Tranchess treasury. # Node Operator Manual Step-by-step guide for Node Operators ## Steps to become a Tranchess node operator 1. Provide Tranchess team with a `name` for display, and an address `operatorOwner` for operator registration. Note that `operatorOwner` holds the admin role for most properties of a registered node operator. Please properly secure the access. We recommend leveraging hardware wallets like Ledger to keep its private key. 2. Wait for the Tranchess team to register you in the smart contract. Once registered, you are assigned with a unique `id`, `withdrawalCredential` and `withdrawalAddress` * `id` is your node operator ID, which could help you look up all relevant data on profile through the `NodeOperatorRegistry` contract deployed at * `withdrawalCredential` is required for generating the `signature` in Step 3 * `withdrawalAddress` is required for configuring beacon chain validators in Step 5 3. Generate `pubkey` and `signature` for a few validators * Use 32 ETH as the deposit amount * Use the `withdrawalCredential` in the previous step * 10 validators are enough to start * All validators’ `pubkey` and `signature` can be found in the generated deposit data JSON file 4. Navigate to [Tranchess Operator Portal](https://tranchess.com/operator). Drag and drop the generated deposit data JSON file to the right column. The tool is designed to conduct several sanity checks such as key lengths and duplicates. If all looks good, click the “Add Keys” button to initiate the `addKeys` transaction. (You can also manually assemble the transaction. Please refer to the specific operation in the "Alternative Step 4" section below.) > ### **Alternative Step 4** > > Pack `pubkey` and `signature` into bytes arrays and submit them to the registry contract using the `addKeys` method: > > 1. Navigate to the “Write Contract” tab: > 2. Click ”Connect to Web3” and connect your operator owner address > 3. Expand the first function `addKeys` and fill in the parameters as follows > 1. `id`: Node operator ID > 2. `pubkeys`: Concatenate all pubkeys and add a “0x” prefix > 3. `signatures`: Concatenate all signatures and add a “0x” prefix > 4. Optionally, you could send the encoded `pubkeys` and `signatures` to Tranchess team in advance so that we could verify the submission before you sign any transaction > 5. Click the “Write” button and sign the transaction > > ```solidity > function addKeys(uint256 id, bytes calldata pubkeys, bytes calldata signatures) > ``` 5\. Configure the execution layer fee recipient of the validators to `withdrawalAddress` (see your validator’s doc for more info about fee recipient, e.g. [Prysm Doc](https://docs.prylabs.network/docs/execution-node/fee-recipient) and [Lighthouse Doc](https://lighthouse-book.sigmaprime.io/suggested-fee-recipient.html#:~:text=The%20fee%20recipient%20is%20an,fee%20recipient%20for%20your%20validators)). Make sure that the validator node has already gone live, since the validator key assignments could happen any minute following Step 6. 6\. As the `operatorOwner`, you could now lift up the `depositLimit:` 1. Navigate to the “Write Contract” tab: 2. Click ”Connect to Web3” and connect your operator owner address (if you haven’t done so) 3. Expand the 7th function `updateDepositLimit`: 1. `id`: Node operator ID 2. `newDepositLimit`: The new maximal number of active validators assigned. We recommend it to be the current total number of validator keys, but it could go beyond the current total validator keys. 4. Click the “Write” button and sign the transaction ```solidity function updateDepositLimit(uint256 id, uint64 newDepositLimit) ``` 7\. Optionally, you could also update the `rewardAddress`, which will receive operator fee in the future. By default, it is the same as `operatorOwner`. ```solidity function updateRewardAddress(uint256 id, address newRewardAddress) ``` ## Steps to batch remove unused validators In rare occasions when signature verification failed for newly added keys or when withdrawal credentials got an update, the Tranchess team will send out a notification for the corresponding operator to truncate all used keys 1. Coordinate with Tranchess team to find out the keys that will be removed; 2. Invoke `truncateUnusedKeys` to truncate all unused keys. ```solidity function truncateUnusedKeys(uint256 id) external ``` # Functions to Read Node Operator Information Navigate to [Tranchess Operator Portal](https://tranchess.com/operator). On the left column of the page, you will find a status summary of all operators for quick reference. For full details, the `NodeOperatorRegistry` contract implements the view functions to read node operator properties. A few commonly used functions are listed below. ```solidity /// @notice Statistics of validator pubkeys from a node operator. /// @param totalCount Total number of validator pubkeys uploaded to this contract /// @param usedCount Number of validator pubkeys that are already used /// @param verifiedCount Number of validator pubkeys that are verified by the contract owner /// @param depositLimit Maximum number of usable validator pubkeys, set by the node operator struct KeyStat { uint64 totalCount; uint64 usedCount; uint64 verifiedCount; uint64 depositLimit; } /// @notice Node operator parameters and internal state /// @param operatorOwner Admin address of the node operator /// @param name Human-readable name /// @param withdrawalAddress Address receiving withdrawals and execution layer rewards /// @param rewardAddress Address receiving performance rewards struct Operator { address operatorOwner; string name; address rewardAddress; address withdrawalAddress; KeyStat keyStat; } function getOperator(uint256 id) external view returns (Operator memory); function getRewardAddress(uint256 id) external view returns (address); function getWithdrawalAddress(uint256 id) external view returns (address); function getWithdrawalCredential(uint256 id) external view returns (bytes32); function getKeyStat(uint256 id) external view returns (KeyStat memory); function getPubkeys(uint256 id, uint256 start, uint256 count) external view returns (bytes[] memory pubkeys) ``` # Contracts Smart contracts for the SolvBTC Fund, slisBNB Fund, and all other funds on BNB Chain: {% content-ref url="/pages/Hu64fAVT4CvIeqmuHrlT" %} [Tranchess on BNB Chain](/tech-support/contracts/bnbchainv2contracts) {% endcontent-ref %} *** Smart contracts for STONE fund, weETH fund, and all other funds on Scroll. {% content-ref url="/pages/SChyuIgZdbj52tnfWnIV" %} [Tranchess on Scroll](/tech-support/contracts/scrollcontracts) {% endcontent-ref %} *** Tranchess liquid staking on Ethereum. {% content-ref url="/pages/-Me849ckNcVBd0lfLVdA" %} [Tranchess on Ethereum](/tech-support/contracts/ethereumcontracts) {% endcontent-ref %} # Tranchess on Scroll Smart contracts of the Tranchess funds on Scroll.
NameAddress
STONE Fund 2
Fund0x4B0D5Fe3C1F58FD68D20651A5bC761553C10D955
Token QUEEN0x6E20E4f0F1a3a6836840001E4195b65d7735D92d
staYSTONE2 (Token BISHOP)0x09750800529E7BBCd07D4760989B19061E79165B
turPSTONE2 (Token ROOK)0xBF4FF74aF2f4E1B3820c32A0fC3a47530367112e
PrimaryMarket0x088E2f0fCB2AcaA5aD990311839B1d37eE41679D
PrimaryMarketRouter0xA2901B0bdBD42747Ca162694D2fcb7A999E0c2Bf
TwapOracle0xA793FB87c9062CDB4A9db031343287A9173a1878
AprOracle0xF380BB909434D5a335e7073B6E17BF52982434A0
FeeConverter0x80DF7e2bb71CD38Af14eE8b1B510AD11c032155f
staYSTONE2-STONE Swap
StableSwap0xEC8bFa1D15842D6B670d11777A08c39B09A5FF00
LiquidityGauge0xD48Cc42e154775f8a65EEa1D6FA1a11A31B09B65
SwapBonus0x62b4b4723770a8F28aFb796613C7E245B3c30C86
STONE Fund
Fund 0x289E69E5B611F6193694F6Cfa2F93B7cF161253f
Token QUEEN0x3B97ccC0C8C5e10Ac3E7F1594B55B6239A493eEA
staYSTONE (Token BISHOP)0x820144D59d20f1838A88caE95c946a9Bb6a7fEA2
turPSTONE (Token ROOK)0x6f2D7CE6601A07FBFAA7b9c9608Ca99D5f35ff4a
PrimaryMarket 0x21366dE9707A1044e351280f085821C734791cee
PrimaryMarketRouter0x194c6AcC13E7ecDCb6fc767359291A6fEE179440
TwapOracle0xDD730B2EBE9E5679F695DB1aA695EF6F2c9A30DF
AprOracle0xB6D5d0a3a8298f9CC322D202D60669dd41621807
FeeConverter 0x00934045078c5159c706ED43b7fA9578b7E058E1
staYSTONE-STONE Swap
StableSwap0xD151ce31322aEa25E4779678dF0A3f376f9FFc6f
LiquidityGauge0x3c8465c04e7478B11C7B5Cee3919781Db5e6D464
SwapBonus0x33b5aD38DCD817090474D4f79B75E1403384e0C8
weETH Fund
Fund0xfbee64fa1a89b76976750d62c8f3298952C5a518
weethQUEEN (Token QUEEN)0xD180fB177890E78aF181823F4eb3cB5033eF7795
staYWEETH (Token BISHOP)0x0e6A005790559B60BFf5B8C3Ea68d2361F92CcAA
turPWEETH(Token ROOK)0xB5e3d3fD34689C27f3549781b0369B87db105839
PrimaryMarket0x47b3913e6AC7DCb9752769465F875596C6f194d4
PrimaryMarketRouter0xEDA4B3946e3A0F6dBE65bBF0A03a4D3a00cee32f
TwapOracle0x49195ECF9390C5E1fB0081ef28A77DF777E0cd65
AprOracle0xfEe8CdDcC1d2345d8e7057A5a19BC69694B86922
FeeConverter0x65CeCC46288abE7B22A4552A98620b78ed4b3462
staYWEETH-weETH Swap
StableSwap0x3d9f20E4F1F5aC1d5F24E271CE6364B2eEd71cA6
LiquidityGauge0x461F98b371ddb47fF0B60F6bE21d9858F13509cf
SwapBonus0x4dd610D8d2A8f7De277711f0DAe0E88e0B270Dff
Governance
STONE FeeDistributor0xdEC17F71Ef579123939ACA1bdfAEeC21eaE00D67
weETH FeeDistributor0xE302F06F7B9b3041f20508548CFF49A0E6FE83e4
Chess0x9735fb1126B521A913697A541f768376011bCcF9
ProxyOFTPool0xf440E381e682a458505C12db813dbc36da4f5970
ChessSubSchedule0xF3bf24b8FdB80B167B3fb6b97131fB942579Dafa
ChessController0xFAe0E20b4d74531e58ea31A964ADFC61C08FA13B
ControllerBallot0x034a993627c5f780e9Af80160EdC94F15C0E9FD7
VotingEscrow0xffD17794bF2e3BA798170f358225763F1aF8f5ba
TimelockController0xA253420a60911b896b87Db7E17192990A37734a9
ProxyAdmin0x80800C31672c534344dd639103B83b088DEdF5FF
Treasury0x1bf019A44a708FBEBA7ADc79bdaD3D0769fF3a7b
Miscellaneous
BatchOperationHelper0xBEfEB1F4afC01416aC25640C482DEFBF8f9D6E68
SwapRouter0x63BAEe33649E589Cc70435F898671461B624CBCc
FlashSwapRouter0x512d9CD7df5D4617fea9386Ae2D6C28d674378C4
# Tranchess on Ethereum Tranchess liquid staking and staked ETH yield enhancement on Ethereum
NameAddress
wstETH Fund
Fund 0x811c9dD8B7B670A78d02fac592EbbE465e5dD0FA
Token QUEEN0x6aFF2526D50fA742ca08Ed1cf6E3cf7987A30F5c
staYETH (Token BISHOP)0xd2DF8D600F7b32B8E708900646F8898C52158690
turYETH (Token ROOK)0x379E8D9F6a8A045a8654169fabFF8bCFEC0D3934
PrimaryMarket 0xa8BE5AB62794a647254e1e62844201EFC8477e22
PrimaryMarketRouter0x9c69B6CAF5074A2DEC33BDb84d0F871d509240FA
TwapOracle0xc32f23Ee32cB5681Eca5e84C2ae728c3f0b0149F
AprOracle0x37473872769ff711BD6d800e518061fAe67E10a9
FeeConverter 0x96ccae5662De55C50B997f13396E6A183074F9D5
staYETH-wstETH Swap
StableSwap0xAD06a2DBd34Da8f8Cf5f85d284A5B93A2057bDb5
LiquidityGauge0x2871956fB1cde2B28F8d77BbECB4D806a4664a9f
SwapBonus0xb6F98aa542C3C4AAFc1a187a39159BFb25B7C9e4
NameAddress
WETH Fund
Fund0x69c53679EC1C06f3275b64C428e8Cd069a2d3966
Token QUEEN0x93ef1Ea305D11A9b2a3EbB9bB4FCc34695292E7d
Token BISHOP0xBB18521b4b19bCB7e6C2327f13BBd8E8149CA3A9
Token ROOK0x307462d1A183659E9aF73fA1bCA7a0d858714598
PrimaryMarket0xcf116313bc9c3712A8165D9A8E1c311567C4C829
NonfungibleRedemptionDescriptor0x7D7473505978442f181eEb9BA147f418281A5504
PrimaryMarketRouter0xEa8E6F2c426d207cA0916adB42CeA032102B18Ba
TwapOracle0x2BaC57D29570Fe56B60216c26dA3C5B5c804B916
AprOracle0xA9f575D735439Eb4187b7BBC07459124811FeaaC
EthStakingStrategy0x96f4489fe75D0494bd5088B0D80b17A5759dac37
BeaconStakingOracle0xFFD3196Ce42Bed1fa988020c902Fe7Ea6624A15a
NodeOperatorRegistry0xE926F01953c3B94222FcAC7474b31e3F8eAfb308
SafeStaking0xFb399517BCB023751b363c2B4333F59D3A202f3D
WithdrawalManager0x4Ec117002928E5319BE38FAa16c7F87b0Ef3E6d3
WithdrawalManagerFactory0x16d0fF163E6430b99c3E23b8EeCbF840A029dd88
Governance
qETH FeeDistributor0xbc428f6573827Db9773F9e4bC1f5C899c884842c
USDC FeeDistributor0xe6E659ad43029E8d89Ded5D3FF030dDC5C909cbf
wstETH FeeDistributor0x00DB7B1300B2B24fB9bdf4F661f650a2998e367A
Chess0xD6123271F980D966B00cA4FCa6C2c021f05e2E73
ProxyOFTPool0x25CD496D66708166a06DA16ED641dd286CE76815
ChessSubSchedule0x0c5F4b16378DFBb71102DB10745B79B2DC22B03D
ChessController0xAa75969E8e407534F6f44D95b5B43b0E6a062750
ControllerBallot0x41b598D49ADE2DBf870b5987C25975EcEC16826f
VotingEscrow0x3FadADF8f443A6DC1E091f14Ddf8d5046b6CF95E
TimelockController0x509b82c847f90E9d19297C25965c534ae0562C35
ProxyAdmin0x18b80619FCa159Fe3c655a11C94C040f72241Abc
Treasury0x1bf019A44a708FBEBA7ADc79bdaD3D0769fF3a7b
Miscellaneous
BatchOperationHelper0x97238BC81fceDe211ECb49A6b16ca0Ad1d55a1D5
RewardClaimer for Balancer qETH/ETH pool0x7f08c4f98265712C162975CB8Da1cF3F5BF8FaC1
SwapRouter0x657498143D67E14d9928bC5Ec1608c771E6C3314
FlashSwapRouter0xd462276eF4Aa78A3533CF13518d97A16B96e0C95
# Tranchess on BNB Chain Smart Contract addresses for all funds and functions on BNB Chain.
NameAddress
uniBTC Fund IV
Fund0xC410977aa97366EB0250678CDC890C5E650609Ed
uniBTCQUEEN4 (Token QUEEN)0xc28fb6dA376A442B589A218e9f9bEf138E01D76C
staYuniBTC4 (Token BISHOP)0xaA107d3cF7035397E2F71b2b588926B01Ca125B4
turPuniBTC4(Token ROOK)0xFDC8a37F4286868751aD24af083cC31cBb991286
PrimaryMarket0xC94231f2f60656D1Ccd1129D67076157a4842166
PrimaryMarketRouter0x55AB1fa264113e32a709a380322eCdf33f4C3dD6
TwapOracle0x8cEb0f7f13c1d2A1076ff3E57493fc1E063B476F
AprOracle0xA096796e289609c715B4A3765e726097108b6E48
FeeConverter0xfCED57Ff211587a9beE78BDb7bCBa3f726cE8885
staYuniBTC4-uniBTC Swap
StableSwap0xda3bd77F8D05d86B9a6356A9cC89aC74939d1Ad4
LiquidityGauge0xa1e3f70c640126d7C3A7a4D026b7601c1942dA66
SwapBonus0x7c29a6a27D3EBD23D6908D16AAd6381377b1FC71
brBTC Fund IV
Fund0x2383A2fDAa3536BE5191e5eEAF57b9C9F71B8DF0
brBTCQUEEN4 (Token QUEEN)0xCDd85b349861E20bd35C4DE72cCd1034D46390C3
staYbrBTC4 (Token BISHOP)0xd4C753a46fb7861138C82588FA9Bc5dFd318856E
turPbrBTC4 (Token ROOK)0xA14424044Cd3e78A4f20Da2ADb25533837fa3547
PrimaryMarket0x756889b49E77e56606a715E4B20d9ec438b8602A
PrimaryMarketRouter0x245A734D01D594430fDf55B46c23C4f477134123
TwapOracle0x64D5Af5Ee4e2a6E9b7AdC04b340723011A25715c
AprOracle0xC61198fDD3b058AE355ebD55591f9cF81dfE83ea
FeeConverter0x6b0c7dd95E9dB7edd2ed5Adf056Bc502Eb1AEAF3
staYbrBTC4-brBTC Swap
StableSwap0xa6D9ad9fd68FA46333a13BB383cc682F50473596
LiquidityGauge0x70548DF45cD73eA326dedCF2F6f774E165cd52E3
SwapBonus0x32B67Cb26F8fB268C6C4f289e809173f4F6D33ae
NameAddress
uniBTC Fund III
Fund0xaC05FF30f79D0D697b5156F85839127101a51FE6
uniBTCQUEEN3 (Token QUEEN)0x1424CAC841DE6540a0df0ed102bE0C18c40A5bd3
staYuniBTC3 (Token BISHOP)0x716155Ad72558e848eaB5CB88d6522a3102F5e21
turPuniBTC3(Token ROOK)0xb87967eA83A8d980F1c4034d8319372E3fBE45D5
PrimaryMarket0x64e30FadE0eBf18Ab8A5123117729d1E374d8A45
PrimaryMarketRouter0x01A45d60AF80c42aA3199899F37A9867A87eB9EE
TwapOracle0x7A5a1170192F28f3EFe30eE6740A104B186f38a7
AprOracle0xFdc433b0Df72cd366F1864cc05553340D3EBc56C
FeeConverter0x911237fCf21421Fe50715B05304780006409e57a
staYuniBTC3-uniBTC Swap
StableSwap0xD0cC89cCf8c7500a3437952A61Df5E5d976e735C
LiquidityGauge0xf11a107A7bbFCFf107383f47249661f4E852371C
SwapBonus0x6911A973ab19Ac6258e5A1E866cC497bbA8a6594
brBTC Fund III
Fund0x155ded598a186148b8a2F1C7B442f9CeaaB0ec37
brBTCQUEEN3 (Token QUEEN)0xa8494CA15C6e70B9b27067Fd90Be614AAAf6389E
staYbrBTC3 (Token BISHOP)0x5aA9038E1934b163740b5077B679cCD833C79Da8
turPbrBTC3 (Token ROOK)0xecD4A7410aAd70858eB38F710E9FDBA49992653a
PrimaryMarket0xC667109e0C857dd7badf3DB28A57410Ee18e29EB
PrimaryMarketRouter0xBD1450AE1Ef037861f762C03aA55aF29F8BdFe17
TwapOracle0x894738A7465422c69C7372bE4aD448c6400FBC6C
AprOracle0x9060dac075f6B96E7d753A321652626cEc038d86
FeeConverter0xc36b90E56a1961cd24dc1E72118c4F635b87368f
staYbrBTC3-brBTC Swap
StableSwap0xC3655312b88B18C5Ab089192c46bDf9F73e75DbE
LiquidityGauge0xc837bEd032A798836214b587B3F7baa0B70Cd295
SwapBonus0x7813B3Ee5FB6E296c73039D0561CEc875cfCD0c3
NameAddress
asBNB Fund II
Fund0x29a90F69aF6ae84C745a3A83CdAc153987Be387E
asBNBQUEEN2 (Token QUEEN)0x1bb33B49D1cC221Da402Cc4277Ba32889f2651b8
staYasBNB2 (Token BISHOP)0xDBEB5f6667d3A6bF54603687E2d23273990CE0b9
turPasBNB2 (Token ROOK)0xbE7ee1B9Abf7cb4e781fCa15fDC9E72FADd601e1
PrimaryMarket0x4346d53e77FBCa11C37e25a51189E0344C8B93F5
PrimaryMarketRouter0xC5d5F9B2bc49fbc0A3565A48eE21256DfE79c343
TwapOracle0xF63293337cDF3581286255ffBbfcC2140F5df04f
AprOracle0x8dedf2651a7a7Ea8d47A4DFeb24524Afe304dD79
FeeConverter0x782546Cda7B28DDdec13B3968bDD35a6A466BAdf
staYasBNB2-asBNB Swap
StableSwap0x399bBBf150af24851b60a55d8de3397195D62B07
LiquidityGauge0x457CD6d7C7202D25489Ca05b9670FCbda0270a35
SwapBonus0x6BEC981b14E5a3872eB35BC19d9672078aa2eb2B
uniBTC Fund II
Fund0x91B07B0fB40874A61C2eD26Dd63869F579BefD34
uniBTCQUEEN2 (Token QUEEN)0x1395B84C8f62a0E03Cbc0Bc83714ce2D82ce5A34
staYuniBTC2 (Token BISHOP)0x5D3c9406feFB2D75f21a24118fa3Cf549c59557F
turPuniBTC2 (Token ROOK)0x01236EFc7C2e52FC940fcca055212a8403aa7eD6
PrimaryMarket0x9af013FAbfd2f4b8E3cd4Cf6d13Dfa502604198B
PrimaryMarketRouter0x8Cf1643C988d105A4B1a83Df8995FF52B083B276
TwapOracle0x53FD57358BF6Bc1F16A7Ccb09eC297353f9B1a4A
AprOracle0x44B8Bb13a27dD12D697c95605E858b7794aCF2D3
FeeConverter0x394E4F2BDFA4a513A1D0fc88B4634d1924ce2922
staYuniBTC2-uniBTC Swap
StableSwap0xB4C672600497EFd6ee1a74A50788a5cd1A0893E6
LiquidityGauge0x8a9A25F8ae5F96263c674da97aC1AFE95b6C3d49
SwapBonus0x125ED6972C9Baf701f33a2605caC33a2e5ce9c27
brBTC Fund II
Fund0xCb00aA9D486c1EF51D38A85C2d16cB849afFE6b6
brBTCQUEEN2 (Token QUEEN)0x3ff927f15e50227f7Db84Cf4F911f5825Bf172a1
staYbrBTC2 (Token BISHOP)0x9d076ecE5DD3ac22DfABFa08dcCEB1D7a244a7A6
turPbrBTC2 (Token ROOK)0x4c1E90A25D2782080114A1a58f78d91429e222B2
PrimaryMarket0x07a2d8c053015B57C2DFc2B7450d521De1bf5559
PrimaryMarketRouter0x3a000a62B82f9b4203C9686e1069D8F8F1c63977
TwapOracle0x827AEc5d01cE1E7dc729c86B7b9Ad6A3BB0D80F9
AprOracle0x0664332D908b1E26B72F7b4c341a051F7Be4736b
FeeConverter0x7716B84dFC8456c5C4Dee389e2e8d1BA113B6533
staYbrBTC2-brBTC Swap
StableSwap0xf443F22bdf347c2898429031512036191C5651Bc
LiquidityGauge0xC468dc3790627c2c4Cc2F856421C37AACAb0C753
SwapBonus0x6e6DFC6cb7d8c3A7D5d03E3179E977aeD69978a0
NameAddress
asBNB Fund
Fund0x97c8D5A7d9c9BE17a5B3fc83e14FBE2A878807A9
asBNBQUEEN (Token QUEEN)0xDCAECD09674e47f8ce6AB004032C8b9F1Ca3b76C
staYasBNB (Token BISHOP)0xD4b3c0E0B7ffc5166539e816d187E7F871C7188a
turPasBNB (Token ROOK)0xA5235D6E6b7684E5C870B797Fd3BA35Cc7eC4e7B
PrimaryMarket0x188Fe201b4335CfC1cC4f08B0C7a53488159f274
PrimaryMarketRouter0x1058c324d2E37c2Da848e7f427dEbf6Ef8264191
TwapOracle0xD5741E4b23CA486366307e43ADdEA1EB928e13e1
AprOracle0xAB7a90088c5B45E1A5ab0356CaF338e53097FaD8
FeeConverter0xFA9040d3fa9498064eaE047062AE7123f9Ad686b
staYasBNB-asBNB Swap
StableSwap0xBA5A53180504caE2f038685914084ed85d336C2b
LiquidityGauge0x7BD1790D0Da10CDB126Cd3BFb6cc57051287C054
SwapBonus0x23FaC9e289Cc5EeabD763af6d83086274749bc88
uniBTC Fund
Fund0x6DCD6942C740D3749792149A21eedF3d82CcE21E
uniBTCQUEEN (Token QUEEN)0x9ED29f2C0985Ac0eedC1D7aD7eFD5a032e9f16F2
staYuniBTC (Token BISHOP)0x21944A92Fb925C811D0543B7B23CFFb4b4385Ff1
turPuniBTC (Token ROOK)0xD94F01D2fB791882FC5E4d11Ca7FFd8192aE5F00
PrimaryMarket0xb26009f75E3f79122d69ECD4688F0E0B90a0EB2F
PrimaryMarketRouter0x46e6a5989569669B6B99C36f8b5C73dD28A4f5b0
TwapOracle0x18651BF4Dd2d920880614DF9ad9779Da8D4Ef250
AprOracle0x83b927Cb79793eD2642EA55840287F1357015D33
FeeConverter0x1dbf2B7b9AaAC27370B13f313C8716bc8A6063CA
staYuniBTC-uniBTC Swap
StableSwap0x0747277AC186a83F828C7Ac3Ba688f499D2a3F33
LiquidityGauge0x8A61419d04D7586F12944e361b053472363862ea
SwapBonus0xAa712f33796Ae98a884fBBEfB78dFBd839692C13
brBTC Fund
Fund0x04Eb0D1dCB55B5c3Fd08baaa286ac84c6E4F7BDd
brBTCQUEEN (Token QUEEN)0xB34309650024D48251f2B4d73c1372Ded31B71D3
staYbrBTC (Token BISHOP)0x17206FaDcF4E9884f1E584DE5d51b363Da26b09D
turPbrBTC (Token ROOK)0xce2a34Da4f20b942038114799cE8b3db0F9D9955
PrimaryMarket0x27b5dc8d68499a3878805Daa4dcbFF154cDD7Fc4
PrimaryMarketRouter0x09E9ECb58e8E485a4999cFe27A6acFE2Cd029290
TwapOracle0xf8143309af0EAe9138cC89254e2F2b6d4710c5d6
AprOracle0x0bC9fa36Aebeb8F7A1261f94e6049e6156C6beC3
FeeConverter0x0fD0130d7271AC44e3e252c58C5856bb11977087
staYbrBTC-brBTC Swap
StableSwap0x8aeA25b112A8A614a417E3Be36ddF8d9bbc46d4B
LiquidityGauge0xe4138a089d1a6aebb3aa3B969c45BB22E18898ea
SwapBonus0xC6549dCfF837bbe9a2F4061aEd188C91DcCCCBA7
NameAddress
SolvBTC.BBN Fund 2
Fund0x01907f044BCAe357f973d051B0f3B09093dc2763
sbbbnQUEEN2 (Token QUEEN)0x92B99c7CCbBD42EB789a564e6Bc73d2a7BB5Fa36
staYSBBBN2 (Token BISHOP)0x47cc4BeDa800A7860c1a310Eb8d8C440cAd74759
turPSBBBN2 (Token ROOK)0xF9cD7AcAbAcAba9E3170106663f18824cA1b9926
PrimaryMarket0xFAF33641c879bf7B5AD9387C0cF5B2084e0eEac9
PrimaryMarketRouter0xE3515EfD6A2d4C49dD7572546985bDee36542979
TwapOracle0x519c13180229EF835C44A262113B244e69bb7E88
AprOracle0xC3626f88fBe4712BE2f8322d8C1b29A8D428a983
FeeConverter0xf4FA05Cc4b4A16FE91AdF40f52852872bc6EBD07
staYSBBBN2-SolvBTC.BBN Swap
StableSwap0x2Fa534B3C9cd003e58dc1E8F44969846AF311698
LiquidityGauge0xe83cF7BA2ABE8981A1418f888423012d051dA23e
SwapBonus0xc29d808EaD2d9dbA0eDD04ca0Cfee0bD8d90B15f
NameAddress
slisBNB Fund 2
Fund0x50635585A2bd884D87Fcc83c5Fc5AaD91495EC6a
slisQUEEN2 (Token QUEEN)0xDB3D7e3ba3d5c2B9128A6E072d84Ca9A5EEaA3d3
staYLBNB2 (Token BISHOP)0xb309F9696EeF80a0b6476e02B84615aDC60F52a2
turPLBNB2 (Token ROOK)0x0a229c88653EC608f7Fd63D50A2c10169864223F
PrimaryMarket0x7A7bbE67A88F1bc13cAd01d9b1e2EcA4af47459D
PrimaryMarketRouter0x675b9D7F14596478Fc8cFf1A83bC60CF46Eaf832
TwapOracle0x2aBE5f5264FF838f84aB7610d37d3931Ba862683
AprOracle0x715cc099e5E0eCF2B000F7B527b68478b0F1A873
FeeConverter0x8dC8cED7fd2e50B28AA73795D03888AF1c716D9F
staYLBNB2-slisBNB Swap
StableSwap0x01209A232daf2068136d15E76c867c7f7fc21F4E
LiquidityGauge0x0FfEA70D4DE8c9cce7312a96c30E8f50C1dc567F
SwapBonus0x9797976A17101b447c19Bd421fdb9B5D875C234F
SolvBTC.BBN Fund
Fund0xb6730D3C7E43ab99a0558c6cAa5Ce59Fc393CEa1
sbbbnQUEEN (Token QUEEN)0x4e8A73fC32562bC43f0Ca311197AB5F50e7B5543
staYSBBBN (Token BISHOP)0x53Ef5c1b632E483e659A07dE6E72D9295Da471fD
turPSBBBN (Token ROOK)0x3f143697aCeD30dC167A4CfD73a6Ce6Bc56A4C7A
PrimaryMarket0x9FB23b8a8Eb33546346E09A9b780d8F54922eAD0
PrimaryMarketRouter0xFDF6c8cf9FaAdc5b9b829C9c8DbBCF15c3Fd3463
TwapOracle0x6037AEFcfbCD1e0bD3108c58f630968dA144D165
AprOracle0x241be9004148d9c12606e412F4938b731b4A20b5
FeeConverter0x4b1D68aF09aDb36d8640C06510820aFA412ed0bC
staYSBBBN-SolvBTC.BBN Swap
StableSwap0xbbb1aa81E95298D64B7f710B936D89394DBdd28f
LiquidityGauge0xBc4aC15F72e3FcFd77DC7dEd423CeB43d373A15d
SwapBonus0x1B52bA6a757434B6B9C62E0d92e3d0bA1E3Aa832
SolvBTC Fund
Fund0x78006B8B80677aeD97ae4f55782E75CE956F54D6
sbtcQUEEN (Token QUEEN)0x9C1829B5d1D8533a4eC1d1b8E62081a34ee82244
staYSBTC (Token BISHOP)0x40fACA191E8c571ffE37c631e78732b49845d52F
turPSBTC (Token ROOK)0x1D56Ee9C14734da0a6ff3eB2A9b7b2669A387E2b
PrimaryMarket0xF2b1EB5486C2AbCCB0EA5b434338FE66B6A111c0
PrimaryMarketRouter0x32a8bb260C6BE0191aD63C4BcF6990D8d4ab4335
TwapOracle0x3C857FF74516BA078155571aD53Aae0bE13e12bf
AprOracle0xBf4507c99898864D3Eed6A13FCd008197b455338
FeeConverter0xB7dF19AB27520006292Ebe15704d28976F6Cc790
staYSBTC-SolvBTC Swap
StableSwap0xf4302b631516E1BDa4f46730856DcaA588Ed2BBb
LiquidityGauge0xf0E6b7Aec2c35c16E47AB342F071718c46f1Cf56
SwapBonus0x4FCA6BaB60C2CfD7852781EFC18972454752A500
slisBNB Fund
Fund0xfD53F8dAaE81F8eb7f5d434E1922949cE6D24f67
slisQUEEN (Token QUEEN)0x0818293f0C6c4e752c4927fff881CBaD1f3723b7
staYLBNB (Token BISHOP)0xff23266e1d30582bB4280D3F01F573a75bB79c7C
turPLBNB (Token ROOK)0x65067CD304850a06A083c4Dbc59A57940Db9dF6D
PrimaryMarket0x2C5752dF78d53955fBD4C585A66Eb12DCC78033a
PrimaryMarketRouter0x235f1bd0c3e155D6E214474a4F6C76350d1A3C20
TwapOracle0x30Bdb451356f37eCe856C8de7a8dd4E0285dDd74
AprOracle0x56bA1f1097a183d649119067616132308D5Dc314
FeeConverter0x29201657BaED8FD0AC66fB10244A2C0d37ca5342
staYLBNB-slisBNB Swap
StableSwap0xD3d47598B56e15D5A3f466fC93517d97f7b6256E
LiquidityGauge0x424ffF3C4ecf03398d5c3652463667782065058E
SwapBonus0x41e80d4BB7F6922fCdee112474Ee1E0ffBe65D65
NameAddress
BTCB Fund
Fund0x2f40c245c66C5219e0615571a526C93883B456BB
Token QUEEN0x81607ff6Fb66e089B573f2CDB428DE4C7fCDbDDE
Token BISHOP0xF87E3D9c0fBD50eeB82cE55205Ad68D71177E77e
Token ROOK0x0e5304160fb7750E89F0A617F5E02bDcF15ac4a4
PrimaryMarket0x25c601a3fca896BE827ef47E52bfcAb18601Eb17
PrimaryMarketRouter0xA61F3d8073f7d83c21761a123b8083Ff73e2F6E1
TwapOracle0x1Fe93AeC4Ae87132a815F44Bf814Da11D3dba99f
AprOracle0x8424D933FbB73665E5a8880de63C7B1366a56EeD
BscAprOracleProxy0x82c9FdF1a17071cd8150aF9c125a21D566d5B165
ShareStaking0x66f9D16dB828D340858b1fD4859c4030247d4b70
UpgradeTool0x8347B6f298340954565bC6c8a47D55Bb21313aA8
ETH Fund
Fund0x1F18cC2b50575A71dD2EbF58793d4e661a7Ba0e0
Token QUEEN0x1094EE7227B03CCb47113309EE51F327bbd6f175
Token BISHOP0x6369395Ab20386b3bf6FEfb30e6eb759012Fea89
Token ROOK0xe94A3eaedCa412A92869345492cb95c1B80f4665
PrimaryMarket0xec887f1eD49Ff192A8Ac3Fcb82E120Bd6785F522
PrimaryMarketRouter0x678DAd6d69b610e0A6440ca2Bd184154689D0fCd
TwapOracle0xda82DBfE2aa32Dc4C888A73f75C57a44D564FFDe
AprOracle0x8424D933FbB73665E5a8880de63C7B1366a56EeD
BscAprOracleProxy0xfc36880eBA1194C3b7bDFc8f2934C34944f9C931
ShareStaking0xaF098f9AAdAd3bD8C9fc17CA16C7148f992Aa1b4
UpgradeTool0x8369d4C07a1F853c5d167C9a042fcc918C3705a6
WBNB Fund
Fund0x7618f37EfE8930d5EE6da34185b3AbB750BD2a34
Token QUEEN0xA5b75770FfBCaC62AaC621d57D7ce9f4EA60D7e7
Token BISHOP0x20D269c5bF15B6679D832ED05734E30a7657dDF3
Token ROOK0x89035Eb6dC4D3Bb504c39E05F6cf25a7C8F68bbC
PrimaryMarket0x991c55304790c75cEbEe69da7601A18aA0977F24
PrimaryMarketRouter0xd5396F6D8173bD0a8f64c68d81b41a39162673eE
TwapOracle0x482f8b17Fe5D0F24Cca7A5E8c65E3975030A83eC
AprOracle0x8424D933FbB73665E5a8880de63C7B1366a56EeD
BscAprOracleProxy0x1c319EC0DEF2474108ad5645a8b6fd92F9f35583
ShareStaking0xFa7b73009d635b0AB069cBe99C5a5D498F701c76
UpgradeTool0xFd781525e7778cFC84D005cb120CF550e1536B9b
Strategy0xDe9F4B6637531852A0C9edad0C92Be839b92437b
Delegator on Binance Chain (1)bnb1y4hx0nyaumf5xjw58qmtwgpfj5fys8cjpwdnhf
Delegator on Binance Chain (2)bnb1sv5g5h7vqe7hufhuq6nes6l9ehrzk5vslmtvp0
bBISHOP-USDC Swap
StableSwap0x6Da3A029d0F0911C7ee36c1cEa2Ea69Fc31dd970
LiquidityGauge0xF2A64F6Fbd72a51EC1963593fF78b742B35D0A38
SwapBonus0xb48D3CD9B1C34c204Ce2e2d9bB7aCcaA937F0bba
eBISHOP-USDC Swap
StableSwap0x09427783666Ec4173e951222ab9B3C12871400AA
LiquidityGauge0x74c8A2E9bc849F023aD15339A5f5e47675b3d633
SwapBonus0xa703768EEC79CfD3b442539FbDAAFC8cfA723f52
nBISHOP-USDC Swap
StableSwap0xD3392699d679DFa57bC8ee71a0Ad44902C1Ab9f7
LiquidityGauge0xF71caD58e91b5f4FAfe19Fdc4FE747E2eBBd5aFe
SwapBonus0x4871782098eF453226b6Bea633280c4533d78BaE
bBISHOP-BUSD Swap(Legacy)
StableSwap0x999DB223F0807B164b783eE33d48782cc6E06742
LiquidityGauge0x3F586aA29C61488f25748911be3c52246c744fc2
SwapBonus0xC219786F83f25ad0Dcee8a3bD1077Cb729e056D5
eBISHOP-BUSD Swap(Legacy)
StableSwap0x87585A84E0A04b96e653de3DDA77a3Cb1fdf5B6a
LiquidityGauge0x00d150c057F5d66107Dfdb9d6d97F8B53eBd4D7A
SwapBonus0xe68910bEAbB617cd40f2eA68a3bF755Ae1ADf3CB
nBISHOP-BUSD Swap(Legacy)
StableSwap0x56118E49582A8FfA8e7309c58E9Cd8A7e2dDAa37
LiquidityGauge0x131678e24F5F447D0a6a1A42Ff7d7723861a9d30
SwapBonus0xdFd3B0DBf3e506E8ef4d0Ffe2820B5a798f793ED
nQUEEN-WBNB Swap
StableSwap0xfcF44D5EB5C4A03D03CF5B567C7CDe9B66Ba5773
LiquidityGauge0x7350D28B4919D9B05443C0d0121b6DbcB76f022f
SwapBonus0x4ae8190fD543167341DDc51682182F5BCB7f4056
Governance
SOLV FeeDistributor0x4d8dCeC171be8Cb32AC9a39F6b024879459B7BB7
wSCR FeeDistributor0x111150736cdea75Eb84cfd86a93E93a60EC56628
SolvBTC.BBN FeeDistributor0x5bd53B0258c38cbf3e57950697f06021c037eb22
SolvBTC FeeDistributor0xe5f4Efe076B830f69a6b3bAd6005618F86DAD5c6
slisBNB FeeDistributor0x57c6DF30436c9f1864536315e157Cb999Ee20Edb
BTCB FeeDistributor0x85ae5e9d510d8723438b0135CBf29d4F2E8BCda8
ETH FeeDistributor0x67EB546A69c7e4d83F3c66018Fa549Dff5FED35b
WBNB FeeDistributor0xE06F85862af08c1C5F67F96e41eA663E29639DAe
BUSD FeeDistributor0x4832f0FaeAE2b9458D0c01BCc11B99d44D16FD42
USDC FeeDistributor0xa80287d7183e23D460AC01f05C1b7f3d0FB76Ea2
STO FeeDistributor0xA4Ecd920aA06639cf27E817c358D5480DAfaFb69
Chess0x20de22029ab63cf9A7Cf5fEB2b737Ca1eE4c82A6
ProxyOFTPool0x38F51Be38c01126FD671586ec9d35c58A1672D59
ChessSchedule0xf071dE0E7A6FfCeee252Df25678c725f04A03b80
ChessScheduleRelayer for Ethereum0xb400D19454efd87EC4199A1f19dbBBAA2352Cd10
ChessScheduleRelayer for Scroll0xdd2Cf276D19F67dEAd53311eEebF3e9AB08122eb
ChessController0x0a7E898e1fAB8639dc3a416fE844662F209de8eD
ControllerBallot0xD1d463D180bC057D104a11654Fad4c5493FAf8d3
VotingEscrow0x95A2bBCD64E2859d40E2Ad1B5ba49Dc0e1Abc6C2
InterestRateBallot0xe5CF958Ff94eADb5247fd4D5C649D85dcf828a0E
TimelockController0x4BB3AeB5Ba75bC6A44177907B54911b19d1cF8f7
ProxyAdmin0x88C8890505384F4Eb3A281274b1DEdFFf8448147
Treasury0x1bf019A44a708FBEBA7ADc79bdaD3D0769fF3a7b
Miscellaneous
SwapRouter0x3599dDC1efcE801f8657f64127ACB07c0B5CAdC2
FlashSwapRouter0x0D5108377C86F4Dcfe473177e0Ca555095fDa0e0
FlashSwapRouterV30x5F2217f0e67Af3a6571Cf4356DD8F6AeB6C60024
BatchOperationHelper0x5647bed4A4d7544d667AEaaBF71b13f1c152529D
BatchUpgradeTool0xD7D8484c835487C2A88c5E653f75E570EeCdE071
# \[Archive]Tranchess V1 Contracts Archive of V1 smart contracts.
NameAddress
BTCB Fund
Fund0xd6B3B86209eBb3C608f3F42Bf52818169944E402
Token QUEEN0x15D0318Fddf785aC0d3ba690C0033b3bedF4c648
Token BISHOP0x8cC456B384C8aD06BF430F4F130Aa63EF0dc6f85
Token ROOK0x80da8Ca6c3DabD3a9f06Ca8eEed5d61687fab7ef
PrimaryMarket0x19Ca3baAEAf37b857026dfEd3A0Ba63987A1008D
Swap0x1216Be0c4328E75aE9ADF726141C2254c2Dcc1b6
FeeDistributor0x85ae5e9d510d8723438b0135CBf29d4F2E8BCda8
TwapOracle0xE4e5c76C9F2274375297559aF030C4B55c7703EB
AprOracle0x8424D933FbB73665E5a8880de63C7B1366a56EeD
ETH Fund
Fund0x677B7304Cb944b413D3c9aEbc4D4B5DA1A698A6B
Token QUEEN0xEd3805EDE679cc48fe1E91E561138bca659fCA43
Token BISHOP0xfff9fC084cb58974DEfaa27E05e1FE2439B75dd9
Token ROOK0xA0c1A9A702dE28d1562C423ccEF74Bbd45e4dCBb
PrimaryMarket0x57C8041C6Aa3440843b5E48B16016A95F822195f
Swap0xB13a07C57bA5297506c71e9c958210Fea8bbCEF0
FeeDistributor0x67EB546A69c7e4d83F3c66018Fa549Dff5FED35b
TwapOracle0x7B38e4d28767638a1725766F8CDeEF4abD4b44f6
AprOracle0x8424D933FbB73665E5a8880de63C7B1366a56EeD
BNB Fund
Fund0x629d4562033e432B390d0808B54A82B0C4A0896B
Token QUEEN0xF8D829C3eB05C078e7911EfB3303C7899c8D2C3A
Token BISHOP0x9Fd554CDb6e77D9Aa048A37DCccee41FfFad1a90
Token ROOK0x3A632B713637D837fF3b0e34D093A21DA1EF9fb1
PrimaryMarket0x15F2FeFcF313d397F9933C1Cb7590ab925d5cb59
Swap0x42867dF3c1ce62613aae3f4238cbcF3d7630880B
FeeDistributor0xE06F85862af08c1C5F67F96e41eA663E29639DAe
TwapOracle0xC8051D8A62851ad4b99B46d503Cb0b0b8C92F35d
AprOracle0x8424D933FbB73665E5a8880de63C7B1366a56EeD
Strategy0x82457aDF5f7F1fD22622DF4808f06392b170134D
Delegator on Binance Chain (1)bnb1y4hx0nyaumf5xjw58qmtwgpfj5fys8cjpwdnhf
Delegator on Binance Chain (2)bnb1sv5g5h7vqe7hufhuq6nes6l9ehrzk5vslmtvp0
Governance
Chess0x20de22029ab63cf9A7Cf5fEB2b737Ca1eE4c82A6
ChessSchedule0xf071dE0E7A6FfCeee252Df25678c725f04A03b80
ChessController0x0a7E898e1fAB8639dc3a416fE844662F209de8eD
VotingEscrow0x95A2bBCD64E2859d40E2Ad1B5ba49Dc0e1Abc6C2
InterestRateBallot0xeB76E34834fB0E2c31D92f0284466385bcE5c09A
TimelockController0x4BB3AeB5Ba75bC6A44177907B54911b19d1cF8f7
ProxyAdmin0x88C8890505384F4Eb3A281274b1DEdFFf8448147
Treasury0x1bf019A44a708FBEBA7ADc79bdaD3D0769fF3a7b
# 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](/files/-MciOY6wO52INmaszCdU) ![ Source: https://www.defistation.io/](/files/-MciOY6xo_x2Ejv6QbPI) 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/](/files/-MciOY6y0Lv912tmh2vX) ![https://insights.deribit.com/market-research/pancakeswap-the-amm-eating-everyone-elses-breakfast/](/files/-MciOY6zG9isu1NPgou-) 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\big(QUEEN\big) = \frac{ R\_{C} \times P\_{C} \times W\_{QUEEN} }{ WO\_{S} \times NAV\_{QUEEN} \times W\_{QUEEN} } $$ $$ Daily YieldRange=\[BaseDailyYield, BaseDailyYield\times3] $$ $$ UDY\_{QUEEN} =BaseDailyYield \big(QUEEN\big) \times WO\_{Q} / WE\_{Q} $$ ### **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: $$APY\_{BISHOP} = \[(UDY\_{BISHOP} +1) ^{365} -1]+APY\_{InterestRateTop-Up}$$ $$APY\_{InterestRateTop-Up}=(Daily InterestRate +1) ^{365}-1$$ $$ BaseDailyYield\big(BISHOP\big) = \frac{ R\_{C} \times P\_{C} \times W\_{BISHOP} }{ WO\_{S} \times NAV\_{BISHOP} \times W\_{QUEEN} } $$ $$ Daily YieldRange=\[BaseDailyYield, BaseDailyYield\times3] $$ $$ UDY\_{BISHOP} =BaseDailyYield \big(BISHOP\big) \times WO\_{BR} / WE\_{BR} $$ 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\big(ROOK\big) = \frac{ R\_{C} \times P\_{C} \times W\_{ROOK} }{ WO\_{S} \times NAV\_{ROOK} \times W\_{QUEEN} } $$ $$ Daily YieldRange=\[BaseDailyYield, BaseDailyYield\times3] $$ $$ UDY\_{ROOK} =BaseDailyYield \big(ROOK\big) \times WO\_{BR} / WE\_{BR} $$ ## **Tranchess Mechanisms and Protocol** ### **Tranchess Primary Market** The Primary market is where creation/redemption and split/merge transactions happen. ![](/files/-MdzxRpP1bhj_gMXfqYw) #### **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: $$ ConversionRatio\_{T} = \frac{ NOS\_{T-} }{ QBTCB\_{T-} } $$ * **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*](/whitepaper#rebalance)), users can convert QUEEN into BISHOP and ROOK, and vice versa. The specific conversion formula is: $$ NOSQ\_{U,t} = \frac{ NOSB\_{U,t} + NOSR\_{U,t} }{2} $$ * **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. $$QUEEN\_{BTC}$$, $$QUEEN\_{ETH}$$,$$BISHOP\_{BTC}$$, $$BISHOP\_{ETH}$$,$$ROOK\_{BSC}$$, 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: $$NAV\_{Q,e} \times 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:** $$ NAV\_{Q,e} = NAV\_{Q,T-1} \times \frac{ TWAP\_{BTC,e} }{ TWAP\_{BTC,T-1} } \times(1- MR\_{e,T-1} ) $$ Latest NAV, **Tranche BISHOP:** $$ NAV\_{B,e} = NAV\_{B ,T-1} \times max\big{1,( 1-MR\_{e,T-1} ) \times (1+ IR\_{e,T-1} )\big} $$ Latest NAV, **Tranche ROOK:** $$ NAV\_{R,e} =2 \times NAV\_{Q,e} - NAV\_{B,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. $$NAV\_{B,T} = NAV\_{R,T} =1$$ 2. SplitRatio will be re-adjusted. newSplitRatio = oldSplitRatio\* ($$NAVB *{pre-rebalance}$$+$$NAVR*{pre-rebalance}$$)/2 3. The amount of tokens changes to reflect the adjusted value. Rebalance is triggered when $$NAV\_{Rook} / NAV\_{Bishop}$$ is less than 0.5 or is more than 2. Here’s how the amount changes specifically. When $$\frac{ NAV\_{ROOK} }{ NAV\_{BISHOP} } < 0.5$$ For Token ROOK holders, amount of Token ROOK after Rebalance:= $$ NOSR\_{ROOK,T} =max \big{0, NOSR\_{ROOK,T-} \times NAV\_{ROOK,T-} \big} $$ For Token BISHOP holders, amount of Token BISHOP after Rebalance: $$ NOSB\_{BISHOP,T} =max \big{0, NOSB\_{BISHOP,T-} \times NAV\_{ROOK,T-} \big} $$ Token BISHOP holders also receive extra token QUEEN: $$ NOSQ\_{BISHOP,T} = NOSB\_{BISHOP,T-} \times (NAV\_{QUEEN,T-} -max \big{0,NAV\_{ROOK,T-}\big} ) \times 2 $$ For Token QUEEN holders, amount of Token QUEEN after Rebalance: $$ NOSQ\_{QUEEN,T} = NOSQ\_{QUEEN,T-} \times NAV\_{QUEEN,T-} $$ When $$\frac{ NAV\_{ROOK} }{ NAV\_{BISHOP} } > 2$$ For Token ROOK holders, amount of Token ROOK after Rebalance: $$ NOSR\_{ROOK,T} = NOSR\_{ROOK,T-} $$ Token ROOK holders also receive extra Token QUEEN: $$ NOSQ\_{ROOK,T} = NOSR\_{ROOK,T-} \times NAV\_{ROOK,T-} - NOSR\_{ROOK,T} $$ For Token BISHOP holders, amount of Token BISHOP after Rebalance: $$ NOSB\_{BISHOP,T} = NOSB\_{BISHOP,T-} $$ Token BISHOP holders also receive extra token QUEEN: $$ NOSQ\_{BISHOP,T} = NOSB\_{BISHOP,T-} \times NAV\_{BISHOP,T-} - NOSB\_{BISHOP,T} $$ For Token QUEEN holders, amount of Token QUEEN after Rebalance: $$ NOSQ\_{QUEEN,T} = NOSQ\_{QUEEN,T-} \times NAV\_{QUEEN,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. ![](/files/-MciOY70iemOc_NyAL5b) *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: ![](/files/-Mchvtsr9_XK50Zf7LiD) 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: ![](/files/FvepH6QkX3aMNlOB7H1H) 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 WeeksSpecific Percentage
20 (Nov. 4)20 (Nov. 11)1ETH: 5%, BTCB: 95%
21 (Nov. 11)21 (Nov. 18)1ETH: 10%, BTCB: 90%
22 (Nov. 18)22 (Nov. 25)1ETH: 15%, BTCB: 85%
23 (Nov. 25)23 (Dec. 2)1ETH: 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% = ($$TVL\_{ETH}/ TVL\_{TOTAL}$$ + Last Week's ETH% )/2 BTCB% = ($$TVL\_{BTCB}/ TVL\_{TOTAL}$$ + 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. ![](/files/-MeAdwxaJwcj-FVzYMNk) ### **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 = WE\_{S} \* veP$$ $$WE\_{BR} = (NOST\_{BISHOP, k} \*4+NOST\_{ROOK,k}\*2)/3$$ $$WO\_{BR} = MIN(WE\_{BR}+BoostingPower\*2, WE\_{BR}\*3)$$ $$WO\_{Q} = MIN\[NOST\_{QUEEN,k}+clamp(BoostingPower-WE\_{BR},0,BoostingPower/2), NOST\_{QUEEN,k}\*3]$$ $$WO\_{Ba} = WO\_{BR}+WO\_{Q}$$ $$WE\_{Ba} = (NOST\_{QUEEN,k}\*3+NOST\_{BISHOP,k}\*4+NOST\_{ROOK,k}\*2)/3$$ $$WE\_{S} = SUM\[WE\_{Ba}]$$ $$WO\_{S} = SUM\[WO\_{Ba}]$$ *Formulas:* $$ ActualBoostFactor = \frac{WO\_{Ba}/WO\_{S}}{WE\_{Ba}/(WO\_{S}-WO\_{Ba}+WE\_{Ba})} $$ $$ PotentialMaxBoostFactor = \frac{WE\_{Ba}\*3/(WO\_{S}-WO\_{Ba}+WE\_{Ba}\*3)}{WE\_{Ba}/(WO\_{S}-WO\_{Ba}+WE\_{Ba})} $$ ## **Variable Definitions**
VariableDefinition
VariableDefinition
tIntraday trading timestamp. Current timestamp within intraday trading windows
eIntraday epoch timestamp. TWAP calculation timestamp of the current 30 minutes intraday trading window
TPost-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-1Last post-daily settlement timestamp. Timestamp for the previous post-daily settlement timestamp
NOS_{k} Fund number of shares. Net number of shares of main fund issued by Tranchess by timestamp k
QBTCB_{k}Fund quantity of BTCB. Net quantity of BTCB held in main fund by timestamp k
NOSQ_{U,k}Number of main fund shares. Number of shares held by a user or corresponding portion targeted for operation, U, at timestamp k
NOSB_{U,t}Number of Tranche BISHOP fund shares. Number of shares held by a user, or corresponding portion targeted for operation, U, at timestamp k
NOSR_{U,t}Number of Tranche ROOK fund shares. Number of shares held by a user, or corresponding portion targeted for operation, U, at timestamp k
NAV_{Q,k}Net asset value of shares. Net asset value of Main Tranche QUEEN/Tranche BISHOP/Tranche ROOK fund shares at timestamp k
TWAP_{BTC,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
MR_{k,T-1}Unsettled management rate. Management rate arithmetically cumulated since last settlement T-1, to timestamp k
IR_{k,T-1}Unsettled interest rate. Interest rate arithmetically cumulated since last settlement T-1, to timestamp k
P_{C} CHESS price
R_{C} CHESS daily release rate
UDY_{N} User's daily yield on a specific tranche N. N can be QUEEN, BISHOP, or ROOK.
NOST_{N,k} Number of staked token N of a specific account at timestamp k. N can be QUEEN, BISHOP or ROOK.
W_{N} CHESS distribution weight of a certain tranche N. N can be QUEEN, BISHOP or ROOK.
veP The share of the veCHESS pool of an individual account
WE_{S} The sum of all individual accounts' weighted balance
WE_{Ba} WeightedBalance. The weighted Q/B/R balance of a particular account calculated based on Chess distribution weight
WE_{Q} The weighted Q balance of a specific account calculated base on Chess distribution weight
WE_{BR} The weighted A&B balance (combined) of a specific account calculated based on Chess distribution weight
WO_{S} The sum of all individual accounts' working balance
WO_{Ba} WorkingBalance. The total actual boosted balance of Q/B/R of an individual's account
WO_{Q} The actual boosted QUEEN balance of an individual account
WO_{BR} 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.**
# DISCLAIMERS This website is operated by Gooseberry Technology Inc. (the “**Company**”, “**we**“ or “**us**”). This website is for informational purposes only and therefore, the information and descriptions contained in it are not to be construed as an offering memorandum, advertisement or prospectus. Accordingly, this information is not intended to be a complete description of all terms, exclusions and conditions applicable to the services described in this website. This website and any information or materials contained in it do not constitute the distribution, an offer or solicitation of any kind to purchase or sell any product, security or instrument whatsoever nor should they be construed as providing any type of investment or other advice or recommendations by us, any of our affiliates or third parties to any person in any jurisdiction where such distribution, offer, solicitation, purchase or sale would be unlawful under the laws of such jurisdiction. Moreover, the Company does not give investment advice, endorsement, analysis or recommendations with respect to any cryptocurrencies, digital assets, tokens or securities (“**cryptocurrencies**”) or provide any financial, tax, legal advice or consultancy services of any kind. We are not your broker, intermediary, agent, or advisor and has no fiduciary relationship or obligation to you in connection with any trades or other decisions or activities effected by you using this website. This website has not been approved by any regulator. This website is for “professional investors”, “accredited investors” or “sophisticated investors” only and not for retail use. We encourage you to consult your professional advisers in respect of any decisions or activities made on the website. **Disclaimer of Warranties** Information contained in this website is current as at the date of publication, may be superseded by subsequent market events or for other reasons, and is subject to change without any notice. Neither the Company, its affiliates nor any of its or their officers, directors, agents, employees or representatives makes any warranty, express or implied, of any kind whatsoever related to the adequacy, accuracy or completeness of any information on this website or the use of information on this website. We do not make any investment recommendations, and no communication, through this website or in any other medium, is intended as or should be construed as advice or recommendation for any cryptocurrencies offered on or off this website or any other sort of advice. In addition, we do not warrant that this website will meet your needs, or that it will be uninterrupted, timely, secure or error-free, that defects will be corrected, or that this website or the server that makes it available are free of viruses or other harmful components. Accordingly, we and our affiliates expressly disclaim any liability, whether in contract, tort, strict liability of otherwise, for any direct, indirect, consequential, punitive or special damages arising out of, or in any way connected with, any person’s access to or use of this website. This is true even if we or our affiliates have been advised of the possibility of such damages or losses. In addition, we will not be liable to any person for any loss resulting from a cause over which we do not have control. We may terminate your access to our website for any reason, without prior notice. **Risks** Investing in cryptocurrencies is highly risky and may lead to a total loss of investment. You must have sufficient understanding of cryptographic tokens, token storage mechanisms (such as token wallets), and blockchain technology to appreciate the risks involved in investing in cryptocurrencies. You should conduct your own due diligence of any issuer or cryptocurrencies and consult your advisors prior to making any investment decision. You are recommended to exercise prudence and trade and invest responsibly within your own capabilities. You are solely responsible for determining whether any investment, investment strategy or related transaction is appropriate for you according to your personal investment objectives, financial circumstances and risk tolerance, and you shall be solely responsible for any loss or liability therefrom. You should consult legal or tax professionals regarding your specific situation. We do not recommend that any cryptocurrencies should be bought, earned, sold, or held by you and we will not be held responsible for the decisions you make based on the information provided by us on this website. AS WITH ANY ASSET, THE VALUES OF CRYPTOCURRENCES ARE VOLATILE AND MAY FLUCTUATE SIGNIFICANTLY AND THERE IS A SUBSTANTIAL RISK OF ECONOMIC LOSS WHEN PURCHASING, HOLDING OR INVESTING IN CRYPTOCURRENCIES. BY ACCESSING THE WEBSITE AND USING OUR SERVICES, YOU ACKNOWLEDGE AND AGREE THAT: (A) YOU ARE AWARE OF THE RISKS ASSOCIATED WITH TRANSACTIONS OF CRYPTOCURRENCIES THAT ARE BASED ON BLOCKCHAIN AND CRYPTOGRAPHY TECHNOLOGIES AND ARE ISSUED AND MANAGED IN A DECENTRALIZED FORM; (B) YOU SHALL ASSUME ALL RISKS RELATED TO THE USE OF THIS WEBSITE AND TRANSACTIONS OF CRYPTOCURRENCIES; AND (C) THE COMPANY SHALL NOT BE LIABLE FOR ANY LOSS OR ADVERSE OUTCOMES.