Token C Programming

[Gaetan Horton]

Ifyou combine these two, you will land somewhere near what is commonly meant when talking about tokens in programming; a symbol representing something. Pretty vague, yes, but then it's used in many different contexts.

One example: you have an authentication system where a user logs on. When the system has authenticated the user, instead of repeating this process for every request, a token is created that represents the fact that the user is authenticated. This token is then used in subsequent requests. In this case the something is the fact the the user is authenticated, and the token represents this fact.

In the compilerLexical analyzer (or scanner ) : Reads theinput stream and fuses characters of thesource text into tokens of the language.Token : sequence of characters having acollective meaning.The character sequence forming a token iscalled the Lexeme.

Token can be seen as a seal, as when in the middle age a courrier representig a king or a duke or a bishop or a pope or a anything went riding from realm to realm, and needed to be authenticated as the true representative of what he claim to be from when passing the gates of each kingdom.

When you want to wrap SOL, you can send SOL to an associated token accounton the native mint and call syncNative. syncNative updates the amountfield on the token account to match the amount of wrapped SOL available.That SOL is only retrievable by closing the token account and choosingthe desired address to send the token account's lamports.

First the receiver uses spl-token create-account to create their associatedtoken account for the Token type. Then the receiver obtains their walletaddress by running solana address and provides it to the sender.

The main difference in spl-token command line usage when referencing multisigaccounts is in specifying the --owner argument. Typically the signer specifiedby this argument directly provides a signature granting its authority, but inthe multisig case it just points to the address of the multisig account.Signatures are then provided by the multisig signer-set members specified by the--multisig-signer argument.

The main difference in using multisign is specifying the owner as the multisig key,and giving the list of signers when constructing a transaction. Normally you wouldprovide the signer that has authority to run the transaction as the owner, but inthe multisig case the owner would be the multisig key.

First create keypairs to act as the multisig signer-set. In reality, these canbe any supported signer, like: a Ledger hardware wallet, a keypair file, ora paper wallet. For convenience, generated keypairs will be used in this example.

Now the multisig account can be created with the spl-token create-multisigsubcommand. Its first positional argument is the minimum number of signers (M)that must sign a transaction affecting a token/mint account that is controlledby this multisig account. The remaining positional arguments are the public keysof all keypairs allowed (N) to sign for the multisig account. This examplewill use a "2 of 3" multisig account. That is, two of the three allowed keypairsmust sign all transactions.

Sometimes online signing is not possible or desirable. Such is the case for example when signers are not in the same geographic locationor when they use air-gapped devices not connected to the network. In this case, we use offline signing which combines theprevious examples of multisig with offline signingand a nonce account.

First a template command is built by specifying all signers by their publickey. Upon running this command, all signers will be listed as "Absent Signers"in the output. This command will be run by each offline signer to generate thecorresponding signature.

Finally, the offline signers communicate the Pubkey=Signature pair from theoutput of their command to the party who will broadcast the transaction to thecluster. The broadcasting party then runs the template command after modifyingit as follows:

First a raw transaction is built using the nonceAccountInformation and tokenAccount key.All signers of the transaction are noted as part of the raw transaction. This transactionwill be handed to the signers later for signing.

A new token type can be created by initializing a new Mint with theInitializeMint instruction. The Mint is used to create or "mint" new tokens,and these tokens are stored in Accounts. A Mint is associated with eachAccount, which means that the total supply of a particular token type is equalto the balances of all the associated Accounts.

It's important to note that the InitializeMint instruction does not requirethe Solana account being initialized also be a signer. The InitializeMintinstruction should be atomically processed with the system instruction thatcreates the Solana account by including both instructions in the sametransaction.

Once a Mint is initialized, the mint_authority can create new tokens using theMintTo instruction. As long as a Mint contains a valid mint_authority, theMint is considered to have a non-fixed supply, and the mint_authority cancreate new tokens with the MintTo instruction at any time. The SetAuthorityinstruction can be used to irreversibly set the Mint's authority to None,rendering the Mint's supply fixed. No further tokens can ever be Minted.

It's important to note that the InitializeAccount instruction does not requirethe Solana account being initialized also be a signer. The InitializeAccountinstruction should be atomically processed with the system instruction thatcreates the Solana account by including both instructions in the sametransaction.

Balances can be transferred between Accounts using the Transfer instruction.The owner of the source Account must be present as a signer in the Transferinstruction when the source and destination accounts are different.

It's important to note that when the source and destination of a Transfer arethe same, the Transfer will always succeed. Therefore, a successful Transferdoes not necessarily imply that the involved Accounts were valid SPL Tokenaccounts, that any tokens were moved, or that the source Account was present asa signer. We strongly recommend that developers are careful about checking thatthe source and destination are different before invoking a Transferinstruction from within their program.

There is no other way to reduce supply on chain. This is similar to transferringto an account with unknown private key or destroying a private key. But the actof burning by using Burn instructions is more explicit and can be confirmed onchain by any parties.

Account owners may delegate authority over some or all of their token balanceusing the Approve instruction. Delegated authorities may transfer or burn upto the amount they've been delegated. Authority delegation may be revoked by theAccount's owner via the Revoke instruction.

M of N multisignatures are supported and can be used in place of Mintauthorities or Account owners or delegates. Multisignature authorities must beinitialized with the InitializeMultisig instruction. Initialization specifiesthe set of N public keys that are valid and the number M of those N that must bepresent as instruction signers for the authority to be legitimate.

It's important to note that the InitializeMultisig instruction does notrequire the Solana account being initialized also be a signer. TheInitializeMultisig instruction should be atomically processed with the systeminstruction that creates the Solana account by including both instructions inthe same transaction.

The Mint may also contain a freeze_authority which can be used to issueFreezeAccount instructions that will render an Account unusable. Tokeninstructions that include a frozen account will fail until the Account is thawedusing the ThawAccount instruction. The SetAuthority instruction can be usedto change a Mint's freeze_authority. If a Mint's freeze_authority is set toNone then account freezing and thawing is permanently disabled and allcurrently frozen accounts will also stay frozen permanently.

The Token Program can be used to wrap native SOL. Doing so allows native SOL tobe treated like any other Token program token type and can be useful when beingcalled from other programs that interact with the Token Program's interface.

To ensure a reliable calculation of supply, a consistency valid Mint, andconsistently valid Multisig accounts all Solana accounts holding an Account,Mint, or Multisig must contain enough SOL to be considered rentexempt

An account may be closed using the CloseAccount instruction. When closing anAccount, all remaining SOL will be transferred to another Solana account(doesn't have to be associated with the Token Program). Non-native Accounts musthave a balance of zero to be closed.

This section describes how to integrate SPL Token support into an existingwallet supporting native SOL. It assumes a model whereby the user has a singlesystem account as their main wallet address that they send and receive SOLfrom.

It's highly recommended that the wallet create the associated token account fora given SPL Token itself before indicating to the user that they are able toreceive that SPL Tokens type (typically done by showing the user their receivingaddress). A wallet that chooses to not perform this step may limit its user's abilityto receive SPL Tokens from other wallets.

At any time ownership of an existing SPL Token account may be assigned to theuser. One way to accomplish this is with thespl-token authorize owner command. Walletsshould be prepared to gracefully manage token accounts that they themselves didnot create for the user.

One natural time to garbage collect ancillary token accounts is when the usernext sends tokens. The additional instructions to do so can be added to theexisting transaction, and will not require an additional fee.

If adding one or more of clean up instructions cause the transaction to exceedthe maximum allowed transaction size, remove those extra clean up instructions.They can be cleaned up during the next send operation.

3a8082e126