Network
Token
The project's token is on the Solana network. This page describes what a token of this kind is technically, what is decided, and what must be disclosed before launch.
Status. Supply and launch details are not final. Nothing on this page is an offer or a recommendation to buy anything.
What is decided
| Item | State |
|---|---|
| Network | Solana |
| Number of tokens | One |
| Supply | Not final |
| Launch | Not final |
| Function | To be specified in public before launch |
How a token on Solana works
A fungible token on Solana does not need a custom program. It is a mint account managed by one of two standard programs, with balances held in token accounts.
| Program | Notes |
|---|---|
| SPL Token | The original program. Simple and widely supported. |
| Token-2022 | Adds optional extensions. Most must be chosen when the mint is created and cannot be added later. |
Extensions change what holders can expect, so each one has to be disclosed.
| Extension | Effect on holders |
|---|---|
| Transfer fee | A fee is taken on every transfer |
| Transfer hook | A custom program runs on every transfer |
| Permanent delegate | A designated account can move or burn any holder's tokens |
| Pausable | Transfers can be halted |
| Default account state | New accounts can start frozen |
| Non-transferable | Tokens cannot be moved |
Authorities
Three powers matter more than anything else about a token.
| Authority | Power | Usual safeguard |
|---|---|---|
| Mint | Create new tokens | Revoke, or hold in a multisig |
| Freeze | Freeze a holder's account | Revoke, or hold in a multisig |
| Upgrade | Change a custom program's code | Multisig or governance, with a time delay |
A multisig requires several named signers to approve an action. Squads is the common implementation on Solana.
Governance
Member votes on Solana are commonly run through Realms, built on the SPL Governance program. A proposal is created, voted on and, if it passes, executed on-chain after a set delay.
Known difficulties are low voter turnout and the risk of lost or stolen keys.
Proposed disclosure before launch
The proposal is to publish the following before any launch.
- The mint address and the program used.
- Every enabled extension, and the reason for it.
- The current holder of each authority, and the multisig threshold and signers.
- The total supply and how it is allocated.
- The governance rules: thresholds, quorum and delays.
- Independent audit reports for any custom program, with builds that can be verified against the published source.
Recommended practice
- Revoke mint and freeze authority if they are not needed.
- Avoid extensions that give one party power over holders' balances, or justify them in public.
- Place any upgrade authority behind a multisig and a time delay.
- Publish audits in full.