DEV Community: Shivam Soni

FluxRPC Quickstart: Query Solana in 5 Minutes

Shivam Soni — Sun, 01 Feb 2026 09:57:11 +0000

You want to read data from Solana. This guide gets you there in 5 minutes.

What you'll build: A script that queries a wallet balance from Solana mainnet using FluxRPC.

TL;DR

TypeScript:

import { Connection, PublicKey, LAMPORTS_PER_SOL } from '@solana/web3.js';

const connection = new Connection('https://eu.fluxrpc.com?key=YOUR_API_KEY', 'confirmed');
const balance = await connection.getBalance(new PublicKey('YOUR_WALLET_ADDRESS'));
console.log(balance / LAMPORTS_PER_SOL, 'SOL');

cURL:

curl -s -X POST https://eu.fluxrpc.com?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getBalance","params":["YOUR_WALLET_ADDRESS"]}' | jq

Output:

{
  "jsonrpc": "2.0",
  "result": {
    "context": { "slot": 123456789 },
    "value": 35737443
  },
  "id": 1
}

Get your API key → dashboard.fluxbeam.xyz

Prerequisites

Node.js 18+
FluxRPC API key (free, takes 30 seconds)

Step 1 — Get Your API Key

Go to dashboard.fluxbeam.xyz
Sign in (Google, GitHub, or Solana wallet)
Click Create API Key
Copy the key

Step 2 — Create Project

mkdir fluxrpc-quickstart && cd fluxrpc-quickstart
npm init -y
npm install @solana/web3.js tsx

Step 3 — Write the Code

Create index.ts:

import { Connection, PublicKey, LAMPORTS_PER_SOL } from '@solana/web3.js';

const API_KEY: string = 'your-api-key-here';
const RPC_URL: string = `https://eu.fluxrpc.com?key=${API_KEY}`;

const WALLET: string = 'YOUR_WALLET_ADDRESS';

async function main(): Promise<void> {
  const connection = new Connection(RPC_URL, 'confirmed');
  const publicKey = new PublicKey(WALLET);

  const start: number = Date.now();
  const lamports: number = await connection.getBalance(publicKey);
  const ms: number = Date.now() - start;

  console.log(`Wallet:  ${WALLET}`);
  console.log(`Balance: ${lamports / LAMPORTS_PER_SOL} SOL`);
  console.log(`Latency: ${ms}ms`);
}

main();

Replace your-api-key-here with your API key.

Step 4 — Run

npx tsx index.ts

Output:

Wallet:  Wallet Address
Balance: 0.035737443 SOL
Latency: 142ms

You just read from Solana mainnet.

What Just Happened

Connection — Opens a connection to FluxRPC. The second param 'confirmed' is the commitment level (how finalized the data needs to be).

PublicKey — Parses the wallet address string into a format Solana understands.

getBalance — Returns the wallet balance in lamports. 1 SOL = 10^9 lamports.

This pattern repeats for all RPC calls: connect → query → handle response.

Why FluxRPC

Fresh Data

Most providers cache responses. FluxRPC returns HEAD slot data, the latest confirmed state. No stale reads.

No Rate Limits

Pay for bandwidth, not requests. $0.06 per GB. That getBalance call? About 0.5KB. 2 million calls = 6 cents.

Free tier: 10GB.

Built for Load

Consistent performance when Solana's congested. No slowdowns during high traffic.

Want Sub-Millisecond?

Lantern caches account state locally. Response times: 0.1–0.25ms. Throughput: 10k+ req/sec.

More Methods

getLatestBlockhash

Required before sending transactions.

const { blockhash, lastValidBlockHeight } = await connection.getLatestBlockhash();
console.log('Blockhash:', blockhash);

getAccountInfo

Returns account details, owner, balance, executable flag, data.

import type { AccountInfo } from '@solana/web3.js';

const account: AccountInfo<Uint8Array> | null = await connection.getAccountInfo(publicKey);

if (account) {
  console.log('Owner:', account.owner.toBase58());
  console.log('Lamports:', account.lamports);
  console.log('Executable:', account.executable);
  console.log('Data length:', account.data.length);
}

Reference

Endpoints

Region	URL
EU	`https://eu.fluxrpc.com?key=API_KEY`
US	`https://us.fluxrpc.com?key=API_KEY`

Choose the closest region. Wrong region adds ~100ms latency.

Commitment Levels

Level	Meaning
`processed`	Node has seen it
`confirmed`	Supermajority voted
`finalized`	Won't be rolled back

Common Errors

Error	Fix
`Invalid public key input`	Check wallet address is valid base58
`Failed to fetch`	Verify API key and endpoint URL
`403 Forbidden`	Regenerate API key from dashboard
`TypeError: fetch failed`	Upgrade to Node.js 18+

try {
  const balance = await connection.getBalance(publicKey);
} catch (error) {
  console.error('RPC error:', error);
}

Next Steps

Transactions — Build and send SOL transfers
WebSockets — Subscribe to account changes

Docs: fluxrpc.com

Stuck? Discord — we respond fast. Twitter

Modifying a Solana dApp to Support Sonic: "SVM Greetings"

Shivam Soni — Thu, 03 Apr 2025 11:09:39 +0000

Introduction

In this tutorial, we will deploy an existing Solana dApp to the Sonic Testnet. Specifically, we’ll use the SVM-Greet Solana program and the SVM-Greeting dApp as examples. This guide is intended for those who already know how to build a Solana dApp and describes the core modifications needed when deploying a Solana dApp to the Sonic SVM Testnet RPC.

You can also take a look at the SVM-greeting deployed frontend.

At a high level, developers should take the following steps:

Get an overview of solana dApp
Set up developer environment
Acquire Sonic Testnet tokens
Deploy the solana program with the Sonic Testnet RPC
Modify frontend
Test and deploy

Overview of solana dApp

Solana DApp can be built using various tech stacks and environments, depending on the developer’s requirements. However, every Solana DApp follows a fundamental architecture composed of several layers, each serving a distinct purpose.

This diagram represents the essential layers that define the architecture of a Solana DApp.

Let’s dive into each layer and explore its purpose.

User layer:

In this layer, we focus on the user—the individual who interacts with the Solana DApp. The purpose of this layer is to authorize users to connect, sign transactions, and interact with the Solana program.

A user can use any compatible solana wallet to connect with the DApp and sign transactions as required.

A developer can use the Solana Wallet Adapter to integrate solana wallets into a DApp to enable user interactions.

Find reference implementation here: wallet integration

Client layer:

In this layer, we focus on building the UI and integrating Solana-compatible libraries like Solana Web3.js and Anchor’s coral. These libraries enable users to submit data to the program and retrieve data in a compatible format.

Find reference implementation here:

Communication layer:

In this layer, we focus on setting up the Solana program and integrating it with the UI. We implement program APIs using the program IDL and a provider(that is created through the wallet and a cluster connection).

This setup provides an interface that allows users to directly interact with the Solana program through a frontend UI, sending requests to the RPC cluster and receiving responses.

Find reference implementation here:

Blockchain layer:

In this layer, we focus on building the Solana program. In this example, we use the Anchor framework to create a Solana program that initializes a Solana account and stores a greeting message sent by the user from the UI.

An Anchor Solana program consists of Three main parts: the Program ID, the Program Module, and the Account Creation and Validation section.

Find reference implementation here:

Within an Anchor project, we can build a program to generate program IDL and program types, which will be used on the client side. We can then deploy it to the preferred network cluster and test it to ensure the program works as expected.

Find reference implementation here:

Create, build, deploy and test anchor program

Deploying the solana program to the Sonic SVM cluster

Solana programs can be easily deployable to Sonic SVM clusters. A variety of Solana programs are available, such as those written natively in Rust or built using frameworks like Anchor, Steel, or Seahorse. For simplicity, we will use an Anchor Solana program to deploy to the Sonic test-net RPC endpoint.

I assume you have set up your developer environment for Solana development. If not, first go through the setup local development for Sonic SVM and set it up.

The first step is to clone the solana-greet repo:

git clone git@github.com:shivamSspirit/solana-greet.git

Now, go to the root of the project and configure your Sonic cluster.

solana config set --url https://api.testnet.sonic.game

Verify your configuration.

solana config get

It will output something like this:

Config File: /Users/shivamsoni/.config/solana/cli/config.yml
RPC URL: https://api.testnet.sonic.game ## Here it is setted-up
WebSocket URL: wss://api.testnet.sonic.game/ (computed)
Keypair Path: ~/.config/solana/id.json 
Commitment: confirmed

Now check your wallet address and account balance. (I assume you have created a CLI wallet using the Solana-keygen command.)

solana address
solana balance

If it shows 0 or no amount of SOL, go to the Sonic Faucet and acquire some testnet SOL for the deployment.

You have testnet SOL, and your RPC endpoint is configured. Now, go to the project folder, open the Anchor.toml file and update the cluster URL to this:

[provider]
cluster = "https://api.testnet.sonic.game" ## sonic testnet RPC endpoint
wallet = "~/.config/solana/id.json" ## your wallet path

At this stage, we are ready to deploy our program to the Sonic testnet.

Go to the terminal and build your program:

anchor build

Deploy your program:

anchor deploy --provider.cluster https://api.testnet.sonic.game

For simplicity, here we are overriding our cluster to deploy it to the correct endpoint.

On successful deployment output will look like this:

Deploying cluster: https://api.testnet.sonic.game
Upgrade authority: ~/.config/solana/id.json
Deploying program "svm_greet"...
Program path: /Users/shivamsoni/Desktop/svm-sonic/svm-greet/target/deploy/svm_greet.so...
Program Id: 97uCKFPMDU4S4DQmNwu7BQAYCCFM5fMBms7zk71uJeib

Signature: 65MAiMNGH3BhE41dSXssNUQgxLEmCqDXg3cVj3zJ7GzDkDcbP6CiU6AbzQ965w1aGdCMGivFoLLKNEHzYyDV9Wbz

Deploy success

Whoa, Congrats! Now your solana program is deployed to Sonic testnet.

Grab your program ID from the terminal, and grab the IDL and program types from the target folder generated by the anchor build command, as we will use these in our frontend program.

Test your program:

Before moving to the front end, please ensure that your program works as expected.

anchor test

On successful testing, all your tests should pass.

  svm-greet
Transaction Signature: CSL7JmirqfRmbUPnYYamSmtE9y6L9SnDiCKDvGkhCmEg98Tqpj9RbCRosi8ydChjQU5NT77xBypPDawHYZMzQXX
    ✔ Is initialized! (4261ms)
{
  "user": "LVw9ncQJe9aRMj4YZcSNgS82bfEKu1rrNJXv6WY1QPs",
  "greet": "Hello, Svm maxim!",
  "bump": ##### your account bump
}
    ✔ Fetch Account (799ms)


  2 passing (5s)

✨  Done in 7.49s.

Modifying Frontend

For this, we will not create an entire frontend dApp. Instead, we will use the Solana SVM-Greeting dApp and make some adjustments to get it working for the Sonic SVM testnet.

First, clone the SVM-Greeting repository onto your system:

git clone git@github.com:shivamSspirit/svm-greet-dapp.git

Go to the svm-greet-dapp directory and run npm install

npm install

Update IDL, Program types, and ProgramID

First, we must set up our program’s interaction with the client. To do this, we need to update our IDL file, program types, and program ID.

At the project root, go to the src/app/idl.json and src/app/programtypes.ts files, remove their contents, and add the IDL and program types that you grabbed from the Sonic SVM program.

In src/app/programsetup.ts, update your program ID with the one you grabbed when you deployed your Sonic program.

export const greetSvmProgramId = new PublicKey(
  "97uCKFPMDU4S4DQmNwu7BQAYCCFM5fMBms7zk71uJeib"
);

Update RPC endpoints and supported wallets

In src/app/context/NetworkContext.tsx, update network endpoints to:

export const NETWORKS = {
  MAINNET: {
    name: "mainnet",
    endpoint: "https://rpc.mainnet-alpha.sonic.game",
    label: "Sonic Mainnet",
  },
  TESTNET: {
    name: "testnet",
    endpoint: "https://api.testnet.sonic.game",
    label: "Sonic Testnet",
  },
} as const;

Update Sonic Testnet as the default network

 const [network, setNetwork] = useState<Network>(NETWORKS.TESTNET);

In src/app/components/WalletProvider.tsx, update WalletAdapterNetwork to:

const walletAdapterNetwork = useMemo(() => {
    switch (network.name) {
      case "mainnet":
        return WalletAdapterNetwork.Mainnet;
      case "testnet":
        return WalletAdapterNetwork.Testnet;
      default:
        return WalletAdapterNetwork.Testnet;
    }
  }, [network.name]);

Add configuration for Sonic SVM-supported wallets.

  const wallets = useMemo(() => [new NightlyWalletAdapter()], [walletAdapterNetwork]);

  const supportedWalletNames = ["Backpack", "Nightly"];

  const filteredWallets = wallets.filter(
    (wallet:any) =>
      supportedWalletNames.includes(wallet.adapter?.name) &&
      wallet.readyState === WalletReadyState.Installed
  );

  return (
    <ConnectionProvider endpoint={endpoint}>
      <SolanaWalletProvider wallets={filteredWallets} autoConnect>
        <WalletModalProvider>{children}</WalletModalProvider>
      </SolanaWalletProvider>
    </ConnectionProvider>
  );

In src/app/programsetup.ts, update the getGreetSvmProgramId function to this:

export function getGreetSvmProgramId(cluster: Cluster): PublicKey {
  switch (cluster) {
    case "testnet":
      return greetSvmProgramId;
    case "devnet":
    default:
      return greetSvmProgramId;
  }
}

Update the provider to use Sonic SVM network endpoints.

export function useAnchorProvider(): AnchorProvider {
  const { network } = useNetwork();
  const testConnection = new Connection(network.endpoint)
  const wallet = useWallet();
  return new AnchorProvider(testConnection, wallet as AnchorWallet, {
    commitment: "confirmed",
  });
}

In src/app/components/CustomWalletButton.tsx and src/app/components/CustomWalletModal.tsx, we are adding configuration for Sonic SVM-supported wallets to ensure that only supported wallets are displayed. If no supported wallet is installed on the user's system, it will suggest download a supported wallet.

const supportedWalletNames = ["Backpack", "Nightly"];
  const filteredWallets = wallets.filter(
    (wallet) =>
      supportedWalletNames.includes(wallet.adapter.name) &&
      wallet.readyState === WalletReadyState.Installed
  );

In src/app/components/CreateGreet, we are updating the transaction explorer link to the Sonic Explorer.

          <Link
            href={`https://explorer.sonic.game/tx/${tx}?cluster=${network.name}`}
            target="_blank"
            rel="noopener noreferrer"
            className="text-sm text-green-400 hover:underline"
          >

We have also changed some refreshing logic when sending our first transaction to initialize the greet account on the Sonic testnet and retrieve it for greet data. You can check these changes in the GitHub repo provided in the resources section.

Finally, we run the front end and test it to ensure transactions are going through and can be observed in the block explorer.

We ran this modified dApp using npm run dev to ensure it works as expected, and yes, it is running! Congrats, our dApp is now live on sonic testent.

Supported wallet on Sonic SVM

In this simple example, we use the Backpack wallet as it works on Sonic. You can use other wallets based on your requirements. Here are some wallets that natively support the Sonic network.

Supported wallet by sonic

Also, note that we updated the Sonic Explorer link to pop up when initializing a greet account.

Here, we are using the Solana Explorer link structure to provide dynamic values for the cluster and transaction signature, but it may not work as expected. For more information about the Sonic Explorer, visit Sonic Explorer.

Resources

Introducing Gill: The Modern Solana JavaScript client library

Shivam Soni — Sat, 15 Mar 2025 10:25:29 +0000

Introduction

Introducing Gill: The new javascript client library to interact with the solana blockchain. It is built on top of modern JavaScript libraries for Solana, which Anza built. it leverages the speed and elegance of web3 js version two and delivers a lightweight and highly abstract solution. it is lightweight, fast, and has tree-shakable architecture. you can use it to build solana d-apps in node, web, React Native or just about any other javascript environment.

Why is Gill useful?

Since Solana Web3.js v2 is great in performance with its tree-shakable architecture but feels verbose in everything you do with its longer function names and hyper-modular sub-packages, Gill is fully compatible with v2 and offers an easier adoption curve with improved developer experience(DevEx).

Gill provides a single entry point for Web3.js v2, popular SPL programs like System, Compute Budget, Memo, Token, Token22, and ecosystem programs like Metaplex’s Token Metadata.

Gill offers Transaction Builders to make it easy to assemble ready-to-sign transactions for common Solana tasks such as creating tokens with metadata, minting tokens, and transferring tokens. These tasks often involve interacting with multiple programs at once.

Gill can be useful for building Solana d-apps in Node, web, React Native, or any other JavaScript environment.

Gill provides a debug mode that you can enable to automatically log additional information helpful for troubleshooting your transactions. You can enable it from the most common places where your code runs, including within your code, Node.js backends, serverless functions, and even directly in the web browser console.

What can I do with Gill?

Gill offers the same features as Solana Web3.js v2 (Solana Kit) but with improved naming and a simplified approach for common Solana tasks.

By using Gill, you can accomplish the following -:

Keypairs/wallets -:

Generate random keypairs - Use generateKeyPairSigner to generate a non-extractable keypair for signing transactions. Non-extractable means that the private key cannot be retrieved from the instance, providing enhanced security for keypairs.
Generate random extractable keypairs - Use generateExtractableKeyPairSigner to generate extractable keypairs. These are less secure because they allow the secret key material to be extracted.
Load a wallet from a file - Use loadKeypairSignerFromFile to load a keypair signer from a filesystem wallet JSON file. By default, this function loads the wallet keypair stored in the file used by the Solana CLI: ~/.config/solana/id.json. It also resolves relative paths that use the ~ character for the user's home directory.
Load a keypair from an environment variable - Load a keypairSigner from environment-stored bytes using loadKeypairSignerFromEnvironment, consistent with standard Solana tools.

Client Connection and Rpc Calls-:

Create a solana RPC connection - Use createSolanaClient to create a Solana client with your preferred RPC endpoint URL or a standard Solana network moniker (e.g., devnet, localnet, mainnet, etc.).
To make an RPC call, the RPC client requires you to call .send() on the RPC method to send the request to your RPC provider and receive a response.

Transactions

Create a transaction - Use the createTransaction method to easily create a transaction with all standard parameters.
Sign and Send transaction - After you have a signable transaction, you can sign it using signTransactionMessageWithSigners, retrieve the signature using getSignatureFromTransaction (even before sending it to the network), and send the transaction using sendAndConfirmTransaction.
Get a Solana Explorer link - Use the getExplorerLink method to generate a Solana Explorer link for transactions, accounts, or blocks.
Transaction builders - To simplify common Solana tasks like creating tokens, minting tokens, and transferring SPL tokens, Gill introduces Transaction Builders to help easily assemble ready-to-sign transactions for these tasks.

Debug mode

Dubug solana transaction - Gill introduced debug mode that will make it easier to troubleshoot the solana transaction. Debug mode is disabled by default to minimize additional logs for your application. But with its flexible debug controller, you can enable it from the most common places your code will be run.

Example Comparision

At this point, we've learned what Gill is, why it's helpful for developers, and the common tasks it can accomplish. Now, let’s look at an example of creating a token using Gill and Web3.js v2:

Create ‘OPOS’ token with Gill-:


import {
  createSolanaClient,
  signTransactionMessageWithSigners,
  getSignatureFromTransaction,
  getExplorerLink,
  createKeyPairSignerFromBytes,
  getBase58Codec,
  generateKeyPairSigner
} from "gill";
import { buildCreateTokenTransaction, TOKEN_2022_PROGRAM_ADDRES } from "gill/programs/token";

const { rpc, sendAndConfirmTransaction } = createSolanaClient({
  urlOrMoniker: "devnet",
});

// get the latest blockhash
const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();

const keypairBase58feePayer = "your_secret_key";
const keypairBytesfeePayer = getBase58Codec().encode(keypairBase58feePayer);
const feepayersigner = await createKeyPairSignerFromBytes(keypairBytesfeePayer);

async function createTokenFunc() {

  const mint = await generateKeyPairSigner();

  // create tokens
  const createTokenTx = await buildCreateTokenTransaction({
    feePayer: feepayersigner,
    latestBlockhash,
    mint: mint,  // Use mintKey here
    metadata: {
      isMutable: true, // if the `updateAuthority` can change this metadata in the future
      name: "Only Possible On Solana",
      symbol: "OPOS",
      uri: "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/Climate/metadata.json",
    },
    decimals: 2,
    tokenProgram: TOKEN_2022_PROGRAM_ADDRESS
  });

  const signedTransaction = await signTransactionMessageWithSigners(createTokenTx);
  const signature: string = getSignatureFromTransaction(signedTransaction);
  console.log(getExplorerLink({ transaction: signature }));

  // default commitment level of `confirmed`
  await sendAndConfirmTransaction(signedTransaction);
}

createTokenFunc().catch(console.error);

Create ‘OPOS’ token without Gill:


import {
    airdropFactory,
    appendTransactionMessageInstructions,
    createSolanaRpc,
    createSolanaRpcSubscriptions,
    createTransactionMessage,
    generateKeyPairSigner,
    getSignatureFromTransaction,
    lamports,
    pipe,
    sendAndConfirmTransactionFactory,
    setTransactionMessageFeePayerSigner,
    setTransactionMessageLifetimeUsingBlockhash,
    signTransactionMessageWithSigners,
    some,
  } from "@solana/web3.js";
  import { getCreateAccountInstruction } from "@solana-program/system";
  import {
    getInitializeMintInstruction,
    getMintSize,
    TOKEN_2022_PROGRAM_ADDRESS,
    extension,
    getInitializeMetadataPointerInstruction,
    getInitializeTokenMetadataInstruction,
    tokenMetadataField,
    getUpdateTokenMetadataFieldInstruction,
  } from "@solana-program/token-2022";

  const rpc = createSolanaRpc("http://127.0.0.1:8899");
  const rpcSubscriptions = createSolanaRpcSubscriptions("ws://127.0.0.1:8900");

  const feePayer = await generateKeyPairSigner();
  console.log(feePayer.address);
  const mint = await generateKeyPairSigner();

  await airdropFactory({ rpc, rpcSubscriptions })({
    recipientAddress: feePayer.address,
    lamports: lamports(1_000_000_000n),
    commitment: "confirmed",
  });

  const balance = await rpc.getBalance(feePayer.address).send();
  console.log("balance:", balance.value);

  const metadataPointerExtension = extension("MetadataPointer", {
    authority: some(feePayer.address),
    metadataAddress: some(mint.address),
  });

  const tokenMetadataExtension = extension("TokenMetadata", {
    updateAuthority: some(feePayer.address),
    mint: mint.address,
    name: "Only Possible On Solana",
    symbol: "OPOS",
    uri: "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/Climate/metadata.json",
    additionalMetadata: new Map<string, string>([["description", "Only Possible On Solana"]]),
  });

  const spaceWithoutMetadata = BigInt(getMintSize([metadataPointerExtension]));

  const spaceWithMetadata = BigInt(getMintSize([metadataPointerExtension, tokenMetadataExtension]));

  const rent = await rpc.getMinimumBalanceForRentExemption(spaceWithMetadata).send();

  const createAccountInstruction = getCreateAccountInstruction({
    payer: feePayer,
    newAccount: mint,
    lamports: rent,
    space: spaceWithoutMetadata,
    programAddress: TOKEN_2022_PROGRAM_ADDRESS,
  });

  const initializeMetadataPointerInstruction = getInitializeMetadataPointerInstruction({
    mint: mint.address,
    authority: feePayer.address,
    metadataAddress: mint.address,
  });

  const initializeMintInstruction = getInitializeMintInstruction({
    mint: mint.address,
    decimals: 2,
    mintAuthority: feePayer.address,
  });

  const initializeTokenMetadataInstruction = getInitializeTokenMetadataInstruction({
    metadata: mint.address,
    updateAuthority: feePayer.address,
    mint: mint.address,
    mintAuthority: feePayer,
    name: tokenMetadataExtension.name,
    symbol: tokenMetadataExtension.symbol,
    uri: tokenMetadataExtension.uri,
  });

  const updateTokenMetadataInstruction = getUpdateTokenMetadataFieldInstruction({
    metadata: mint.address,
    updateAuthority: feePayer,
    field: tokenMetadataField("Key", ["description"]),
    value: "Only Possible On Solana",
  });

  const instructions = [
    createAccountInstruction,
    initializeMetadataPointerInstruction,
    initializeMintInstruction,
    initializeTokenMetadataInstruction,
    updateTokenMetadataInstruction,
  ];

  const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();

  const transactionMessage = pipe(
    createTransactionMessage({ version: 0 }),
    (message) => setTransactionMessageFeePayerSigner(feePayer, message),
    (message) => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, message),
    (message) => appendTransactionMessageInstructions(instructions, message),
  );

  const signedTransaction = await signTransactionMessageWithSigners(transactionMessage);

  const transactionSignature = getSignatureFromTransaction(signedTransaction);

  await sendAndConfirmTransactionFactory({ rpc, rpcSubscriptions })(signedTransaction, {
    commitment: "confirmed",
    skipPreflight: true,
  });

  console.log("Transaction Signature:", `https://explorer.solana.com/tx/${transactionSignature}?cluster=custom`);

As you can see, creating tokens with Gill is easy thanks to its transaction builders and a higher level of abstraction over Web3.js v2. Using one transaction builder and some line of code, we created an SPL token.

Now that we understand what Gill is, why it matters, and how it enhances the Web3.js v2 developer experience, it's time to code a simple SPL token mint and transfer example. Let's go!

Quick spl token mint and transfer With Gill

As we know, there are various ways to mint or create an SPL token. We can use JavaScript/TypeScript with Solana Web3.js and Solana's developer helpers for SPL tokens, or create a Solana program in Rust/Anchor to mint an SPL token. In this guide, we will use the Gill library to mint an SPL token. We'll also utilize the quickest method, leveraging Gill's pre-built transaction builder methods for various transactions.

What you will need

Experience with Solana Web3.js v2
Latest Node.js version installed
TypeScript and ts-node installed

Dependencies used in this guide

For this project, the dependencies in the package.json file will look like this:


"dependencies": {
    "esrun": "^3.2.26",
    "gill": "^0.6.0"
  },
  "devDependencies": {
    "@types/node": "^22.13.10",
    "ts-node": "^10.9.2",
    "typescript": "^5.8.2"
  }

Let’s set up a new project:

mkdir spl-token && cd spl-token

Initialize your project as a Node.js project:

npm init -y

Install the required dependencies:

pnpm install gill esrun && pnpm install --save-dev @types/node typescript ts-node

Create a new file named spl-token.ts in your project directory:

echo > spl-token.ts

Great! Now, let’s start coding.

Import dependencies

In your spl-token.ts file, let's start by importing the necessary dependencies:

import {
    address,
    KeyPairSigner,
    getBase58Codec,
    getExplorerLink,
    createSolanaClient,
    generateKeyPairSigner,
    getSignatureFromTransaction,
    createKeyPairSignerFromBytes,
    signTransactionMessageWithSigners,
    setTransactionMessageLifetimeUsingBlockhash,
  } from "gill";

  import {
    buildCreateTokenTransaction,
    buildMintTokensTransaction,
    buildTransferTokensTransaction
  } from "gill/programs/token";

We're importing key functions from the Gill library to create, mint, and transfer SPL tokens.

Create an RPC connection to interact with the blockchain

  // create Rpc connection
  const { rpc, sendAndConfirmTransaction } = createSolanaClient({
    urlOrMoniker: "devnet",
  });

  // get slot
  const slot = await rpc.getSlot().send();

  // get the latest blockhash
  const { value: latestBlockhash } = await rpc.getLatestBlockhash().send();

We are using Gill's createSolanaClient method to establish an RPC connection to Devnet. To call any RPC method, we need to use .send() on the RPC method to send the request to the RPC provider and receive a response.

Generate Keypairs


 const keypairBase58alice = "your_wallet_secret_key";
 const keypairBytesalice = getBase58Codec().encode(keypairBase58alice);
 const aliceKeyPair = await createKeyPairSignerFromBytes(keypairBytesalice);

 // KeyPairs and addresses
 const alice = aliceKeyPair.address;

 const bob = address("4d4zsfq4gtJixDGvisSdFjsY78uH7BypkwmkXL1D8RfT");

 const mint = await generateKeyPairSigner();

Here, we generate the Alice, Bob, and Mint addresses. For Alice, we use a secret key pair to generate her address. In this guide, Alice will create and mint tokens in her wallet, and then send the minted tokens to Bob’s wallet.

Create the Main Function

Next, let's create our main function that will house the logic of our script:


async function main(){


// Create token transaction


// Mint token transaction


// Transfer tokens transaction


}

main().catch(console.error);

Create or mint spl token

Let's add the following code to the main function as the first step:

const createTokenTx = await buildCreateTokenTransaction({
      feePayer: aliceKeyPair,
      latestBlockhash,
      mint: mint,  // Use mintKey here
      metadata: {
        isMutable: true, // if the `updateAuthority` can change this metadata in the future
        name: "Only Possible On Solana",
        symbol: "OPOS",
        uri: "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/Climate/metadata.json",
      },
      decimals: 2,
    });


const signedTransaction = await signTransactionMessageWithSigners(createTokenTx);
const signature: string = getSignatureFromTransaction(signedTransaction);
console.log(getExplorerLink({ transaction: signatureformint }));

// default commitment level of `confirmed`
await sendAndConfirmTransaction(signedTransaction);

Here, we use the buildCreateTokenTransaction tx builder from Gill to create an SPL token, specifying aliceKeypair as the feePayer and providing metadata for the token.

Next, we use signTransactionMessageWithSigners to sign the transaction before sending it to the network, similar to Web3.js. We then obtain the signature using getSignatureFromTransaction and finally send the transaction to the network using sendAndConfirmTransaction.

Congrats! Our OPOS token has been created. Check the Solana Explorer link for details.

Minting Created token to Alice's wallet

Let's add the following code to the main function as the second step:


const mintTokensTx = await buildMintTokensTransaction({
      feePayer: aliceKeyPair,
      latestBlockhash,
      mint,
      mintAuthority: aliceKeyPair,
      amount: 1000, // note: be sure to consider the mint's `decimals` value
      // if decimals=2 => this will mint 10.00 tokens
      // if decimals=4 => this will mint 0.100 tokens
      destination: alice,
      // use the correct token program for the `mint`
      // tokenProgram, // default=TOKEN_PROGRAM_ADDRESS
      // default cu limit set to be optimized, but can be overriden here
      // computeUnitLimit?: number,
      // obtain from your favorite priority fee api
      // computeUnitPrice?: number, // no default set
    });



    const signedTransactionformint = await signTransactionMessageWithSigners(mintTokensTx);
    const signatureformint: string = getSignatureFromTransaction(signedTransactionformint);
    console.log(getExplorerLink({ transaction: signatureformint }));
    // default commitment level of `confirmed`
    await sendAndConfirmTransaction(signedTransactionformint);

Here, we use the buildMintTokensTransaction tx builder from Gill to mint tokens to Alice's address, sign the transaction, obtain the signature, and send the transaction to the network.

You don't need to worry about associated token accounts because, in transaction builders, if the destination owner does not have an associated token account (ATA) for the mint, one will be automatically created for them.

Congrats! You have minted 10 OPOS SPL tokens into Alice's token account.

Transfer the spl token to Bob’s wallet

Let's add the following code to the main function as the third step:


const transferTokensTx = await buildTransferTokensTransaction({
      feePayer: aliceKeyPair,
      latestBlockhash,
      mint,
      authority: aliceKeyPair,
      // sourceAta, // default=derived from the `authority`.
      /*
       * if the `sourceAta` is not derived from the `authority` (like for multi-sig wallets),
       * manually derive with `getAssociatedTokenAccountAddress()`
      */
      amount: 900, // note: be sure to consider the mint's `decimals` value
      // if decimals=2 => this will transfer 9.00 tokens
      // if decimals=4 => this will transfer 0.090 tokens
      destination: bob,
      // use the correct token program for the `mint`
      //  tokenProgram, // default=TOKEN_PROGRAM_ADDRESS
      // default cu limit set to be optimized, but can be overriden here
      // computeUnitLimit?: number,
      // obtain from your favorite priority fee api
      // computeUnitPrice?: number, // no default set
    });


    const signedTransactionfortransfer = await signTransactionMessageWithSigners(transferTokensTx);
    const signaturefortransfer: string = getSignatureFromTransaction(signedTransactionfortransfer);
    console.log(getExplorerLink({ transaction: signaturefortransfer }));

    // default commitment level of `confirmed`
    await sendAndConfirmTransaction(signedTransactionfortransfer);

We use the buildTransferTokensTransaction method to transfer SPL tokens from Alice to Bob, Then sign, obtain the signature, and send it to the network. The associated token account (ATA) is also auto-created for Bob's wallet for this mint.

Congrats! You transferred 9 OPOS tokens from Alice's token account to Bob's token account.

Run Your Code

In your Terminal, type:

npx esrun ./index.ts

Upon successful execution, you should see an output of three Solana Explorer links for each operation: create, mint, and transfer of the 'OPOS' token.

https://explorer.solana.com/tx/58KC1GPc1f8aCUox6Pst7YheYRCqrQY9Np2gP6LfqDP5ogQjP5Hy76opzmJ8EKW2PyMdoGh71MYGWHL6oYHLAvdD
https://explorer.solana.com/tx/4DXAFBfsAVCgZ3X3rwEZ72EN81JVWj2zpzsYERCu5xitf1aztuytn9og3cyNbNeR3t5KnaJgneNckFy6MGAoWLGr
https://explorer.solana.com/tx/4PkHW9dSbQicKcempBoD3VCe2xQhJidJ6gptXPNvq4LVRBzJYAQrN5AGcaVfu88NabrczkgV8FrF4x1sVxKB7xSH

Let’s wrap

Gill is a new JavaScript client library for interacting with the Solana blockchain. In this post, we discussed what Gill is, why it matters for Solana developers, and how it helps improve the developer experience. We also explored its key features, provided examples comparing it to Web3.js v2, and demonstrated how to create and mint an SPL token using Gill.

Overall, you'll find that Gill offers a great developer experience when working with Web3.js v2.

Further Resources

Soon 101: Overview of building program on soon

Shivam Soni — Fri, 15 Nov 2024 05:18:56 +0000

What Is SOON

SOON is the most efficient roll-up stack delivering top performance to every L1, powered by Decoupled SVM.

SOON Stack

SOON Stack is the collection of components that allows for the deployment and running of an SVM Layer 2 on top of any base Layer 1. Chains deployed using the SOON Stack are referred to as SOON Chains.

Decoupled SVM

Decoupled SVM refers to the separation of the Solana Virtual Machine (SVM) from Solana's native consensus layer, turning the SVM into an independent execution layer. This allows SVM to be deployed across different Layer 1 ecosystems, providing enhanced performance and security for rollup architectures.

What This Guide Will Teach You

This guide will teach you how to create and deploy a Solana program on SOON Devnet and connect it to a UI for a basic on-chain counter d-App.

What You Will Learn

Setting up your development environment
Using npx create-solana-dApp
Anchor program development
How to create and store data in a solana account
How to update the data of an account
Deploying a Solana program to Soon Devnet
Connecting counter on-chain program to a React UI

Prerequisites

For this guide, you will need to have your local development environment setup with a few tools:

For more information about the setup, you can explore this setup.

What We Are Building

We are developing a counter program.

In this d-App, Solana accounts will be utilized to:

Create a counter account.
Update the counter account by incrementing and decrementing the counter’s count.

Setting Up The Project

Please ensure all necessary development environments and dependencies are properly installed and configured.

This project uses npx create-solana-dapp to create a quick Solana dApp. You can find the source code here.

First, clone the soon-counter example repository to your local machine.

git clone git@github.com:shivamSspirit/soon-counter.git

Change into the project directory:

cd soon-counter
npm i
npm run dev

Anchor Program Development

If you're new to Anchor, The Anchor Book and Anchor Examples are great references to help you learn.

In the project folder, navigate to soon-counter/anchor/programs/counter/src/lib.rs. Let's delete it and start from scratch to walk through each step.

use anchor_lang::prelude::*;

declare_id!("EBgotvhJTqX98LR7moF9V85dgnbQYedmCyY2nsXqTaCV");

#[program]
pub mod soo_counter {
    use super::*;
}

Counter Account State

use anchor_lang::prelude::*;

declare_id!("EBgotvhJTqX98LR7moF9V85dgnbQYedmCyY2nsXqTaCV");

#[program]
pub mod soo_counter {
    use super::*;
}


#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub count: u64,
}

In the above code, we are creating an account struct that will be used to keep track of our counter’s count, which is of type u64.

The #[derive(InitSpace)] attribute will calculate the initial space for the counter account struct. space is used to calculate how many bytes our account will need, You can learn more about account space here.

Create Counter Context

use anchor_lang::prelude::*;

declare_id!("EBgotvhJTqX98LR7moF9V85dgnbQYedmCyY2nsXqTaCV");

#[program]
pub mod soo_counter {
    use super::*;
}

#[derive(Accounts)]
pub struct InitializeCounter<'info> {
    #[account(
        init,
        payer = signer,
        space = 8 + Counter::INIT_SPACE,
      )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub signer: Signer<'info>,

    pub system_program: Program<'info, System>,
}


#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub count: u64,
}

In the code above, we are creating a counter account context of type Counter. This context specifies to our program which accounts are passed when we send a transaction from the client side. The #[derive(Accounts)] attribute handles many abstractions for us, such as serialization and deserialization of account data, allowing us to focus on the core logic.

To initialize the counter account, we need three account keys: the counter account, the signer account, and the system program.

To create the counter account, we use Anchor constraints such as init, payer, and space:

init: This constraint creates the counter account via a CPI to the system program and initializes it.
payer: This Specifies the payer responsible for covering the rent associated with the counter account.
space: Allocates the required space for the counter account.

The second account is the signer account, which will sign the transaction to create the counter account.

The third is the system program, which will be the owner of our counter account and facilitate the account creation.

Initialize Counter Instruction In The Program Module

The program module is where you define your business logic. You do so by writing functions which can be called by clients or other programs.

use anchor_lang::prelude::*;

declare_id!("EBgotvhJTqX98LR7moF9V85dgnbQYedmCyY2nsXqTaCV");

#[program]
pub mod soo_counter {
    use super::*;

     pub fn initialize(ctx: Context<InitializeCounter>) -> Result<()> {
        let counter_account = &mut ctx.accounts.counter;
        counter_account.count = 0;
        Ok(())
    }

}

#[derive(Accounts)]
pub struct InitializeCounter<'info> {
    #[account(
        init,
        payer = signer,
        space = 8 + Counter::INIT_SPACE,
      )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub signer: Signer<'info>,

    pub system_program: Program<'info, System>,
}


#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub count: u64,
}

In the updated code above,

We define an initialize function and set the InitializeCounter context as the function argument.

Since the context contains the program ID, accounts, and other elements that we will explore in future guides, we fetch the counter account from the context and set the counter’s count to zero as its initial value.

Now that our counter account is initialized—great job, everyone!—we can move on to the increment and decrement operations.

Increment Counter

use anchor_lang::prelude::*;

declare_id!("EBgotvhJTqX98LR7moF9V85dgnbQYedmCyY2nsXqTaCV");

#[program]
pub mod soo_counter {
    use super::*;

     pub fn initialize(ctx: Context<InitializeCounter>) -> Result<()> {
        let counter_account = &mut ctx.accounts.counter;
        counter_account.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        ctx.accounts.counter.count = ctx.accounts.counter.count.checked_add(1).unwrap();
        Ok(())
    }

}

#[derive(Accounts)]
pub struct InitializeCounter<'info> {
    #[account(
        init,
        payer = signer,
        space = 8 + Counter::INIT_SPACE,
      )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub signer: Signer<'info>,

    pub system_program: Program<'info, System>,
}


#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub counter: Account<'info, Counter>,
}


#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub count: u64,
}

In the updated code above,

We first create an Increment context struct and mark the counter account as mutable, which ensures that the account can be updated to modify the counter’s count.

Next, in the program module, we create an increment function that takes the Increment context as an argument, fetches the counter account from the context, and increases the count by one.

Decrement Counter

use anchor_lang::prelude::*;

declare_id!("EBgotvhJTqX98LR7moF9V85dgnbQYedmCyY2nsXqTaCV");

#[program]
pub mod soo_counter {
    use super::*;

     pub fn initialize(ctx: Context<InitializeCounter>) -> Result<()> {
        let counter_account = &mut ctx.accounts.counter;
        counter_account.count = 0;
        Ok(())
    }

    pub fn increment(ctx: Context<Increment>) -> Result<()> {
        ctx.accounts.counter.count = ctx.accounts.counter.count.checked_add(1).unwrap();
        Ok(())
    }

    pub fn decrement(ctx: Context<Decrement>) -> Result<()> {
        ctx.accounts.counter.count = ctx.accounts.counter.count.checked_sub(1).unwrap();
        Ok(())
    }

}

#[derive(Accounts)]
pub struct InitializeCounter<'info> {
    #[account(
        init,
        payer = signer,
        space = 8 + Counter::INIT_SPACE,
      )]
    pub counter: Account<'info, Counter>,

    #[account(mut)]
    pub signer: Signer<'info>,

    pub system_program: Program<'info, System>,
}


#[derive(Accounts)]
pub struct Increment<'info> {
    #[account(mut)]
    pub counter: Account<'info, Counter>,
}

#[derive(Accounts)]
pub struct Decrement<'info> {
    #[account(mut)]
    pub counter: Account<'info, Counter>,
}


#[account]
#[derive(InitSpace)]
pub struct Counter {
    pub count: u64,
}

In the updated code above,

We first create a Decrement context struct and add the counter account to update the counter’s count.

Next, in the program module, we create a decrement function that takes the Decrement context as an argument, fetches the counter account from the context, and decreases the count by one.

Wohlaa! We’re all set with the counter operations, including initialize, increment, and decrement. Now, we can build this program and deploy it to Devnet.

Build, Deploy and Test program

In your project folder, open soon-counter/anchor/Anchor.toml and check the cluster URL. It should look like this, as we are deploying the program to Soon Devnet.

[provider]
cluster = "https://rpc.devnet.soo.network/rpc"
wallet = "~/.config/solana/id.json"     /** add your wallet path here **/

Next, go to the CLI, navigate to the anchor directory, and run:

anchor build

This will generate the program ID, IDL, and program types needed for client-side interaction.

To deploy the program, you'll need access to the Soon Solana faucet. You can request it in Discord here or go to our faucet to get them. https://faucet.soo.network/

After receiving faucet access, configure the Solana CLI to use the SOON Devnet RPC endpoint.

To do this, run:

solana config set --url https://rpc.devnet.soo.network/rpc

Make sure everything is configured correctly. To check this, run:

solana config get

This command generates output like this:

Config File: ~/.config/solana/cli/config.yml
RPC URL: https://rpc.devnet.soo.network/rpc 
WebSocket URL: wss://rpc.devnet.soo.network/rpc (computed)
Keypair Path: ~/.config/solana/id.json 
Commitment: confirmed

Finally, check your Soon Devnet SOL balance by running:

solana balance

Next, go to the CLI, navigate to the anchor directory, and run:

anchor deploy --provider.cluster https://rpc.devnet.soo.network/rpc

After this, you will receive your deployed program ID.

Next, test your program by running:

anchor test

Connect program to UI

Create-solana-dapp already sets up a UI with data access and a wallet connector for you. All you need to do is simply modify it to fit your newly created program.

Since this counter program has three instructions, we will need components in the UI that will be able to call each of these instructions:

Initialize counter
Increment counter
Decrement counter

In your project folder open soon-counter/anchor/src/counter-exports.ts

// Here we export some useful types and functions for interacting with the Anchor program.
import { AnchorProvider, Program } from '@coral-xyz/anchor'
import { Cluster, PublicKey } from '@solana/web3.js'
import SoocounterIDL from '../target/idl/soo_counter.json'
import type { SooCounter } from '../target/types/soo_counter'

// Re-export the generated IDL and type
export { SooCounter, SoocounterIDL }

// The programId is imported from the program IDL.
export const SOONCOUNTER_PROGRAM_ID = new PublicKey(SoocounterIDL.address)

// This is a helper function to get the Soonsoonsooncounter Anchor program.
export function getSoocounterProgram(provider: AnchorProvider) {
  return new Program(SoocounterIDL as SooCounter, provider)
}

// This is a helper function to get the program ID for the Soocounter program depending on the cluster.
export function getSoocounterProgramId(cluster: Cluster) {
  switch (cluster) {
    case 'devnet':
    case 'testnet':
      // This is the program ID for the Soocounter program on devnet and testnet.
      return new PublicKey('Ho4gWX427c2qWdy1ZrQ97qA5B8eeSe86okrxJ1nMxvkR')
    case 'mainnet-beta':
    default:
      return SOONCOUNTER_PROGRAM_ID
  }
}

In the above code, we are importing IDL and Program types from the generated target folder. and re-exporting IDL, types, program ID and Program API.

Next, update your cluster to the Soon Devnet network. To do this, go to soon-counter/src/components/cluster/cluster-data-access.tsx and update the custom cluster to the Soon Devnet RPC endpoint.

export const defaultClusters: Cluster[] = [
  {
    name: 'devnet',
    endpoint: clusterApiUrl('devnet'),
    network: ClusterNetwork.Devnet,
  },
  { name: 'local', endpoint: 'http://localhost:8899' },
  {
    name: 'testnet',
    endpoint: clusterApiUrl('testnet'),
    network: ClusterNetwork.Testnet,
  },
  {
    name: 'custom',
    endpoint: 'https://rpc.devnet.soo.network/rpc',
    network: ClusterNetwork.Custom,
  }
]

Next, move to soon-counter/src/components/counter/counter-data-access.tsx And update useSoocounterProgram() to initialize the counter:

export function useSoocounterProgram() {
  const { connection } = useConnection()
  const { cluster } = useCluster()
  const transactionToast = useTransactionToast()
  const provider = useAnchorProvider()
  const programId = useMemo(() => getSoocounterProgramId(cluster.network as Cluster), [cluster])
  const program = getSoocounterProgram(provider)

  const accounts = useQuery({
    queryKey: ['soocounter', 'all', { cluster }],
    queryFn: () => program.account.counter.all(),
  })

  const getProgramAccount = useQuery({
    queryKey: ['get-program-account', { cluster }],
    queryFn: () => connection.getParsedAccountInfo(programId),
  })

// keypair for counter account

  const counter = Keypair.generate();

  const initialize = useMutation({
    mutationKey: ['soocounter', 'initialize', { cluster }],
    mutationFn: ({ user }: { user: PublicKey }) =>

      program.methods.initialize().accounts({
        counter: counter.publicKey,
        signer: user
      }).signers([counter]).rpc(),

    onSuccess: (signature) => {
      transactionToast(signature)
      return accounts.refetch()
    },
    onError: () => toast.error('Failed to initialize account'),
  })

  return {
    program,
    programId,
    accounts,
    getProgramAccount,
    initialize,
  }
}

In the above code, we call our first instruction initialize() to initialize a counter account.

Next, update the useSoocounterProgramAccount() function to be able to call increment and decrement instructions:

export function useSoocounterProgramAccount({ account }: { account: PublicKey }) {
  const { cluster } = useCluster()
  const transactionToast = useTransactionToast()
  const { program, accounts } = useSoocounterProgram()

  const accountQuery = useQuery({
    queryKey: ['soocounter', 'fetch', { cluster, account }],
    queryFn: () => program.account.counter.fetch(account),
  })


  const incrementMutation = useMutation({
    mutationKey: ['soocounter', 'increment', { cluster, account }],
    mutationFn: () => program.methods.increment().accounts({ counter: account }).rpc(),
    onSuccess: (tx) => {
      transactionToast(tx)
      return accountQuery.refetch()
    },
  })


  const decrementMutation = useMutation({
    mutationKey: ['soocounter', 'decrement', { cluster, account }],
    mutationFn: () => program.methods.decrement().accounts({ counter: account }).rpc(),
    onSuccess: (tx) => {
      transactionToast(tx)
      return accountQuery.refetch()
    },
  })


  return {
    accountQuery,
    decrementMutation,
    incrementMutation,
  }
}

Next update UI, for this, go into soon-counter/src/components/counter/counter-ui.tsx and create a UI for the initialize counter button

export function SoocounterCreate() {
  const { initialize } = useSoocounterProgram()
  const { publicKey } = useWallet();

  return (
    <button
      className="btn btn-xs lg:btn-md btn-primary"
      onClick={() => initialize.mutateAsync({ user: publicKey! })}
      disabled={initialize.isPending}
    >
      Create {initialize.isPending && '...'}
    </button>
  )
}

Next, create a UI for the list of counters that will be created.

export function SoocounterList() {
  const { accounts, getProgramAccount } = useSoocounterProgram()

  if (getProgramAccount.isLoading) {
    return <span className="loading loading-spinner loading-lg"></span>
  }
  if (!getProgramAccount.data?.value) {
    return (
      <div className="alert alert-info flex justify-center">
        <span>Program account not found. Make sure you have deployed the program and are on the correct cluster.</span>
      </div>
    )
  }
  return (
    <div className={'space-y-6'}>
      {accounts.isLoading ? (
        <span className="loading loading-spinner loading-lg"></span>
      ) : accounts.data?.length ? (
        <div className="grid md:grid-cols-2 gap-4">
          {accounts.data?.map((account) => (
            <SooncounterCard key={account.publicKey.toString()} account={account.publicKey} />
          ))}
        </div>
      ) : (
        <div className="text-center">
          <h2 className={'text-2xl'}>No accounts</h2>
          No accounts found. Create one above to get started.
        </div>
      )}
    </div>
  )
}

Finally, create a UI for the counter’s increment and decrement controls.


function SooncounterCard({ account }: { account: PublicKey }) {
  const { accountQuery, incrementMutation, decrementMutation } = useSoocounterProgramAccount({
    account,
  })

  const count = useMemo(() => accountQuery.data?.count ?? 0, [accountQuery.data?.count])

  return accountQuery.isLoading ? (
    <span className="loading loading-spinner loading-lg"></span>
  ) : (
    <div className="card card-bordered border-base-300 border-4 text-neutral-content">
      <div className="card-body items-center text-center">
        <div className="space-y-6">
          <h2 className="card-title justify-center text-3xl cursor-pointer" onClick={() => accountQuery.refetch()}>
            {count.toString()}
          </h2>
          <div className="card-actions justify-around">
            <button
              className="btn btn-xs lg:btn-md btn-outline"
              onClick={() => incrementMutation.mutateAsync()}
              disabled={incrementMutation.isPending}
            >
              Increment
            </button>

            <button
              className="btn btn-xs lg:btn-md btn-outline"
              onClick={() => decrementMutation.mutateAsync()}
              disabled={decrementMutation.isPending}
            >
              Decrement
            </button>
          </div>
          <div className="text-center space-y-4">
            <p>
              <ExplorerLink path={`account/${account}`} label={ellipsify(account.toString())} />
            </p>
          </div>
        </div>
      </div>
    </div>
  )
}

Resources

Github: soon-counter-github
Vercel: soon-counter-live

The Overview and walkthrough of Solana Dapp

Shivam Soni — Thu, 29 Feb 2024 23:55:44 +0000

Full stake dev guide

Solana - Dapp architecture

Tech stake-:

Nextjs, Anchor, Rust, and Phantom, solana tool suite, Solana web3.js

Overview

Building an NFT Minting and Transfer DApp on Solana with Next.js, Anchor, and Rust

Welcome In this guide, we'll walk you through building a dApp (decentralized application) on the Solana blockchain for minting and transferring non-fungible tokens (NFTs). We'll utilize the following technologies:

Solana: The high-performance blockchain platform
Next.js: A popular JavaScript framework for building fast and efficient React applications
Anchor: A framework that simplifies smart contract development on Solana using Rust
Rust: A powerful and memory-safe programming language used for Solana smart contracts
Phantom: A popular Solana wallet for interacting with your dApp
Solana Tool Suite: A collection of command-line tools for interacting with the Solana network
Solana web3.js: A JavaScript library for interacting with the Solana blockchain from the front-end

What We'll Build:

Throughout this guide, we'll create a basic dApp that allows users to:

Mint their own unique NFTs: Users will be able to mint NFT.
Transfer NFTs to other users: Users will be able to securely transfer ownership of their NFTs to other Solana wallet addresses.

Ready to embark on this exciting journey into the world of Solana NFT development? Let's dive in!

The Dapp-guide code-repo available here

https://github.com/shivamSspirit/spl-tokens

Solana Dapps

Solana DApps: What Makes Them Special?

Solana dApps work like other blockchain apps but have their own unique features. Here's a simpler breakdown:

Similarities:

They're decentralized apps, just like others on blockchain networks.
They operate with decentralized governance and operation.

Differences:

Solana uses its own special blockchain technology, unlike other platforms.
Building Solana dApps requires specific tools and languages like Rust and Anchor, different from other blockchain systems.

Focus on Solana DApps:

This guide explores Solana dApps, helping you understand and create your own cool apps on this powerful blockchain platform.

Solana DApp Use Cases:

Solana dApps are applications on the Solana blockchain.
They serve purposes such as finance, gaming, trading digital assets, and buying/selling digital items.
These dApps cater to various needs, including finance, gaming, and digital markets.

Some core pillers to build solana - dapp

Foundations of Running Things in a DApp:

Solana Tools:
- Rust
- Anchor
- Node.js
- Solana DApp Scaffold

Purpose Behind This:

The Solana Tools:
- These tools help prepare for building on a distributed ledger.
- For instance, Solana CLI is essential.
- Before diving into DApps, it's crucial to understand basic Solana CLI commands.
- Getting hands-on experience with web3 wallets and some test funds in those wallets helps interact with the live Devnet blockchain.

There are various ways to start building on Solana, but here, we'll focus on:

Setting up the local system to build on the Solana Devnet cluster. (A cluster is simply a single-node replication of the blockchain.)

Checkpoint-0 check environment

Before You Begin, Install the Following Tools:

Node
Yarn
Git
Rust
Solana Tools
Anchor

Verify These Installations:

yarn -V
node --version
git --version
rustc --version
solana -V
anchor --version

Then, download the challenge to your computer and install dependencies by running:

git clone git@github.com:shivamSspirit/spl-tokens.git
cd spl-tokens
npm install (if error, use -f flag)

Now, you have an Anchor Solana DApp.

About DApp:

DApp Features:

Connect to the DApp with the Devnet network using your Solana wallet (Phantom is recommended).
Mint NFT SPL tokens
Transfer tokens to another user or friend.

NOW

After setting up Solana tools and CLI, follow these steps:

Visit: https://docs.solanalabs.com/cli/wallets/file-system
Generate your file system wallet by using:

solana keygen

This command will generate a keypair, which is an account keypair used for signing transactions.

In a blockchain development environment, we mainly build and manage transactions.
Type:

solana address

You will receive your generated wallet public key, which looks like this:

OgxvVbhxGacHb92hzxogWQgVyuq4v4NdbYmPX6Hsv5Bz

Now, you have a file system wallet ready to interact with Solana DApps.

The Development Pillars of Solana

Solana tools provide a comprehensive understanding of how Solana operates under the hood. It offers:

Wallet integration
Blockchain node replication
Low transaction costs
Faster transaction completion

With raw Solana development (the traditional approach), we focus on:

On-chain program processing
Utilizing the BPF loader

The Program Entrypoint

In the Solana runtime, only the Solana program entrypoint is visible and called.

This entrypoint accepts a generic byte array containing serialized program parameters, including the program ID, accounts, instruction data, and more. Each loader comes with its own wrapper macro, which:

Exports the raw entrypoint.
Deserializes the parameters.
Calls a user-defined instruction processing function.
Returns the result.

Parameter Deserialization

In each loader, there's a helper function that simplifies the deserialization of the program's input parameters into Rust types. The entrypoint macros then automatically invoke this deserialization helper.

Data Types

The loader's entrypoint macros invoke the program-defined instruction processor function with the following parameters:

program_id: &Pubkey,
accounts: &[AccountInfo],
instruction_data: &[u8]

NoTe-:
The program ID is the on-chain deployed program ID.

Accounts: If you're new to building on Solana, understand
that everything in Solana revolves around accounts.
Developers (users of web3) mainly manage accounts. There are
various types of accounts in Solana, which you'll grasp once
you delve deeper into the platform.

The general-purpose program instruction data that will be referenced by accounts.

Before you transition from the Ethereum ecosystem:

You need to understand that in Solana, programs (similar to smart contracts in Ethereum) separate logic from data. However, for both, we require accounts for creating logic and managing data.

Move To Modern

This is about traditional Solana development with native Rust.

Now, Armani provides us with wings by creating a super useful Solana development framework:

Anchor by Armani.

When building with native Rust, complexities arise with serializing and deserializing accounts data.

However, with Anchor, you gain access to many useful features for building Solana programs, including the capability to develop full-stack DApps using the Anchor framework.

Now root here and clone this repo

git clone git@github.com:shivamSspirit/spl-tokens.git

💡 This is an Anchor DApp architecture.

At the start, you don't need to know about all files. As we progress, we will cover them.

Initially, keep in mind these files:

The main setup for the DApp is automatically provided by Anchor.
1. app
2. programs
3. test
4. utils
5. anchor.toml
The first directory is app. This contains the client interaction with the Solana on-chain deployed program.
programs: This directory contains the Solana program that we want to build for this DApp.
test: This directory is for testing the on-chain program before deploying it to the client.
utils: This directory contains utility helper methods we need to manage DApp functionality.
anchor.toml is the DApp-runner file, which will build the DApp environment for:
- Building
- Deploying
- Testing
- Managing Solana programs.

The program we want to build for this guide is the SPL NFT mint and transfer.

You can learn more about Solana NFTs here.

As for the DApp features, let's walk through them:

Users will connect their Phantom wallet extension (compatible with Solana wallets) and switch their cluster to Devnet. Once connected, users can mint and transfer the NFT to another user.

Do you know what mint means? If not, it's important to learn.

Now, what are the important things you need to learn and be aware of?

First, from the smart contract side

As you are aware, Anchor provides us with good functionality.

It is built using Rust and abstracts some utilities in certain Rust macros and traits.

Reviewing Anchor-Compatible Solana Programs

The program will consist of three parts:

The program module
The account structs
The declare ID macro

In the program module, you will utilize accounts data and manage that data (the business logic).

For the account structs, in Anchor, we can provide a context (like an object) of accounts for better validation of accounts running the DApp, eliminating the need to provide an array of accounts.

The declare ID macro creates an ID field that stores the address of your program. This is the first code you'll see when you generate a new Anchor project on your own.

// Use this import to gain access to common Anchor features
use anchor_lang::prelude::*;

// Declare an ID for your program
declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

// Write your business logic here
#[program]
mod hello_anchor {
    use super::*;
    pub fn initialize(_ctx: Context<Initialize>) -> Result<()> {
        Ok(())
    }
}

// Validate incoming accounts here
#[derive(Accounts)]
pub struct Initialize {}

Go to anchor.toml and learn about it here.

This will generate a provider for all Anchor commands to interact with the Solana DApp.

[provider]
cluster = "devnet"                   # The cluster used for all commands.
wallet = "~/.config/solana/id.json"  # The keypair used for all commands.

You know about wallets, right? This is our filesystem wallet path. Find it in your system and put the path of your generated keypair here.

Next, we have the cluster. You also know about the Solana blockchain node (a distributed state replication). We're discussing the test file here, so Anchor allows you to build a script for testing environments in Anchor Solana DApps.

Some features you need to set up to instruct the IDL generation of the backend system on what to add or not.

Next is the programs section:

tomlCopy code
[programs.devnet]
spltokens = "3ocdHhxYMDArmD5JXrAgrw1caHE3C76HvMD1dquEhX3S"

This includes the addresses of the programs in the workspace.

The programs.devnet is used during testing on devnet where it's possible to load a program at genesis with the --bpf-program option on solana-test-validator.

NOW Dive into Program

Now, let's dive into our SPL NFT mint and transfer program.

First, ensure you've cloned and installed the dependencies on your own system. If not, set it up according to your operating system requirements.

Navigate to the program directory and then to spltokens/src/cargo.toml. This file contains the packages (dependencies) and crates you'll need to use and manage with imports in our Anchor programs.

Next, go to the lib.rs file. This serves as the entry point file for our Solana program. Here, you'll encounter three key components of an Anchor program, which you learned about earlier in this guide: imports, program ID, and program module.

Here's a snippet of what you'll see:

use anchor_lang::prelude::*;
pub mod instructions;
pub use instructions::*;

These are some imports including primitives and local module imports needed to build our program.

Next, you'll encounter our program ID:

declare_id!("3ocdHhxYMDArmD5JXrAgrw1caHE3C76HvMD1dquEhX3S");

Lastly, you'll see the program module named spltokens, which contains some instructional methods to build things around SPL tokens (both non-fungible and fungible). For our current focus on learning DApp architecture, we're interested in just two methods:

#[program]
pub mod spltokens {
    use super::*;

    pub fn mint_nft(ctx: Context<MintNFT>, name: String, symbol: String, uri: String) -> Result<()>
    {
        mint_nft::mint_nft(ctx, name, symbol, uri)
    }

    pub fn mint_token(ctx: Context<MintToken>, _decimals:u8, name: String, symbol: String, uri: String, amount: u64) -> Result<()>
    {
        mint_token::mint_token(ctx, _decimals, name, symbol, uri, amount)
    }

    pub fn transfer_tokens(ctx: Context<TransferToken>, amount: u64) -> Result<()>
    {
        transfer_token::transfer_tokens(ctx, amount)
    }
}

These methods are responsible for minting NFTs, minting tokens, and transferring tokens, respectively.

use super::*;

This will inherit and apply all under-the-hood methods for building contract business logic.

Now, let's first move to...

 pub fn mint_nft(ctx: Context<MintNFT>, name: String, symbol: String, uri: String) -> Result<()> 
    {
        mint_nft::mint_nft(ctx, name, symbol, uri)
    }

This is simply a Rust function, as in programming languages. It takes some parameters and assigns those parameters into instruction methods.

Now, let's navigate to the instruction instruction/mint_nft. Check lines 64 to 101. This section covers the account creation phase in the Anchor program. For NFTs, we need to build accounts around:

Solana native program
Token program
System program
Token metadata program
Metaplex program

We won't delve deeply into account creation in this DApp architecture guide. You'll need to experience use cases to build around accounts.

After the account phase (which takes input from the client and sends them to provide business logic to process), behind the scenes, accounts are assigned to Solana native programs to serve their required or lifetime information of that program.

Now, let's talk about the business logic:

The algorithm is as follows:

First, we receive some parameters and context.
In the first parameter, we can only provide account context.
Then, in the subsequent parameters, we put some general data and arguments that we process around NFT metadata (we won't explain what a master edition is here, just the mint and transfer mechanism).

For minting:

We need to create a CPI (Cross-Program Invocation) context to call the token program to create a token mint account to simply store the mint key and a reference for that token metadata.
We are setting up the context account and then making a CPI to the Metaplex program to create the metadata account for this NFT.

This is all about NFT minting as a developer.

💡 Now we are moving to spl token transfer

Let's discuss ins/transfer-tokens.

Here, we're simply creating another CPI context to call the token program methods for transferring SPL tokens under the token program environment

NOW we are Able to

To build and deploy your Solana program locally,

follow these steps:

Run anchor build in the root folder named spl tokens.
After a successful build, run solana config get to get your cluster configuration details.
Open another terminal in the same folder and run solana-test-validator. This will start your local cluster.

Now that you're all set to deploy your Solana program:

First, get some devnet SOL from the faucet by running solana airdrop 4.
After a successful airdrop, run anchor deploy. This will give you a program ID, which contains all the information about your program in the Solana blockchain.

Next, update the program ID in your anchor.toml and Solana program entrypoint Rust file. Then, rebuild the Solana program and redeploy it.

Now, let's discuss testing:

Navigate to the test directory in the root folder and then to the test file.
Here, we'll engage in two test cases: mint NFT and transfer NFT.
We'll set up a provider for the program and create a program API to send transactions through RPC requests to our Solana on-chain program. We'll fetch types from our Anchor build in the target folder.

Regarding the testing process:

We'll create accounts and set up UMI client wrapper for building things around token metadata.
Then, we'll curate our first transaction by calling our Solana program methods and sending accounts and required params to mint an NFT.

Moving on to the transfer test case:

We'll set up the minted token mint public key and create required ATAs (Associated Token Accounts) and destination accounts to curate and send transactions to the deployed on-chain program.

This concludes the backend setup. Now,

Let's move to our DApp client interaction:

Navigate to the app directory. This is a Solana DApp scaffold project architecture, preconfigured for building frontend using Next.js, TypeScript, and Solana-compatible wallet providers and package dependencies.
Learn about this scaffold architecture and how to integrate it with the frontend. You can explore components like the NFT mint button and NFT card.
Manage the IDL (Interface Description Language) generated by the Solana program to bridge the other side of the program: the client side.

Understanding Requirements and Similarities

How It's Similar to Anchor Tests
Remember the Anchor tests we discussed? They involved creating and transferring tokens using specific commands (RPC calls). We're going to use these same types of commands here.

Adding More Layers to Our DApp
We're enhancing our DApp by adding an extra layer. This isn't just for show – it helps display the current state of the DApp in the user interface.

First Steps: Setting Up
Before we dive in, let's make sure everything is ready:

Check your computer's Node version.
Install the Phantom extension and set up a new wallet.
Go to the settings in your wallet and switch the cluster to Devnet – this is our playground for development.

Exploring the App Directory

Now, let's get to the heart of our setup – the Next.js framework we're using. It's based on a template provided by Solana Labs. In our project, you'll see a folder named "app" – this is where the magic happens.

Inside the "app" directory, our DApp combines several technologies:
• Solidity and Solang for the contract logic
• Next.js and Tailwind for the website part
• Anchor, Zustand, and Solana Wallet Adapter for connecting everything together
We'll be focusing on specific files in this directory:
• For integrating the contract:
◦ [idl] – This file describes the interface of our contract.
◦ [contracttypes] – Here, we define the types used in our contract.
• For running the DApp state:
◦ [_app.tsx] – The main file that runs our DApp.
◦ [context] – This manages the shared data within our app.
• For the user interface and helper functions:
◦ [ui view] – The visual part of our DApp.
◦ [component] – These are the building blocks of our user interface.

Setting Up Wallet, Provider, and Program API for Transactions

Integrating the Contract:
First, when you run anchor build for your contract, Anchor creates a "target" folder for your Solana program. In this folder, you'll find the deploy script, the IDL (Interface Description Language) file, and a directory for types.

IDL is like a blueprint for our program. It describes how our program should work.
We need to connect the blockchain part of our DApp (which runs in its own special environment) to the frontend (which uses different tools and languages). The IDL file acts as a bridge, using RPC protocols to make this connection.

RPC (Remote Procedure Call) is a set of methods we use to send requests to the Solana network.
The IDL file includes all the instructions and the program ID. The "types" directory gives us special Anchor types for sending these RPC calls.
Setting Up the Cluster and Wallet

To connect everything, we need:

A cluster, which is like a specific area of the blockchain network where we send our transactions.
A wallet for interacting with the DApp, which signs transactions and provides a public key.

By combining these, we set up an Anchor provider, which simplifies integrating the contract.
Using Wallet and Contexts

In our context directory, we define certain contexts and export them for use in other parts of our DApp. We need the network (our cluster) and the wallet (using Solana Wallet Adapter) for this. These are already set up, with configurations in their respective files.

In Next.js _app.tsx file

We use a main context provider in our Next.js _app file. Once we have the wallet and connection ready, we move to the next step.
Getting the Program API:
In the mintNftbutton component, we start by importing our contract's IDL.

import idl from "../../idl.json";

We then establish a connection, configure the wallet, and import necessary methods from various packages.

Set up the program id (the ID of our deployed Solana program).

const programId = new PublicKey(idl.metadata.address);

Use these hooks to access the connection and wallet states.

const { connection } = useConnection();
const wallet = useWallet();
const { publicKey, sendTransaction } = useWallet();```



Acquiring the Program API:
Create a provider with `new AnchorProvider(connection, wallet as any, opts);` using the wallet and connection. Then use the Anchor Program API to create an instance of our Solana program API.



```tsx
const getProgram = () => {
    const provider = new AnchorProvider(connection, wallet as any, opts);
    const program = new Program(idl as Idl, programId, provider);
    return program;
};

Generating an RPC Call
Now, you can make an RPC call with the program:

const tx = await program.methods
        .mintNft(MetaData.name, MetaData.symbol, MetaData.uri)
        .accounts({
          signer: wallet.publicKey,
          mint: mintKeypair.publicKey,
          associatedTokenAccount,
          metadataAccount,
          masterEditionAccount,
          tokenProgram: TOKEN_PROGRAM_ID,
          associatedTokenProgram: ASSOCIATED_TOKEN_PROGRAM_ID,
          tokenMetadataProgram: MPL_TOKEN_METADATA_PROGRAM_ID,
          systemProgram: anchor.web3.SystemProgram.programId,
          rent: anchor.web3.SYSVAR_RENT_PUBKEY,
        })
        .signers([mintKeypair])
        .rpc();

This is similar to a function call in rust:

  pub fn mint_nft(ctx: Context<MintNFT>, name: String, symbol: String, uri: String) -> Result<()> 
    {
        mint_nft::mint_nft(ctx, name, symbol, uri)
    }

Remember, these operations are asynchronous because we're using Solana's Web3 JS.

we can use same setup for build our next instruction to transfer nft to another solana wallet

like this

const tx = await program.methods
.transferTokens(new BN(1))
.accounts({
from: publicKey,
fromAta: sellerTokenAccount,
toAta: buyerTokenAccount,
tokenProgram: TOKEN_PROGRAM_ID
}).rpc({ skipPreflight: true });

How you can use the Dapp-:

Go to app dir

Start the project:

npm run dev

Open http://localhost:3000 with your browser to see the DApp.

Using the DAPP

Connect your wallet to the DAPP by clicking on the "Select Wallet" button.

You can switch the network of the dapp from the header.

Now click on Mint NFT, once you sign the transaction a Token Account will be created for the NFT and NFT will be minted in your wallet.

You can see the minted NFT and the NFT details on the screen

To transfer the NFT to another wallet, enter the wallet address in the input box, click SEND, and after signing the transaction your NFT will be transferred to another wallet.

After transfer the screen will look like this

Creating the similar DApp

To create the similar Dapp you need to have pre knowledge of react and basic of spl token and solana NFTs.
You can use the code from the repository and modify it according to your need.
You can also use the code from the repository and deploy it on vercel or netlify to create your own DApp.

How to Transfer Solana Tokens with Solidity

Shivam Soni — Fri, 15 Sep 2023 18:57:38 +0000

Transfer token via cpi(solang-series part-3)

Introduction

Greetings to the fourth instalment of our series! here, we're continuing our exploration of making solana programs. We're still using the solidity language, which is compiled by the solang compiler.

In the previous articles, we laid the foundation by understanding how solana's high-performance blockchain merges with the familiar solidity syntax. we learned how to build smart contracts and make cross program invocation easily.

In this article, we will explore the intriguing concept of cross program invocation. our focus will be on developing a program responsible for transferring tokens between different accounts through cross program invocation.

By the end of this tutorial, you will gain insights into the concept of composability in solana programming. We will discuss the process of transferring tokens between accounts.

Prerequisite

Prior to proceeding, it would be beneficial if you have reviewed the previous articles in this series. You can find them at this link: solang-series.

The code for this project is located here.
You can clone it(instruction provide in readme file) or use same repo spl-token-minter program.

Setup development environment using this link

Here's what you're gonna learn:

Table Of Content

Recap Of Previous Articles
Transfer spl tokens
Associated token accounts in solana
Upgrading spl-token-minter program by implementing transfer gold token to another account via cpi
- Solidity code
- Typescript test
Building, deploying and testing
Conclusion
Further resources

Recap Of Previous Articles

In our earlier articles, we've discussed different aspects of Solana programs. We explained how Solana programs work, talked about using Invoke CPI to make switch power programs, and explored the idea of composability in Solana programs. We believe these articles have helped you understand how to develop Solana programs better.

In this article, we will take a deeper look at transferring our gold token to another associated token account by utilizing the Invoke CPI method.

Transfer spl tokens

First understand the analozy

I am Shivam,

And I want to send some of the gold tokens we minted (in spl-token-minter program) to my friend, Justin.

To get started, we need token accounts linked to the same mint, specifically the gold token mint. The actual token transfer happens from my account to Justin's. To make this transfer smoother, we need to create a brand-new associated token account for Justin. This step ensures that the transfer takes place seamlessly from my account to Justin's.

But here's the twist - this isn't your typical wallet-to-wallet transfer. It stands apart from the usual Sol transfer process. Why? Because in this case, the system program takes charge of the transaction, eliminating the need to create another associated token account to hold the Sol that's being transferred.

You can see this analogy in below image

We will now proceed to interact with the Associated Token Account.

Associated token accounts in solana

Associated Token Accounts (ATAs) provide a simple and reliable way to find the token account associated with a specific public key and token mint. This makes it easier to manage token transfers and interactions within programs.

Managing multiple token accounts under the same mint can be complex and confusing.

Token program offers a way to generate token account keys based on a user's main System account address and the token mint address. This makes it easier for users to create a primary token account for each token they own, for simplifying management.

These specialized accounts are called Associated Token Accounts (ATAs).

This program establishes a standard and provides a mechanism to map a user's wallet address with their associated token accounts.

See below image

In this image, we're creating two linked token accounts for the Gold Token. We do this by using The Gold Token Mint and the owners' addresses. This process is essentially about generating a Program Derived Address (PDA) from the user's wallet and the Gold Token Mint.

We will learn about pda in next article

Some key take-away for ata

Each Associated Token Account (ATA) is also a Program Derived Address (PDA).

Every Associated Token Account (ATA) is also a Token Account.

We can create associate token account for shivam in typescript using getOrCreateAssociatedTokenAccount method provide by spl-token module

const tokenAccount = await getOrCreateAssociatedTokenAccount(
    connection,// web3 connection
    wallet.payer, // payer for the account
    mintKeypair.publicKey, // mint for the gold token
    wallet.publicKey // owner(shivam)
  );

getOrCreateAssociatedTokenAccount use to get the Token Account associated with a given address or create it if it doesn't exist and return a public key for gold token account

Same for justin to hold some gold token we need to change owner to justin and create brand new ata for him

like this

const receipient = anchor.web3.Keypair.generate(); // Random key generator

const receipientTokenAccount = await getOrCreateAssociatedTokenAccount(
    connection,   // web3 connection
    wallet.payer, // payer for the account
    mintKeypair.publicKey, // mint for the gold token
    receipient.publicKey // owner(justin)
  );

Upgrading spl-token-minter program by implementing transfer gold token to another account via cpi

In our spl-token-minter program we mint some gold token and transfer to our ata

Now we want to transfer some gold token to another account(justin’s ata).

We're using the same code for our project. It's the same code for minting, and we've added the transfer function in both the Solidity program and the TypeScript test file.

Now open our code directory in vscode and move to solidity folder

In transfergold.sol file we are adding a transfer function under mintTo function

// Transfer tokens from one token account to another via Cross Program Invocation to Token Program
function transferTokens(
address from, // token account to transfer from
address to, // token account to transfer to
uint64 amount // amount of gold to transfer
) public {
SplToken.TokenAccountData from_data = SplToken.get_token_account_data(from);
SplToken.transfer(from, to, from_data.owner, amount);
}

let’s break it down

We've made a transferTokens function that needs three things to work:

The sender's token account with Gold Tokens.
The recipient's account with the Gold Token Mint.
The amount of Gold Tokens to transfer.

Now on first line of function body we retrive the shivam’s token account data by make a call to SplToken.get_token_account_data(from).

On the next line

SplToken.transfer function performs the actual gold token transfer between the specified ATAs.

This function requires the following parameters:

from: The account from which we're transferring tokens.
to: The account to which we're transferring tokens.
owner: The public key of the owner of the from account.
amount: The amount of tokens to transfer.

It executes a cross-program invocation to the SPL Token Library using the transfer CPI (Cross-Program Invocation).

Now see in below image

We transferred the amount of Gold Tokens from Shivam's Associated Token Account (ATA) to Justin's ATA using CPI (Cross-Program Invocation).

Now, we're going to write the test for transferring Gold Tokens.

Open the transfersol.ts test file and add this test right after the mint tokens to our wallet test.

// transfer token to another wallet via cpi

it("Transfer some tokens to another wallet!", async () => {
  // Wallet's associated token account address for mint
  const tokenAccount = await getOrCreateAssociatedTokenAccount(
    connection,
    wallet.payer, // payer
    mintKeypair.publicKey, // mint
    wallet.publicKey // owner(shivam)
  );

  const receipient = anchor.web3.Keypair.generate();
  const receipientTokenAccount = await getOrCreateAssociatedTokenAccount(
    connection,
    wallet.payer, // payer
    mintKeypair.publicKey, // mint account
    receipient.publicKey // owner(justin) account
  );

  console.log("receipientTokenAccount",receipientTokenAccount)

  const tx = await program.methods
    .transferTokens(
      tokenAccount.address,
      receipientTokenAccount.address,
      new anchor.BN(54000000000)
    )
    .accounts({ dataAccount: dataAccount.publicKey })
    .remainingAccounts([
      {
        pubkey: wallet.publicKey,
        isWritable: true,
        isSigner: true,
      },
      {
        pubkey: mintKeypair.publicKey,
        isWritable: false,
        isSigner: false,
      },
      {
        pubkey: tokenAccount.address,
        isWritable: true,
        isSigner: false,
      },
      {
        pubkey: receipientTokenAccount.address,
        isWritable: true,
        isSigner: false,
      },
    ])
    .rpc();
  console.log("Your transaction signature", tx);

 const recepienttokenAmount = (await getAccount(connection, receipientTokenAccount.address)).amount;
  console.log("recipienttokenAmount", recepienttokenAmount);
  let tokens = Number(recepienttokenAmount);

  assert.equal(tokens / LAMPORTS_PER_SOL, 54);
});

let’s break it down

First, we create Shivam's Associated Token Account (ATA) using this.

const tokenAccount = await getOrCreateAssociatedTokenAccount(
    connection,
    wallet.payer, // payer
    mintKeypair.publicKey, // mint
    wallet.publicKey // owner(shivam)
  );

We use the getOrCreateAssociatedTokenAccount method from the SPL Token library to create an associated token account.

We're using the same Gold Token Mint for this, and the owner is our wallet.

Next, we create a new keypair for the recipient, which is Justin in our case.

const receipient = anchor.web3.Keypair.generate();

After we create justin’s ata using this

const receipientTokenAccount = await getOrCreateAssociatedTokenAccount(
    connection,
    wallet.payer, // payer
    mintKeypair.publicKey, // mint account
    receipient.publicKey // owner(justin) account
  );

By using same gold token mint and set owner as receipient

Next, we start a transaction using the transferTokens method provided by the Solidity program. We give it the necessary token accounts and specify the amount of Gold Tokens we want to transfer.

Then, we provide the data account and other required accounts for these cross-program invocation (CPI) calls. Finally, we confirm our test by ensuring that Justin's ATA contains 54 Gold Tokens.

Next we move to building, deploying and testing our program

Building

Open the terminal in the root directory of your project and enter the following command.

anchor build

This command will generate a target folder in the project root and generate idl and types of our solana program to interact with the client side using rpc methods.

Now open a new terminal and check our configuration By writing this command

solana config get

After running this you will see something like this

Config File: ~/.config/solana/cli/config.yml
RPC URL: https://api.devnet.solana.com
WebSocket URL: wss://api.devnet.solana.com/ (computed)
Keypair Path: ~/.config/solana/id.json
Commitment: confirmed

Devnet is the RPC URL, and my wallet's default location is at keypairpath. Make sure you Generate a wallet keypair for deploying the program.

You can set devnet for cluster

By writing this command

solana config set --url https://api.devnet.solana.com

By writing this command you can generate a new keypair

solana-keygen new

Now you have a wallet

You can check the address(pubkey) and balance of this account using these commands

solana address
solana balance

If you have some devnet sol then it is okay for deployment if it is not then Get some devnet airdrop by writing this command

solana airdrop 4

Deploying

Deploying the program by opening terminal in a new tab and starting network cluster by writing this command

solana-test-validator

This will start a devnet cluster in the system next deploy program using

anchor deploy

you will get something like this

Deploying cluster: https://api.devnet.solana.com
Upgrade authority: ~/.config/solana/id.json
Deploying program "spl_token_minter"...
Program path: /Users/shivamsoni/Desktop/composability/transfergold/transfergold/target/deploy/spl_token_minter.so...
Program Id: EhJE9AUd8ybeRoTz79QHrxG6j3Z2hWX22g4SCSCKmGwE

Deploy success

Now our both program is on chain (devnet)

We get program id of our deployed program on the chain

Now grab this program id and change it in our program (solidity file) as well as anchor.toml file After pasting the new program id to both files

Build the program again with the command

anchor build

Testing Program

Before testing check dependencies and run:

yarn install
npm install

Now we run the test using this command

anchor test

After this, you will see something like this

spl-token-minter
Your transaction signature 5eMMtzhkGq8sZFNkLir3i7KFCua6b9itjym7mn1Gm2KBTPDjUL6p27qMba8GynZwVfvEBynF2rc57qBrtR3XZdiJ
    ✔ Is initialized! (2311ms)
Your transaction signature 38opFwF4DgQyXmtUwKgx2NDoTGsCTaWJzLqcRk49BS4x1a3hj8MyHSAn89cRvEaf6p62DVKX1u9tBzXtxSK861u9
    ✔ Create an SPL Token! (1540ms)
tokenAmount 199000000000n
    ✔ Mint some tokens to your wallet! (1794ms)
Your transaction signature 36aRV86YKuSab4iMcrBJbgcF2QskVshnFC5fQGDdoXoJm7qnpwAKJ7coXTM9ia2JNDPnr15FTvALtHT9DzvhCksQ
recipienttokenAmount 54000000000n
    ✔ Transfer some tokens to another wallet! (2814ms)


  4 passing (8s)

✨  Done in 12.26s.

And that's it! We've successfully made a CPI call to transfer gold token from our account to jsutin’s account.

Here is the solana explorer demo

Conclusion

To wrap up our article on How to Transfer Solana Tokens with Solidity, we've expanded on our previous discussion of cross-program invocation. This time, we've dived into the details of Solana token transfers and explained how Associated Token Accounts play a crucial role in making these transfers happen on the Solana network.

In the last part, we put this knowledge into action by performing a transfer using the CPI method for the Gold Tokens that we minted in our SPL Token program.

In next article we will learn about program derived address

Further resources

helius spl token transfer
associated token account
sol dev
solana cookbook
solana token program

Building a CPI-Enabled Flip Program with Solidity on Solana

Shivam Soni — Sat, 26 Aug 2023 20:44:08 +0000

Introduction

Greetings to the third instalment of our series! Here, we're continuing our exploration of making Solana programs. We're still using the Solidity language, which compiles by the Solang compiler.

In previous articles, we built the foundation by explaining how Solana's high-performance blockchain combines with the familiar solidity syntax. We learned how to build smart contracts and make fungible tokens.

In this article, we're going to delve into a fascinating idea called program composition on Solana. We will discuss cross-program invocation, an advanced technique that allows different Solana programs to interact. Our primary goal is to explain Solana program composition using various program examples and coordinating many Solana programs.

By the end of this tutorial, you will gain a comprehensive understanding of Solana programming's composability concept. We will explore how programs interact, share data, and collaborate, providing you with valuable insights into the Solana ecosystem.

This tutorial contains two-part

Theory part of composability(Table of contents 1-7)
Practical part of cross-program invocation(Table of contents 8-12)

Prerequisite

Before proceeding, it would be beneficial if you have reviewed the previous articles in this series. You can find them at this link:solana-solang-guide.

The code for the project is located here

Here's what you're gonna learn:

Table Of Content

Recap Of Previous Articles
Composability
Composability of programs(within Solana and Ethereum)
- Composibility of programs in solana via CPI and PDA
- Composability of contracts in ethereum
Implementing the invoke cpi technique.
System setup
Program Design
Writing program
Writing test
Setting configuration (for building, deploying and testing program)
Building
Deploying
Testing
Conclusion
Further resources

Recap Of Previous Articles

In our earlier articles, we covered topics like Solana programs, accounts, instructions, transactions, SPL tokens, and JSON RPC calls. We trust these pieces helped you grasp the process of building Solana programs.

In Solana, accounts are at the core of everything.

In our upcoming articles, we'll dive into the idea of composability in Solana programs. We'll talk about development techniques like cross-program invocation and the use of program-derived addresses(PDA). To make things clearer, We'll handle business using Solana accounts to create sample programs that show these concepts.

These articles aim to provide you with practical exposure to the composability aspect of Solana programs.

Now, let's delve deeper into the composability of Solana programs in this article.

Composability

Composability is a concept that might ring a bell for Web2 developers. It's all about using software parts that fit into various apps. This concept has existed since the advent of open-source technology and held significant importance during the early days of the Internet. While Web2 got a boost from this, Web3 relies on it even more to improve user experiences and spark fresh ideas.

In this article, we're discussing how composability functions and why it's beneficial for Web3. Think of it as building with blocks – developers can combine different pieces to make something new without starting from scratch.

Web3, the updated Internet version, is reintroducing composability. It allows various blockchain apps, such as trading platforms and decentralized apps, to collaborate. It's like having different tools in a single toolbox.

In Web3, composability occurs when parts of blockchain apps link up, either via smart contracts or project assembly.

Composibility Of Programs(within solana and ethereum)

In Solana, think of composability as being like Functional Programming (FP). It's like having separate roles for a smart contract and the data it uses. Unlike Ethereum, where each token has its special contract, Solana uses something called spl-token to control all tokens in one place.

Ethereum's composability is akin to interface-based inheritance in traditional Object Oriented Programming (OOP). This means that if something acts like a particular entity, it's treated as such. In Ethereum, you expand on established standards like ERC-20 and implement the necessary functions.

When dealing with Solana, transactions centre around Solana accounts, which form the core of the entire Solana development Ecosystem..

On Ethereum, data lives right inside the smart contract. But in Solana, data is spread out across many atomic accounts. Even though it might sound a bit complex, this setup lets Solana do many things at the same time. Transactions that need to look at an account, without changing it, can all happen together.

In Solana's programming universe, different programs can talk to each other using something called cross-program invocation and PDA. One program can tell another program what to do. The starting program takes a little break while the other program does its thing.

In Ethereum When you call a contract code from another contract, the msg.sender(who is calling this contract) will refer to the address of our contract.

Here's a simplified comparison table between Solana and Ethereum composability:

Aspect	Solana	Ethereum
Composability Approach	Like Functional Programming (FP)	Interface-based Inheritance (OOP)
Token Management	Centralized through spl-token	Each token has its own contract (e.g., ERC-20)
Transaction Foundation	Centered around Solana accounts	Focuses on smart contract interaction
Data Storage	Data distributed across atomic accounts	Data stored within the smart contract
Concurrency Advantage	Supports simultaneous task execution	Limited parallel processing
Inter-program Comm.	Cross-program invocation and PDA	Interface and inheritance

Composibility of programs in solana via CPI and PDA

Cross-Program Invocation (CPI) is key to ensuring Solana programs collaborate , this enables the composability of Solana programs. It enables one program to call another, establishing a smooth connection. It's like how any user can communicate with a program using JSON RPC. This intelligent feature simplifies the expansive Solana system into a unified, tool for developers.

Calling Programs with CPIs

A Cross-Program Invocation (CPI) is when one program calls another program, aiming at a certain instruction in that program. CPIs allow the calling program to extend its signer privileges to the callee program.
This is achieved using instructions like invoke or invoke_signed. The latter is employed when programs have to give their signatures for Program-Derived Addresses (PDAs, which we'll cover in this series).

CPIs are what make Solana programs work together . Any public instruction of a program can be triggered by another program using a CPI. This makes different programs within the Solana system work together like clockwork.

Even though we can't control the accounts and data that are sent to a program, we should always double-check the information we pass into a CPI. This is crucial for keeping the program secure and working as expected.

Don't worry if the concept of one program calling another seems complex – it's quite straightforward. Think of it as giving directions using an "Instruction."

To make a CPI, you must specify and construct an instruction on the program being invoked and supply a list of accounts necessary for that instruction. If a PDA is required as a signer, the signers_seeds must also be provided when using invoke_signed.

To make this work, the Instruction needs three things: the program ID of the program you're calling, information(data) that the program can understand, and a list of "AccountInfos." These AccountInfos are like the accounts the program you're calling will use see diagram below.

Here's the neat part: the calling program receives these AccountInfos from the system at the beginning. This means that any account the program you're calling requires must also be needed by the calling program. It's like a chain reaction – one thing leads to another.

Oh, and that program ID we mentioned? The program doing the calling needs to get it in the same way. It's a rule everyone follows.

Imagine this instruction as a recipe – you gather these elements, and then something incredible unfolds. It's like a sort of magic that's built into the Solana system.

In this tutorial, you'll discover how to use invoke CPI in Solang when a program-derived address (PDA) isn't required for the signer.

Composability of contracts in Ethereum

Smart contracts on Ethereum work like public APIs – they're like building blocks that can be used without starting from scratch. For instance, you can use the ready-made smart contracts from projects like Uniswap, a decentralized exchange, to simplify tasks in your app.

How Composability Works in Ethereum

Ethereum's smart contracts are open to everyone, enhancing app development. Composability relies on three aspects:

Modularity: Each smart contract has a specific role.
Autonomy: Smart contracts can function .
Discoverability: Anyone can use and modify smart contracts.

Advantages of Composability:

Quicker Development: Developers avoid starting from scratch.
Enhanced Innovation: Experimenting with new ideas becomes simpler.
User-Friendly: Apps collaborate seamlessly.

An Example:

Imagine a situation where a token has a higher value on one exchange than another. If you have enough money, you can buy it on the cheaper exchange and sell it on the more expensive one to make a profit. But if you don't have enough money, you can use something called a flash loan. This kind of loan lets you borrow assets without having to put up anything as security. With flash loans, you can do complicated things in one move, like buying and selling tokens to make money. And all this is possible because smart contracts are working together.

Using invoke cpi

How to use invoke to make cpi

The invoke function is used when making a CPI that does not need any PDAs to act as signers. When making CPIs, the Solana runtime extends the original signature passed into a program to the callee program.

When you're calling a program, you might find a library with helpful functions to create the Instruction. People and groups often make these libraries available, making it easier to call their programs.

The definition of the Instruction type required for a CPI includes:

invoke() is built into Solana's runtime and handles routing the given instruction to another program via the instruction's program_id field.
accounts - a list of AccountInfo corresponding to all the accounts accessed by the other program
data - instruction data that will be understood by the other program

To use invoke and invoke_signed, a list of account_infos is also required. Like the list of AccountMeta in the instructions, you need to include all the AccountInfo of each account that the program you're calling will read from or write to.

Since programs can only get AccountInfo values from the runtime at the program's entry point, any account that the called program needs must be needed by the calling program and provided by its caller. This also applies to the program ID of the called program.

In below code block see how cpi are creating to leverProgram by calling their switchPower function

function pullLever(address dataAccount, string name) public {
// The account required by the switchPower instruction.
// This is the data account created by the lever program (not this program), which stores the state of the switch.
AccountMeta[1] metas = [
AccountMeta({pubkey: dataAccount, is_writable: true, is_signer: false})
];

    // The data required by the switchPower instruction.
    string instructionData = name;

    // Invoke the switchPower instruction on the lever program.
    leverProgram.switchPower{accounts: metas}(instructionData);
}

In this section of code, we're making a pullLever function that takes dataAccount and name as inputs. This function sets up the accountMeta for the data account of the lever program. It then puts the name into the instruction Data. Finally, we use cpi (cross-program-invocation) to call the switchPower method in the leverProgram(then a CPI is constructed, and the compiler will generate a invoke()), providing the necessary accountInfos and instructionData.

When creating a CPI, use the following syntax to specify the AccountMeta for each account:

AccountMeta::new - indicates writable
AccountMeta::new_readonly - indicates not writable
(pubkey, true) - indicates account is signer
(pubkey, false) - indicates the account is not signer

You usually make the Instruction within the calling program, but you can also get it from an external source through deserialization.

Shared data validation

The AccountInfo structures given to this function hold data that the runtime uses . This data is copied to and from the memory space of the program being called.

Call Depth

Cross-program invocations let programs call other programs , but currently, this is limited to a depth of 4.

Reentrancy

Currently, reentrancy is only allowed in cases of direct self-recursion, and it's limited to a set depth. This limitation is in place to prevent scenarios where a program could call another program from an interim state without knowing it might be called back. Direct recursion ensures that the program has complete control over its state when it's called back.

System setup

First note: We are utilizing the same system setup of our project dependency from previous articles
that is located here

We're kicking off by using a project initialization command.

anchor init cpiinvoke --solidity

After going to the project directory

cd cpiinvoke

Run the following command to open the vscode

code .

We already discussed all project files in our previous article
so go to the solidity directory and make two files
hand.sol(this is the caller)
and
lever.sol(this is callee)

Program Design

We're making a flip program that can turn on or off power using a boolean type. To do this, we need to create two programs: Program A (the caller) and Program B (the callee).
Program A is in charge of calling Program B using cross-program invocation (CPI). Program B is the one being called from Program A.

Writing program

Now, let's start by creating the program that will be called. Navigate to the solidity directory within our project and open a created file called lever.sol. Then, insert the following code into this file:

@program_id("J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh")
contract lever {
    // Switch state
    bool private isOn = true;

    @payer(payer) // payer for the data account
    constructor() {}

    // Switch the power on or off
    function switchPower(string name) public {
        // Flip the switch
        isOn = !isOn;

        // Print the name of the person who pulled the switch
        print("{:} is pulling the power switch!".format(name));

        // Print the current state of the switch
        if (isOn){
            print("The power is now on.");
        } else {
            print("The power is now off!");
        }
    }

    // Get the current state of the switch
    function get() public view returns (bool) {
        return isOn;
    }
}

Let's break this down:

We're familiar with the program ID, payer, contract, and construction annotation from the previous articles in this series.

Now, we'll begin by defining the switch state.

 // Switch state
    bool private isOn = true;

Here, bool is the data type, private is used to set access limits, and isOn is the name of a variable with the value true.

Next, we create a function called switchPower.

function switchPower(string name) public {
        // Flip the switch
        isOn = !isOn;

        // Print the name of the person who pulled the switch
        print("{:} is pulling the power switch!".format(name));

        // Print the current state of the switch
        if (isOn){
            print("The power is now on.");
        } else {
            print("The power is now off!");
        }
    }

This function takes a parameter called name, which is of string type, and it's visible to the public. Inside the function, it flips the value of isOn – if it was true, now it becomes false, and vice versa. After that, it prints the name of the person who triggered the switch.

The function uses a basic programming concept, a conditional statement with an if-else block, to check if the power is on (true) or off (false) and prints .

// Print the current state of the switch
        if (isOn){
            print("The power is now on.");
        } else {
            print("The power is now off!");
        }

We expand our contract by adding another function. This function's role is to fetch the present state of the switch. It does this by having a view visibility, allowing anyone to read from it.

// Get the current state of the switch
    function get() public view returns (bool) {
        return isOn;
    }

That's it. This is our callee program, which receives cross-program invocation (CPI) instructions from the caller program. It then calls the switchPower function to handle and update the state of the switch.

Let's now switch to our caller program.

In the solidity directory, open a created file called hand.sol and copy-paste this block of code.

import "solana";

// Interface to the lever program.
leverInterface constant leverProgram = leverInterface(address'J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh');
interface leverInterface {
    function switchPower(string name) external;
}

@program_id("7zJ7E8uZccmCH89eykH8yZsB6G685nbz7sSq8N9sZTtq")
contract hand {

    // Creating a data account is required by Solang, but the account is not used in this example.
    // We only interact with the lever program.
    @payer(payer) // payer for the data account
    constructor() {}

    // "Pull the lever" by calling the switchPower instruction on the lever program via a Cross Program Invocation.

}

Let's break this down:

We start by importing the Solana library.

Then, we build an interface for our callee (lever, or Program B) within our caller program (hand, or Program A).

Interface

When you flip a light switch, the light goes on.
You do not care how the switch turns the light on.
You just care that “it does turn the light on”.

Next, we're required to perform a Cross-Program Invocation (CPI) to the lever program, live at address J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh. This process leads us to create the interface for the callee program.

interface leverInterface {
    function switchPower(string name) external;
}

In this step, we're crafting an interface for the lever program. We're including the switchPower function's entry point into this interface as an external function.

Afterwards, we set the program ID. In Solana contract development, programs are typically deployed to specific accounts. This account can be indicated in the source code using an annotation, specifically @program_id.

Let's begin with the hand contract. We're creating a data account, a necessity in Solang, although it remains unused in this program. Our interaction is solely with the lever program.

For this copy and paste pullLever function below constructor in hand.sol

// "Pull the lever" by calling the switchPower instruction on the lever program via a Cross Program Invocation.
    function pullLever(address dataAccount, string name) public {
        // The account required by the switchPower instruction.
        // This is the data account created by the lever program (not this program), which stores the state of the switch.
        AccountMeta[1] metas = [
            AccountMeta({pubkey: dataAccount, is_writable: true, is_signer: false})
        ];

        // The data required by the switchPower instruction.
        string instructionData = name;

        // Invoke the switchPower instruction on the lever program.
        leverProgram.switchPower{accounts: metas}(instructionData);
    }

The pullLever function handles receiving arguments from the caller as an instruction. It then sets the instruction data and triggers the lever by invoking the switchPower instruction on the lever program through a Cross-Program Invocation (CPI Invoke).

During an external call (also known as CPI), the AccountMeta defines the accounts that need to be handed over to the called program.

instruction for the CPI to be processed by the callee in the lever program.

This is accountmeta information

address pubkey

The address (or public key) of the account

bool is_writable

Can the callee write to this account

bool is_signer

AccountMeta[1] metas = [
AccountMeta({pubkey: dataAccount, is_writable: true, is_signer: false})
];

NOTE-:

For those familiar with Anchor Rust development, you're likely already acquainted with CPI (Cross-Program Invocation), but when working with Solang, things are a bit different. Unlike Anchor Rust, Solang doesn't have specific methods for CPI. Instead, if you use the syntax <address>.call(), a CPI is automatically constructed for you. The compiler takes care of generating the invoke or invoke_signed for you.

Here's an example:
leverInterface constant leverProgram = leverInterface(address'J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh');
This code allows you to perform a CPI to the lever program residing at address J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh.

Now, when you have:
leverProgram.switchPower{accounts: metas}(instructionData);
A CPI is constructed automatically, and the compiler generates an invoke() for this operation. This simplifies the process of working with CPI when using Solang.

This is how we achieve composability in Solana and Solang – by utilizing Cross-Program Invocation (CPI).

In our next articles of this series, we will explore how to do cpi with invoke_signed(that consumes PDA)

Writing test

Start by going into the test file and removing all the existing code. Then, replace it with this block of code.

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { Lever } from "../target/types/lever";
import { Hand } from "../target/types/hand";

describe("cross-program-invocation", () => {
  // Configure the client to use the local cluster.
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);

  // Generate a new keypair for the data accounts for each program
  const dataAccountLever = anchor.web3.Keypair.generate();
  const dataAccountHand = anchor.web3.Keypair.generate();
  const wallet = provider.wallet;

  // The lever program and hand program
  const leverProgram = anchor.workspace.Lever as Program<Lever>;
  const handProgram = anchor.workspace.Hand as Program<Hand>;

  it("Initialize the lever!", async () => {
    // Initialize data account for the lever program
    const tx = await leverProgram.methods
      .new()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .signers([dataAccountLever])
      .rpc();
    console.log("Your transaction signature", tx);

    // Fetch the state of the data account
    const val = await leverProgram.methods
      .get()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .view();

    console.log("State:", val);
  });

  it("Pull the lever!", async () => {
    // Initialize data account for the hand program
    // This is required by Solang, but the account is not used
    const tx = await handProgram.methods
      .new()
      .accounts({ dataAccount: dataAccountHand.publicKey })
      .signers([dataAccountHand])
      .rpc();
    console.log("Your transaction signature", tx);

    // Call the pullLever instruction on the hand program, which invokes the lever program via CPI
    const tx2 = await handProgram.methods
      .pullLever(dataAccountLever.publicKey, "Chris")
      .accounts({ dataAccount: dataAccountHand.publicKey })
      .remainingAccounts([
        {
          pubkey: dataAccountLever.publicKey, // The lever program's data account, which stores the state
          isWritable: true,
          isSigner: false,
        },
        {
          pubkey: leverProgram.programId, // The lever program's program ID
          isWritable: false,
          isSigner: false,
        },
      ])
      .rpc({ skipPreflight: true });
    console.log("Your transaction signature", tx2);

    // Fetch the state of the data account
    const val = await leverProgram.methods
      .get()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .view();

    console.log("State:", val);
  });

  it("Pull it again!", async () => {
    // Call the pullLever instruction on the hand program, which invokes the lever program via CPI
    const tx = await handProgram.methods
      .pullLever(dataAccountLever.publicKey, "Ashley")
      .accounts({ dataAccount: dataAccountHand.publicKey })
      .remainingAccounts([
        {
          pubkey: dataAccountLever.publicKey, // The lever program's data account, which stores the state
          isWritable: true,
          isSigner: false,
        },
        {
          pubkey: leverProgram.programId, // The lever program's program ID
          isWritable: false,
          isSigner: false,
        },
      ])
      .rpc({ skipPreflight: true });

    console.log("Your transaction signature", tx);

    // Fetch the state of the data account
    const val = await leverProgram.methods
      .get()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .view();

    console.log("State:", val);
  });
});

Let's break this down:

Begin by importing the necessary dependencies and types for both of our programs. This is crucial for managing tests that involve flipping the switch state, where Program A calls the "switchPower" function through cross-program invocation (CPI).

Then, we describe the test for the Cross-Program Invocation (CPI).

describe("cross-program-invocation", () => {

}

In this part, we'll talk about and test how the "cpi" program works. We'll write different test cases, make assertions, and set expectations to make sure the program behaves correctly.

For this, you need to first set the Requierments for the test

Let’s write this

// Configure the client to use the local cluster.
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);

  // Generate a new keypair for the data accounts for each program
  const dataAccountLever = anchor.web3.Keypair.generate();
  const dataAccountHand = anchor.web3.Keypair.generate();
  const wallet = provider.wallet;

  // The lever program and hand program
  const leverProgram = anchor.workspace.Lever as Program<Lever>;
  const handProgram = anchor.workspace.Hand as Program<Hand>;

Here we configure and start the setup for testing our cross-program-invocation Solana program.

Configuration and Provider Setup: First, we connect to the local cluster and set up the provider using AnchorProvider.env(). This provider is then assigned with anchor.setProvider(provider) The Provider is an abstraction of a connection to the Solana network, typically consisting of a Connection, Wallet, and a preflight commitment.
Generating Key Pairs: To store the program's state, we create a new data account using a key pair . Here we Generate a new keypair for the data accounts for each program. We set up wallet variables too.
Initializing the Program: We use anchor.workspace.Lever and anchor.workspace.Hand to make an instance of the program as Program. This prepares both program from the workspace, The program is an abstraction that combines the Provider, idl, and the programID (which is generated when the program is built) and allows us to call RPC methods against our program.

Now, let's initialize the data account for the lever program.

it("Initialize the lever!", async () => {
    // Initialize data account for the lever program
    const tx = await leverProgram.methods
      .new()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .signers([dataAccountLever])
      .rpc();
    console.log("Your transaction signature", tx);

    // Fetch the state of the data account
    const val = await leverProgram.methods
      .get()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .view();

    console.log("State:", val);
  });

Here, we start by initializing the test and creating a transaction to establish a data account for the lever program. This is done using the following steps:

const tx = await leverProgram.methods
      .new()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .signers([dataAccountLever])
      .rpc();
    console.log("Your transaction signature", tx);

Afterwards, we retrieve the current state value using this approach.

// Fetch the state of the data account
    const val = await leverProgram.methods
      .get()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .view();

    console.log("State:", val);

Here, we get the state value by calling the "get()" method from the lever program.

Now, let's construct a test for pulling the lever. This test creates a transaction to alter the power state by initiating a cross-program invocation (CPI) to the lever program from the hand program.

First, we set up the data account for the hand program, which is needed by Solang even though it remains unused.

Then, the transaction uses the lever's data account and the name of the person who pulled the switch. We include the rest of the accounts and the program ID as accounts and instruction data for the CPI call.

it("Pull the lever!", async () => {
    // Initialize data account for the hand program
    // This is required by Solang, but the account is not used
    const tx = await handProgram.methods
      .new()
      .accounts({ dataAccount: dataAccountHand.publicKey })
      .signers([dataAccountHand])
      .rpc();
    console.log("Your transaction signature", tx);

    // Call the pullLever instruction on the hand program, which invokes the lever program via CPI
    const tx2 = await handProgram.methods
      .pullLever(dataAccountLever.publicKey, "Chris")
      .accounts({ dataAccount: dataAccountHand.publicKey })
      .remainingAccounts([
        {
          pubkey: dataAccountLever.publicKey, // The lever program's data account, which stores the state
          isWritable: true,
          isSigner: false,
        },
        {
          pubkey: leverProgram.programId, // The lever program's program ID
          isWritable: false,
          isSigner: false,
        },
      ])
      .rpc({ skipPreflight: true });
    console.log("Your transaction signature", tx2);

    // Fetch the state of the data account
    const val = await leverProgram.methods
      .get()
      .accounts({ dataAccount: dataAccountLever.publicKey })
      .view();

    console.log("State:", val);
  });

Next, we retrieve the current state value using the lever program's "get" method. Then, we perform another pull, this time with different arguments, and fetch the updated state value.

And that’s it our tests are done.

Now we move to building, deploying, and testing our program.

Setting configuration (for building, deploying and testing program)

To begin, let's construct the program.

Building

Building the Program: Before building the program, navigate to the anchor.toml file and switch the cluster to "devnet".

Open the terminal in the root directory of your project and enter the following command.

anchor build

This command will generate a target folder in the project root and generate idl and types of our Solana program to interact with the client side using rpc methods.

Now open a new terminal and check our configuration By writing this command

solana config get

After running this you will see something like this

Config File: ~/.config/solana/cli/config.yml
RPC URL: https://api.devnet.solana.com
WebSocket URL: wss://api.devnet.solana.com/ (computed)
Keypair Path: ~/.config/solana/id.json
Commitment: confirmed

"Devnet" is the RPC URL, and my wallet's default location is at "keypairpath." Make sure you generate a wallet keypair for deploying the program.

you can set devnet for cluster

by writing this command

solana config set --url https://api.devnet.solana.com

by writing this command you can generate a new keypair

solana-keygen new

Now you have a wallet

You can check the address(pubkey) and balance of this account using these commands

solana address
solana balance

If you have some devnet sol then it is okay for deployment if it is not then Get some devnet airdrop by writing this command

solana airdrop 4

Deploying

Deploying the program by opening terminal in a new tab and starting network cluster by writing this command

solana-test-validator

This will start a devnet cluster in the system next deploy program using

anchor deploy

you will get something like this

Deploying cluster: https://api.devnet.solana.com
Upgrade authority: ~/.config/solana/id.json
Deploying program "hand"...
Program path: ~/composability/cpi/target/deploy/hand.so...
Program Id: 7zJ7E8uZccmCH89eykH8yZsB6G685nbz7sSq8N9sZTtq

Deploying program "lever"...
Program path: ~/composability/cpi/target/deploy/lever.so...
Program Id: J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh

Deploy success

Now our both program is on chain (devnet)

we get program id of our deployed program on the chain

Now grab this program id and change it in our program (solidity file) as well as anchor.toml file After pasting the new program to both files

in anchor.toml write like this

[features]
seeds = false
skip-lint = false

[programs.devnet]
hand = "7zJ7E8uZccmCH89eykH8yZsB6G685nbz7sSq8N9sZTtq"
lever="J5J3mD4ABcRtB7YcgrJBgugiQAP3DfcZi5bSAdiMAZWh"

[registry]
url = "https://api.apr.dev"

[provider]
cluster = "Devnet"
wallet = "~/.config/solana/id.json"

[scripts]
test = "yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts"

Build the program again with the command

anchor build

Testing Program
Before testing check dependencies and run:

yarn install
npm install

Now we run the test using this command

anchor test

after this, you will see something like this

cross-program-invocation
Your transaction signature 5LixPfBtppvK6CGUgxKaY4obZfksEGoLXaKJMcvKgQVqcAir91oc1NHc8SCJ9MTbt4U9jvBHgQJPEQxwgkbqSXQv
State: true
    ✔ Initialize the lever! (1307ms)
Your transaction signature 5HkGWLAriP5XRJ9MTCpnMP8ZzUx2JMXsDk2B8TNYzuXPm4Wng1BwfaDMsUwiXqHjSVA683DA9YWuWVUKNvN4hyDV
Your transaction signature 4v1Zxyc5czpgkJ1SYYcwVi1C7K9icehPYkzDLUTyu9QfenaYqRnnkzVfX5Hyw6LXvA5kcdZEaiDsVx6o1hyNJx6x
State: false
    ✔ Pull the lever! (1528ms)
Your transaction signature 4qWHg6hrdWcXmGoS5zD4RGHdPczcMNYzKZnDTef8yyN7RNJj5Spj1ULG2ii6wBgf4pSczZNd3bApxedDQCKhSFhW
State: true
    ✔ Pull it again! (694ms)


  3 passing (4s)

And that's it! We've successfully made a CPI call to switch the power status from "on" to "off" and back to "on."

This demonstrates how Cross-Program Invocation (CPI) functions in Solang to combine Solana programs.

Now, leveraging this concept of CPI, let's move on to integrating it into our "goldminttoken" program. This involves transferring some tokens to another account.

Conclusion

In this article, we've taken a detailed look at the concept of composability in Web3 programs, with a special focus on Solana using Solang (a solidity-compatible compiler).

In the theoretical part, we've covered cross-program invocation and how to create it using the invoke method by setting up the necessary instructions for the invocation. We've also delved into the inner workings of cross-program invocations in Solang, including the autogenerated invoke function by the Solang compiler.

In the practical section, we've walked through a hands-on example where we built a flip functionality to toggle power on and off, showcasing how cross-program invocation can be applied.

In our upcoming articles, we will further explore the concept by delving into invoke_signed, which requires PDA authority for cross-program invocations.

Further resources

Solana cpi
Calling between programs
Solang
Solang solana libraries
Invoke

Minting Fungible Tokens on Solana with Solidity

Shivam Soni — Tue, 15 Aug 2023 20:16:00 +0000

Introduction

In this tutorial, I want to dive into Solana and Solang to show you how to build an spl-token-minter program using solidity.

By the end of this tutorial, you'll have accomplished a working on-chain program that can be deployed to the Solana blockchain and interact with the Solana blockchain for extremely low fees and fast confirmation times.

This is the second part of the Solang series, this part features a practical example using a Solidity program called spl-token-minter within the Anchor framework. This example will give you hands-on experience in creating and minting fungible tokens on Solana using Solidity.

The code for the project is located here

Here's what you're gonna learn:

How to write Solana program
Setting up a development environment.
- Step 0 installing dependencies.
- Step 1 Spl-token minter.
  - Solana blockchain cluster Types.
  - Important Differences(Compared with EVM smart contract)
  - Storing of state data.
- Step 2 Creating the solidity program.
  - What it takes to mint any custom spl tokens to token address.
  - Write program.
Setting up for building, deployment and testing
- Writing test script
- Building program
- Deploying the program
- Testing Program
Conclusion
Further learning resources

How to write a Solana program

Continuing our discussion on building Solana programs with the aid of Solana's tools and languages, let's now embark on a detailed exploration of developing a Solana program. Specifically, we'll focus on creating a Solana program named "spl-token-minter" using Solidity within the Anchor Solana framework. To begin this endeavour, we must initiate the setup of a new project.

Setting up the development environment

Step 0 Install dependencies(Prerequisites)

Do not be scared of rust here this is mandatory to install because Anchor and Solang use rust to build programs

We are Installing and setting up required dependencies for working with Solidity on the Solana blockchain development platform Make sure to do this on your preferred system, whether it's Linux, MacOS, or Windows.

Install and set up Rust

https://www.rust-lang.org/tools/install

Make sure the installation is successful by running

rustup --version  
rustc --version  
cargo --version

Anchor requires nodejs and yarn on your machine to run so if you don’t have them yet install it from here

Install and set up Node.js

https://nodejs.org/en

Once the installation is completed confirm the successful installation
like this:

node --version  
npm --version

Installing yarn

npm i -g yarn

Next, we need to install Solana-tools from here
As mentioned solang pre-bundled with Solana tool suite.

The main things we'll be doing with the Solana CLI will be configuring our network (to devnet) as well as airdropping tokens into our wallets, pretty much everything else we'll be doing with the Anchor CLI.

Now Install and set up the Solana Tools Suite.

https://docs.solana.com/cli/install-solana-cli-tools

After a successful installation run:

solana --version

Make a wallet account that you'll use later for deploying the program on Solana Devnet.

solana-keygen new

Install and Configure Solang

The newest Solang version comes already included with the Solana Tools Suite that you've set up before. It should now work well together with Solana CLI.

To make sure Solang is installed correctly, use this command.

Solang --version

If everything is fine you see something like this

➜  ~ solang --version
solang version v0.3.1
➜  ~

Install and Configure Anchor Framework

https://www.anchor-lang.com/docs/installation

Once you've set up everything, just use the following command to install Confirm AVM and Anchor CLI:

avm --version
anchor --version

If everything is fine you see something like this

➜  ~ avm --version
avm 0.28.0
➜  ~ anchor --version
anchor-cli 0.28.0
➜  ~

Install and Configure Solang VSCode Extension

With the setup complete, let's move on to initializing a new Anchor project. I'll also provide an overview of the project files.

Step 1 Create a development workspace

First of all, create a new folder where all your work will be located. Once you have created the folder, open a terminal in that folder and run the following command.

anchor init spl-token-minter --solidity

This will take some time
Anchor will be installing all dependencies that are needed for the project.

After going to the project directory

cd spl-token-minter

Run the following command to open the vscode

code .

You will go to your vscode app
from terminal
Then, You will see the project have a structure like this:

Below is How by default Anchor organizes newly created project, we will focus on these folders/files:

Here's a simplified and concise version of the content:

app: This folder holds frontend code if you plan to build and host it together with your code.
solidity: This folder contains your actual Solana smart contract code in ".sol" files.
tests: Here, you can test how your contract behaves when used, helping you build, deploy, and test Solana programs.
anchor.toml: Similar to package.json for Node.js, this tracks dependencies and important Anchor settings. You can install a VSCode extension to work with it easily.
.gitignore: This file lists things to ignore when you share your code on GitHub.
You can ignore these for now: migrations, node_modules, .prettierignore, package.json, tsconfig.json. We'll go over them later.

Note -:

If you're used to working with Solidity on Ethereum, you know about Mainnet and Testnet. With Solana, it might be a bit surprising to find out that there are three options instead of two.

Types of Solana Blockchain Cluster:

Mainnet: This is the actual Solana Blockchain where you use real SOL cryptocurrency. It's for doing real things with Solana programs, and once they're here, they can't be undone.
Devnet: When you're building on Solana using Solidity, you'll mostly be working here. It's a place to test your Solana programs before they go live on Mainnet. On Devnet, you get free SOL through airdrops (I'll explain how to get it below). Unlike Mainnet, stuff on Devnet can be reset, which means what you put here might not stay forever.
Testnet: This is like Devnet, The Testnet is where Solana's main team carefully tests the newest release features in a live cluster setup. Their main goal is to check network performance, stability, and validator behaviour while also paying attention to good grammar, clear writing, and a smooth flow of information.

You'll only need to worry about Testnet if you're directly dealing with the Solana protocol. The tokens on Testnet aren't real money, and you can get free SOL through airdrops.

In anchor.toml file you will need to change cluster
localnet to devnet

To this

Next, let’s go over the starter code beginning with the on-chain program itself. Within your project's ./solidity directory, you’ll find the following contract named spl-token-minter.sol below, which includes:

A constructor for state variable initialization.
A print function for messages in the program logs.
A flip function to update the state variable.
A get function to retrieve the current state variable value.

Important Differences(Compared with EVM smart contract).

Compared to an EVM smart contract, there are two important differences you might notice:

The @program_id annotation:

On Solana, smart contracts are referred to as “programs”. The @program_id annotation is used to specify the on-chain address of the program.

@program_id("F1ipperKF9EfD821ZbbYjS319LXYiBmjhzkkf5a26rC") //

on-chain program address.

The @payer annotation:

When storing data on the Solana blockchain, a certain amount of SOL needs to be allocated to cover the storage costs and the rent(we will discuss this later in further articles). The @payer annotation specifies the user that will pay the SOL required to create the account for storing the state variable.

@payer(payer) // payer for the "data account"
constructor(address payer) {
    print("Hello, World!");
}

Storing of state data

An important distinction between EVM smart contracts and Solana programs is how each store "state" variables/data:

EVM smart contracts can directly store state variables.
Solana on-chain programs, on the other hand, create separate accounts to hold state data. These are often referred to as "data accounts" and are "owned" by a program.

In this example, when the contract is deployed, it is deployed to the address specified in @program_id. When the constructor is called after the program is deployed, a separate account with its address is created to store the state variable, instead of being stored within the contract itself.

Step 2 Creating the solidity program

Now you can clear this all code off as we are going to build a spl-token-minter program

What it takes to mint any custom spl tokens to token address

Minting SPL Tokens involves a conceptually straightforward process, yet the intricacy emerges in understanding Solana's mechanism for monitoring users' balances of SPL Tokens.

By default, each Solana account tracks its SOL balance, the native token. However, a crucial question arises: How does every Solana account manage its balance for any possible SPL Token within the network?

In reality, achieving this feat directly is unfeasible. The solution necessitates the creation of distinct accounts purposefully configured for each SPL Token, known as Associated Token Accounts.

Imagine the scenario of introducing a new token named "JOE." To determine an individual's JOE token balance:

Mint the JOE tokens.

Establish an Associated Token Account customized for the user's wallet, designed to monitor their JOE balance.

Mint or transfer JOE tokens into the user's JOE Associated Token Account.

In essence, Associated Token Accounts operate as basic counters, directly tied to a Mint and a Wallet. Their primary function is to convey the balance linked to a specific Mint for a specific Wallet.

Write program

Design

We will create a Solana program focused on minting fungible SPL tokens. To make this happen, we'll need the right Solidity libraries that handle creating tokens, making a token mint, and sending the freshly minted tokens to a user's wallet.

Create a directory name libraries in the project root and add these files to it

No need to delve into the code just yet. Let me clarify what we're aiming for with these files: we'll be importing this code and utilizing specific methods to create and mint SPL tokens.

Create mpl_metdata.sol in the library and add code from here
mpl_metadata.sol

This library provides a way for Solidity to interact with Metaplex mpl metadata

Create spl_token.sol in the library and add code from here
spl_token.sol

This library provides a way for Solidity to interact with Solana's SPL-Token

Create system_instruction.sol in the library and add code from here
system_instruction.sol

This library provides a bridge for Solidity to interact with Solana's system instructions.

Now go over to spl-token-minter.sol file and let’s import these libraries

import "../libraries/spl_token.sol";
import "../libraries/mpl_metadata.sol";

Using Import Directives for Solidity Files

In this code block, the import directive helps bring things from libraries. This is handy when you want to keep one definition in a file and use it in lots of other files.

These import statements let the current contract use the functions, data structures, and variables from "spl_token.sol" (Solana SPL token) and "mpl_metadata.sol" (Metaplex) files. This adds to the contract's ability to create and mint tokens.

Next, write this

@program_id("4Huxs8ujxKqT76qqfmfJXMThmo4WMsvmdiCkqzNKF5kq")

On Solana, smart contracts are referred to as “programs”. The @program_id annotation is used to specify the on-chain address of the program.

Next, write a program

contract spl_token_minter {
@payer(payer)
    constructor() {}
}

Within a contract constructor, you have the option to include the @payer annotation, which takes a sequence of characters as an argument. This annotation designates a Solana account responsible for funding the initialization of the contract's data account.

The syntax @payer(payer) introduces an account named payer, which becomes essential for every invocation of the constructor.

The significance of the @payer annotation:

Allocating SOL for Blockchain Data Storage

When you put data on the blockchain, you need to set aside some SOL to pay for storage costs, including rent (which we'll explain more about later in the series). The @payer annotation tells us who's responsible for giving the needed SOL to create the account that stores the data.

Next, write this code block (createTokenMint function) after the constructor in spl_token_minter contract

function createTokenMint(
        address payer, // payer account
        address mint, // mint account to be created
        address mintAuthority, // mint authority for the mint account
        address freezeAuthority, // freeze authority for the mint account
        address metadata, // metadata account to be created
        uint8 decimals, // decimals for the mint account
        string name, // name for the metadata account
        string symbol, // symbol for the metadata account
        string uri // URI for the metadata account
    ) public {
        // Invoke System Program to create a new account for the mint account and,
        // Invoke Token Program to initialize the mint account
        // Set mint authority, freeze authority, and decimals for the mint account
        SplToken.create_mint(
            payer,            // payer account
            mint,            // mint account
            mintAuthority,   // mint authority
            freezeAuthority, // freeze authority
            decimals         // decimals
        );

        // Invoke Metadata Program to create a new account for the metadata account
        MplMetadata.create_metadata_account(
            metadata, // metadata account
            mint,  // mint account
            mintAuthority, // mint authority
            payer, // payer
            payer, // update authority (of the metadata account)
            name, // name
            symbol, // symbol
            uri // URI (off-chain metadata json)
        );
    }

Let's break down what's happening in this code block:

The createTokenMint function makes use of these parameters:

address payer, // payer account(who pay for the rent)
address mint, // mint account to be created (mint account for that specific any custom spl token)
address mintAuthority, // mint authority for the mint account(mint authority is account signer )
address freezeAuthority, // freeze authority for the mint account(same as mint authority)
address metadata, // metadata account to be created(metadata address used for storing metadata using metaplex program)
uint8 decimals, // decimals for the mint account(eth does not have decimal concept to create and mint token eth have different types of interfaces like erc-20 for fungible token and ERC721 for nft whereas in Solana is single spl token program is responsible for minting both type of tokens using decimal concept)
string name, // name for the metadata account(title, name of the token)
string symbol, // symbol for the metadata account(symbol of token)
string uri // uri for the metadata account(this is uri that is stored in somewhere decentralized storage providers like (ipfs) this is used for storing token logo and different types of metadata).

This is responsible for creating a new token mint and its associated metadata within the Solana blockchain ecosystem.

We use the public specifier for this function to make it accessible to everyone.

Creating a Mint Account and Setting Authorities

In this step, we're making a mint account for our token and deciding who's in charge and how many decimal places it has. We do this by using the System Program and the Token Program. It happens when we use the SplToken.create_mint call. This sets up things like who's in charge, who can freeze, and how many decimals there are for the Mint account.

SplToken.create_mint(
            payer,            // payer account
            mint,            // mint account
            mintAuthority,   // mint authority
            freezeAuthority, // freeze authority
            decimals         // decimals
        );

Creating Metadata Account for Minted Tokens

After making the mint account, the process moves on to using the Metadata Program. This program helps set up a new account just for storing metadata linked to the minted tokens. We make this happen by using the MplMetadata.create_metadata_account call. This step takes care of things like who owns the metadata account, the name and symbol of the tokens, and a link to off-chain metadata using a URI (Uniform Resource Identifier).

// Invoke Metadata Program to create a new account for the metadata account
        MplMetadata.create_metadata_account(
            metadata, // metadata account
            mint,  // mint account
            mintAuthority, // mint authority
            payer, // payer
            payer, // update authority (of the metadata account)
            name, // name
            symbol, // symbol
            uri // uri (off-chain metadata JSON)
        );

Now place the "mintTo" function directly under the "createTokenMint" function.

function mintTo(address mintAuthority, address tokenAccount, address mint, uint64 amount) public {
        // Mint tokens to the token account
        SplToken.mint_to(
            mint, // mint account
            tokenAccount, // token account
            mintAuthority, // mint authority
            amount // amount
        );
    }

Here we are minting tokens to user wallet with mintTo Function

The mintTo function does something important: it mints tokens to a user's associated token account in their wallet. This helps Solana keep track of how many tokens each account has.

We create associated accounts using the token mint and minting towards a user's wallet. Here's an example:

Imagine I create the JOE token. To see how much JOE someone has, I'd have to:

Make the JOE token
Make an Associated Token Account for that person's wallet to keep track of their JOE balance
Mint or send JOE tokens to their JOE Associated Token Account

Our Solidity program is now complete, allowing us to create and send tokens to a user's wallet.

Next, we'll move to building, deploying, and running this program on the chain using the devnet cluster. Thanks to the anchor framework, this is an easy and smooth process. To do this, we just need to set up the steps for running and testing our program.

Setting up for deployment and testing

First, go to the package.json file and change this block of code

{
    "scripts": {
        "lint:fix": "prettier */*.js \"*/**/*{.js,.ts}\" -w",
        "lint": "prettier */*.js \"*/**/*{.js,.ts}\" --check"
    },
    "dependencies": {
        "@coral-xyz/anchor": "^0.28.0",
        "@metaplex-foundation/js": "^0.19.4",
        "@solana/spl-token": "^0.3.8",
        "@solana/web3.js": "^1.78.4",
    },
    "devDependencies": {
        "@types/bn.js": "^5.1.0",
        "@types/chai": "^4.3.0",
        "@types/mocha": "^9.0.0",
        "chai": "^4.3.4",
        "mocha": "^9.0.3",
        "prettier": "^2.6.2",
        "ts-mocha": "^10.0.0",
        "typescript": "^4.3.5"
    }
}

Save this go to the terminal and write the command-:

npm install

For installing these dependencies

The anchor.toml file serves as the central driver for our application. It's responsible for both app configuration and running tests.

[scripts]
test = "yarn run ts-mocha -p ./tsconfig.json -t 1000000 tests/**/*.ts"

This script is an anchor.toml file responsible for running tests in test folder

Now, let's proceed with writing a test script for spl-token-minter. To do this, navigate to the test folder and open the spl-token-minter.ts file. Remove all existing code in that file.

Start with importing these programs and dependencies at the top of the file

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { SplTokenMinter } from "../target/types/spl_token_minter";
import { PublicKey, SystemProgram, SYSVAR_RENT_PUBKEY,LAMPORTS_PER_SOL,ParsedAccountData } from "@solana/web3.js";
import { Metaplex } from "@metaplex-foundation/js";
import { assert } from "chai"
import {
  ASSOCIATED_TOKEN_PROGRAM_ID,
  getOrCreateAssociatedTokenAccount,
  TOKEN_PROGRAM_ID,
  getAccount
} from "@solana/spl-token";

Here are the imported modules, classes, and tools that are utilized in test for creating and sending SPL tokens to a user's associated token account:

import * as anchor from "@coral-xyz/anchor";: This line brings in the entire Anchor library, enabling us to reference it as "anchor." Anchor is a valuable tool for developing Solana programs.
import { Program } from "@coral-xyz/anchor";: This import specifically fetches the Program class from the Anchor library. The Program class facilitates the creation and interaction with Solana programs.
import { SplTokenMinter } from "../target/types/spl_token_minter";: This import statement obtains the SplTokenMinter class from the spl_token_minter module, which will be explored further during the building process.
import { PublicKey, SystemProgram, SYSVAR_RENT_PUBKEY, LAMPORTS_PER_SOL, ParsedAccountData } from "@solana/web3.js";: In this line, we import classes such as PublicKey, SystemProgram, and others from the @solana/web3.js library. These classes are valuable for managing Solana's public keys, system program, and rent-related aspects.
import { Metaplex } from "@metaplex-foundation/js";: This import statement brings in the Metaplex class from the @metaplex-foundation/js library. Metaplex is likely used for tasks related to NFTs and metadata.
import { ASSOCIATED_TOKEN_PROGRAM_ID, getOrCreateAssociatedTokenAccount, TOKEN_PROGRAM_ID, getAccount } from "@solana/spl-token";: These imports originate from the @solana/spl-token library, which is dedicated to Solana's token standard (SPL tokens). They are instrumental in managing associated token accounts and handling various token-related tasks.

Now describe the test for spl-token-minter

describe("spl-token-minter", () => {
});

In this section, we will discuss and thoroughly test the functionality of the "spl-token-minter" program. Our testing process will include the creation of various test cases, assertions, and expectations to ensure the program's accurate behaviour. These tests will encompass a variety of scenarios, including token creation and minting.

For this, you need to first set the requirements for the test
Let’s write this

// Configure the client to use the local cluster.
  const provider = anchor.AnchorProvider.env();
  anchor.setProvider(provider);

  // Generate a new keypair for the data account for the program
  const dataAccount = anchor.web3.Keypair.generate();
  // Generate a mint keypair
  const mintKeypair = anchor.web3.Keypair.generate();
  const wallet = provider.wallet as anchor.Wallet;
  const connection = provider.connection;

  const program = anchor.workspace.SplTokenMinter as Program<SplTokenMinter>;

  // Metadata for the Token
  const tokenTitle = "Solana pro";
  const tokenSymbol = "Gold";
  const tokenUri =
    "https://raw.githubusercontent.com/solana-developers/program-examples/new-examples/tokens/tokens/.assets/spl-token.json";

Here we are configuring and initiating the setup for testing our spl-token-minter Solana program.

Configuration and Provider Setup: First, we connect to the local cluster and set up the provider using AnchorProvider.env(). This provider is then assigned with anchor.setProvider(provider) The Provider is an abstraction of a connection to the Solana network, typically consisting of a Connection, Wallet, and a preflight commitment.
Generating Key Pairs: To store the program's state, we create a new data account using a key pair. We also generate a mintKeypair, likely for the minting process. We set up wallet and connection variables too.
Initializing the Program: We use anchor.workspace.SplTokenMinter to make an instance of the program as Program. This prepares the SplTokenMinter program from the workspace, The program is an abstraction that combines the Provider, idl, and the programID (which is generated when the program is built) and allows us to call RPC methods against our program.
Defining Metadata: We provide info about the token's metadata. This means giving the token a title, symbol, and URI. These metadata bits are super important for describing what the token is all about.

Now to initialize the data account write this

it("Is initialized!", async () => {
    // Initialize data account for the program, which is required by Solang
    const tx = await program.methods
      .new()
      .accounts({ dataAccount: dataAccount.publicKey })
      .signers([dataAccount])
      .rpc();
    console.log("Your transaction signature", tx);
  });

Here we initialise the data account for the program, a crucial requirement for Solang, the Solidity compiler for Solana. The initialization process is conducted using the new() method from the program.methods object

Here we specify the dataAccount as an account parameter and the dataAccount keypair as a signer. This ensures that the transaction possesses the necessary authorization and input parameters for the initialization operation.

Now create spl token

it("Create an SPL Token!", async () => {
    // Get the metadata address for the mint
    const metaplex = Metaplex.make(connection);
    const metadataAddress = await metaplex
      .nfts()
      .pdas()
      .metadata({ mint: mintKeypair.publicKey });

    // Create the token mint
    const tx = await program.methods
      .createTokenMint(
        wallet.publicKey, // payer
        mintKeypair.publicKey, // mint
        wallet.publicKey, // mint authority
        wallet.publicKey, // freeze authority
        metadataAddress, // metadata address
        9, // decimals
        tokenTitle, // token name
        tokenSymbol, // token symbol
        tokenUri // token uri
      )
      .accounts({ dataAccount: dataAccount.publicKey })
      .remainingAccounts([
        {
          pubkey: wallet.publicKey,
          isWritable: true,
          isSigner: true,
        },
        { pubkey: mintKeypair.publicKey, isWritable: true, isSigner: true },
        {
          pubkey: new PublicKey("metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s"), // Metadata program id
          isWritable: false,
          isSigner: false,
        },
        { pubkey: metadataAddress, isWritable: true, isSigner: false },
        { pubkey: SystemProgram.programId, isWritable: false, isSigner: false },
        { pubkey: SYSVAR_RENT_PUBKEY, isWritable: false, isSigner: false },
      ])
      .signers([mintKeypair])
      .rpc({ skipPreflight: true });
    console.log("Your transaction signature", tx);
  });

Here we create an custom spl token named solana pro and have title gold

For this first, we create the metaplex connection using this

const metaplex = Metaplex.make(connection);

Get the metadata address for our token mint

// Get the metadata address for the mint
const metadataAddress = await metaplex
      .nfts()
      .pdas()
      .metadata({ mint: mintKeypair.publicKey });

Let's look at how we get metadata details for a specific mint. We use mintKeypair.publicKey to say which mint we're looking at. When we run this code, we find the metadata address connected to that mint and save it in metadataAddress.

Next, we use the createtokenmint method from our spl-token-minter program to make a token mint. We give it necessary accounts, data, and a decimal of 9 to make sure we create a fungible token mint. We also give accounts or signers for the methods.

After that, we execute the transaction using .rpc() and set skipPreflight to true for an async process. We get the transaction signature (tx) for reference, and the results show up in the console.

Now mint some solana pro tokens to our wallet

it("Mint some tokens to your wallet!", async () => {
    // Wallet's associated token account address for mint
    const tokenAccount = await getOrCreateAssociatedTokenAccount(
      connection,
      wallet.payer, // payer
      mintKeypair.publicKey, // mint
      wallet.publicKey // owner
    );

    const tx = await program.methods
      .mintTo(
        wallet.publicKey, // payer
        tokenAccount.address, // associated token account address
        mintKeypair.publicKey, // mint
        new anchor.BN(15900000000) // amount to mint
      )
      .accounts({ dataAccount: dataAccount.publicKey })
      .remainingAccounts([
        {
          pubkey: wallet.publicKey,
          isWritable: true,
          isSigner: true,
        },
        { pubkey: tokenAccount.address, isWritable: true, isSigner: false },
        { pubkey: mintKeypair.publicKey, isWritable: true, isSigner: false },
        {
          pubkey: SystemProgram.programId,
          isWritable: false,
          isSigner: false,
        },
        { pubkey: TOKEN_PROGRAM_ID, isWritable: false, isSigner: false },
        {
          pubkey: ASSOCIATED_TOKEN_PROGRAM_ID,
          isWritable: false,
          isSigner: false,
        },
      ])
      .rpc({ skipPreflight: true });
    console.log("Your transaction signature", tx);
  });

Initially, we establish an associated token account by leveraging the token mint and associating it with the user's wallet address. To accomplish this, we employ the getOrCreateAssociatedTokenAccount() method. This method requires several parameters, including the connection, the payer (associated with the wallet), the mint, and the owner (the wallet's owner).

Next, we make a transaction by using the mintTo method from our spl-token-minter program. We give it important stuff like the wallet, the address of the associated token account, the mint key pair, and the number of tokens we want to mint (like Bn). We also include the accounts and signers, making sure we provide all the accounts needed to mint tokens to the user's wallet.

Now let’s test and make an assertion if our tokens are minted or not by getting the token amount balance

And make assert.equal with 159 tokens

// Get the minted token amount on the associated token account
    const tokenAmount = (await getAccount(connection, tokenAccount.address)).amount;
    console.log("tokenAmount", tokenAmount);
    // Converting tokenAmount to a regular number using Number()
    let tokens = Number(tokenAmount);
    console.log("minted token amounts", tokens / LAMPORTS_PER_SOL);
    assert.equal(tokens / LAMPORTS_PER_SOL, 159);

Aha, All test writing is done

Now we can move forward to build our program to generate program types and idl

open anchor.toml file
and add this block of code in the end of the file

[[test.validator.clone]]
address = "metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s"

This is the metadata program id for Metaplex

It’s time to build our spl-token-minter program

Building program
Go to the terminal in project root
and write command

anchor build

This command will generate a target folder in the project root and generate idl and types of our Solana program to interact with the client side using rpc methods

Now open a new terminal and check our configuration By writing this command

solana config get

After running this you will see something like this

Config File: ~/.config/solana/cli/config.yml
RPC URL: https://api.devnet.solana.com
WebSocket URL: wss://api.devnet.solana.com/ (computed)
Keypair Path: ~/.config/solana/id.json
Commitment: confirmed

For Devnet, please note that it uses an RPC URL, and your wallet's default location is specified by the keypairpath. Make sure to generate a wallet keypair for program deployment.
You can set devnet for cluster
by writing this command

solana config set --url https://api.devnet.solana.com

by writing this command you can generate a new keypair

solana-keygen new

Now you have a wallet
You can check the address(pubkey) and balance of this account using these commands

solana address 
solana balance

If you have some devnet sol then it is okay for deployment if it is not then Get some devnet airdrop by writing this command

solana airdrop 4

Deploying the program
Open the terminal in the new tab and start the network cluster
by writing this command

solana-test-validator

This will start a devnet cluster in the system
Next, deploy the program using

anchor deploy

you will get something like this

Deploying cluster: https://api.devnet.solana.com
Upgrade authority: ~.config/solana/id.json
Deploying program "spl_token_minter"...
Program path: ~/Desktop/demo/spl-token-minter/target/deploy/spl_token_minter.so...
Program Id: 3iCbv94ivHb4of8NEeikMbk2kckLVSDmUEprpQZ1cBUw
Deploy success

Our program is now deployed on the Devnet cluster. It possesses program upgrade authority, which is granted to our wallet. To proceed, we need to obtain the program ID of our deployed program on-chain.

Once we have the program ID, update it in our program (solidity file) as well as the anchor.toml file. Make sure to replace the existing program ID with the new one in both files.

Build the program again with the command

anchor build

Testing Program

Before testing check dependencies and run:

yarn install

Now we are doing testing with the command

anchor test

after this, you will get results like this

spl-token-minter
Your transaction signature 5KzehPTbYCuUtwQzbigvTnwnkiuNcWuXPtuWSMGMVc914xcV8ddFLV3BqEr3hMsbS9ga6SJjzEDcjRMZhGi6KgvJ
✔ Is initialized! (4616ms)
Your transaction signature ePvkJFcHdgjbWnYh1e5nab57bv32TyviXgrfNi1QQFsHytXgcJvuneD9BzmrEv4rcMu1KXQSr2hpJ2Gsqzf2TAm
✔ Create an SPL Token! (1466ms)
Your transaction signature 4qdXPTQArZTyFq5mCtdyJVx2Hu1NxeYnY1wwGCVpHy91SZjdkngvRYVWDJvmaTigUEshACFbKMULojfChMxcNp85
minted token amounts **156**
✔ Mint some tokens to your wallet! (6090ms)
3 passing (12s)

All test is passed and we can see minted tokens in Solana Explorer

Get the workspace program wallet address using this command Write in the terminal

solana address

Now goto this link
https://explorer.solana.com/?cluster=devnet
Paste wallet address in the search explorer
you will get something like this

This will give you info about the wallet
like balance transactions and token holdings

To see our minted tokens click on tokens then you will see something like this

Find out minted tokens with the title solana pro that have 159 GM supply
Click on this you will see something like this

All the information related to minted tokens is here
that’s it

This is how you can mint fungible tokens on Solana using solidity(solang).

Conclusion

This article, delved deep into different aspects of Solana program development using Solidity. It laid a solid foundation by highlighting the differences in behaviour between Solidity programs on the Solana and Ethereum platforms.

To enhance clarity and organization, the article was methodically partitioned into two distinct sections, facilitating a well-structured grasp of the subject matter for readers.

The initial section was dedicated to imparting a fundamental comprehension of Solidity Solana programs within the context of the Solana ecosystem. This segment intricately elucidated multiple aspects of Solana blockchain development utilizing the Solidity (Solang) approach.

The subsequent section offered an engaging hands-on experience by meticulously detailing the creation of a "spl-token-minter" program using Solidity. This practical example empowered readers with the ability to practically apply the previously discussed concepts.

As the series advances, the upcoming article will pivot its focus towards crafting a Flip program using CPI(Cross-program-invocation) and PDA(program-derived address) in Solidity (Solang), thereby deepening and expanding the scope of knowledge conveyed throughout this series.

Further learning resources

Building Solana Programs with Solidity : Transitioning from EVM to Solana

Shivam Soni — Tue, 15 Aug 2023 18:26:07 +0000

Introduction

Whether you know about Ethereum, blockchains, or websites, or want to learn something new, this guide helps you become a Solana developer. The guide has simple steps to help you learn .

This article helps you understand Solana programming using Solidity. It also shows how to use Solidity programs on Solana. The article has two parts:

Basics for EVM Developers: This part is for developers who know Ethereum and want to learn about Solana. It gives you a good start for the series.
Practical Example: spl-token-minter: The second part has a hands-on example using a Solidity program called spl-token-minter with the Anchor framework. It teaches you how to make tokens on Solana using Solidity.

Prerequisite

Before diving in, it's helpful if you already have some coding experience in any programming language. A basic understanding of Solidity (used in Ethereum) and the Solana ecosystem will also come in handy.

Here's what you're gonna learn:

Table of contents-:

Introduction to Solana
Why build on Solana
Solidity basics
- Learning resources for solidity
Solidity program compilation
- Solidity on solana
- Solidity on ethereum
Exploring Solang
Solidity For Solana vs. Solidity For Ethereum.
Technical architecture comparison (accounts on both platforms)
- Account modal
Ethereum Smart Contracts vs. Solana Programs: A Comparative Study

Introduction to Solana

Solana is a fast and efficient blockchain platform designed for decentralized applications (DApps) and cryptocurrencies. By blending advanced technologies, Solana achieves impressive scalability and fast transaction processing.

Recognized as one of the most cost-effective and rapid public blockchains worldwide, Solana's speed and economic efficiency set it apart.

Unlike Ethereum's single-threaded execution and EOS's WASM-based runtimes, Solana introduces a groundbreaking approach called Sealevel. This innovative smart contracts runtime operates , handling thousands of contracts at once. It optimizes the Validator's infrastructure to enhance Solana's exceptional performance.

Why build on Solana

Starting in the Solana Ecosystem

If you're new to Solana, don't worry – you don't need an extensive background in smart contracts or blockchain to start building.

In Solana, smart contracts are like programs you can call, and you can use different programming languages to create them. You'll find Rust (native and through Anchor), C, C++, Python (using Seahorse), and even the new addition of Solidity (with Solang and Anchor) for building and deploying these programs on the chain.

By participating, you gain access to a sprawling community of millions, till August 2023 Solana encompassing over 11 million active accounts. This environment has facilitated the minting of more than 21 million NFTs, all at an average transaction cost of $0.00025. , Solana currently boasts a transaction throughput of 4,386 transactions per second (tps), in stark contrast to Ethereum's 24.02 tps.

As you delve into Solana's development realm, you'll find an array of tools and technologies ready to assist you, ensuring a seamless journey into the world of Solana building.

Solidity basics

Solidity is a recently developed programming language originating from Ethereum, the second-largest cryptocurrency market by capitalization. Introduced in 2015 under the guidance of Christian Reitwiessner, Ethereum's core developer, Solidity possesses a set of significant attributes:

Solidity serves as a high-level programming language crafted for implementing smart contracts.
It adheres to a typed object-oriented (contract-oriented) paradigm.
The design of Solidity draws significant inspiration from programming languages like Python, C++, and JavaScript, all which function on the Ethereum Virtual Machine (EVM).
Solidity boasts support for intricate user-defined programming constructs, libraries, and inheritance.
As the predominant language, Solidity is the foundation for blockchain platforms.
The capabilities of Solidity extend to creating diverse contracts such as voting systems, blind auctions, crowdfunding mechanisms, multi-signature wallets, and more.

Learning resources for solidity

solidity_by_example
youtube
cryptozombies

Solidity program compilation

Solidity on solana

Using Solidity with Solana: A Seamless Process

Solidity, the programming language for smart contracts, plays a pivotal role in Solana. It's made even more powerful with the Solang compiler. This tool is essential for converting Solidity code into a format that fits with the Solana blockchain. The compiler handles various optimization stages, transforming the code into bytecode or machine code. This bytecode is tailored for Solana's platform, making it effortless for Solidity developers to create and deploy smart contracts on Solana.

Here's a breakdown of the process:

Crafting in Solidity: Smart contracts are written in the Solidity programming language.
Compilation: The Solang compiler compiles the Solidity smart contract into BPF (Berkeley Packet Filter) or SBF (Solana Bytecode Format) bytecode using the LLVM compiler.
Deployment: The resulting BPF or SBF bytecode is deployed on the Solana Blockchain, becoming a Solana program.
Operation: The Solidity Solana program becomes functional within the Solana Blockchain.

Even though the main ideas of Solidity are the same for Ethereum and Solana, there are some small changes you should make when using Solidity on Solana. These ensure seamless compatibility. While similarities exist, Solidity on Solana requires some refinement for a smooth integration with the Solana Blockchain. This means a direct copy-paste from Ethereum might not work.

Solidity on ethereum

Creating and Deploying Solidity Smart Contracts on Ethereum

Developing smart contracts using Solidity on the Ethereum platform follows this process:

Crafting the Smart Contract: The process begins with crafting a smart contract using the Solidity programming language. This involves creating a .sol file that signifies the use of Solidity.
Compiling the Smart Contract: The Solidity compiler comes into play to compile the smart contract written in Solidity.
Transformation to ABI and Bytecode: After compilation, the high-level code transforms into ABI (Application Binary Interface) and bytecode formats. This transformation prepares the code for seamless integration into the Ethereum network.
Formation of Program Bytecode: The bytecode takes another step forward and transforms into program bytecode, a significant milestone in the process.
Execution or Deployment on the Ethereum Chain: The final step involves executing (deploying) the crafted smart contract onto the Ethereum blockchain. This deploys the smart contract, making it functional within the Ethereum network.

This systematic sequence encapsulates the complete journey of implementing a Solidity-based smart contract on Ethereum's platform.

Exploring Solang

Solang is a Solidity Compiler designed to enable the creation of Solana programs—referred to as 'smart contracts' in other blockchain contexts—using the Solidity programming language.

The compiler leverages the llvm compiler framework to generate WebAssembly (WASM) or Solana SBF contract code. This approach yields optimized output, resulting in reduced gas costs or compute units during execution.

Solang is crafted to maintain source file compatibility with version 0.8 of the Ethereum EVM Solidity compiler.

Moreover, it integrates with established Solana development tools and frameworks, such as Anchor, facilitating the streamlined construction and deployment of Solana programs rooted in the Solidity language.

Solidity For Solana vs. Solidity For Ethereum

Adapting Solidity for Solana's Unique Environment

When integrating Solidity's mechanics into the Solana environment, certain adjustments are necessary. Within a Solidity contract on Solana, a distinct structure emerges, comprising two separate accounts: a data account and a program account. The program account stores the contract's executable binary and controls the data account, which encompasses all storage variables. This contrasts with Ethereum's approach, where a single account manages both executable code and data.

Simplifying Technical Concepts in Solana and Ethereum

In Solana, an account is represented by a 32-byte key, denoted as the address type, which differs from Ethereum's 20-byte address format. An address is represented using syntax like 36VtvSbE6jVGGQytYWSaDPG7uZphaxEjpJHUUpuUbq4D.
It's important to note that Ethereum's address format 0xE0f5206BBD039e7b0592d8918820024e2a7437b9 isn't compatible with Solana.
Ethereum's wallet addresses generally have 40 characters, including the 0x prefix. , Solana wallet addresses can be around 44 characters in length, without a fixed prefix.
The use of Solana's target requires Solana version v1.8.1.
In Ethereum, setting the gas limit while invoking a smart contract function influences resource consumption. Gas encompasses the on-chain execution expenses and permits the prioritization of execution through the allocation of extra gas. Each instruction within the Ethereum Virtual Machine (EVM) carries a unique gas value, which corresponds to real ETH costs.
Solana optimizes for low latency and high transaction throughput, introducing compute units like Ethereum's gas. Each smart contract function is allocated the same number of compute units (currently 200k), and every instruction of a contract consumes exactly one compute unit. Unlike Ethereum, Solana doesn't need specifying compute units for transactions, and they aren't charged. Yet, charges are based on consumed compute units for execution priority. Thus, gas concepts don't apply to Solidity on Solana.
The msg.sender function isn't available in Solana.
Due to different signature algorithms, Solana lacks the ecrecover() function. Yet, signatureVerify() verifies ed25519 signatures. Extracting a signer from a signature isn't workable.
On Solana, try-catch statements lack functionality. If a call or contract creation fails, the runtime stops execution and reverts the transaction.
Error definitions, reverts, and error messages don't work in Solana.
The ERC-20 interface isn't currently compatible with Solana.

Here's a simplified comparison table between Solana and Ethereum various technical incompatibilities:

Concept	Solana	Ethereum
Account Address Format	32-byte key (address type)	20-byte address
Wallet Address Length	Varies (around 44 characters)	40 characters (with 0x prefix)
Required Solana Version	v1.8.1	-
Gas and Resource Management	Compute Units (similar to gas)	Gas and EVM instructions
Compute Unit Allocation	200k per function	Varies per instruction
`msg.sender` Function	Not Available	Available
Signature Verification	`signatureVerify()`	`ecrecover()`
Try-Catch Statements	Not Functional	Available
Error Handling and Reverts	Limited	Available
ERC-20 Compatibility	Not Compatible	Compatible

Technical Architecture comparison

(Accounts on both platforms)

The technical structure of blockchains sets Solana apart from Ethereum through distinct programming approaches. Solana utilizes diverse paradigms and patterns, moulding its account model, rent system, Cross-Program Invocation (CPI), and Program Derived Address (PDA). These concepts will be explored in-depth in this series. This article centers on outlining the account model and its differences from Ethereum's architecture.

Account Model:

In Solana's runtime environment, known as Sealevel, the account model simplifies complex interactions. For preserving the transaction state, the mechanism involves accounts. These are like files in systems such as Linux, storing lasting data beyond program lifetimes.
Unlike traditional files, an account's longevity is tied to its rent, denoted in fractional native tokens known as lamports. These accounts live in validator memory and rely on rent to persist. Regular scans are conducted to collect rent, and accounts with zero lamports are deleted. Accounts are considered rent-exempt if they maintain a smallest lamport balance.
Solana's Sealevel, unlike Ethereum's EVM, has two distinct account types: executable (upgradeable) and non-executable (for mutable data). Unlike EVM, Sealevel allows contract data access in any account, but changes are limited to the designated "owner" for security.
Solana's storage approach differs from Ethereum's. Any Solana account can host state. , Solana's contract state is within other accounts. Each Solana account links to an owner contract, securing state change control.
In account-based blockchains like Ethereum and Solana, versatile on-chain data enhances decentralized applications. Yet, EVM and Sealevel differ in state storage. Ethereum's smart contracts manage storage, while Solana allows any account. Smart contract storage uses bytecode. Solana's state is in accounts, each linked to an owner contract for state changes.

Here's a simplified comparison table highlighting the key differences between Solana and Ethereum their technical architecture and account models:

Aspect	Solana	Ethereum
Account Model	Uses an account model referred to as accounts, which store data and bytecode.	Employs a single account for both storage and smart contract code.
Data and Lamports	Accounts include Data and use fractional tokens called lamports for lifespan sign.	Ethereum uses gas for transaction cost estimation.
Executable and Non-executable Accounts	Features two account types: executable (bytecode) and non-executable (mutable data).	Follows a basic account model for storage and code accounts for smart contracts.
Storage Approach	Any account can host state; smart contract storage is confined to bytecode.	Smart contracts manage their storage.
Ownership and Security	Each account has an owner contract to secure data changes and maintain integrity.	Ownership and control are linked to the Ethereum wallet address.
Data Access	Contracts can read and write data in any account, but changes are limited to the account's "owner".	Smart contracts access data through the contract itself or external calls.
Storage Flexibility and Encapsulation	Allows any account to host state, offering flexibility and encapsulation.	Offers more controlled storage for contracts, with data storage segregated.
State Modification and Integrity	Ensures state changes are secured and validated through ownership contracts.	Requires proper coding practices to maintain data integrity and avoid vulnerabilities.

On Ethereum, token contracts have a mapping which defines the balance for each owner address:

mapping (address => uint256) private _balances;

On Solana, token balances are stored in unique accounts where the storage account address is derived from the address of the owner account.

Solang integrates Solidity with the Solana account model by modifying existing code patterns and introducing new ones that are unique to Solana, making this complex undertaking possible.

Ethereum Smart Contracts vs. Solana Programs: A Comparative Study

Within the realm of Solana, the Anchor framework serves as the tool of choice for crafting Solana programs. A multitude of programming languages are at one's disposal for building on the Solana platform, including Rust(via native and anchor), C, C++, Python(seahorse), and most recently, Solidity via the Solang compiler. This means you can develop your Solana programs using the Solidity language through the pre-integrated Solang compiler within the Solana tools, akin to how Hardhat and Remix IDE ease Ethereum's development environment. as Ethereum features Solidity smart contracts, Solana boasts its equal: Solana programs.

First section of Foundational knowledge is over now we are Moving to minting spl token solidity Solana program Section second (development of spl-token-minter program).

Spl token minter-:

SPL_TOKEN_MINTER