[User] What is the significance of enabling the Yellowstone gRPC add-on on your QuickNode endpoint?

[Assistant]
Enabling the Yellowstone gRPC add-on on your QuickNode endpoint is significant because it unlocks access to specific gRPC methods that are essential for interacting with the Solana blockchain. One such method is `isBlockhashValid`, which checks whether a given blockhash is still valid on the Solana blockchain.

This functionality is crucial for developers who need to ensure that the blockhash they are working with is still relevant and can be used in transactions or queries. Without the Yellowstone gRPC add-on, you would not be able to use this method or other related functionalities, limiting your ability to effectively interact with the Solana network.

Here’s a brief overview of the `isBlockhashValid` method:

- **Parameters**: It requires a `blockhash` (of type bytes) that you want to validate.
- **Returns**: It provides a boolean value indicating whether the blockhash is still valid, along with the associated slot number.

For example, if you wanted to check the validity of a blockhash, you would need to enable this add-on to make the following gRPC call:

```go
valid, slot, err := client.IsBlockhashValid(ctx, &pb.IsBlockhashValidRequest{Blockhash: yourBlockhash})
if err != nil {
    log.Fatalf("Failed to validate blockhash: %v", err)
}
fmt.Printf("Blockhash valid: %v, Slot: %s\n", valid, slot)
```

In summary, the Yellowstone gRPC add-on is essential for accessing advanced features that enhance your development capabilities on the Solana blockchain through QuickNode.

text.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()

    version, err := client.GetVersion(ctx, &pb.GetVersionRequest{})
	if err != null {
		log.Fatalf("Failed to get version: %v", err)
	}

	fmt.Printf("Yellowstone gRPC Version:\n")
	fmt.Printf("  GeyserGrpc: %s\n", version.GetVersion())

}
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getSlot
Next
isBlockhashValid
Chat with our community
Check out our product changelog
Check on the status of our services
Read our blog for the latest announcements
Want the latest news in Web3?
We send out the #Web3Vibes newsletter with the coolest stuff in Blockchain every month. Sign up below!

hi@example.com
isBlockhashValid gRPC Method
Checks whether a given blockhash is still valid on the Solana blockchain.
Updated on
Oct 25, 2024
Please note that this RPC method requires the Yellowstone gRPC add-on enabled on your QuickNode endpoint.
Parameters
blockhash
bytes
REQUIRED
The blockhash you want to validate
Returns
valid
boolean
A boolean value (true or false) indicating whether the blockhash is still valid
slot
string
The slot number associated with the blockhash
Request

Go
package main

import (
	"context"
	"crypto/tls"
	"fmt"
	"log"
	"time"

	pb "yellowstone/proto"

	"google.golang.org/grpc"
	"google.golang.org/grpc/credentials"
	"google.golang.org/grpc/encoding/gzip"
	"google.golang.org/grpc/keepalive"
)

// QuickNode endpoints consist of two


[User] Where can developers find resources and courses for general Solana development as mentioned in Magic Eden?

[Assistant] Developers can find resources and courses for general Solana development on Soldev. Soldev offers a variety of educational materials and resources to help developers get started and enhance their skills in Solana development.

 {string} message The message to sign
 * @returns {Promise<string>} A promise that resolves to the signed message
 * @throws {Error} If an unexpected error occurs while signing the message
 */
export const signMessage = async (
  provider: MagicEdenProvider,
  message: string
): Promise<string> => {
  try {
    const encodedText = new TextEncoder().encode(message);
    const signedMessage = await provider.signMessage(encodedText);
    return signedMessage;
  } catch (error) {
    console.warn(error);
    throw new Error("An unexpected error occured while signing the message.");
  }
};
Signing a message is relatively simple and doesn't require any real interaction with web3 libraries. Check out the signMessage functionality in the demo app for a more well rounded implementation.

Sending a Transaction
Sending a transaction on the Solana network requires the creation of a Transaction object, followed by the transaction being signed and submitted by the user's Magic Eden wallet.

📗Solana Web3js

For more information on interacting with Solana on the client side, check out the docs for Solana Web3js

For more general Solana development information, check out the courses and resources offered on Soldev

Creating a Transaction
Before you can sign or send a transaction, you must create one! Below is a basic example of creating a tx that has a user send funds right back to themselves

Copy
import {
  Transaction,
  SystemProgram,
  Connection,
  PublicKey,
} from "@solana/web3.js";


[User] How do you connect to a Solana cluster using the @solana/web3.js library?

[Assistant]
To connect to a Solana cluster using the `@solana/web3.js` library, you can follow these steps:

1. **Import the library**: First, ensure you have the `@solana/web3.js` library installed in your project. You can install it using npm:

   ```bash
   npm install @solana/web3.js
   ```

2. **Create a connection**: Use the `Connection` class from the library to establish a connection to your desired Solana cluster. You can choose from several clusters, such as `devnet`, `testnet`, or `mainnet-beta`.

Here is an example of how to connect to the `devnet` cluster:

```javascript
const web3 = require("@solana/web3.js");

// Connect to the devnet cluster
const connection = new web3.Connection(web3.clusterApiUrl("devnet"));

// You can now use the connection object to interact with the Solana cluster
```

In this example, `web3.clusterApiUrl("devnet")` provides the URL for the devnet cluster, and the `Connection` object allows you to perform various operations, such as sending transactions, querying account data, and more.

  },
);

JSON requests to the RPC #
Using a standard JSON formatted POST request, you can set the maxSupportedTransactionVersion when retrieving a specific block:

curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d \
'{"jsonrpc": "2.0", "id":1, "method": "getBlock", "params": [430, {
  "encoding":"json",
  "maxSupportedTransactionVersion":0,
  "transactionDetails":"full",
  "rewards":false
}]}'

How to create a Versioned Transaction #
Versioned transactions can be created similar to the older method of creating transactions. There are differences in using certain libraries that should be noted.

Below is an example of how to create a Versioned Transaction, using the @solana/web3.js library, to send perform a SOL transfer between two accounts.

Notes: #
payer is a valid Keypair wallet, funded with SOL
toAccount a valid Keypair
Firstly, import the web3.js library and create a connection to your desired cluster.

We then define the recent blockhash and minRent we will need for our transaction and the account:

const web3 = require("@solana/web3.js");

// connect to the cluster and get the minimum rent for rent exempt status
const connection = new web3.Connection(web3.clusterApiUrl("devnet"));
let minRent = await connection.getMinimumBalanceForRentExemption(0);
let blockhash = await connection
  .getLatestBlockhash()
  .then(res => res.blockhash);

Create an array of all the instructions you desire to send in your transaction. In this example belo


[User] What type of request does Alchemy expect for the 'getMultipleAccounts' method?

[Assistant]
Alchemy expects a POST request for the 'getMultipleAccounts' method. The request should be formatted as a JSON-RPC call. Here’s the structure of the request:

1. **Method**: The method name should be "getMultipleAccounts".
2. **Params**: This should be an array where the first element is an array of Pubkeys (account addresses) you want to query, and the second element is an optional object for specifying additional parameters like `dataSlice`.

Here’s an example of how the request should look:

```bash
curl --location --request POST 'https://solana-mainnet.g.alchemy.com/v2/demo/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getMultipleAccounts",
    "params": [
        [
            "vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg",
            "4fYNw3dojWmQ4dXtSGE9epjRGy9pFSx62YypT7avPYvA"
        ],
        {
            "dataSlice": {
                "offset": 0,
                "length": 0
            }
        }
    ]
}'
```

In this example:
- The `params` array contains two elements: an array of Pubkeys and an object specifying the `dataSlice` with `offset` and `length`.

 can be evaluated at.
Result
Pubkey Exists
<object> - a JSON object:
lamports: <u64>, number of lamports assigned to this account
owner: < base-58 encoded string>, Pubkey of the program this account has been assigned to
data: <[string, encoding]|object>, data associated with the account, either as encoded binary data or JSON format {<program>: <state>}, depending on encoding parameter
executable: <bool>, boolean indicating if the account contains a program (and is strictly read-only)
rentEpoch: <u64>, the epoch at which this account will next owe rent
Pubkey Does Not Exist
<null> - if the account at that Pubkey doesn't exist
Example

curl --request POST \
     --url https://solana-mainnet.g.alchemy.com/v2/docs-demo \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getMultipleAccounts"
}
'

Request
cURL

curl --location --request POST 'https://solana-mainnet.g.alchemy.com/v2/demo/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getMultipleAccounts",
    "params": [
        [
            "vines1vzrYbzLMRdu58ou5XTby4qAqVRLmqo36NKPTg",
            "4fYNw3dojWmQ4dXtSGE9epjRGy9pFSx62YypT7avPYvA"
        ],
        {
            "dataSlice": {
                "offset": 0,
                "length": 0
            }
        }
    ]
}'
Response
JavaScript

{
    "jsonrpc": "2.0",
    "result": {
        "context": {


[User] How can a PSBT created by Magic Eden be utilized after it is generated?

[Assistant]
After a Partially Signed Bitcoin Transaction (PSBT) is generated using Magic Eden's `createPSBT` function, it can be utilized in the following ways:

1. **Decoding the PSBT**: The generated PSBT, which is returned as a base64 string, can be decoded to inspect its contents. This is useful for verifying that the inputs and outputs are correct before proceeding with signing or broadcasting.

2. **Signing the PSBT**: Once the PSBT is created, it can be signed by the necessary private keys. This can be done using a wallet or a signing service that supports PSBTs. The signing process adds the necessary signatures to the PSBT, allowing it to be finalized for broadcasting.

3. **Broadcasting the Transaction**: After the PSBT has been fully signed (if multiple signatures are required), it can be finalized and broadcasted to the Bitcoin network. This typically involves converting the PSBT back into a raw transaction format and sending it to a Bitcoin node.

4. **Using in Wallets**: Many Bitcoin wallets support PSBTs, allowing users to import the PSBT for signing and broadcasting. This provides flexibility in managing transactions across different wallets.

Here’s an example of how you might decode and sign a PSBT after generating it:

```javascript
import { Psbt } from 'bitcoinjs-lib';

// Assume `psbtBase64` is the base64 string returned from createPSBT
const psbtBase64 = await createPSBT({...});

// Decode the PSBT
const psbt = Psbt.fromBase64(psbtBase64);

// Sign the PSBT (assuming you have the necessary private key)
const keyPair = ...; // Your key pair
psbt.signInput(0, keyPair);

// Finalize the PSBT
psbt.finalizeAllInputs();

// Convert it to a raw transaction
const rawTransaction = psbt.extractTransaction().toHex();

// Now you can broadcast `rawTransaction` to the Bitcoin network
```

This process allows you to effectively utilize the PSBT created by Magic Eden for sending Bitcoin transactions.

needed to create a PSBT.
 * @returns {Promise<string>} A promise that resolves with the base64 representation of the PSBT.
 */
export const createPSBT = async ({
    utxo,
    recipientAddress,
    changeAddress,
    amountToSend,
    scriptPubKey,
}: SegwitProps) => {
    const psbt = new Psbt({ network: networks.bitcoin });

    // change to return to sender minus the amount to send and the transaction fee (500 sats for this example)
    const changeValue = utxo.value! - amountToSend - 500;

    psbt.addInput({
        hash: utxo?.txid!,
        index: utxo?.vout!,
        witnessUtxo: {
            script: Buffer.from(scriptPubKey!, 'hex'),
            value: utxo.value!,
        },
    });

    psbt.addOutput({
        address: recipientAddress,
        value: amountToSend,
    });

    // change from the UTXO needs to be returned to the sender
    psbt.addOutput({
        address: changeAddress,
        value: changeValue,
    });

    return psbt.toBase64();
};
This formed PSBT can be decoded and sent back to the original code snippet to be executed in our SignTransaction function we created at the top of this section.

Sending BTC
Since creating PSBTs from scratch can be rather intensive, the ME wallet exposes a simple method on the provider called sendBtcTransaction to facilitate the basic request of sending bitcoin to another address.

In pattern with the previous methods, the ME provider extends Sats Connect to ensure a clear format to send BTC.

Copy
import { sendB


[User] How can I obtain a higher throughput when using the Alchemy API?

[Assistant]
To obtain a higher throughput when using the Alchemy API, you should create your own API key instead of using the default `docs-demo` API key. The documentation indicates that using a personal API key allows for higher throughput.

Here’s how you can use your own API key in the API request:

1. Replace `{apiKey}` in the endpoint URL with your own API key.
2. Ensure that you follow the same request structure as shown in the examples.

For example, if your API key is `yourApiKey`, the request to get the highest snapshot slot would look like this:

```bash
curl --request POST \
     --url https://solana-mainnet.g.alchemy.com/v2/yourApiKey \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getHighestSnapshotSlot"
}
'
```

By using your own API key, you can achieve better performance and handle more requests efficiently.

.alchemy.com/v2/{apiKey}
Returns the highest slot information that the node has snapshots for.

Path Params
apiKey
string
required
Defaults to docs-demo
For higher throughput, create your own API key

docs-demo
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getHighestSnapshotSlot
getHighestSnapshotSlot

curl --request POST \
     --url https://solana-mainnet.g.alchemy.com/v2/docs-demo \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getHighestSnapshotSlot"
}
'

Response

200
Response body
object
id
integer
jsonrpc
string
result
object
full
int64
u64 - Highest full snapshot slot.

incremental
int64 | null
u64 | undefined - Highest incremental snapshot slot based on full if available.

getIdentity
post
https://{network}.g.alchemy.com/v2/{apiKey}
Returns the identity pubkey for the current node.

Path Params
apiKey
string
required
Defaults to docs-demo
For higher throughput, create your own API key

docs-demo
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getIdentity
getIdentity

curl --request POST \
     --url https://solana-mainnet.g.alchemy.com/v2/docs-demo \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getIdentity"
}
'

Response

200
Response body
object
id
int


[User] How recent is the data referenced by the 'updated_at' field in CoinGecko?

[Assistant] The 'updated_at' field in CoinGecko indicates that the data was last updated 11 months ago. This means that the information may not reflect the most current market conditions or statistics.


[User] What type of value does the 'value' field in the RpcResponse JSON object represent?

[Assistant]
The 'value' field in the RpcResponse JSON object represents the balance of the specified account in the context of the `getBalance` method. It is of type `<u64>`, which indicates that it is an unsigned 64-bit integer. This value reflects the amount of tokens or currency held by the account queried in the request.

For example, in a typical response from the `getBalance` method, the 'value' field might look like this:

```json
{
  "jsonrpc": "2.0",
  "result": { "context": { "slot": 1 }, "value": 0 },
  "id": 1
}
```

In this example, the 'value' field is `0`, indicating that the account has no balance.

d at.

curl --request POST \
     --url https://solana-mainnet.g.alchemy.com/v2/docs-demo \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getBalance"
}
'

Result
RpcResponse:<u64> - RpcResponse JSON object with value field set to the balance
Example
Request
cURL

curl --location --request POST 'https://solana-mainnet.g.alchemy.com/v2/demo' \
--header 'Content-Type: application/json' \
--data-raw '  {
    "jsonrpc": "2.0",
    "id": 1,
    "method":"getBalance",
    "params":
    [
    "83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"
    ]
  }'
Response
JavaScript

{
  "jsonrpc": "2.0",
  "result": { "context": { "slot": 1 }, "value": 0 },
  "id": 1
}
Path Params
apiKey
string
required
Defaults to docs-demo
For higher throughput, create your own API key

docs-demo
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getBalance
getBalance
params
array

ADD
Response

200
Response body
object | null
id
integer
jsonrpc
string
result
object
context
object

context object
value
number

getBlock
post
https://{network}.g.alchemy.com/v2/{apiKey}
Returns identity and transaction information about a confirmed block in the ledger.

Parameters
<u64> - a slot integer denoting the target block number.

<object> - (optional) Config object:

encoding: (optional) <string> - data encoding for each returned transaction
Accepts one of the followin


[User] How can you retrieve the total supply of an SPL Token using Alchemy's API?

[Assistant]
To retrieve the total supply of an SPL Token using Alchemy's API, you can use the `getTokenSupply` method. This method requires the public key (Pubkey) of the token mint you want to query.

Here’s how you can make a request to the API:

### Request

You can use a cURL command to send a POST request to the Alchemy API. Here’s an example:

```bash
curl --location --request POST 'https://solana-mainnet.g.alchemy.com/v2/{apiKey}' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getTokenSupply",
    "params": [
        "HfYFjMKNZygfMC8LsQ8LtpPsPxEJoXJx4M6tqi75Hajo"
    ]
}'
```

### Parameters

- **apiKey**: Replace `{apiKey}` with your actual Alchemy API key.
- **params**: The first parameter is the base-58 encoded string of the token mint's public key.

### Response

Upon a successful request, you will receive a response in the following format:

```json
{
    "jsonrpc": "2.0",
    "result": {
        "context": {
            "slot": 137571639
        },
        "value": {
            "amount": "999999999997060679",
            "decimals": 9,
            "uiAmount": 9.999999999970608E8,
            "uiAmountString": "999999999.997060679"
        }
    },
    "id": 1
}
```

### Response Fields

- **amount**: The raw balance without decimals (as a string).
- **decimals**: The number of base 10 digits to the right of the decimal place.
- **uiAmount**: The balance as a floating-point number.
- **uiAmountString**: The balance as a string, formatted using the mint-prescribed decimals.

This method allows you to easily retrieve the total supply of any SPL Token on the Solana blockchain using Alchemy's API.

thod": "getTokenAccountsByOwner"
}
'

Response

200
Response body
object
id
integer
jsonrpc
string
result
object
context
object

context object
value
object

value object

getTokenSupply
post
https://{network}.g.alchemy.com/v2/{apiKey}
Returns the total supply of an SPL Token type.

Parameters
<base-58 encoded string> - Pubkey of token Mint to query
<object> - (optional) Config object:
commitment: <object> - (optional) Configures the commitment level of the blocks queried
Accepts one of the following strings: ["finalized", "confirmed", "processed"]
For more info, refer to this doc.
Results
amount: <u64 string> - the raw balance without decimals
decimals: <u8> - number of base 10 digits to the right of the decimal place
uiAmountString: <string> - the balance as a string, using mint-prescribed decimals
Example
Request
cURL

curl --location --request POST 'https://solana-mainnet.g.alchemy.com/v2/demo/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getTokenSupply",
    "params": [
        "HfYFjMKNZygfMC8LsQ8LtpPsPxEJoXJx4M6tqi75Hajo"
    ]
}'
Response
JavaScript

{
    "jsonrpc": "2.0",
    "result": {
        "context": {
            "slot": 137571639
        },
        "value": {
            "amount": "999999999997060679",
            "decimals": 9,
            "uiAmount": 9.999999999970608E8,
            "uiAmountString": "999999999.997060679"
        }
    },
    "id": 1
}
Path Params
apiKey
string
required
Defa


[User] What type of response can I expect from ChainStack when using the getFirstAvailableBlock method?

[Assistant]
When using the `getFirstAvailableBlock` method in ChainStack, you can expect a response that includes the slot of the lowest confirmed block that has not been purged from the ledger. This response indicates the earliest block that is still available for retrieval from the ledger, which is useful for determining the range of historical data that is accessible.

The response will typically look like this:

```json
{
  "jsonrpc": "2.0",
  "result": {
    "value": <slot_number>
  },
  "id": 1
}
```

In this response:
- `value` will contain the slot number of the lowest confirmed block that is still available.

This allows you to understand the earliest point in the blockchain history that you can access.

nths ago

getEpochSchedule | Solana
getFirstAvailableBlock | Solana
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request POST \
2
     --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/ \
3
     --header 'accept: application/json' \
4
     --header 'content-type: application/json' \
5
     --data '
6
{
7
  "id": 1,
8
  "jsonrpc": "2.0",
9
  "method": "getFeeForMessage",
10
  "params": [
11
    "AQABA36MCIdgv94d3c8ywX8gm4JC7lKq8TH6zYjQ6ixtCwbyhwEgP0xzGjSa7QhxjYGUHwUPDgYsz9S8Mb/9c7ejFiwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIOnEi/spkCilDriqSI6o2AneB2xk65o4Xm9EM+yGyiPAQICAAEMAgAAAADKmjsAAAAA",
12
    {
13
      "commitment": "finalized"
14
    }
15
  ]
16
}
17
'

getFirstAvailableBlock | Solana
post
https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/
Solana getFirstAvailableBlock method
The Solana getFirstAvailableBlock method returns the slot of the lowest confirmed block that has not been purged from the ledger.

This method provides the earliest block that is still available for retrieval from the ledger. It is useful for determining the range of historical data that is available.

👍
Get you own node endpoint today

Start for free and get your app to production levels immediately. No credit card required.

You can sign up with your GitHub, X, Google, or Microsoft account.

Parameters
This method does not require any parameters.

Response
value — the slot of the lowest confirmed block that has not been purg


[User] How does Solana identify accounts in a transaction based on the 'accounts' array?

[Assistant]
In Solana, accounts in a transaction are identified using the `accounts` array, which is part of the transaction's instruction data. Each entry in the `accounts` array corresponds to a specific account that is required for executing the instruction.

The `accounts` array uses indices to reference accounts that are passed to the program. Here's how it works:

1. **Indexing**: Each account in the `accounts` array is referenced by its index. The first account is at index 0, the second at index 1, and so on. This allows for a compact representation of the accounts involved in the transaction.

2. **Program-Specific Accounts**: Each instruction specifies which accounts it needs by providing their indices in the `accounts` array. For example, if an instruction requires three accounts, it will list their indices in the `accounts` field.

3. **Accessing Accounts**: When the program executes, it uses these indices to access the corresponding accounts from the transaction's account list. This allows the program to read from or write to the specified accounts as needed.

Here’s a simplified example of how accounts are referenced in an instruction:

```json
{
  "programIdIndex": 14,
  "accounts": [3, 5, 1],
  "data": "6LC7BYyxhFRh"
}
```

In this example:
- `programIdIndex` indicates which program is being called.
- `accounts` specifies that the program will use the accounts at indices 3, 5, and 1 from the transaction's account list.

This structure allows Solana to efficiently manage and execute transactions by clearly defining which accounts are involved in each instruction.

               ],
                "innerInstructions": [
                  {
                    "index": 0,
                    "instructions": [
                      {
                        "programIdIndex": 13,
                        "accounts": [1, 15, 3, 4, 2, 14],
                        "data": "21TeLgZXNbtHXVBzCaiRmH"
                      },
                      {
                        "programIdIndex": 14,
                        "accounts": [3, 4, 1],
                        "data": "6qfC8ic7Aq99"
                      },
                      {
                        "programIdIndex": 13,
                        "accounts": [1, 15, 3, 5, 2, 14],
                        "data": "21TeLgZXNbsn4QEpaSEr3q"
                      },
                      {
                        "programIdIndex": 14,
                        "accounts": [3, 5, 1],
                        "data": "6LC7BYyxhFRh"
                      }
                    ]
                  },
                  {
                    "index": 1,
                    "instructions": [
                      {
                        "programIdIndex": 14,
                        "accounts": [4, 3, 0],
                        "data": "7aUiLHFjSVdZ"
                      },
                      {
                        "programIdIndex": 19,
                        "accounts": [17, 18, 16, 9, 11, 12, 14],
                        "data": "8kvZyjATKQWYxaKR1qD53V"
                      },


[User] What is the purpose of the 'getConfirmedSignaturesForAddress2' method in Solana?

[Assistant]
The `getConfirmedSignaturesForAddress2` method in Solana is used to retrieve a list of confirmed signatures for transactions associated with a specific account address. This method allows users to query the blockchain for transaction signatures that have been confirmed, which can be useful for tracking the transaction history of an account.

### Parameters
- **address (string)**: The account address for which you want to fetch the confirmed signatures.
- **options (object, optional)**: This includes configuration options such as:
  - **limit (number, optional)**: The maximum number of signatures to return.

### Example Usage
Here’s an example of how you might call this method:

```json
{
  "jsonrpc": "2.0",
  "method": "getConfirmedSignaturesForAddress2",
  "params": [
    "Vote111111111111111111111111111111111111111",
    {
      "limit": 1
    }
  ],
  "id": 1
}
```

### Response
The response will include a list of confirmed transaction signatures, along with metadata about each transaction, such as the slot in which it was processed and any associated errors.

### Result Structure
The result will contain:
- **err**: Indicates if there was an error (null if no error).
- **signature**: The base-58 encoded transaction signature.
- **slot**: The slot number where the transaction was processed.
- **blockTime**: The estimated production time of the transaction (null if not available).

This method is particularly useful for developers and users who want to track the activity of specific accounts on the Solana blockchain.

tConfirmedSignaturesForAddress2",
    "params": [
      "Vote111111111111111111111111111111111111111",
      {
        "limit": 1
      }
    ]
  }
'

Response #
{
  "jsonrpc": "2.0",
  "result": [
    {
      "err": null,
      "memo": null,
      "signature": "5h6xBEauJ3PK6SWCZ1PGjBvj8vDdWG3KpwATGy1ARAXFSDwt8GFXM7W5Ncn16wmqokgpiKRLuS83KUxyZyv2sUYv",
      "slot": 114,
      "blockTime": null
    }
  ],
  "id": 1
}

getConfirmedTransaction RPC Method
Edit Page
Returns transaction details for a confirmed transaction

Deprecated Method
This method is expected to be removed in solana-core v2.0. Please use getTransaction instead.

Parameters #
string required

transaction signature, as base-58 encoded string

object optional

Configuration object containing the following fields:

commitment string optional

encoding string optional

Default: json
Encoding format for Account data

Values: jsonbase58base64jsonParsed

Details
Result #
<null> - if transaction is not found or not confirmed
<object> - if transaction is confirmed, an object with the following fields:
slot: <u64> - the slot this transaction was processed in
transaction: <object|[string,encoding]> - Transaction object, either in JSON format or encoded binary data, depending on encoding parameter
blockTime: <i64|null> - estimated production time, as Unix timestamp (seconds since the Unix epoch) of when the transaction was processed. null if not available
meta: <object|null> - transaction status metadata object:
err: <obje


[User] How does QuickNode define the amount_in parameter in the commission swap webhook?

[Assistant]
In the commission swap webhook, the `amount_in` parameter is defined as follows:

- **Parameter Name**: `amount_in`
- **Type**: integer
- **Requirement**: REQUIRED
- **Description**: This parameter represents the amount of the token you were paid in commission that is going to be swapped.

This means that `amount_in` specifies the quantity of the source token that is being swapped as part of the commission swap process.

nnouncements
Want the latest news in Web3?
We send out the #Web3Vibes newsletter with the coolest stuff in Blockchain every month. Sign up below!

hi@example.com
Commission Swap Webhook Payload
Specification of webhook for commission swaps.
Updated on
Aug 9, 2024
Please note that this method is only available for paid subscribers on the Navigator plan of Metis - Jupiter V6 Swap API.
Parameters
event_type
string
REQUIRED
The type of event we have detected. Must be `swap_tokens` for this webhook.
body
object
REQUIRED
The details for this event
tx
string
REQUIRED
The transaction as an unsigned encoded string.
tx_type
string
REQUIRED
The type of transaction we are sending you. Must be one of `versioned_transaction` or `transaction`.
amount_in
integer
REQUIRED
The amount of the token you were paid in commission we are going to swap.
quote
object
REQUIRED
The quote we used to generate this swap.
inputMint
string
REQUIRED
The source token's mint address
inAmount
string
REQUIRED
The amount of the source token being swapped
outputMint
string
REQUIRED
The destination token's mint address
outAmount
string
REQUIRED
The amount of the destination token received after the swap
otherAmountThreshold
string
REQUIRED
A threshold amount for the destination token
swapMode
string
REQUIRED
Indicates the swap mode
slippageBps
integer
REQUIRED
Slippage tolerance in basis points
platformFee
object
REQUIRED
The platform Fee object which contains the following fields:
amount
string
REQUIRED
The amount o


[User] How does the 'minimumLedgerSlot' value change over time when using QuickNode?

[Assistant]
The `minimumLedgerSlot` value represents the lowest slot that the QuickNode has information about. As time progresses, this number may increase if the node is purging older ledger data. This means that as new blocks are added to the blockchain and older data is removed to manage storage, the minimum ledger slot will reflect the most recent data available from the node.

To retrieve the current `minimumLedgerSlot`, you can use the following RPC method:

### Request Example

You can make a request using cURL as follows:

```bash
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"method":"minimumLedgerSlot","params":[],"id":1,"jsonrpc":"2.0"}'
```

This request will return the current lowest slot number that the node has information on, which may change over time as the node purges older ledger data.

parameters
Returns
u64
The lowest slot that the node has information of. This number may increase over time if the node is purging older ledger data
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"method":"minimumLedgerSlot","params":[],"id":1,"jsonrpc":"2.0"}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
isBlockhashValid
Next
requestAirdrop
Chat with our community
Check out our product changelog
Check on the status of our services
Read our blog for the latest announcements
Want the latest news in Web3?
We send out the #Web3Vibes newsletter with the coolest stuff in Blockchain every month. Sign up below!

hi@example.com
requestAirdrop RPC Method
Requests an airdrop of lamports to a Pubkey (does not work on mainnet-beta). The API credit value for this method is 30.
Updated on
Sep 20, 2024
Please note that the Airdrop method is subject to limits set by Solana. For more tools for getting Devnet SOL, check out our Guide on : A Complete Guide to Airdropping Test SOL on Solana
Parameters
pubkey
string
The Pubkey of account to receive lamports, as a base-58 encoded string
lamports
integer
The lamports to airdrop, as a u64
object
array
The configuration object with the following fields:
commitment
string
The level of commitment required for the query. The options include:
finalized
string
The node will query the most recent block


[User] What method would I use in Tatum to fetch account information, and what parameters are required?

[Assistant]
To fetch account information in Tatum, you would use the `getAccountInfo` method. The required parameters for this method include:

1. **Account Address**: The public key of the account you want to fetch information for.
2. **Options**: An object containing additional options, which can include:
   - **commitment**: A string indicating the commitment level (e.g., "finalized").
   - **encoding**: A string specifying the encoding format (e.g., "base64").

### Example of JSON-RPC Request

Here is an example of how to structure the JSON-RPC request:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getAccountInfo",
  "params": [
    "ChkH4bTk7c5NSGbxvXx89yY2oU7rFJsr3Cq1gPNCCPVe",
    {
      "commitment": "finalized",
      "encoding": "base64"
    }
  ]
}
```

In this example:
- The account address is `"ChkH4bTk7c5NSGbxvXx89yY2oU7rFJsr3Cq1gPNCCPVe"`.
- The options specify a commitment level of `"finalized"` and an encoding of `"base64"`.

This method will return detailed information about the specified account, including its owner, balance, and data.

ollowing fields:

context: An object containing details about the context in which the account information was fetched.
slot: The slot at which the data was fetched.
value: An object containing the account's information.
owner: The public key of the account's owner.
lamports: The account's current balance.
data: data associated with the account, either as encoded binary data or JSON format {<program>: <state>} - depending on encoding parameter
executable: Whether the account is marked as executable.
rentEpoch: The rent epoch value of the account.
size: The data size of the account
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getAccountInfo",
  "params": [
    "ChkH4bTk7c5NSGbxvXx89yY2oU7rFJsr3Cq1gPNCCPVe",
    {
      "commitment": "finalized",
      "encoding": "base64"
    }
  ]
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "context": {
      "slot": 123456
    },
    "value": {
      "owner": "Base58('11111111111111111111111111111111')",
      "lamports": 1000000,
      "data": "Base64('...')",
      "executable": false,
      "rentEpoch": 20,
      "size": 120
    }
  }
}

getfirstavailableblock
Solana RPC

Archive Method
Only on the full archive nodes. Complex queries might take longer and incur additional cost

How to Use It
JavaScript

// yarn add @tatumio/tatum

import { TatumSDK, Solana, Network } from '@tatumio/tatum'

const tatum = (await TatumSDK.init) < Solana > { network: Network.SOLANA }

co


[User] How long does it typically take for newly created farms to appear on the Raydium UI?

[Assistant] Newly created farms generally appear on the Raydium UI approximately 5 minutes after creation, depending on Solana’s network status. Prior to the start time of rewards, farms on the UI will display an 'Upcoming' tag.

r the farming to start. The farming end time will be calculated accordingly.

Pay close attention to the chosen start time as this can NOT be adjusted after the farm has been created.

Newly created farms generally appear on the Raydium UI approx 5 minutes after creation, depending on Solana’s network status. Farms on the UI will display an 'Upcoming' tag prior to the start time of rewards.

Rewards allocated to farms are final and cannot be withdrawn once the farm is created. Details on adding additional rewards to the farm are below.

3. Review and confirm

After all settings for the farm are confirmed, click “Review Farm.”

Make sure to confirm that rewards, duration and start time are correct. These can not be changed once the farm is created. Then click 'Confirm changes'

That's it, your farm should be live on the UI in approx 5 minutes. You can click the 'Show Created' tab on the Concentrated page to view your farms.

4. Extend or adjust farming rewards

After creating, you can easily view and manage rewards from the Portfolio page.

If you want to extend farm emissions or adjust rewards for a specific farm, click the ‘Edit Farm’ button.

Rewards allocated to farms are final and cannot be withdrawn

Rewards can be adjusted or extended according to below requirements:

To increase rewards rate or extend the farming period, additional tokens can be added to the farm at any time while the farm period is running. The farming period must be extended by at least 7 days an


[User] Can UDP packet loss cause transactions to be dropped in Solana, and if so, how?

[Assistant]
Yes, UDP packet loss can cause transactions to be dropped in Solana. This typically occurs before a transaction is processed by a leader. When a transaction is submitted to the network, it is sent as a UDP packet. If there is packet loss during this transmission, the transaction may not reach the intended validator, leading to its unintentional drop from the network.

In addition to UDP packet loss, other factors can contribute to transaction drops, especially during periods of intense network load. Validators may become overwhelmed by the volume of transactions they need to process. Although they can forward surplus transactions via the `tpu_forwards` mechanism, there is a limit to how much data can be forwarded, and each forward is restricted to a single hop between validators. This means that if a transaction is not successfully received by a validator, it cannot be forwarded to another validator for processing.

Thus, UDP packet loss is one of the simpler reasons why transactions might not be processed in the Solana network.

unable to process all transactions
For more information on the TPU, please refer to this excellent writeup by Jito Labs.

How Transactions Get Dropped #
Throughout a transaction's journey, there are a few scenarios in which the transaction can be unintentionally dropped from the network.

Before a transaction is processed #
If the network drops a transaction, it will most likely do so before the transaction is processed by a leader. UDP packet loss is the simplest reason why this might occur. During times of intense network load, it's also possible for validators to become overwhelmed by the sheer number of transactions required for processing. While validators are equipped to forward surplus transactions via tpu_forwards, there is a limit to the amount of data that can be forwarded. Furthermore, each forward is limited to a single hop between validators. That is, transactions received on the tpu_forwards port are not forwarded on to other validators.

There are also two lesser known reasons why a transaction may be dropped before it is processed. The first scenario involves transactions that are submitted via an RPC pool. Occasionally, part of the RPC pool can be sufficiently ahead of the rest of the pool. This can cause issues when nodes within the pool are required to work together. In this example, the transaction's recentBlockhash is queried from the advanced part of the pool (Backend A). When the transaction is submitted to the lagging part of the pool (Backend B), the


[User] Is it possible to conduct class actions in arbitration as per Pump Portal's Terms?

[Assistant] No, it is not possible to conduct class actions in arbitration according to Pump Portal's Terms. The Terms specify that the arbitrator may only conduct an individual arbitration and may not consolidate more than one individual's claims, preside over any type of class or representative proceeding, or preside over any proceeding involving more than one individual. This means that each arbitration must be handled on an individual basis without the inclusion of class actions.

Authority of Arbitrator. As limited by these Terms and applicable arbitration rules, the arbitrator will have: (a) the exclusive authority and jurisdiction to make all procedural and substantive decisions regarding a Dispute; and (b) the authority to grant any remedy that would otherwise be available in court. The arbitrator may only conduct an individual arbitration and may not consolidate more than one individual s claims, preside over any type of class or representative proceeding or preside over any proceeding involving more than one individual.

10. Miscellaneous
Changes. We may amend any portion of these Terms at any time by posting the revised version of these Terms with an updated revision date. The changes will become effective and shall be deemed accepted by you, the first time you use or access the Interface after the initial posting of the revised Terms and shall apply on a going-forward basis with respect to your use of the Interface including any transactions initiated after the posting date. In the event that you do not agree with any such modification, your sole and exclusive remedy are to terminate your use of the Interface.

Entire Agreement. These Terms (and any additional terms, rules, and conditions of participation that may be posted on the website of PumpPortal) constitute the entire agreement with respect to the Interface and supersedes any prior agreements, oral or written.

Survival. Upon termination of these Terms for any reason, all rights and obli


[User] What role does the `recent_blockhash` play in the transaction signing process in Solana?

[Assistant]
In Solana, the `recent_blockhash` serves a crucial role in the transaction signing process. It acts as a nonce that ensures the transaction is valid and prevents replay attacks. Here’s how it works:

1. **Transaction Uniqueness**: The `recent_blockhash` is included in the transaction to ensure that each transaction is unique. This means that even if the same transaction is attempted multiple times, it will be invalid if the blockhash is outdated.

2. **Confirmation of Validity**: When a transaction is submitted to the Solana network, the validators check the `recent_blockhash` to confirm that it is recent and has not been used in a previous transaction. If the blockhash is old, the transaction will be rejected.

3. **Signing Process**: When creating a transaction, the `recent_blockhash` is included as part of the transaction data. It is used during the signing process to generate a unique signature for that specific transaction. This ensures that the signature is tied to the state of the blockchain at the time of signing.

Here is a simplified code example illustrating how `recent_blockhash` is used in the transaction signing process:

```rust
// Assume `recent_blockhash` has been fetched from the bank or cluster
let mut transaction = Transaction::new_with_payer(&instructions, Some(&payer.pubkey()));
transaction.sign(&[&payer, &counter_keypair], recent_blockhash);
```

In this example, the `recent_blockhash` is passed to the `sign` method, which incorporates it into the transaction signature, ensuring that the transaction is valid and unique at the time of signing.

t.process_transaction(transaction).await.unwrap();

        // Check account data
        let account = banks_client
            .get_account(counter_keypair.pubkey())
            .await
            .expect("Failed to get counter account");

        if let Some(account_data) = account {
            let counter: CounterAccount = CounterAccount::try_from_slice(&account_data.data)
                .expect("Failed to deserialize counter data");
            assert_eq!(counter.count, 42);
            println!(
                "✅ Counter initialized successfully with value: {}",
                counter.count
            );
        }

        // Step 2: Increment the counter
        println!("Testing counter increment...");

        // Create increment instruction
        let increment_instruction = Instruction::new_with_bytes(
            program_id,
            &[1], // 1 = increment instruction
            vec![AccountMeta::new(counter_keypair.pubkey(), true)],
        );

        // Send transaction with increment instruction
        let mut transaction =
            Transaction::new_with_payer(&[increment_instruction], Some(&payer.pubkey()));
        transaction.sign(&[&payer, &counter_keypair], recent_blockhash);
        banks_client.process_transaction(transaction).await.unwrap();

        // Check account data
        let account = banks_client
            .get_account(counter_keypair.pubkey())
            .await
            .expect("Failed to get counter account");


[User] What sample code does QuickNode offer for Solana Web3.js to help with priority fees?

[Assistant]
QuickNode provides sample code for both the legacy version of Solana Web3.js and the 2.0 version to help users implement priority fees. Here are the relevant code snippets for each version:

### Sample Code - Solana Web3.js (Legacy)

```javascript
const { Connection, Keypair, Transaction, SystemProgram } = require('@solana/web3.js');

const connection = new Connection('https://your-quiknode-endpoint');
const payer = Keypair.generate();

async function sendTransaction() {
    const transaction = new Transaction().add(
        SystemProgram.transfer({
            fromPubkey: payer.publicKey,
            toPubkey: 'recipient-public-key',
            lamports: 1000000,
        })
    );

    const signature = await connection.sendTransaction(transaction, [payer], {
        skipPreflight: false,
        preflightCommitment: 'confirmed',
        // Set priority fees here
        feePayer: payer.publicKey,
    });

    console.log('Transaction signature', signature);
}

sendTransaction();
```

### Sample Code - Solana Web3.js 2.0

```javascript
import { Connection, Keypair, Transaction, SystemProgram } from '@solana/web3.js';

const connection = new Connection('https://your-quiknode-endpoint');
const payer = Keypair.generate();

async function sendTransaction() {
    const transaction = new Transaction().add(
        SystemProgram.transfer({
            fromPubkey: payer.publicKey,
            toPubkey: 'recipient-public-key',
            lamports: 1000000,
        })
    );

    const signature = await connection.sendTransaction(transaction, [payer], {
        skipPreflight: false,
        preflightCommitment: 'confirmed',
        // Set priority fees here
        feePayer: payer.publicKey,
    });

    console.log('Transaction signature', signature);
}

sendTransaction();
```

In both examples, you can set the priority fees by adjusting the transaction options when sending the transaction. Make sure to replace `'https://your-quiknode-endpoint'` and `'recipient-public-key'` with your actual QuickNode endpoint and the recipient's public key, respectively.

mates in four categories: low, medium, high, and extreme. Additionally the response includes a recommended property that provides a recommended fee level for each compute unit based on the current network conditions.

Priority Fees During High Traffic Periods
During periods of high network congestion, to increase the likelihood of successful transaction processing, we recommend using the recommended property of the response. We monitor the network conditions and adjust the fee level accordingly to maximize the likelihood of successful transaction processing. Any user sending non-duplicate transactions with recommended priority fees or higher will now be routed through our staked connections. Learn more about Stake-Weighted Quality of Service (SWQoS) here.

Priority Fees Resources
How to Use Priority Fees on Solana
Solana Priority Fees Add-on
Priority Fees Add-on Documentation
Guide: How to Optimize Solana Transactions - Priority Fees
Sample Code - Solana Web3.js (Legacy)
Sample Code - Solana Web3.js 2.0
Optimize Compute Units
Optimizing compute units (CU) helps prevent transactions from being dropped due to exceeding block limits. Every transaction on Solana uses CU to process. The more complex the transaction, the more compute units it will consume. The network has a limit on the number of compute units that can be processed in a single block. If your transaction exceeds this limit, it will be dropped. Additionally, priority fees are a function of compute units, so lower co


[User] How does QuickNode define the 'feeBps' and what does it represent in a swap?

[Assistant]
In QuickNode, the 'feeBps' field represents the fee percentage for a swap expressed in basis points. Specifically, one basis point is equal to 0.01%, so 'feeBps' allows for a precise representation of fees in a more granular manner.

For example, if 'feeBps' is set to 100, this would indicate a fee of 1% for the swap. This field is part of the response structure when querying swap information and helps users understand the cost associated with executing a swap on the platform.

Here’s a brief illustration of how it might appear in a response:

```json
{
  "feeBps": 100, // This indicates a 1% fee
  "amount": "1000", // Amount of the platform fee
  ...
}
```

In this example, if the swap amount is $1000, the fee charged would be $10, reflecting the 1% fee indicated by the 'feeBps' value.

ains the following fields:
amount
string
The amount of the platform fee
feeBps
integer
The fee percentage in basis points
priceImpactPct
string
The percentage of price impact due to the swap
routePlan
array
An array containing detailed information about each step of the swap process
swapInfo
object
Detailed information about a specific swap step
ammKey
string
The key identifying the Automated Market Maker (AMM) responsible for the swap
label
string
A label or identifier for the AMM
inputMint
string
The mint address of the token being swapped from in this step
outputMint
string
The mint address of the token being received in this step
inAmount
string
The amount of the token being swapped from in this step
outAmount
string
The amount of the token being received after the swap in this step
feeAmount
string
The amount of fee charged for this step of the swap
feeMint
string
The mint address of the token used for paying fees in this step
percent
integer
The percentage allocation of the swap for this step
contextSlot
integer
A contextual identifier
timeTaken
integer
Time taken for the request to be processed
Request

WSCAT
wscat -c wss://public.jupiterapi.com/ws \
# wait for connection
{"jsonrpc": "2.0", "method": "quote", "params": {"inputMint": "So11111111111111111111111111111111111111112", "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "amount": 1000000, "slippageBps": 1}, "id": 1}
Don't have an account yet?
Create your QuickNode endpoint in seconds and start bu


[User] How would you implement the getFeeForMessage method in a Node.js application using ChainStack?

[Assistant]
To implement the `getFeeForMessage` method in a Node.js application using ChainStack, you can utilize the JSON-RPC API provided by the Solana network. Below is a step-by-step guide along with a code example.

### Step 1: Set Up Your Node.js Environment

Make sure you have Node.js installed. You can create a new project and install the necessary dependencies:

```bash
mkdir solana-fee-example
cd solana-fee-example
npm init -y
npm install axios
```

### Step 2: Create the Function to Get Fee for a Message

You will need to create a function that sends a POST request to the ChainStack RPC endpoint with the `getFeeForMessage` method. Here’s how you can do it:

```javascript
const axios = require('axios');

async function getFeeForMessage(serializedMessage) {
    const url = 'https://nd-326-444-187.p2pify.com'; // Replace with your ChainStack RPC endpoint

    const params = {
        id: 1,
        jsonrpc: '2.0',
        method: 'getFeeForMessage',
        params: [serializedMessage]
    };

    try {
        const response = await axios.post(url, params);
        return response.data.result; // Return the fee details
    } catch (error) {
        console.error('Error fetching fee:', error);
        throw error;
    }
}

// Example serialized message (replace this with your actual serialized message)
const exampleSerializedMessage = 'AQABA36MCIdgv94d3c8ywX8gm4JC7lKq8TH6zYjQ6ixtCwbyhwEgP0xzGjSa7QhxjYGUHwUPDgYsz9S8Mb/9c7ejFiwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIOnEi/spkCilDriqSI6o2AneB2xk65o4Xm9EM+yGyiPAQICAAEMAgAAAADKmjsAAAAA';

getFeeForMessage(exampleSerializedMessage)
    .then(fee => {
        console.log('Transaction Fee:', fee);
    })
    .catch(error => {
        console.error('Error:', error);
    });
```

### Step 3: Run Your Application

You can run your Node.js application using the following command:

```bash
node index.js
```

### Explanation

1. **Axios**: This library is used for making HTTP requests. You can use it to send a POST request to the ChainStack RPC endpoint.
2. **Serialized Message**: You need to provide the serialized message that you want to get the fee for. Make sure to replace the `exampleSerializedMessage` with your actual serialized message.
3. **Error Handling**: The function includes error handling to catch any issues that may arise during the request.

This implementation will allow you to retrieve the transaction fee for a given serialized message using the ChainStack infrastructure.

dd(
        web3.SystemProgram.transfer({
            fromPubkey: new web3.PublicKey('9WzDXwBbmkg8ZTbNMqUxvQRAyrZzDsGYdLVL9zYtAWWM'),
            toPubkey: new web3.PublicKey('A6132mRJy5zRmGsCCRbMsrbynuB9MRVgo3n6D5j49dBh'),
            lamports: web3.LAMPORTS_PER_SOL // This transfers 1 SOL.
        })
    );

    transaction.feePayer = transaction.instructions[0].keys[0].pubkey; // Set fee payer as the sender
    transaction.recentBlockhash = (await connection.getRecentBlockhash()).blockhash;

    // Serialize only the message part of the transaction
    return transaction.serializeMessage().toString('base64');
}

createSerializedTransaction().then(serializedMessage => {
    console.log(serializedMessage);
    // Use this output as the parameter in your getFeeForMessage call
});
Try the getFeeForMessage RPC method yourself
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getFeeForMessage
getFeeForMessage
params
array
Defaults to AQABA36MCIdgv94d3c8ywX8gm4JC7lKq8TH6zYjQ6ixtCwbyhwEgP0xzGjSa7QhxjYGUHwUPDgYsz9S8Mb/9c7ejFiwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIOnEi/spkCilDriqSI6o2AneB2xk65o4Xm9EM+yGyiPAQICAAEMAgAAAADKmjsAAAAA,[object Object]

Option 1

Option 2

Option 1

Option 2

ADD
Response

200
Fee details

Updated 5 months ago

getEpochSchedule | Solana
getFirstAvailableBlock | Solana
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request POST \
2
     --url https://nd-326-444-187.p2pify.


[User] What is the role of the `mintKeypair` and `signerKeyPairs` in signing transactions in Pump Portal?

[Assistant]
In Pump Portal, the `mintKeypair` and `signerKeyPairs` play crucial roles in the process of signing transactions, particularly when dealing with creation transactions and other types of transactions.

1. **mintKeypair**: This keypair is required when signing creation transactions. Specifically, when a transaction action is of type "create", it needs to be signed by both the `mintKeypair` and the respective `signerKeyPairs`. The `mintKeypair` typically represents the mint authority for the token being created.

2. **signerKeyPairs**: This is an array of keypairs that represent the signers for each transaction. Each transaction in the `bundledTxArgs` array corresponds to a signer in the `signerKeyPairs` array. For creation transactions, both the `mintKeypair` and the specific `signerKeyPairs[i]` are used to sign the transaction. For other types of transactions (not creation), only the corresponding `signerKeyPairs[i]` is used.

Here is a code snippet illustrating how these keypairs are used in the signing process:

```javascript
for(let i = 0; i < bundledTxArgs.length; i++){
    const tx = VersionedTransaction.deserialize(new Uint8Array(bs58.decode(transactions[i])));
    if(bundledTxArgs[i].action === "create"){  // creation transaction needs to be signed by mint and creator keypairs
        tx.sign([mintKeypair, signerKeyPairs[i]]);
    } else {
        tx.sign([signerKeyPairs[i]]);
    }
}
```

In this example, if the action is "create", both the `mintKeypair` and the specific `signerKeyPairs[i]` are used to sign the transaction. For other actions, only the corresponding `signerKeyPairs[i]` is used. This structure ensures that the appropriate authorities are involved in the signing process based on the type of transaction being executed.

     headers: {
            "Content-Type": "application/json"
        },
        body: JSON.stringify(bundledTxArgs)
    });
    if(response.status === 200){ // successfully generated transactions
        const transactions = await response.json();
        let encodedSignedTransactions = [];
        let signatures = [];
        for(let i = 0; i < bundledTxArgs.length; i++){
            const tx = VersionedTransaction.deserialize(new Uint8Array(bs58.decode(transactions[i])));
            if(bundledTxArgs[i].action === "create"){  // creation transaction needs to be signed by mint and creator keypairs
                tx.sign([mintKeypair, signerKeyPairs[i]])
            } else {
                tx.sign([signerKeyPairs[i]]);
            }
            encodedSignedTransactions.push(bs58.encode(tx.serialize()));
            signatures.push(bs58.encode(tx.signatures[0]));
        }

        try{
            const jitoResponse = await fetch(`https://mainnet.block-engine.jito.wtf/api/v1/bundles`, {
                method: "POST",
                headers: {
                    "Content-Type": "application/json"
                },
                body: JSON.stringify({
                    "jsonrpc": "2.0",
                    "id": 1,
                    "method": "sendBundle",
                    "params": [
                    encodedSignedTransactions
                    ]
                })
            });
            console.log(jitoResponse);
        } catch(e){


[User] How does the realizedFeeUsd impact the APR calculations and what happens when it resets?

[Assistant]
The `realizedFeeUsd` plays a crucial role in the APR calculations for the liquidity pool. It represents the total fees collected by the pool up to a certain point. The APR is calculated weekly by taking the realized fees (after deducting the 25% share taken by the protocol) and dividing that by the total pool value. This calculation is then annualized to express the APR.

When the `realizedFeeUsd` resets to zero, which occurs when the fees are reinvested back into the pool, it can cause fluctuations in the APR value. This reset means that the next calculation period will start fresh, and the realized fees will need to accumulate again before the next APR calculation can be made. Consequently, the APR may drop temporarily until enough fees are collected again to reflect a more stable rate.

Here's a simplified example to illustrate the APR calculation:

```python
# Example values
realized_fee_usd = 1000  # Total fees collected
protocol_share_bps = 2500  # 25% of fees taken by protocol
total_pool_value = 10000  # Total value of the pool

# Calculate net fees after protocol share
net_fees = realized_fee_usd * (1 - (protocol_share_bps / 10000))

# Calculate APR (annualized)
apr_bps = (net_fees / total_pool_value) * (52) * 10000  # Weekly to annualized

print(f"APR in BPS: {apr_bps}")
```

In this example, if `realized_fee_usd` resets to zero after reinvestment, the next APR calculation will reflect a lower value until new fees accumulate.

taxBps
taxBps: Tax fee for non-stablecoins, determined based on the difference between the current and target weightage. A larger difference results in a higher tax fee, encouraging liquidity providers to rebalance the pool to the target weightage.
stableSwapBps: Swap fee for exchanges involving stablecoins, routed through the liquidity pool.
stableSwapTaxBps: Tax fee for stablecoin swaps. Similar to taxBps, this fee is determined by the difference between the current and target weightage.
protocolShareBps: Jupiter takes a share of 2500 BPS (25%) from the fees collected by the pool.
poolApr: Contains data related to the pool's APR / APY calculations.

lastUpdated: The UNIX timestamp when the pool's APR data was last updated.
feeAprBps: The pool's APR in BPS format. The APR is calculated weekly by dividing the pool's realized fees (minus the 25% collected by the protocol) by the total pool value, adjusting for the 1 week time period to annualize the rate.
realizedFeeUsd: The fees collected by the pool so far. This fee is reinvested back into the pool and is also used to calculate the APR as mentioned above. realizedFeeUsd resets to zero when the fee is reinvested into the pool hence causing the APR value to fluctuate weekly.
Custody account
The Custody account contains information for all the custodies (tokens) managed by the JLP pool. The JLP pool currently manages the following custodies:

SOL: https://solscan.io/account/7xS2gz2bTp3fwCC7knJvUWTEU9Tycczu6VhJYKgi1wdz
ETH: http


[User] How should the amount parameter be formatted for a SELL type quote in QuickNode?

[Assistant]
For a SELL type quote in QuickNode, the `amount` parameter should be formatted as follows:

- The amount should represent the number of tokens being sold, which is specified in the `mint` field.
- All Pump.fun mints have 6 decimal places, so you need to include these decimals in the specified amount.

For example, if you are selling 100 tokens, you should pass the amount as `100000000`. This is because you multiply the number of tokens by 10^6 to account for the 6 decimal places.

Here’s a quick example of how to set the `amount` parameter for a SELL type quote:

```json
{
  "type": "SELL",
  "mint": "your_pump_fun_mint_address",
  "amount": "100000000" // This represents selling 100 tokens
}
```

Make sure to replace `"your_pump_fun_mint_address"` with the actual mint address of the token you are selling.

un into any issues, please reach out to support.
Query Parameters
type
string
REQUIRED
The type of quote to get (BUY or SELL)
mint
string
REQUIRED
The pump.fun mint address of the token to quote
amount
string
REQUIRED
The amount of tokens to quote for the input token. For type = BUY, the amount should be for SOL. For type = SELL, the amount should be for the pump.fun token being sold, which is provided in the mint field. Note: All Pump.fun mints have 6 decimals. Specified amount should include those decimals here, e.g. Selling 100 tokens should be passed as 100000000.
Returns
quote
object
Quote details for the requested token swap
mint
string
The pump.fun mint address of the token
bondingCurve
string
The pump.fun bonding curve address for the token
type
string
The type of quote (BUY or SELL)
inAmount
string
The raw input amount in base units
inAmountUi
number
The formatted input amount
inTokenAddress
string
The input mint token address
outAmount
string
The raw output amount in base units
outAmountUi
number
The formatted output amount
outTokenAddress
string
The output mint token address
meta
object
Additional metadata about the quote
isCompleted
boolean
Whether the bonding curve is completed
outDecimals
number
Decimal places for the output token
inDecimals
number
Decimal places for the input token
totalSupply
string
Total supply of the token
currentMarketCapInSol
number
Current market cap in SOL
Request

Curl
curl --location --request GET 'https://public.jupiterapi.com/pump-fu


[User] How does Magic Eden handle requests for aggregated marketplace listings versus just its own listings?

[Assistant]
Magic Eden provides an API endpoint that allows users to retrieve listings for collections. When making a request to this endpoint, users can specify whether they want aggregated marketplace listings or just the listings from Magic Eden.

To control this behavior, you can use the `aggregated` query parameter in your request:

- Set `aggregated` to `true` to return aggregated marketplace listings.
- Set `aggregated` to `false` to return only Magic Eden listings.

Here’s an example of how to make a request to get batch listings with the `aggregated` parameter:

### Example Request

```bash
curl --request POST \
     --url https://api-mainnet.magiceden.dev/v2/collections/batch/listings \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '{
       "collections": [
         {
           "symbol": "your_collection_symbol"
         }
       ],
       "aggregated": true  # Set to false for only Magic Eden listings
     }'
```

In this example, replace `"your_collection_symbol"` with the actual symbol of the collection you are interested in. Adjust the `aggregated` parameter as needed to get the desired type of listings.

ue to return aggregated marketplace listings, false to return just Magic Eden listings.

Body Params
Collection symbols to retrieve listings for

collections
array of objects

ADD object
Responses

200
success response

400
Invalid symbol

Updated 11 months ago

Get listings of a collection
Get holder stats of a collection
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
URL

https://api-mainnet.magiceden.dev/v2
/collections/batch/listings
1
curl --request POST \
2
     --url https://api-mainnet.magiceden.dev/v2/collections/batch/listings \
3
     --header 'accept: application/json' \
4
     --header 'content-type: application/json'

Try It!
RESPONSE
Click Try It! to start a request and see the response here! Or choose an example:
application/json

200

400

Get holder stats of a collection
get
https://api-mainnet.magiceden.dev/v2/collections/{symbol}/holder_stats
Log in to see full request history
time	status	user agent
Make a request to see history.

Path Params
symbol
string
required
collection symbol

Responses

200
success response

400
Bad request

Updated about 1 year ago

Get batch listings of a collection
Get wallets rank sorted by volume for one collection
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
URL

https://api-mainnet.magiceden.dev/v2
/collections/{symbol}/holder_stats
1
curl --request GET \
2
     --url https://api-mainnet.magiceden.dev/v2/collections/symbol/holder_stats \
3
     --header 'accept: application/json'

T


[User] How does Solana Bankrun dynamically handle time and account data compared to other testing frameworks?

[Assistant]
Solana Bankrun handles time and account data dynamically, which is a significant advantage over other testing frameworks like solana-test-validator.

In Solana Bankrun, you can manipulate time and account data directly within your test code, allowing for more flexible and efficient testing scenarios. This capability means that you can simulate various conditions and states without needing to set up a specific environment or rely on predefined states, which is often required in other frameworks.

For example, in a typical testing scenario using Solana Bankrun, you can adjust the time and modify account data on-the-fly within your tests. This contrasts with solana-test-validator, where you might have to set up the environment and manage state transitions manually, which can be cumbersome and less efficient.

By allowing dynamic adjustments, Solana Bankrun simplifies the testing process, enabling developers to focus on writing tests rather than managing the testing environment.

Here’s a simple code example illustrating how you might set up a test using Solana Bankrun:

```javascript
const { Bankrun } = require('solana-bankrun');

const bankrun = new Bankrun();

bankrun.start(async () => {
    // Dynamically set time
    await bankrun.setTime(1000); // Set time to a specific value

    // Dynamically modify account data
    const account = await bankrun.createAccount();
    await bankrun.setAccountData(account, { balance: 1000 });

    // Perform your tests here
});
```

In this example, you can see how time and account data are manipulated directly within the test, showcasing the flexibility that Solana Bankrun provides compared to other frameworks.

programs, and simulate and process transactions seamlessly. solana-program-test (Rust), solana-bankrun (Rust, JavaScript), anchor-bankrun (Anchor, JavaScript), solders.bankrun (Python) are examples of the BanksClient-based testing framework.
Info
pnpm create solana-program can help you generate JS and Rust clients including tests. Anchor is not yet supported.

In this guide, we are using Solana Bankrun. Bankrun is a superfast, powerful, and lightweight framework for testing Solana programs in Node.js.

The biggest advantage of using Solana Bankrun is that you don't have to set up
an environment to test programs like you'd have to do while using the
solana-test-validator. Instead, you can do that with a piece of code, inside
the tests.
It also dynamically sets time and account data, which isn't possible with
solana-test-validator
Installation #
Add solana-bankrun as a dev dependency to your node project. If your Solana program is not a node project yet, you can initialize it using npm init.

npm i -D solana-bankrun

Usage #
Program Directory #
Firstly, the program's .so file must be present in one of the following directories:

./tests/fixtures (just create this directory if it doesn't exist already).
Your current working directory.
A directory you define in the BPF_OUT_DIR or SBF_OUT_DIR environment variables. export BPF_OUT_DIR='/path/to/binary'
Build your program specifying the correct directory so that library can pick the file up from directory just from the name. cargo b


[User] What are the options available for generating clients in Solana?

[Assistant]
In Solana, when generating clients, you have the option to choose between two types of clients:

1. **JavaScript Client**: This creates a TypeScript library that is compatible with web3.js, allowing you to interact with your Solana smart contract using JavaScript.

2. **Rust Client**: This generates a Rust crate that enables consumers to interact with the smart contract using Rust.

You can select either or both options depending on your project's requirements.

ADME.md

Generated Clients #
Next, you'll have the option to choose between a JavaScript client, a Rust Client, or both.

JavaScript Client creates a typescript library compatible with web3.js.

Rust Client creates a rust crate allowing consumers to interact with the smart contract.

For further workspace customization and additional information, check out the create-solana-program README.

Build #
After answering the above prompts, the workspace will be generated. To get started, build your program and clients by running:

cd <my-program-name>
npm install
npm run generate

To update an existing Anchor project to have this scaffold, read this guide.

Additional Resources #
Developing Rust Programs
Program Examples

Web App with a Smart Contract Connection
Info
This is a beta version of the Solana Toolkit, and is still a WIP. Please post all feedback as a GitHub issue here.

npx create-solana-dapp

This command generates a new project that connects a Solana smart contract to a frontend with a wallet connector. It has options for multiple popular frontend stacks and UI libraries, including: NextJS, React, Tailwind, and more.

Build and Test #
To test out this project before making any modifications, follow these steps:

Build the smart contract #
npm run anchor-build

Start the local validator #
npm run anchor-localnet

Run tests #
npm run anchor-test

Deploy to the local validator #
npm run anchor deploy --provider.cluster localnet

Build the web app #
npm run build

Run the w


[User] What does the 'await tatum.destroy()' command accomplish in the context of using Tatum?

[Assistant]
The `await tatum.destroy()` command is used to clean up and release resources that were allocated by the Tatum SDK. Specifically, it is necessary for stopping any background jobs that may have been initiated during the use of the SDK. This is important for preventing memory leaks and ensuring that the application does not continue to run processes that are no longer needed.

In the context of using Tatum, calling `destroy()` is a good practice when you are finished with the SDK and want to ensure that all resources are properly released. Here is how it fits into the overall usage:

```javascript
import { TatumSDK, Solana, Network } from '@tatumio/tatum'

const tatum = await TatumSDK.init<Solana>({ network: Network.SOLANA })

// Example usage of Tatum SDK methods
const res = await tatum.rpc.getSlotLeaders(100, 10)

// Clean up resources
await tatum.destroy() // This stops background jobs and releases resources
```

By including `await tatum.destroy()`, you ensure that your application manages resources efficiently.

  "Vote111111111111111111111111111111111111111",
    {
      "limit": 1
    }
  ]
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "result": [
    {
      "err": null,
      "memo": null,
      "signature": "5h6xBEauJ3PK6SWCZ1PGjBvj8vDdWG3KpwATGy1ARAXFSDwt8GFXM7W5Ncn16wmqokgpiKRLuS83KUxyZyv2sUYv",
      "slot": 114,
      "blockTime": null
    }
    // More signatures...
  ],
  "id": 1
}

getslotleaders
Solana RPC

Archive Method
Only on the full archive nodes. Complex queries might take longer and incur additional cost

How to Use It
JavaScript

// yarn add @tatumio/tatum

import { TatumSDK, Solana, Network } from '@tatumio/tatum'

const tatum = (await TatumSDK.init) < Solana > { network: Network.SOLANA }

const res = await tatum.rpc.getSlotLeaders(100, 10)

await tatum.destroy() // Destroy Tatum SDK - needed for stopping background jobs
Overview
The getSlotLeaders method returns an array of the slot leaders for a given slot range. In the Solana network, a slot leader is responsible for producing blocks for the network during their assigned slot time. This method could be used to monitor the network's operation, for analysis of network activity, or to understand which nodes have been assigned to produce blocks in the upcoming slots.

Parameters
startSlot (number, optional)
limit (number, optional): Integer between 1 and 5,000.
Return Object
The method returns an array of strings that represents an array of Node identity public keys as base-58 encoded strings.

JSON-


[User] How does Solana's 'TransactionMessage' facilitate the creation of a transaction?

[Assistant]
In Solana, the `TransactionMessage` class is essential for creating a transaction. It encapsulates the necessary components of a transaction, such as the instructions to be executed, the recent blockhash, and the payer's public key. Here's a breakdown of how it facilitates transaction creation:

1. **Instructions**: The `TransactionMessage` takes an array of instructions that define what operations should be performed in the transaction. Each instruction typically specifies a program to be called and the accounts involved.

2. **Recent Blockhash**: The `recentBlockhash` parameter is crucial as it ensures that the transaction is valid and prevents replay attacks. It represents the latest blockhash from the Solana blockchain.

3. **Payer Key**: The `payerKey` is the public key of the account that will pay for the transaction fees. This is important for identifying who is responsible for the transaction costs.

4. **Compilation to Message**: The `compileToV0Message` method is used to convert the `TransactionMessage` into a versioned message format that can be processed by the Solana network.

Here’s a code snippet illustrating how to create a `TransactionMessage`:

```javascript
import { TransactionMessage, VersionedTransaction } from "@solana/web3.js";

// Assuming instructions and recentBlockhash are already defined
const transactionMessage = new TransactionMessage({
  instructions, // Array of instructions for the transaction
  recentBlockhash: recentBlockhash.blockhash, // Latest blockhash
  payerKey: signer.publicKey, // Public key of the payer
});

// Compile the transaction message to a versioned transaction
const versionedTransaction = new VersionedTransaction(
  transactionMessage.compileToV0Message(lookupTables)
);
```

In this example:
- `instructions` would be defined elsewhere in your code, containing the operations to be executed.
- `recentBlockhash` should be fetched from the network to ensure it is up-to-date.
- `signer` represents the account that will pay for the transaction.

By encapsulating these elements, `TransactionMessage` simplifies the process of creating a transaction in Solana, ensuring that all necessary information is included and correctly formatted for submission to the blockchain.

  return {
    transaction: new VersionedTransaction(
      new TransactionMessage({
        instructions,
        recentBlockhash: recentBlockhash.blockhash,
        payerKey: signer.publicKey,
      }).compileToV0Message(lookupTables),
    ),
    recentBlockhash,
  };
}

Offline Transactions
Sign Transaction #
To create an offline transaction, you have to sign the transaction and then anyone can broadcast it on the network.

sign-transaction.ts
import {
  clusterApiUrl,
  Connection,
  Keypair,
  Transaction,
  SystemProgram,
  LAMPORTS_PER_SOL,
  Message,
} from "@solana/web3.js";
import * as nacl from "tweetnacl";
import * as bs58 from "bs58";

// to complete a offline transaction, I will separate them into four steps
// 1. Create Transaction
// 2. Sign Transaction
// 3. Recover Transaction
// 4. Send Transaction

(async () => {
  // create connection
  const connection = new Connection(clusterApiUrl("devnet"), "confirmed");

  // create a example tx, alice transfer to bob and feePayer is `feePayer`
  // alice and feePayer are signer in this tx
  const feePayer = Keypair.generate();
  await connection.confirmTransaction(
    await connection.requestAirdrop(feePayer.publicKey, LAMPORTS_PER_SOL),
  );
  const alice = Keypair.generate();
  await connection.confirmTransaction(
    await connection.requestAirdrop(alice.publicKey, LAMPORTS_PER_SOL),
  );
  const bob = Keypair.generate();

  // 1. Create Transaction
  let tx = new Transaction().add(
    SystemProgram.transfe


[User] What are the limitations regarding contract addresses and the CoinGecko API?

[Assistant]
The limitations regarding contract addresses and the CoinGecko API are as follows:

1. **Not All Coins Have Contract Addresses**: Not every cryptocurrency listed on CoinGecko will have a contract address available. If a contract address is not shown on the CoinGecko page for a specific coin, you will not be able to query that coin by its contract address via the API.

2. **Curated Addresses**: The contract addresses provided on CoinGecko are curated by the CoinGecko team. If you notice any missing contract addresses, you are encouraged to share this information with CoinGecko for review.

3. **Alternative Sources for Contract Addresses**: If you need a token's contract address, it is recommended to look for it on the project's official website, whitepaper, documentation, or through block explorer sites like Etherscan.

These limitations highlight the importance of verifying contract addresses through reliable sources when using the CoinGecko API.

6a738034120c302",
      "avalanche": "0xd501281565bf7789224523144fe5d98e8b28f267",
      "binance-smart-chain": "0x111111111117dc0aa78b770fa6a738034120c302",
      "near-protocol": "111111111117dc0aa78b770fa6a738034120c302.factory.bridge.near",
      "energi": "0xdda6205dc3f47e5280eb726613b27374eee9d130",
      "harmony-shard-0": "0x58f1b044d8308812881a1433d9bbeff99975e70c",
      "polygon-pos": "0x9c2c5fd7b07e95ee044ddeba0e97a665f142394f"
      }
   },
  ......
]
Look for the "Contract“ by visiting the info section of a coin page on CoinGecko

📘
Notes:

Not all coins will have a contract address listed on the CoinGecko site
If an address is not shown on the CoinGecko page, you will not be able to query the coin by its contract address via the API
The contract addresses are curated by the CoinGecko team, if you find out any missing contract address, feel free to share with us to review.

[USDC Coin Page](https://www.coingecko.com/en/coins/usdc)
[USDC Coin Page](https://www.coingecko.com/en/coins/usdc

Get the token contract address from project wesbsite, whitepaper, documentation, or block explorer site

Uniswap Documentation
Block Explorer (Etherscan)

Specify target currency to return
In the 2 examples above, both queries for Coin ID and Contract Address contain vs_currencies=usd. Most of the CoinGecko API endpoints will require you to specify the currency

CoinGecko API data supports all major fiat currencies and some famous crypto currencies like the following:

Type	Cu


[User] What accounts are required for the deposit method in Meteora's VaultUtils?

[Assistant]
The `deposit` method in Meteora's `VaultUtils` struct requires the following accounts:

1. `vault`: An `AccountInfo` reference representing the vault account.
2. `lp_mint`: An `AccountInfo` reference representing the liquidity provider mint account.
3. `user_token`: An `AccountInfo` reference representing the user's token account.
4. `user_lp`: An `AccountInfo` reference representing the user's liquidity provider token account.
5. `user`: An `AccountInfo` reference representing the user account.
6. `token_vault`: An `AccountInfo` reference representing the token vault account.
7. `token_program`: An `AccountInfo` reference representing the token program account.
8. `vault_program`: An `AccountInfo` reference representing the vault program account.
9. `token_amount`: A `u64` value representing the amount of tokens to deposit.
10. `minimum_lp_amount`: A `u64` value representing the minimum amount of liquidity provider tokens expected in return.

Here's a snippet of the method signature for clarity:

```rust
pub fn deposit<'info>(
    vault: &AccountInfo<'info>,
    lp_mint: &AccountInfo<'info>,
    user_token: &AccountInfo<'info>,
    user_lp: &AccountInfo<'info>,
    user: &AccountInfo<'info>,
    token_vault: &AccountInfo<'info>,
    token_program: &AccountInfo<'info>,
    vault_program: &AccountInfo<'info>,
    token_amount: u64,
    minimum_lp_amount: u64,
) -> Result<()>
```

This method facilitates the deposit of tokens into the vault, returning liquidity provider tokens in exchange.

ativeFee.toString(),
})

Using CPI
Developers can refer to our example about a program that integrates with vault program on-chain here:

https://github.com/MeteoraAg/vault-periphery

Add mercurial-vault to dependencies
If you are using rust, you can include the mercurial-vault link in your Cargo.toml file under "dependencies".

Copy
mercurial-vault = { git = "https://github.com/mercurial-finance/vault-sdk", rev="9ea05048146878f5e22549ce270d0e5d6776ccc9", features = ["cpi"] }
CPI to Vault program
Copy
//! Vault utilities

use anchor_lang::prelude::*;
use mercurial_vault::cpi::accounts::{DepositWithdrawLiquidity, WithdrawDirectlyFromStrategy};
use mercurial_vault::cpi::*;
use mercurial_vault::state::Vault;

/// MercurialVault struct
#[derive(Clone)]
pub struct MercurialVault;

impl anchor_lang::Id for MercurialVault {
    fn id() -> Pubkey {
        mercurial_vault::id()
    }
}
/// VaultUtils struct
pub struct VaultUtils;

impl VaultUtils {
    /// deposit to vault
    #[allow(clippy::too_many_arguments)]
    pub fn deposit<'info>(
        vault: &AccountInfo<'info>,
        lp_mint: &AccountInfo<'info>,
        user_token: &AccountInfo<'info>,
        user_lp: &AccountInfo<'info>,
        user: &AccountInfo<'info>,
        token_vault: &AccountInfo<'info>,
        token_program: &AccountInfo<'info>,
        vault_program: &AccountInfo<'info>,
        token_amount: u64,
        minimum_lp_amount: u64,
    ) -> Result<()> {
        let accounts = DepositWithdrawLiquidity {


[User] What types of developers would find Jito's services particularly useful?

[Assistant]
Jito's services are particularly useful for the following types of developers:

1. **Solana Validators**: Those who operate validators on the Solana network can benefit from Jito's low-latency transaction sending and shred data.

2. **Telegram Bot Developers**: Developers creating Telegram bots can utilize Jito's bundles feature, which offers MEV protection and fast transaction landing.

3. **High-Frequency Traders & Searchers**: Traders who require rapid and reliable transaction execution will find Jito's fast transaction sending essential for their trading strategies.

4. **dApp Developers**: Developers building decentralized applications (dApps) that require low-latency transaction sending and cross-transaction atomicity can leverage Jito's capabilities.

These developers can gain a competitive edge by utilizing Jito's specialized solutions tailored for Solana MEV users.

What is Jito?
What is Jito?
Turbocharged Solana trading experience.

What does Jito offer?
Low latency transaction sending

Low latency blockchain/shred data

Around the clock developer support

Who should use Jito?
Solana Validators

Telegram Bots

High Frequency Traders & Searchers

dApps

If your use case requires low-latency transaction sending and turbine streaming, MEV protection, and/or cross-transaction atomicity, then Jito is right for you.

Jito’s Products
Jito provides specialized solutions tailored to the needs of Solana MEV users:

🌪 Fast Transaction Sending: Essential for any Solana MEV user requiring rapid and reliable transaction execution.

💼 Bundles: Offers MEV protection, fast transaction landing, support for multiple transactions, and revert protection, making it ideal for developers of Telegram bots and automated trading systems.

🧲 Shredstream: Ensures minimal latency for receiving shreds to any RPC or validator on the network, saving hundreds of milliseconds during trading on Solana. It also provides a redundant shred path for servers in remote locations, enhancing reliability.

These use cases offer a competitive edge to traders, bot developers, and anyone seeking MEV protection.

 Low Latency Transaction Send
Jito provides Solana MEV users with superior transaction execution through fast landing, MEV protection, and revert protection, available for both single transactions and multiple transactions(bundles) via gRPC and JSON-RPC services, ensuri


[User] How does the price range selection in CLMMs impact the efficiency of capital deployment on Raydium?

[Assistant]
In Raydium's Concentrated Liquidity Market Maker (CLMM) model, the selection of a specific price range for liquidity deployment significantly impacts the efficiency of capital utilization. Here’s how it works:

1. **Targeted Liquidity**: Unlike traditional Automated Market Maker (AMM) pools where liquidity is uniformly distributed across all price points, CLMMs allow liquidity providers (LPs) to concentrate their liquidity within a specific price range. This means that LPs can choose to provide liquidity only where they anticipate trading activity will occur, leading to more efficient use of their capital.

2. **Higher Yield**: By concentrating liquidity in a narrower price range, LPs can earn a higher yield from trading fees. Since the liquidity is more likely to be utilized for trades within that range, LPs can capture more fees compared to a scenario where their liquidity is spread thinly across a wide range of prices.

3. **Improved Liquidity Depth**: For traders, concentrated liquidity around the current price improves liquidity depth, resulting in better prices and lower price impact on swaps. This is beneficial for both LPs and traders, as it facilitates more efficient trading.

4. **Risk Considerations**: While concentrating liquidity can lead to higher returns, it also comes with risks. If the market price moves outside of the selected range, the liquidity becomes inactive, and LPs may not earn fees during that period. Therefore, careful selection of the price range is crucial for maximizing capital efficiency while managing risk.

In summary, the ability to select a specific price range in Raydium's CLMMs allows LPs to deploy their capital more efficiently by targeting areas of expected trading activity, thus enhancing potential returns while also improving the trading experience for users.

tails of the position, then click 'Confirm Deposit'.

6. That's it! An NFT that represents the position will now be visible in your wallet!

IMPORTANT: If an NFT is lost, sold, or burnt, the liquidity it represents will also be lost!

How to manage a position
To check or manage a position, click 'Portfolio' in the navigation menu, all details can be viewed in the position drop-down by clicking 'View more'.

Liquidity can be added or removed from an existing position by clicking the + or - buttons. However, if you want to adjust the price range, you will need to create a new position.

When withdrawing liquidity, users have the option to keep their positions open. This allows them to redeposit into the position later, saving on fees associated with position creation, such as the Metaplex protocol fee of 0.01 SOL.

Intro on Concentrated Liquidity
What is a CLMM?
Concentrated Liquidity Market Maker (CLMM) pools allow liquidity providers to select a specific price range at which liquidity is active for trades within a pool. This is in contrast to constant product Automated Market Maker (AMM) pools, where all liquidity is spread out on a price curve from 0 to ∞. For LPs, CLMM design enables capital to be deployed with higher efficiency and earn increased yield from trading fees. For traders, CLMMs improve liquidity depth around the current price which translates to better prices and lower price impact on swaps.

While CLMMs come with the benefits of higher capital efficiency, i


[User] What does the Expiry feature do for limit orders in Jupiter?

[Assistant]
The Expiry feature for limit orders in Jupiter allows users to set a time dimension for their submitted orders. This feature is helpful for automatically canceling orders after a specific time period.

For example, if a user sets the Expiry to "Never," the order will remain active on-chain until the price hits the specified amount, at which point the order will be executed. If a user sets a specific expiry time, the order will be canceled automatically if it is not filled within that timeframe. This helps users manage their orders more effectively and avoid having open orders indefinitely.

u'll be getting.
Place Order: Once you've reviewed the order details, you will be able to place the limit order and submit the transaction to the system.
Open Order
Limit Order 4

The Open Orders section is where users will see their open submitted orders that are in the system and have yet to be filled.

Order Info: This identifies the order token details from TokenA (Selling) to TokenB (Buying) and the amounts for the order.
Price: Price is the specified user submitted rate for the limit order - When the on-chain price of the purchase token hits, order will be executed, if there is liquidity available.
Expiry: This is the time dimension set by user when submitting the order, which can be helpful to auto-cancel orders after a specific time period. In this example it's Never, therefore the order will remain active on-chain until the price hits the specified amount, at which point the order will be executed.
Filled Size: The fulfillment indicator to monitor the size of the order which has been filled. If it is a large order, and there is insufficient liquidity on-chain, Jupiter's keeper will try to execute partially, and continue monitoring on-chain price to fulfill the rest of the order. If the order is fully executed, Jupiter will send the tokens directly to user's wallet. There is no claiming process required once a Limit Order is entirely filled.
Action: Action is where users are able to cancel and close their order/positions.
Order History
Limit Order 3

Order History sec


[User] What is the format of the request to cancel orders using QuickNode's API?

[Assistant]
To cancel orders using QuickNode's API, you need to make a POST request to the endpoint `https://public.jupiterapi.com/limit-orders/cancel`. The request should include a JSON body that specifies the `maker` public key associated with the orders you want to cancel.

Here is the format of the request using cURL:

```bash
curl --location --request POST 'https://public.jupiterapi.com/limit-orders/cancel' \
--header 'Content-Type: application/json' \
--data '{
    "maker": "J2RNWdFBRbiVzjYukgzyStfYhpTHFoBFRHQjvDAsnPY9"
}'
```

In this example, replace `"J2RNWdFBRbiVzjYukgzyStfYhpTHFoBFRHQjvDAsnPY9"` with the actual public key of the maker whose orders you wish to cancel. If you want to cancel specific orders, you can include the `orders` array with the respective `orderPubKey` values. If the `orders` array is empty, all orders associated with the maker will be cancelled.

can set a custom fee i.e 500000
orders
array
The order(s) that are being cancelled. If it is empty, all orders associated to the maker will be cancelled
orderPubKey
string
The public key of the order that is being cancelled
Returns
txs
array
The array of transaction strings that should be signed and sent to the network to cancel
tx
string
The unsigned transaction to cancel the order(s)
Request

Curl
curl --location --request POST 'https://public.jupiterapi.com/limit-orders/cancel' \
--header 'Content-Type: application/json' \
--data '{
    "maker": "J2RNWdFBRbiVzjYukgzyStfYhpTHFoBFRHQjvDAsnPY9"
}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
/limit-orders/{pubkey}
Next
/limit-orders/open
Chat with our community
Check out our product changelog
Check on the status of our services
Read our blog for the latest announcements
Want the latest news in Web3?
We send out the #Web3Vibes newsletter with the coolest stuff in Blockchain every month. Sign up below!

hi@example.com
/limit-orders/open REST API Endpoint
Returns a list of all open Jupiter Limit Orders associated to a wallet.
Updated on
Dec 12, 2024
Please note that this method is only available for paid subscribers of Metis - Jupiter V6 Swap API. This endpoint is currently in BETA. If you have any feedback or run into any issues, please reach out to support.
Query Parameters
wallet
string
REQUIRED
The wallet address of the user who wants to get their open


[User] What information can I obtain about a specific token using CoinGecko's token info endpoint?

[Assistant]
Using CoinGecko's token info endpoint, you can obtain specific information about a token based on the provided token contract address on a network. The endpoint to query this information is:

```
/onchain/networks/{network}/tokens/{address}/info
```

The information you can retrieve includes:

- **Token Name**: The name of the token.
- **Symbol**: The symbol representing the token.
- **CoinGecko ID**: The unique identifier for the token on CoinGecko.

This endpoint is useful for getting essential details about a specific token that can help in various applications, such as displaying token information on a website or app.

nchain/search/pools	Search for pools on a network
/onchain/networks/{..}/tokens/{token_address}/pools	Query top pools based on the provided token contract address on a network
/onchain/networks/{network}/tokens/{address}	Query specific token data based on the provided token contract address on a network
/onchain/networks/{network}/tokens/multi/{addresses}	Query multiple tokens data based on the provided token contract addresses on a network
/onchain/networks/{network}/tokens/{address}/info	Query specific token info such as name, symbol, CoinGecko id etc. based on provided token contract address on a network
/onchain/networks/{..}/pools/{pool_address}/info	Query pool info including base and quote token info based on provided pool contract address on a network
/onchain/tokens/info_recently_updated	Qeery 100 most recently updated tokens info across all networks on GeckoTerminal
/onchain/networks/{network} /pools/{pool_address}/ohlcv/{timeframe}	Get the OHLCV chart (Open, High, Low, Close, Volume) of a pool based on the provided pool address on a network
/onchain/networks/{..}/pools/{pool_address}/trades	Query the last 300 trades in the past 24 hours based on the provided pool address
💼 /onchain/categories	Query all the supported categories on GeckoTerminal
💼 /onchain/categories/.../pools	Query all the pools based on the provided category id

❌ Common Errors & Rate Limit
Common Errors
The server responds to a user’s request by issuing status codes when the request is made to the