This post is a part of a series of posts documenting my experience as a fellow in the Solana India Fellowship. You can find other posts in this series here.

Week[5]

This week’s talk was on the mechanics and economics of DAO’s by Shreyas, the founder of Llama. He discussed proposals, voting, delegates and other governance concepts.

Any successful crypto project with a governance token or a DAO will eventually need to think about how to sustainably scale to govern its funds and users. I enjoyed reading his blog and the Llama newsletter to understand how this is done in practice.

The Solana token experience

This weeks exercise was focused on creating custom tokens and staking programs on-chain.

ERC 20

On Ethereum, if you want to create a new (ERC20) token, you deploy a new contract implementing the ERC-20 specification (most of which you can simply copy from the OpenZeppelin implementation).

contract ERC20Interface {
    function totalSupply() public constant returns (uint);
    function balanceOf(address tokenOwner) public constant returns (uint balance);
    function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
    function transfer(address to, uint tokens) public returns (bool success);
    function approve(address spender, uint tokens) public returns (bool success);
    function transferFrom(address from, address to, uint tokens) public returns (bool success);

    event Transfer(address indexed from, address indexed to, uint tokens);
    event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
}

Thus, the workflow for implementing a new token on Ethereum looks something like this:

1. Fork the 0penZepellin ERC20 contract.
2. Change the function implementations as needed.
3. Deploy. The client does not have to do anything at all, you can simply mint tokens to his publicKey.

Solana Token program

The analog on Solana is the Token program implemented in the Solana Program Library. Since Solana contracts are stateless, the token program first needs to create a new Mint account defining which Publickey is allowed to control the supply of your token.

For every user or program who wants to use your token, you then have to create a new TokenAccount which holds the state of the token for that user/program.

// spl_token::state::Mint
#[repr(C)]
pub struct Mint {
   pub mint_authority: COption<Pubkey>,
   pub supply: u64,
   pub decimals: u8,
   pub is_initialized: bool,
   pub freeze_authority: COption<Pubkey>,
}
// spl_token::state::Account
#[repr(C)]
pub struct Account {
   pub mint: Pubkey,
   pub owner: Pubkey,
   pub amount: u64,
   pub delegate: COption<Pubkey>,
   pub state: AccountState,
   pub is_native: COption<u64>,
   pub delegated_amount: u64,
   pub close_authority: COption<Pubkey>,
}

This leads to a lot more steps needed for the same functionality on Solana:

1. Generate PDA’s in your program for the MintAuthority as well as TokenAccount owned by the program.
2. Initialize a mint account for the token using CPI.
3. Create a token account for the program using CPI.
4. For every client who wants to use your token:
   • Scan the blockchain to find his token account publickey for this token.
   • If he does not have one, call the Associated Token Account Program, to generate a PDA which will be owned by the user and create it on his behalf.
5. Mint tokens to this token account.

This all made sense once I played around with it a few times, however it was really confusing at first. I guess this is the price you have to pay as a developer to get Token transfers at ~$0.0005 per transaction.