What are Token Extensions?
Understanding Token Extensions: Powering the Next Generation of Tokens on Solana
Developments in the Solana Ecosystem have been rapid over the last year and there is a lot of new, exciting tech being released. Solana has been renowned for its ultra-fast processing speeds and lower transaction fees, but even with these impressive offerings there's always room for improvement. Cue Token Extensions, a new token program designed to enhance Solana's current token functionality. Let's explore what the Token Extensions standard has in store for the Solana ecosystem.
The Current Token Program on Solana
All tokens on Solana that are not the native $SOL token are considered spl-tokens. This includes both fungible (tokens such as $BONK) and non-fungible tokens (NFTs). The token program is a program that defines common functions for creating and working with both Fungible and Non Fungible tokens. The token program offers a few features that developers and end-users have grown used to. These operations include minting, transferring, and the burning of tokens. Additionally, it offers functionalities like updating the token and freezing the token, which provides the ability to freeze a token account, preventing any changes to the account state until it's unfrozen.
What are Token Extensions and Why is it Needed?
You can think of Token Extensions as a new and improved version of the token program on Solana. It can handle both fungible and non-fungible tokens. This new program still has all the features of the old Token program but it now comes with a set of useful new features designed to improve token functionality on Solana. These new features which are the real magic of Token2022 come in the form of extensions.
But why are Token Extensions needed? As Solana advances, the demand for more intricate and adaptable token functionalities grows. While the current Token Program on Solana has served the basic needs of fungible and non-fungible tokens via a simple set of features, its simplicity creates limitations that can hinder innovation. Developers, armed with fresh ideas, have often needed to fork the Token Program to add required functionality, which presents challenges for achieving widespread adoption. The programming model of Solana requires the inclusion of both programs and accounts in transactions, this complicates the creation of transactions that involve multiple token programs. Additionally, wallets and on-chain programs must trust any token program they choose to support, this can be risky. In response to this evolving scenario, Solana presents Token2022—a suite of additional features and enhancements designed to broaden the capabilities of tokens within the ecosystem.
Introducing Extensions: An Evolutionary Step
The game changing abilities of this new standard lie in the available extensions, a suite of new fields introduced to meet various needs. In simple terms, an extension in the context of Token Extensions is an extra feature or functionality that can be added to a token to enhance its capabilities and usefulness. Extensions allow token creators to customize the behaviour and characteristics of their tokens to suit specific needs or goals. When creating a token one can choose to make use of any number of these extensions. Let's unpack some of the key extensions and their potential impact on the Solana ecosystem. It is important to note that not all of these extensions are currently live.
1. Transfer Fees
While the existing Token program doesn't allow for fees on transfers, the Token Extensions standard changes this by allowing the configuration of a transfer fee at the protocol level. This mechanism introduces a new level of financial control over transactions.
2. Transfer Hooks
The Transfer Hook extension empowers token creators with an additional layer of control over their token’s transfers. This is particularly crucial for managing challenges linked to NFT royalties. The Transfer Hook extension works by enabling token creators to create custom programs that tokens will use whenever they are transferred . Whenever a token transfer is initiated, the token will communicate with this custom program which will allow for any subsequent actions to take place.
3. Closing Mint
Token Extensions addresses a significant gap in the Token program by enabling the closure of mint accounts by an address of ones choosing, which was previously impossible. It's accomplished by initializing the MintCloseAuthority extension before initializing the mint. This allows someone other than the authority wallet to close a token’s mint.
4. Interest-Bearing Tokens
Token Extensions introduce an InterestBearingMint extension, which allows the representation of the UI amount of tokens differently, incorporating the interest they have accumulated. This feature essentially allows tokens to 'earn interest,' making them more valuable the longer you hold them.
5. Non-Transferable Tokens (Soulbound tokens)
The NonTransferable mint extension enables the creation of "soul-bound" tokens that cannot be moved from a wallet. This is perfect for unique achievements or rewards, these tokens can also be great for event ticketing as you would not be able to send that ticket to anyone else.
6. Confidential Transfers
Token Extensions introduce a new Confidential Token Extension, known as Confidential Transfers - a privacy-enabling feature that utilizes zero-knowledge proofs to encrypt token balances and transfer amounts for SPL tokens.
The overall aim of this extension is to improve user privacy by focusing on confidentiality, rather than anonymity.Because balances can be added to or subtracted from, The Token Extensions standard requires an encryption scheme that allows for these hidden mathematical operations; the encryption must be homomorphic. Homomorphic encryption is a special class of encryption scheme that allows specific types of computations to be performed on encrypted data without actually having to decrypt the data. Thus, these hidden computations would yield an encrypted result that, when decrypted, is equivalent to the result of applying the same mathematical operations in plaintext. Confidential transfers use “Twisted ElGamal Encryption” to enable the performance of hidden mathematical operations on ciphertext.
As an aside for those more interested, Twisted ElGamal Encryption is a simple variant of the standard ElGamal encryption scheme where a ciphertext is divided into a Pedersen commitment of the encrypted message and a decryption handle to enable the performance of hidden mathematical operations on ciphertext.
Confidential Transfers are validated using Sigma Protocols, a specific class of zero-knowledge proofs where one party (the prover) can prove to another party (the verifier) that they know a secret, without revealing the secret itself. These Sigma Protocols are required for a number of instructions provided with the extension. Let’s break down each proof:
(Public-key) Validity Proof
- Verifies that a Twisted ElGamal publickey is correctly formatted
- Think of it as validating another person’s “digital identity card” before you start a secure chat
- This is required for the ConfigureAccount instruction
(Ciphertext) Validity Proof
- Ensures the encrypted message is well-formed
- Think of it as receiving a sealed box - you know the box hasn’t been tampered with because it is still sealed
- This is required for the Withdraw, Transfer, and TransferWithFee instructions
- Proves the Twisted ElGamal ciphertext encrypts the number zero
- Think of it as a way to check that your bank account balance is zero without opening up your bank app and checking
- This is required for the EmptyAccount instruction
- Confirms two types of equality - between two ElGamal ciphertexts or an ElGamal ciphertext and a Pedersen commitment
- Think of it as having two locked sheds full of tools and proving that both sheds have all the same tools without actually opening the sheds
- This is required for the Transfer, TransferWithFee, WithdrawWithheldTokensFromMint, and WithdrawWithheldTokensFromAccounts instructions
Fee Sigma Proof
- Proves a committed transfer fee is correct
- Think of it as confirming to FedEx that you’ve paid duty fees on your package without showing them the exact amount you’ve paid in fees
- This is required for the TransferWithFee instruction
- Confirms an encrypted number is within a certain range
- Think of it as guessing the height of a person and proving your guess falls within a certain, correct range without revealing the person’s actual height
- Solana uses Bulletproofs for these proofs, which can be you can learn more about from this academic paper and their dalek implementation
TLDR; these zero-knowledge proofs are used to validate that one party knows a secret that another party can verify without saying it aloud. These different types of proofs help with ensuring token balances and transfers work as intended mathematically, in a way that is completely private via encryption.
Only the account holder, who has the decryption key, can view their balance in this confidential system. There may be cases however where an external third-party needs to review the balances, whether it be for auditing or compliance purposes. The Confidential Token Extension allows for this with their Global Auditor system. In this system each account can have a separate decryption key so a holder can selectively provide read access to specific accounts. The mint, or the entity that is issuing the assets, has a special data structure that can optionally include a global “auditor encryption key”. The code is as follows:
The amount_auditor parameter is the transfer amount that is encrypted using the public encryption key of the auditor. Anyone with the auditor’s secret key can decrypt amount_auditor thereby being able to audit the transaction amounts for a particular mint.
If you’re a security enthusiast, you may have noticed a potential flaw in this design. Suppose Alice generates a proof with respect to her encrypted balance. But, at the same time, Bob sends tokens to Alice and his transaction is processed first. Then, Alice’s transaction is rejected because the proof generated will not reflect the newly updated account state. This sort of attack, known as front-running, could render Alice’s account unusable if Bob continuously flooded the network with a transfer to Alice’s account. The encrypted balance of an account is divided into its pending balance and its available balance to prevent this type of attack:
Any outgoing funds are subtracted from its available balance whereas any incoming funds are added to its pending balance.
Confidential Transfers are not live yet and the Solana documentation for the Introduction and Quick Start Guide subheadings are still under development. You can, however, track the remaining tasks for the Confidential Transfers with this GitHub issue on the solana-program-library repository. The documentation does have a Protocol Deep Dive, but it is vital to note that an understanding of what is discussed in the deep dive is not required to use the extension. The layman’s summary of Confidential Transfers presented in the paragraphs above should be more than enough to get you started with Confidential Transfers once everything is live.
1. Memo Required on Incoming Transfers
Token Extensions includes a feature for enforcing memos with all incoming transfers. Memos are basically a short on-chain message. This feature acts a bit like getting a note with a gift, so you know who it's from and why they gave it to you.
2. Immutable Ownership
The ImmutableOwner extension adds a layer of security by making it impossible to reassign ownership of an account. This provision enhances the safety of token transactions. To better understand this we need to look at how tokens in the standard token program are stored. Usually when one looks to send a token to a wallet the first step is to create a token account to hold that token inside the recipients wallet, this account is made from a combination of the token mint address and the recipients wallet address. This is all fine and well expect for the fact that once this account is made its ownership can be transfered to someone else. With the Immutable Owner extension in Token2022 this will no longer be possible.
3. Default Account State
The DefaultAccountState extension enables mint creators to restrict token use by setting all new token accounts to be frozen by default. It provides an additional layer of control over token distribution and usage. This would mean that you would be able to receive a token but would not be able to do anything with it until the token creators allow it.
4. Permanent Delegate
With Token Extensions, it's possible to specify a permanent account delegate for a token. This basically allows you to appoint someone (a delegate) who will always have the authority to manage tokens from a mint. They can do things like transferring or burning tokens. If this extension is used the authority will have unlimited delegate privileges over any account for that mint, this can be very dangerous as that delegate/person would be able to transfer or burn tokens in anyones wallet.
Token Extensions vs Ethereum and Binance Smart Chain (BSC)
Ethereum and Binance Smart Chain (BSC) have already made significant strides in the DeFi space and we have seen some of the Token Extensions features on tokens on those chains.
One example is SafeMoon on BSC that introduced a 10% fee on each transaction, 5% of this is redistributed to other SafeMoon holders. This encourages holders to HODL. The concept of confidential transfers using zero-knowledge proofs also isn't new. On Ethereum, projects like Aztec Protocol explored private transactions.
Even with Solana's being slightly slower to provide these features its superior speed and lower transaction costs provide a conducive environment for Token Extensions to flourish, thus providing a competitive edge over Ethereum and BSC.
Early adopters of Token Extensions
Developers, dApps, and wallets need to adapt to these new functionalities to make the most of what Token Extensions have to offer. Here are a few early adoptions of the new program:
$BERN / BonkEarn
$BERN, created by the $BONK community, is one of the first tokens that was built on top of the Token Extensions program. Currently $BERN is using the Transfer Fee extension to take a 6.9% fee on all transfers. The $BERN team is using this fee to reward both holders of $BERN and holders of $BONK.
- 5% to the “Bernzy Bonus Fee”, to be used to reward holders of $BERN
- 1% to be used to buy and burn $BONK
- 0.5% to burn $BERN
- 0.3% to go to the developer fund for paying more fees and adding to the tokens liquidity pool.
- 0.1% to go to the $BONK DAO
FluxBeam is a DEX on Solana that currently supports tokens made with the Token Extensions program.
Tools for mining your own token with the Token Extensions program are now live on FluxBeam.
RugCheck a tool for looking into Solana token markets and different tokens have been set up already allows for the checking of tokens built with Token 2022.
Embracing the Future / Conclusion
The introduction of Token Extensions are a huge leap forward in Solana's web3 journey. It brings an array of novel functionalities while boosting the capabilities of existing features. Its groundbreaking extensions not only empower token creators with more control and flexibility, but also carve out new possibilities in the DeFi space. Despite other blockchains already offering similar features, Solana's edge in speed and affordability coupled with the functionalities of Token2022 presents a formidable competitor in the crypto world. As the support from initial users and the extensive community continues to expand, Token2022 stands ready to enhance and elevate the Solana ecosystem.