The Basket token (BSK) by Vingt.io is a digital asset in the form of an index with a DAO(Decentralized Autonomous Organization) like structure, designed to track the performance of some of the main assets in the cryptocurrency space. BSK falls within the “Indexed Products” workstream and involves the creation of a tokenized basket of twenty cryptocurrencies. This would allow investors to have macro exposure to the crypto space while limiting idiosyncratic risks around holding a single underlying asset. The BSK token is fully collateralized by its constituent crypto assets. BSK is a dynamic pool based on selection driven by periodic reviews. VGT itself will be a constituent of BSK as a permanent member and used as governance token to administer BSK’s executive functioning.

Token Selection Criteria

As part of the token inclusion assessment, Vingt.io would be considering a wide range of characteristics of different projects to be added to BSK. VGT holders would then decide what tokens would eventually be added to BSK.

  • Every token must be available on BNB Chain and preferably listed on Binance Exchange (Except VGT)
  • The token must not be considered a security by the corresponding authorities across different jurisdictions.
  • There should be sufficient liquidity for each token to carry out large transactions.
  • None of the following categories of token would be included in BSK. Including but not limited to,
  1. Meme Coins with no potential utility
  2. Abandoned Projects
  3. Protocol/Project that have become insolvent
  4. Projects with unknown developers and low circulating market cap
  5. Projects having structural problems as seen in the case of LUNA/UST
  6. Wrapped Tokens (Excluding Binance Pegged Tokens)
  7. Other Tokenized derivatives
  8. Tokens having inconsistencies in roadmap
  9. Tokens having less than 15% of their total supply in market circulation
  • The tokenomics must not have locking, minting or other characteristics that would put passive holders at a disadvantage.
  • The project must be widely considered to be building a useful protocol or product.Projects focused on competitive trading/holding, having Ponzi characteristics, or projects that exist primarily for entertainment, will not be included.
  • Any other criteria deemed fit by Vingt.io core team can be added at a later stage along with amendments made to the ones listed above.
  • The protocol or product must have been launched at least 180 days before being able to qualify to be included in the index.

Index Maintenance

The index is maintained in two phases:

Determination Phase

It is the phase when the changes needed for the next reconstitution are determined.

Reconstitution Phase

The index components are adjusted, added and deleted.

Smart Contracts

These are the open-source smart contracts used for Decentralised Basket Token (BSK) via Set Protocol. BSK token is the first DeFi index being built on BNB Chain.

This public-facing smart contract contains all the business logic and external functions associated with creating, issuing, and redeeming Sets. Core serves as a kernel that orchestrates interactions between the various other smart contracts. In addition, Core exposes privileged functions that are available to Modules (defined below), which allow the extension of the System’s functionality.

his smart contract facilitates the transfer of BEP20 tokens for all transactions.Users who wish to utilize their tokens must authorize the TransferProxy contract to move their tokens by calling the BEP20-compliant token’s approve function. The design of a centralized TransferProxy contract is intended to minimize the overall number of BEP20 approve transactions required in the system.

This smart contract stores all the Set’s component and contains mappings to track ownership of assets. Vault’s accounting interfaces are only available to Core and indirectly to Modules through Core.

This smart contract contains the template for a specific type of Set and facilitates the creation of all Set token contracts. Creators can create a new Set token by calling Core’s createSet function and supplying the Factory address and the required parameters. For a Factory to be valid, it needs to be registered with Core. Initially, there will be a SetTokenFactory (creating standard Sets) and RebalancingSetTokenFactory (a factory for creating Rebalancing Set tokens).

Rebalancing Set Token(s):
In addition to sharing the interface and functionality of a Set Token, this smart contract stores rebalancing functionality-related state and contains all the business logic related to how the Rebalancing Set is rebalanced.

Set Token(s):
This BEP20 compliant smart contract represents a unique Set with specified BEP20 components and units and tracks balances of the Set tokens. Each Set token smart contract is created by a Factory and is tracked by Core. Each smart contract exposes mint and burn functions that only Core could call during issuance and redemption..

Rebalancing Set Token(s):
In addition to sharing the interface and functionality of a Set Token, this smart contract stores rebalancing functionality-related state and contains all the business logic related to how the Rebalancing Set is rebalanced.

This smart contract serves to extend the functionality of Core without requiring a complete redeployment or upgrade of Core. Modules are tracked contracts that have access to Core’s exposed module functions (e.g. batchDepositModule, redeemModule). Some modules appended to the system include: ExchangeIssueModule, RebalanceAuctionModule, and RebalancingSetExchangeIssuanceModule.

This smart contract serves as a conduit between decentralized exchanges and Core to facilitate component-acquisition during issuances that require usage of outside liquidity. Each exchange wrapper contract exposes a common exchange function that accepts exchange metadata and a bytes string that encodes exchange messages. The ExchangeWrapper is responsible for parsing call data conforming to an exchange’s interface (“exchange messages”) and executing each order as the taker of each transaction. Initially, we will be supporting tokens from pancake swap.

This smart contract contains a list of components deemed suitable for inclusion as a base Set component in rebalancing Sets. This contract is used during the proposal phase of Rebalancing to ensure only vetted components are rebalanced into.


There are several participants in the network: Creators, Users, and Traders:

  • Creators (such as Vingt.io) utilize their domain knowledge, creativity, and intuition to design, create, and deploy static and rebalancing Sets (such as BSK) that have market appeal.
  • Users can gather components from various centralized and decentralized liquidity sources to issue Sets for trading, holding, and usage. They can also redeem their Sets for the components.
  • Traders are economically-driven participants who compete to profit by bidding during rebalance auctions as well as facilitating price discovery by issuing and redeeming undervalued / overvalued Sets in the market


Core is the smart contract that contains the business logic for everything in BSK token’s lifecycle including creating, issuing, and redeeming. Initially, BSK is designed and created through the Core contract and its specified Factory. BSK tokens are then funded or issued through the standard Issuance Flow (if the user has all the underlying components). Users who wish to have their Basket updated can choose to do so by issuing a Rebalancing Set Token. Finally, BSK can be redeemed by burning the owner’s Set token and retrieving the components. Issuance and Redemption of BSK tokens is explained below.

Issuance of BSK

Issuance is the process of minting new tokens for BSK, increasing BSK supply. With a valid deployed Set such as BSK, anybody can call the Core’s issue function to convert a specified mix of BEP20 tokens into a BSK token. For a standard issuance, users need to contain all components of BSK in a single public address and/or the Vault.

Issuance is a two-step process of depositing funds into the Vault and then issuing (attributing components to BSK and minting a BSK token to the user). Ahead of any deposits, users need to approve their tokens to the TransferProxy. Users can incrementally deposit tokens into their vault before issuing, as issuance uses a combination of the user’s tokens in their wallet as well as their tokens in the Vault.

The issuance flow is formalized as follows:

  1. User approves components for transfer to the TransferProxy.

  2. User calls the issue function on Core, targeting Set A and specifying an issue quantity.Core validates that the Set A is a known/tracked Set. The issue amount must be a multiple of the Set’s natural unit.

  3. Core reads the targeted Set’s components, units, and naturalUnit.

  4. For each component, Core calls the TransferProxy contract’s transfer function and moves the funds from the user into the Vault.

  5. The Core then increments the balance in the Vault for each of the transferred components to the Set.

  6. When all the transfers are complete, Core calls Set A’s mint function (callable only by the Core), which mints the corresponding number of BSK token the user has issued.

Redemption of BSK

Redemption is the process of converting a Set into its underlying component tokens. Redeeming tokens reduces the token supply of Set tokens in the contract. It involves burning a Set token and attributing the components to the end user. Users who wish to redeem a token can call Core’s redeem or redeemAndWithdraw function, specifying the Set address and the quantity to redeem

The redemption flow is formalized as follows:

  1. User calls the redeem function on Core, targeting Set A and specifying a redemption quantity. Core validates that the Set A is a known/approved Set.

  2. Core queries Set A for the user’s balance and checks the user has sufficient Set A tokens to redeem. If the user has sufficient balance, it queries the Set for its components, units,and naturalUnits. To prevent re-entrancy attacks, Core call Set A’s burn function, decrementing the user’s balance.

  3. For each component, Core calls Vault to decrements the specified units attributed to the Set A. In each decrement, the Vault decrements the corresponding Set A’s ownership of a token and increments the User’s.

  4. The user can subsequently call Core’s withdraw function to retrieve the tokens from the Vault.


Modules are smart contracts that augment the Core’s capabilities of creating, issuing, and redeeming Sets. To allow efficient facilitation of components and minimize state modifications, Modules are granted privileged capabilities such as transferring tokens using the Transfer Proxy and incrementing/decrementing tokens from the Vault. Modules can be appended and removed through protocol governance. Some of the modules are explained below

  1. ExchangeIssuanceModule: This module helps facilitate the issuance and redemption of Sets using liquidity from decentralized exchanges in a single transaction.

  2. RebalancingSetIssuanceModule: This module is a smart contract that simplifies the process of issuing and redeeming Rebalancing Sets. It allows a user to acquire or dispose of a Rebalancing Set directly to and from ether in a single transaction utilizing liquidity from decentralized exchanges.

Exchange Redeem

Exchange Redeem is the process of breaking up a Set like BSK, into its components and using liquidity from decentralized exchanges to consolidate the value into a single or multiple BEP20 tokens in a single atomic transaction. Mechanically, it is the inverse of Exchange Issue and utilizes the same ExchangeIssuanceParams data structure and exchange wrappers. The ExchangeIssuanceParam inputs differ in that the send tokens must be the Set’s components and the receive tokens the token to consolidate into.

The exchange redeem flow is formalized as follows:

  1. User desires to redeem a Set (A,B) composed of 1x A, 1x B into receive token (R). User specifies the address of A,B, quantity to redeem, send tokens, send quantities, receive token address, and receive token quantities.

  2. User then looks at a separate decentralized exchange for exchange orders that dispose of 1x A and 1x B for the receive token. User is incentivized to finds orders that maximize the total receive token quantity. The User then submits the orders along with the ExchangeIssuanceParams to the Exchange Issuance module.

  3. The Exchange Issuance module redeems the user’s Set Token for components A and B into the vault.

  4. The Components / Send Tokens are then transferred from the vault to the appropriate Exchange Wrappers.

  5. For each exchange order, the Exchange Issuance Module sends the order data to ExchangeWrapper.

  6. The order gets parsed by the ExchangeWrapper and gets executed on the decentralized exchange with the ExchangeWrapper as the taker of the order.

  7. Each of the acquired receive tokens then gets transferred to the Vault and attributed to the User. Any unattributed tokens are returned to the User in the Vault.

  8. Finally, the receive tokens are then withdrawn from the Vault to User A.


Rebalancing is the process of realigning the weights of a portfolio, which involves periodically purchasing and selling components to maintain a certain allocation. Typically, users rebalance their portfolios actively by reviewing their portfolio, calculating the optimal allocation, and then trading their excess tokens for the missing tokens needed to create the new portfolio. In the traditional finance world where users purchase Index Funds, fund managers (the counterparty) would perform the portfolio composition selection and rebalancing execution on behalf of users.

We introduce Rebalancing Set Tokens (“Rebalancing Set(s)”), a Set Token composed of another Set Token (“current Set” or “Base Set”). Using logic added to Rebalancing Sets, the current Set such as BSK can be transitioned to a new Set Token utilizing the guidance of a manager entity.Rebalancing Sets take a novel approach to rebalancing execution which completely removes counterparty risk. Rebalancing Sets can be configured to retrieve inputs regarding the most up to date Set Token through trusted or trustless sources.

Rebalancing Sets have many use cases, out of which Vingt.io would be using the following two:

  • Tracking the Market Index: Users who own Rebalancing Sets can passively track the market index by owning a single BEP20 token. Once users have acquired a Rebalancing Set, future rebalances execute behind the scenes, and the users do not need to perform any additional transactions, mimicking the user experience of traditional Index Funds.
  • Automating Trading Strategies: Using a smart contract, trading strategies can be mechanized and automatically executed by holding a Rebalancing Set token.

In a Rebalancing Set system, the participants include:

  • User: Rebalancing Sets enables users to get exposure to an automatically balanced crypto portfolio by simply acquiring a BEP20 token on an exchange or by minting a Rebalancing Set themselves. Only if the user decides to opt out of a rebalance proposal, does he or she need to get involved.
  • Manager: Each Rebalancing Set has a manager that creates proposals which dictate how a Set is rebalanced. The manager entity could be a person or a smart contract that has rebalance rules programmed in.

Please note that Vingt.io would not be using the auction mechanism of set protocol at the rebalancing phases for BSK – Basket Token.