[User] How does Raydium determine the start time for a pool, and what should users be aware of regarding Solana's cluster time?

[Assistant]
Raydium determines the start time for a pool based on the cluster time on-chain. It is important for users to be aware that Solana's cluster time can be inconsistent. This inconsistency may affect the actual start time of the pool, so users should ensure they have set their desired start time accordingly and be prepared for any potential discrepancies due to the cluster time.

For further clarity, users can check the cluster time through the provided resources to ensure they are aligned with the expected timing for their pool launch.

 initial liquidity: You can enter one side of initial liquidity and the other side will be calculated according to the Base Token starting price.

Set the start date and time that you want your pool to launch.

Ensure that you have adequate funds in your wallet for this initial liquidity, then click 'Confirm and Initialize Liquidity Pool'.

IMPORTANT: After confirming and initializing the pool, you can no longer edit starting price, liquidity or start time. The start time is determined by the cluster time on-chain, it is possible that Solana's cluster time is inconsistent. You can check the cluster time here.

5. After clicking confirm, you will need to approve TWO separate transactions in your wallet. These transactions initialize the pool, create the AMM account and ID, and add liquidity from your wallet. If you do not see one of the transactions appear, your wallet window may be hiding behind your main browser window. If you miss a transaction, the process will fail and you'll need to click confirm again, and re-approve all transactions.

6. Once you've confirmed the two transactions in your wallet, the new LP will have been created, you will be provided with the new AMM ID, and the pool will launch at the set start time.

Helping users find your pool:

The AMM ID or Serum Market ID can be used to easily search for the pool on the Swap or Liquidity page, or shared with others to do the same.

Users can also select tokens on the swap page, or search by token mint address


[User] What happens to my liquidity if I burn my LP tokens on incinerator platforms in Meteora?

[Assistant]
If you burn your LP tokens on incinerator platforms in Meteora, it distributes your liquidity to all the other LPs in the pool, and you lose access to those funds. This is a critical point to note, as burning your LP tokens in this manner is not advisable.

In a special case where you are the only LP for a fairly new dynamic pool, you might be able to access your liquidity again by depositing some liquidity inside after burning your LP tokens. However, it is strongly recommended that you do not burn your LP tokens in the first place.

are of the pool including fees earned. Farming rewards would have to be claimed separately.

The quantity of your LP tokens will not increase. The pool is compounding fees and growing, and the LP tokens are your share of the pool. If the value of the pool grows your LP tokens increase in value but they do not increase in quantity.

Formula to calculate the estimated $ value of your LP token

Lp_token_price (in $) = ((total_TokenA_balance * TokenA_price) + (total_TokenB_balance * TokenB_price)) / total_lp_supply

Note: total_lp_supply can be found in the LP mint address of the pool

What happens if I burn my LP token?
Meteora's LP token works differently from the LP tokens from other DEXes. DO NOT burn your LP tokens on  incinerator platforms, as that distributes your liquidity to all the other LPs in the pool and you lose access to those funds.

Special case: If it is a fairly new dynamic pool and you happen to be the one and only LP for that pool, after burning your LP tokens you can access your liquidity again by depositing some liquidity inside. However, please try not to burn your LP token in the first place.

For new memecoin / token projects: If you are a memecoin project that wants to permanently leave the liquidity in the pool (your lose this liquidity forever), we recommend these options:

Use Meteora to permanently lock your liquidity in your dynamic pool

After you permanently lock liquidity in the dynamic pool, you can even claim compounding trading fees from yo


[User] What method does Meteora use to filter pool configurations that have vault support?

[Assistant]
Meteora filters pool configurations that have vault support by combining public and creator pool configurations and then applying a filter based on the `vaultConfigKey`. Here’s the relevant code snippet that demonstrates this process:

```javascript
// 1. Pool configs that can be used by anyone to create pool
const publicPoolConfigs =
  await DynamicAmm.getPoolConfigsWithPoolCreatorAuthority(
    connection,
    PublicKey.default
  );

// 2. Pool configs that can only be used by specific pubkey to create pool
const creatorPoolConfigs =
  await DynamicAmm.getPoolConfigsWithPoolCreatorAuthority(
    connection,
    creator
  );

// 3. Look for pool configs that have vault support
const poolConfigsWithVaultSupport = [
  ...publicPoolConfigs,
  ...creatorPoolConfigs,
].filter((config) => config.account.vaultConfigKey != PublicKey.default);

console.log(
  `Gotten ${poolConfigsWithVaultSupport.length} usable pool configs with vault support`
);
```

In this code:
1. It retrieves both public and creator pool configurations.
2. It combines these configurations into a single array.
3. It filters the combined array to include only those configurations where the `vaultConfigKey` is not equal to `PublicKey.default`, indicating that they have vault support.

uration: number,
  minimumVestingDuration: number,
  maximumVestingDuration: number,
  vaultMode: VaultMode
) {
  // 1. Pool configs that can be used by anyone to create pool
  const publicPoolConfigs =
    await DynamicAmm.getPoolConfigsWithPoolCreatorAuthority(
      connection,
      PublicKey.default
    );

  // 2. Pool configs that can only be used by specific pubkey to create pool
  const creatorPoolConfigs =
    await DynamicAmm.getPoolConfigsWithPoolCreatorAuthority(
      connection,
      creator
    );

  // 3. Look for pool configs that have vault support
  const poolConfigsWithVaultSupport = [
    ...publicPoolConfigs,
    ...creatorPoolConfigs,
  ].filter((config) => config.account.vaultConfigKey != PublicKey.default);

  console.log(
    `Gotten ${poolConfigsWithVaultSupport.length} usable pool configs with vault support`
  );

  const configFuture =
    vaultMode === VaultMode.FCFS
      ? AlphaVault.getFcfsConfigs(connection)
      : AlphaVault.getProrataConfigs(connection);

  const configs = await configFuture;

  for (const programAccount of poolConfigsWithVaultSupport) {
    const { account } = programAccount;
    // 3.1 Pool activation type and duration matches
    if (
      account.activationType == activationType &&
      account.activationDuration.toNumber() >= maximumActivationDuration
    ) {
      const vaultConfig = configs.find((c) =>
        c.publicKey.equals(account.vaultConfigKey)
      );

      if (!vaultConfig) {
        continue;


[User] What is the significance of the 'floor_price_7d_percentage_change' in CoinGecko's NFT market data?

[Assistant]
The `floor_price_7d_percentage_change` in CoinGecko's NFT market data indicates the percentage change in the floor price of an NFT collection over the past 7 days. This metric is significant because it provides insights into the short-term price trends of the NFT collection, helping users understand market sentiment and price volatility.

For example, if the `floor_price_7d_percentage_change` is reported as:

```json
"floor_price_7d_percentage_change": {
  "usd": -18.0014948262365,
  "native_currency": -13.7931034482759
}
```

This indicates that the floor price has decreased by approximately 18% in USD and about 13.79% in the native currency over the last week. Such information can be crucial for investors and collectors as it may influence their buying or selling decisions based on the perceived value and market dynamics of the NFT collection.


[User] What library is imported to handle query functionality in the Magic Eden setup?

[Assistant]
In the Magic Eden setup, the library imported to handle query functionality is `@tanstack/react-query`. This library is used to manage server state and caching in React applications.

Here is the relevant code snippet showing the import:

```javascript
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
```

t Connector
const ME_CONNECT = injected({
  target() {
    const provider =
      typeof window !== "undefined" ? window.magicEden?.ethereum : undefined;
    return {
      id: "Magic Eden",
      name: "Magic Eden",
      provider: provider as any, // We still use `any` here to bypass strict type checking for the provider from WAGMI
    };
  },
});

// Create the configuration
export const config = createConfig({
  chains: [mainnet, sepolia],
  connectors: [ME_CONNECT, coinbaseWallet({ appName: "Create Wagmi" })],
  ssr: true,
  transports: {
    [mainnet.id]: http(),
    [sepolia.id]: http(),
  },
});

// Declare the module to register the config type with wagmi
declare module "wagmi" {
  interface Register {
    config: typeof config;
  }
}
Setup WAGMI Provider and QueryClient
Once you have the config setup, you need to wrap your page or app with
WagmiProvider using the config object we previously created, and QueryClient.

If using NextJS 14 with App Router, make sure you add use client; at the top of the file.

Copy
"use client";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

export default function EvmDemoPage() {
  return (
    <WagmiProvider config={config}>
      <QueryClientProvider client={queryClient}>
        <div className="flex min-h-screen flex-col items-center justify-between p-24">
          {wallet component will go here}
        </div>
      </QueryClientProvider>
    </WagmiProvider>
  );
}
Display Wallet Options Component
Once


[User] What is the significance of the `createKeyPairSignerFromBytes` function in the context of Solana?

[Assistant]
The `createKeyPairSignerFromBytes` function is significant in the context of Solana as it allows developers to create a key pair signer from a byte array representation of a key pair. This is particularly useful when working with key pairs that are not generated within the application but are instead loaded from external sources, such as a file or a database.

By using this function, developers can easily integrate existing key pairs into their Solana applications, enabling them to sign transactions and interact with the Solana blockchain using pre-defined credentials. This is essential for scenarios where you want to maintain a consistent identity across different sessions or applications, or when you need to load key pairs that were generated offline.

Here’s a brief example of how you might use `createKeyPairSignerFromBytes` in your code:

```javascript
import { createKeyPairSignerFromBytes } from "@solana/web3.js";

// Assuming you have a byte array representation of your key pair
const keyPairBytes = new Uint8Array([...]); // Your byte array here

// Create a key pair signer from the byte array
const keyPairSigner = createKeyPairSignerFromBytes(keyPairBytes);

// Now you can use keyPairSigner to sign transactions
```

This function streamlines the process of utilizing key pairs in Solana applications, making it easier to manage and use cryptographic identities.

ing the account's file and destination address (on the local cluster) when starting the validator:

# solana-test-validator --account <address to load the account to> <path to account file> --reset
solana-test-validator --account JUPyiwrYJFskUPiHa7hkeR8VUtAeFoSYbKedZNsDvCN jup.json --reset

Similarly, it is possible to download the Openbook program:

# solana program dump -u <source cluster> <address of account to fetch> <destination file name/path>
solana program dump -u m srmqPvymJeFKQ4zGQed1GFppgkRHL9kaELCbyksJtPX openbook.so

Loading it to your localnet is then done by passing the program's file and destination address (on the local cluster) when starting the validator:

# solana-test-validator --bpf-program <address to load the program to> <path to program file> --reset
solana-test-validator --bpf-program srmqPvymJeFKQ4zGQed1GFppgkRHL9kaELCbyksJtPX openbook.so --reset

Load a local json file keypair
When running your local project you probably want to use a file json keypair. This can be very useful for all the cookbook examples as well. You can grind yourself a keypair using solana-keygen grind --starts-with a23:1 and then load and use this one for your projects using the loadKeypairFromFile function.

load-keypair-from-file.ts
import {
  airdropFactory,
  createKeyPairSignerFromBytes,
  createSolanaRpc,
  createSolanaRpcSubscriptions,
  devnet,
  generateKeyPair,
  getAddressFromPublicKey,
  KeyPairSigner,
  lamports,
} from "@solana/web3.js";
import fs from "fs";
impo


[User] How does Solana's getRecentBlockhash method handle blockhash validity?

[Assistant]
The `getRecentBlockhash` method in Solana returns a recent block hash along with a fee schedule that can be used to compute the cost of submitting a transaction. It provides information about the validity of the blockhash through the following fields in the response:

1. **lastValidSlot**: This field indicates the last slot in which the blockhash will be valid. However, it is marked as deprecated and should not be relied upon due to its inaccuracy.

2. **lastValidBlockHeight**: This field specifies the last block height at which the blockhash will be valid. This is the recommended field to use for determining the validity of the blockhash.

Here is a brief overview of the response structure related to blockhash validity:

- `blockhash`: A base-58 encoded string representing the blockhash.
- `lastValidSlot`: A deprecated field indicating the last slot for validity (not reliable).
- `lastValidBlockHeight`: A field indicating the last block height for validity.

This information helps clients understand how long they can use the returned blockhash for submitting transactions before it becomes invalid.

### Example Response
Here’s an example response from the `getRecentBlockhash` method:

```json
{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 1
    },
    "value": {
      "blockhash": "CSymwgTNX1j3E4qhKfJAUE41nBWEwXufoYryPbkde5RR",
      "feeCalculator": {
        "lamportsPerSignature": 5000
      },
      "lastValidSlot": 297,  // Deprecated
      "lastValidBlockHeight": 296  // Recommended for validity check
    }
  },
  "id": 1
}
```

In summary, while the `lastValidSlot` is provided, it is not reliable, and users should focus on the `lastValidBlockHeight` to determine the validity of the blockhash returned by the `getRecentBlockhash` method.

ed to compute the cost of submitting a transaction using it, and the last slot in which the blockhash will be valid.

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

Parameters #
string required

Pubkey of account to query, as base-58 encoded string

object optional

Configuration object containing the following fields:

commitment string optional

Result #
The result will be an RpcResponse JSON object with value set to a JSON object with the following fields:

blockhash: <string> - a Hash as base-58 encoded string
feeCalculator: <object> - FeeCalculator object, the fee schedule for this block hash
lastValidSlot: <u64> - DEPRECATED - this value is inaccurate and should not be relied upon
lastValidBlockHeight: <u64> - last block height at which the blockhash will be valid
Code sample #
curl https://api.devnet.solana.com -s -X POST -H "Content-Type: application/json" -d '
  { "jsonrpc":"2.0", "id": 1, "method":"getFees"}
'

Response #
{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 1
    },
    "value": {
      "blockhash": "CSymwgTNX1j3E4qhKfJAUE41nBWEwXufoYryPbkde5RR",
      "feeCalculator": {
        "lamportsPerSignature": 5000
      },
      "lastValidSlot": 297,
      "lastValidBlockHeight": 296
    }
  },
  "id": 1
}

getRecentBlockhash RPC Method
Edit Page
Returns a recent block hash from the ledger, and a fee schedule that can be used to compute the cost of submitting a transaction us


[User] What does 'price_change_percentage_24h_in_currency' represent in CoinGecko?

[Assistant]
The `price_change_percentage_24h_in_currency` represents the percentage change in the price of a cryptocurrency over the last 24 hours, expressed in a specific currency. This metric helps users understand how much the price of a coin has fluctuated within the past day relative to the currency specified.

For example, if the price of a cryptocurrency was $100 a day ago and is now $110, the `price_change_percentage_24h_in_currency` would be 10%.

This information is useful for investors and traders to assess the short-term performance of a cryptocurrency.

urrency

price_change_percentage_24h_in_currency object
price_change_percentage_7d_in_currency
object
coin 7d price change in currency

price_change_percentage_7d_in_currency object
price_change_percentage_14d_in_currency
object
coin 14d price change in currency

price_change_percentage_14d_in_currency object
price_change_percentage_30d_in_currency
object
coin 30d price change in currency

price_change_percentage_30d_in_currency object
price_change_percentage_60d_in_currency
object
coin 60d price change in currency

price_change_percentage_60d_in_currency object
price_change_percentage_200d_in_currency
object
coin 200d price change in currency

price_change_percentage_200d_in_currency object
price_change_percentage_1y_in_currency
object
coin 1y price change in currency

price_change_percentage_1y_in_currency object
market_cap_change_24h_in_currency
object
coin 24h market cap change in currency

market_cap_change_24h_in_currency object
market_cap_change_percentage_24h_in_currency
object
coin 24h market cap change in percentage

market_cap_change_percentage_24h_in_currency object
total_supply
number
coin total supply

max_supply
number
coin max supply

circulating_supply
number
coin circulating supply

last_updated
date-time
coin market data last updated timestamp

community_data
object
coin community data

facebook_likes
number
coin facebook likes

twitter_followers
number
coin twitter followers

reddit_average_posts_48h
number
coin reddit average posts in 48 hours

r


[User] What is the purpose of the port number 10000 in QuickNode's gRPC implementation?

[Assistant]
In QuickNode's gRPC implementation, the port number 10000 is designated for establishing a gRPC connection to the QuickNode endpoint. It is part of the connection string that specifies where the gRPC service is hosted. This port is used to facilitate communication between the client and the QuickNode server over the gRPC protocol.

For example, when setting up the connection, you would specify the endpoint as follows:

```go
endpoint = "YOUR_QN_ENDPOINT:10000"
```

This indicates that the client should connect to the specified QuickNode endpoint using port 10000 for gRPC requests.

0000  {10000 is the port number for gRPC}
// token will be : abcde123456789

var (
	endpoint = "YOUR_QN_ENDPOINT:10000"
	token    = "YOUR_TOKEN_NUMBER"
)

func main() {
	opts := []grpc.DialOption{
		grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{})),
		grpc.WithKeepaliveParams(kacp),
		grpc.WithDefaultCallOptions(grpc.MaxCallRecvMsgSize(1024*1024*1024), grpc.UseCompressor(gzip.Name)),
		grpc.WithPerRPCCredentials(tokenAuth{token: token}),
	}

	conn, err := grpc.NewClient(endpoint, opts...)
	if err != null {
		log.Fatalf("Failed to connect: %v", err)
	}
	defer conn.Close()

	client := pb.NewGeyserClient(conn)

    commitment := pb.CommitmentLevel_FINALIZED
    subReq := &pb.SubscribeRequest{
        Commitment: &commitment,
        BlocksMeta: map[string]*pb.SubscribeRequestFilterBlocksMeta{
            "blocks": {},
        },
        Slots: map[string]*pb.SubscribeRequestFilterSlots{
            "slots": {},
        },
    }

    d, _ := json.Marshal(subReq)
    fmt.Printf("Subscription request: %s\n", string(d))

    stream, err := client.Subscribe(context.Background())
    if err != null {
        fmt.Printf("Failed to subscribe to yellowstone: %v\n", err)
        return
    }

    if err = stream.Send(subReq); err != null {
        fmt.Printf("Failed to send subscription request: %v\n", err)
        return
    }

    for {
        m, err := stream.Recv()
        if err != null {
            fmt.Printf("Failed to receive yellowstone message: %v\n", err)


[User] What role does the QueryClient play in a Magic Eden application using React?

[Assistant]
In a Magic Eden application using React, the `QueryClient` plays a crucial role in managing server state and handling data fetching, caching, and synchronization with the server. It is part of the `@tanstack/react-query` library, which provides powerful tools for data fetching and state management.

Here’s how the `QueryClient` is typically utilized:

1. **Data Fetching**: The `QueryClient` is responsible for initiating and managing queries to fetch data from APIs. It helps in making requests and handling responses efficiently.

2. **Caching**: It caches the results of queries, which means that if the same data is requested again, it can be retrieved from the cache instead of making a new network request. This improves performance and reduces unnecessary API calls.

3. **Synchronization**: The `QueryClient` keeps the client state in sync with the server state. It automatically refetches data when it becomes stale or when certain conditions are met, ensuring that the application displays the most up-to-date information.

4. **Error Handling**: It provides built-in mechanisms for handling errors that occur during data fetching, allowing developers to manage error states gracefully.

5. **Integration with React**: By wrapping your application with `QueryClientProvider`, you make the `QueryClient` available throughout your component tree, allowing any component to access and utilize the data fetching capabilities.

Here’s a code snippet illustrating the setup of `QueryClient` in a Magic Eden application:

```javascript
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

// Create a QueryClient instance
const client = new QueryClient();

// Wrap your application with QueryClientProvider
function MyApp({ Component, pageProps }) {
  return (
    <QueryClientProvider client={client}>
      <Component {...pageProps} />
    </QueryClientProvider>
  );
}
```

In this example, the `QueryClient` is created and passed to the `QueryClientProvider`, making it accessible to all components within the application. This setup enables efficient data management and enhances the overall user experience in a Magic Eden application.

llet.

Note:

The ME wallet works out of the box in the RainbowKit default config if a user has the wallet installed on their browser, because all installed wallets that conform to EIP-6963 will be detected. This guide is to illustrate how you can control the specific wallets shown in a custom list.

Installation
Copy
npm install @rainbow-me/rainbowkit wagmi viem@2.x @tanstack/react-query
Implementation
Here we will import the necessary libraries, create a custom connectors list, and a config that communicates with those connectors and Ethereum mainnet.

Once you've done that, you can wrap your application with RainbowKitProvider, WagmiProvider, and QueryClientProvider.

Copy
import "../styles/globals.css";
import "@rainbow-me/rainbowkit/styles.css";
import type { AppProps } from "next/app";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { WagmiProvider } from "wagmi";
import { RainbowKitProvider, connectorsForWallets } from "@rainbow-me/rainbowkit";
import { magicEdenWallet } from "@rainbow-me/rainbowkit/wallets";
import { http, createConfig } from "wagmi";
import { mainnet } from "wagmi/chains";

const connectors = connectorsForWallets(
	[
		{
			groupName: "Recommended",
			wallets: [magicEdenWallet],
		},
	],
	{
		appName: "My RainbowKit App",
		projectId: "YOUR_PROJECT_ID",
	}
);

const config = createConfig({
	connectors,
	chains: [mainnet],
	ssr: true,
	transports: {
		[mainnet.id]: http(),
	},
});

const client = new QueryClient();

f


[User] Can you explain the bi-directional routing engine introduced in Raydium V3?

[Assistant]
Raydium V3 introduces a new bi-directional routing engine that enhances the swapping functionality within the platform. This routing engine allows users to input the exact amount of the quote token they wish to receive from a swap, which is referred to as "Exact Out."

When utilizing the Exact Out feature, the slippage is applied to the base token amount rather than the quote token. This means that users can specify the exact amount they want to receive, and only the amount of the base token paid may vary based on the user's slippage tolerance.

For example, if a user wants to swap tokens and specifies an exact amount of the quote token they wish to receive, the system will calculate how much of the base token is required for that swap, taking into account the slippage tolerance set by the user. This feature provides more control over the swap outcomes and helps prevent unexpected losses due to price fluctuations during the transaction.

Overall, the bi-directional routing engine enhances the user experience by providing more precise control over token swaps on the Raydium platform.

 (strict or all) on top of the Raydium list. You can adjust your token list settings by clicking on a ticker and selecting "view token list".
To prevent users from swapping for an incorrect token, Raydium prompts users to paste the contract address of tokens not included in any of the token lists. You can find this address directly on the project documentation, Raydium pool list, or any explorer.

Exact out: Raydium V3 introduces a new bi-directional routing engine. Raydium's Swap UI now allows you to input the exact amount of quote token you wish to receive from a swap. When using Exact Out the slippage is applied to the base token amount.
For example, you can specify the exact amount you'd like to swap for, with only the amount of base token paid susceptible to deviation from the quote based on your slippage tolerance.

Portfolio
Raydium V3 introduces a new portfolio page, displaying user positions. This page serves as the main interface for users to manage their positions (such as adding/withdrawing liquidity, collecting yield, etc.).
However, users can create pools and positions from the pool list.
This new page also offers quick access for pool and farm creators to edit their incentive campaigns.

Liquidity
The Liquidity Pools page now consolidates all Raydium liquidity under one roof. You can easily access CLMM, Standard (AMM pools), or ALL pools on the same interface.
Additionally, this new page also comes with a card view which can be toggled by clicking the setti


[User] How can the until parameter be utilized in the getSignaturesForAddress method of QuickNode?

[Assistant]
The `until` parameter in the `getSignaturesForAddress` method is used to specify a transaction signature as a stopping point for the query. When you provide the `until` parameter, the method will return confirmed signatures for transactions involving the specified address, but it will stop searching once it encounters the transaction signature you specified.

Here’s how you can utilize the `until` parameter in your request:

### Example Usage

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getSignaturesForAddress",
  "params": [
    "YourBase58EncodedAccountAddress",
    {
      "until": "YourTransactionSignature",
      "limit": 100
    }
  ]
}
```

### Explanation of Parameters:
- **account_address**: This is the required base-58 encoded account address you want to query.
- **until**: This optional parameter specifies the transaction signature to stop the search at. The method will return signatures for transactions that occurred before this signature.
- **limit**: This optional parameter specifies the maximum number of transaction signatures to return. In this example, it is set to 100.

By using the `until` parameter, you can effectively limit the results to only those transactions that occurred before a specific transaction, which can be useful for analyzing historical data or debugging specific transactions.

s
getRecentPrioritizationFees
Next
getSignaturesForAddress
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
getSignaturesForAddress RPC Method
Returns confirmed signatures for transactions involving an address backwards in time from the provided signature or most recent confirmed block. The API credit value for this method is 30.
Updated on
Dec 7, 2023
Please note that the parameter minContextSlot is not a filter on historical transactions. You can use the before or until parameter to filter historical transactions.
Parameters
account_address
string
REQUIRED
The account address encoded as base-58 string
object
array
(Optional) The configuration object with the following fields:
limit
integer
The maximum number of transaction signatures to return (between 1 and 1000). The default value is 1000
before
string
Start searching backward from this transaction signature. If not provided, the search starts from the top of the highest max confirmed block
until
string
Searches until this transaction signature, if found before limit reached
commitment
string
The level of commitment required for the query. The options include:
finalized
string
The node will query the most recent block confirmed by the supermajority of the cluster as having reached maximum lo


[User] How can a user specify their referral wallet when changing a sell price on Magic Eden?

[Assistant]
To specify a referral wallet when changing a sell price on Magic Eden, a user needs to include the `sellerReferral` query parameter in their request to the `sell_change_price` endpoint.

Here’s how the request should be structured:

### Request URL
```
GET https://api-mainnet.magiceden.dev/v2/instructions/sell_change_price
```

### Query Parameters
- `seller`: (string, required) Seller wallet
- `auctionHouseAddress`: (string, optional) Auction house Address. If not provided, the default auction house will be used.
- `tokenMint`: (string, required) Token mint address
- `tokenAccount`: (string, required) Token account
- `price`: (number, required) Price in SOL
- `newPrice`: (number, required) New price in SOL
- `sellerReferral`: (string, optional) Seller referral wallet
- `expiry`: (number, optional) Timestamp in seconds in the future; 0 means no expiry
- `priorityFee`: (number, optional) Priority fee (in microlamports) to reprioritize the transaction against others

### Example Request
Here is an example of how to change the sell price while specifying the referral wallet:

```bash
curl --request GET \
     --url 'https://api-mainnet.magiceden.dev/v2/instructions/sell_change_price?seller=YOUR_SELLER_WALLET&tokenMint=YOUR_TOKEN_MINT&tokenAccount=YOUR_TOKEN_ACCOUNT&price=OLD_PRICE&newPrice=NEW_PRICE&sellerReferral=YOUR_REFERRAL_WALLET' \
     --header 'accept: application/json'
```

Make sure to replace `YOUR_SELLER_WALLET`, `YOUR_TOKEN_MINT`, `YOUR_TOKEN_ACCOUNT`, `OLD_PRICE`, `NEW_PRICE`, and `YOUR_REFERRAL_WALLET` with the actual values relevant to your transaction.

This will include the referral wallet in the request when changing the sell price.

mainnet.magiceden.dev/v2/instructions/sell \
3
     --header 'accept: application/json'

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

200
Get instruction to change a sell price
get
https://api-mainnet.magiceden.dev/v2/instructions/sell_change_price
Log in to see full request history
time	status	user agent
Make a request to see history.
0 Requests This Month

Query Params
seller
string
required
Seller wallet

auctionHouseAddress
string
Auction house Address. If not provided, will use default auction house.

tokenMint
string
required
Token mint address

tokenAccount
string
required
Token account

price
number
required
Price in SOL

newPrice
number
required
New price in SOL

sellerReferral
string
Seller referral wallet

expiry
number
timestamp in seconds in the future, 0 means no expiry

priorityFee
number
Priority fee (in microlamports) to reprioritize the transaction against others

Response

200
successful operation

Updated about 1 year ago

Get instruction to sell (list)
Get instruction to sell now (accept offer)
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
Credentials
Bearer
auth-scheme
token

URL

https://api-mainnet.magiceden.dev/v2
/instructions/sell_change_price
1
curl --request GET \
2
     --url https://api-mainnet.magiceden.dev/v2/instructions/sell_change_price \
3
     --header 'accept: application/json'

Try It!
RESPONSE
Click Try It! to start a request and see the respons


[User] What type of parameter is 'transaction' in Tatum's sendTransaction method?

[Assistant]
In Tatum's `sendTransaction` method, the `transaction` parameter is of type `string` and is required. It represents a fully-signed transaction, provided as an encoded string.

For example, it would look like this:

```javascript
transaction: '4hXTCkRzt9WyecNzV1XPgCDfGAZzQKNxLXgynz5QDuWWPSAZBZSHptvWRL3BjCvzUXRdKvHL2b7yGrRQcWyaqsaBCncVG7BFggS8w9snUts67BSh3EqKpXLUm5UMHfD7ZBe9GhARjbNQMLJ1QD3Spr6oMTBU6EhdB4RD8CP2xUxr2u3d6fos36PD98XS6oX8TQjLpsMwncs5DAMiD4nNnR8NBfyghGCWvCVifVwvA8B8TJxE1aiyiv2L429BCWfyzAme5sZW8rDb14NeCQHhZbtNqfXhcp2tAnaAT'
```

hich is used to identify the transaction (transaction id). This identifier can be easily extracted from the transaction data before submission.

Parameters
transaction(string, required): Fully-signed Transaction, as an encoded string.
Example: '4hXTCkRzt9WyecNzV1XPgCDfGAZzQKNxLXgynz5QDuWWPSAZBZSHptvWRL3BjCvzUXRdKvHL2b7yGrRQcWyaqsaBCncVG7BFggS8w9snUts67BSh3EqKpXLUm5UMHfD7ZBe9GhARjbNQMLJ1QD3Spr6oMTBU6EhdB4RD8CP2xUxr2u3d6fos36PD98XS6oX8TQjLpsMwncs5DAMiD4nNnR8NBfyghGCWvCVifVwvA8B8TJxE1aiyiv2L429BCWfyzAme5sZW8rDb14NeCQHhZbtNqfXhcp2tAnaAT'
options (object, optional): An object containing various options for the request.
encoding (string, optional): Encoding used for the transaction data.
Values: base58 (slow, DEPRECATED), or base64.
skipPreflight (boolean, optional): If "true", skip the preflight transaction checks.
preflightCommitment(string, optional): Commitment level to use for preflight.
Values: finalised confirmed processed
maxRetries(number, optional): Maximum number of times for the RPC node to retry sending the transaction to the leader.
minContextSlot (number, optional): Set the minimum slot at which to perform preflight transaction checks.
Return Object
The method returns a base-58 encoded string value which is the first Transaction Signature embedded in the transaction. This is used to identify the transaction.

JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sendTransaction",
  "params": [
    "4hXTCkRzt9WyecNzV1XPgCDfGAZzQKNxLXgynz5QDuWWPS


[User] What happens if the destinationTokenAccount is set when using the wrapAndUnwrapSol parameter in QuickNode?

[Assistant]
When the `destinationTokenAccount` is set while using the `wrapAndUnwrapSol` parameter in QuickNode, the `wrapAndUnwrapSol` parameter will be ignored. This is because the `destinationTokenAccount` may belong to a different user, and QuickNode does not have the authority to close that account.

By default, the `wrapAndUnwrapSol` parameter is set to true, which means that if it were not for the presence of the `destinationTokenAccount`, the system would automatically wrap or unwrap SOL. However, since the `destinationTokenAccount` is specified, the behavior of wrapping or unwrapping SOL will not take effect.

Here’s a brief summary of the relevant behavior:

- **If `destinationTokenAccount` is set:** `wrapAndUnwrapSol` is ignored.
- **If `destinationTokenAccount` is not set:** `wrapAndUnwrapSol` will determine whether to wrap/unwrap SOL (default is true).

This ensures that the operation respects the ownership and authority constraints of the specified token accounts.

us 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
/swap-instructions REST API Endpoint
Returns instructions that you can use from the quote you get from /quote.
Updated on
Sep 20, 2024
Please note that this method is available for Free and Paid subscribers of Metis - Jupiter V6 Swap API, along with jupiterapi.com users.
Solana Web3.js 2.0 includes the ability to customize RPC methods and transports, allowing you to seamlessly integrate QuickNode Marketplace add-ons into your applications. For more information on how to use QuickNode Marketplace add-ons with Solana Web3.js 2.0, check out these guides: How to Use QuickNode Add-ons using Solana Web3.js 2.0 (Part 1) and How to Use QuickNode Add-ons using Solana Web3.js 2.0 (Part 2)
Important: Always use the parameter useQNMarketCache=true when working with new markets that have been added via POST /markets. Please see /markets documentation for more details.

Query Parameters
userPublicKey
string
REQUIRED
The user public key
wrapAndUnwrapSol
boolean
If set to true, it will automatically wrap/unwrap SOL. If it is false, it will use wSOL token account. It will be ignored if destinationTokenAccount is set because the destinationTokenAccount may belong to a different user that we have no authority to close. By default, it is set to true
useSharedAccounts
boolean
This enables


[User] What is the purpose of the 'getSignaturesForAddress' method in Alchemy?

[Assistant]
The `getSignaturesForAddress` method in Alchemy is used to retrieve the transaction signatures associated with a specific Solana address. This method allows users to see the history of transactions that have been made to or from a given address, providing insights into the activity and interactions of that address on the Solana blockchain.

### Key Features:
- It returns an array of transaction signatures.
- Each signature includes details such as the block time, confirmation status, and any errors associated with the transaction.

### Example Usage:
Here is an example of how to use the `getSignaturesForAddress` method with a cURL request:

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

### Response Structure:
The response will include:
- `blockTime`: The time when the block containing the transaction was confirmed.
- `confirmationStatus`: The status of the transaction confirmation (e.g., finalized).
- `err`: Any error associated with the transaction (if applicable).
- `signature`: The Base-58 encoded string representing the transaction signature.
- `slot`: The slot number that contains the block with the transaction.

### Example Response:
```json
{
    "jsonrpc": "2.0",
    "result": [
        {
            "blockTime": 1654173549,
            "confirmationStatus": "finalized",
            "err": null,
            "memo": null,
            "signature": "67iWWgeXYSXxKmxMjAahr9ATXvv1SJoHedXYZxicFQtF4eFxCWJxUwEYczNbrua8pQAshmkf73gfAX5itutWTA7m",
            "slot": 136105283
        }
    ],
    "id": 1
}
```

This method is particularly useful for developers and users interested in tracking the transaction history of specific addresses on the Solana blockchain.

s://solana-mainnet.g.alchemy.com/v2/demo/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSignaturesForAddress",
    "params": [
        "Vote111111111111111111111111111111111111111",
        {
            "limit": 1
        }
    ]
}'

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": "getSignaturesForAddress"
}
'

Response
JavaScript

{
    "jsonrpc": "2.0",
    "result": [
        {
            "blockTime": 1654173549,
            "confirmationStatus": "finalized",
            "err": null,
            "memo": null,
            "signature": "67iWWgeXYSXxKmxMjAahr9ATXvv1SJoHedXYZxicFQtF4eFxCWJxUwEYczNbrua8pQAshmkf73gfAX5itutWTA7m",
            "slot": 136105283
        }
    ],
    "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 getSignaturesForAddress
getSignaturesForAddress
params
array

ADD
Response

200
Response body
object
id
integer
jsonrpc
string
result
array of objects
object
signature
string
Base-58 Encoded String - Transaction signature as

slot
int64
u64 - The slot that contains the block with the transaction.

err
string | null
Error if trans


[User] How can I obtain a higher throughput for my Alchemy API usage?

[Assistant]
To obtain a higher throughput for your Alchemy API usage, you need to create your own API key instead of using the default `docs-demo` key. The default key is limited in terms of throughput, so by generating a personal API key, you can access higher limits.

Here’s how you can set it up:

1. **Create Your Own API Key**: Sign up for an Alchemy account and generate your API key from the Alchemy dashboard.

2. **Use Your API Key in Requests**: Replace `docs-demo` with your newly created API key in your API requests.

For example, if you want to check if a blockhash is valid using your API key, your `curl` command would look like this:

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

Make sure to replace `YOUR_API_KEY` with the actual API key you obtained from the Alchemy dashboard. This will allow you to take advantage of higher throughput limits.

        "value": false
    },
    "id": 45
}
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 isBlockhashValid
isBlockhashValid
params
array

Option 1

Option 2

Option 1

Option 2

ADD

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": "isBlockhashValid"
}
'

Response

200
Response body
object | null
id
integer
jsonrpc
string
result
boolean
True if the blockhash is still valid.

minimumLedgerSlot
post
https://{network}.g.alchemy.com/v2/{apiKey}
Returns the lowest slot that the node has information about in its ledger. This value may increase over time if the node is configured to purge older ledger data.

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 minimumLedgerSlot
minimumLedgerSlot

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": "minimumLedgerSlot"
}
'

Response

200
Re


[User] What method does Solana use for clients to submit transactions to RPC servers?

[Assistant] Clients submit transactions to RPC servers using the `sendTransaction` JSON-RPC method. This method allows the client to send a transaction to the RPC node, which then attempts to broadcast the transaction to both the current and next leaders in the Solana network.

By proxy via an RPC server and the sendTransaction JSON-RPC method
Directly to leaders via a TPU Client
The vast majority of end-users will submit transactions via an RPC server. When a client submits a transaction, the receiving RPC node will in turn attempt to broadcast the transaction to both the current and next leaders. Until the transaction is processed by a leader, there is no record of the transaction outside of what the client and the relaying RPC nodes are aware of. In the case of a TPU client, rebroadcast and leader forwarding is handled entirely by the client software.

Overview of a transactions journey, from client to leader
Overview of a transactions journey, from client to leader

How RPC Nodes Broadcast Transactions #
After an RPC node receives a transaction via sendTransaction, it will convert the transaction into a UDP packet before forwarding it to the relevant leaders. UDP allows validators to quickly communicate with one another, but does not provide any guarantees regarding transaction delivery.

Because Solana's leader schedule is known in advance of every epoch (~2 days), an RPC node will broadcast its transaction directly to the current and next leaders. This is in contrast to other gossip protocols such as Ethereum that propagate transactions randomly and broadly across the entire network. By default, RPC nodes will try to forward transactions to leaders every two seconds until either the transaction is finalized or the transaction's blockhash exp


[User] What is the expected format of the notification response from Solana when a signature is processed?

[Assistant]
The expected format of the notification response from Solana when a signature is processed is as follows:

The notification will be an `RpcResponse` JSON object with a `value` containing an object with the following fields:

- `slot`: `<u64>` - The corresponding slot.
- `value`: `<object|string>` - A notification value of `RpcSignatureResult`, which can result in either:
  - If `enableReceivedNotification` is true and the signature is received: the literal string `"receivedSignature"`, or
  - When the signature is processed:
    - `err`: `<object|null>`:
      - `null` if the transaction succeeded in being processed at the specified commitment level, or
      - A `TransactionError`, if the transaction failed.

### Example Response
Here is an example response of a notification from a successfully processed transaction:

```json
{
  "jsonrpc": "2.0",
  "method": "signatureNotification",
  "params": {
    "slot": 123456,
    "value": {
      "err": null
    }
  }
}
```

In this example, the transaction was successfully processed, indicated by `err: null`.

ust be the first signature from the transaction (see transaction id for more details).

object optional

Configuration object containing the following fields:

commitment string optional

enableReceivedNotification bool optional

Whether or not to subscribe for notifications when signatures are received by the RPC, in addition to when they are processed.

Result #
<integer> - subscription id (needed to unsubscribe)

Code sample #
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "signatureSubscribe",
  "params": [
    "2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b",
    {
      "commitment": "finalized",
      "enableReceivedNotification": false
    }
  ]
}

Response #
{ "jsonrpc": "2.0", "result": 0, "id": 1 }

Notification Format: #
The notification will be an RpcResponse JSON object with value containing an object with:

slot: <u64> - The corresponding slot.
value: <object|string> - a notification value of RpcSignatureResult, resulting in either:
when enableReceivedNotification is true and the signature is received: the literal string "receivedSignature", or
when the signature is processed: err: <object|null>:
null if the transaction succeeded in being processed at the specified commitment level, or
a TransactionError, if the transaction failed
Example responses: #
The following is an example response of a notification from a successfully processed transactions:

{
  "jsonrpc": "2.0",
  "method": "signatureNotification",
  "params": {


[User] How does DexScreener define 'Market Activity' in relation to a token's performance?

[Assistant]
DexScreener defines 'Market Activity' in relation to a token's performance through several key metrics that reflect the token's trading dynamics. The specific metrics considered under Market Activity include:

1. **Volume**: This indicates the total amount of the token traded over a specific period, showcasing how actively the token is being bought and sold.

2. **Liquidity**: This measures how easily the token can be traded without causing significant price changes, indicating the availability of buy and sell orders.

3. **Transactions**: The total number of trades executed for the token, which helps gauge the level of trading activity.

4. **Unique Makers**: This refers to the number of distinct addresses that have participated in trading the token, providing insight into the diversity of the token's trading community.

5. **Holders**: The number of unique addresses holding the token, which can indicate the level of interest and investment in the token.

These metrics collectively contribute to the assessment of a token's performance and its Trending Score on DexScreener.

s every token on the platform a Trending Score - a snapshot of the token's buzz and market activity. This score is used to rank tokens on the trending screener and trending bar, showcasing the hottest pairs at any given time.

While we keep the special blend of our algorithm close to our chest, here are some of the key metrics we take into account:

Market Activity
Volume

Liquidity

Transactions

Unique makers

Holders

Community Engagement
Visitors on the token's DEX Screener page, both on website and app

Reactions: how the community feels about the token 🚀 🔥 💩 🚩

Trust & Credibility
Tokens with verified info get a boost, especially those with Enhanced Token Info

Security audit: we value tokens that are open-source and pass security checks with flying colors

For projects keen on climbing the trending list, a robust trading activity and community engagement on DEX Screener are your tickets to the top!

⚡
Boosting
What are Boosts?
Boosts are a powerful way to amplify a token's presence on DEX Screener. By purchasing a Boost pack you can temporarily increase a token's Trending Score, helping it gain more visibility. Boosts last from 12 to 24 hours depending on the pack, and the number of active Boosts is prominently displayed next to the token across the platform. The more Boosts, the bigger the bragging rights — and the higher the token's score!

What is the Golden Ticker?
The Golden Ticker is the ultimate flex for any token on DEX Screener. It's unlocked when 500 or more


[User] How does the subscription mechanism work for receiving notifications in Solana?

[Assistant]
In Solana, the subscription mechanism allows users to receive notifications about changes to accounts or logs related to specific programs. There are two primary RPC methods for this purpose: `programSubscribe` and `logsSubscribe`.

### 1. `programSubscribe` RPC Method

This method is used to subscribe to a program, allowing you to receive notifications when the lamports or data for an account owned by the specified program changes.

#### Parameters:
- **string required**: The public key of the `program_id`, provided as a base-58 encoded string.
- **object optional**: A configuration object that can contain the following fields:
  - **commitment string optional**: Specifies the commitment level (e.g., "finalized").
  - **filters array optional**: Allows filtering of results based on various criteria. The resultant account must meet all filter criteria to be included in the returned results.
  - **encoding string optional**: Specifies the encoding format for account data. Possible values include `base58`, `base64`, `base64+zstd`, and `jsonParsed`.

#### Result:
- Returns an **integer** which is the subscription ID needed to unsubscribe later.

#### Code Example:
```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "programSubscribe",
  "params": [
    "11111111111111111111111111111111",
    {
      "encoding": "base64",
      "commitment": "finalized"
    }
  ]
}
```

### 2. `logsSubscribe` RPC Method

This method allows you to subscribe to logs generated by transactions, enabling you to receive notifications when new logs are created.

#### Parameters:
- **object required**: An object that can contain various fields to specify the subscription criteria.
- **commitment string optional**: Specifies the commitment level.
- **filters array optional**: Allows filtering of logs based on specific criteria.

#### Result:
- Returns an **integer** which is the subscription ID needed to unsubscribe later.

### Unsubscribing

To unsubscribe from either type of subscription, you would use the `logsUnsubscribe` or `programUnsubscribe` methods, providing the subscription ID as a parameter.

#### Code Example for Unsubscribing:
```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "logsUnsubscribe",
  "params": [0]
}
```

### Summary

The subscription mechanism in Solana is designed to provide real-time notifications about changes in account data or logs, allowing developers to build responsive applications that react to blockchain events.

          "SBF program 83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri success"
        ]
      }
    },
    "subscription": 24040
  }
}

logsUnsubscribe RPC Method
Edit Page
Unsubscribe from transaction logging

Parameters #
integer required

subscription id to cancel

Result #
<bool> - unsubscribe success message

Code sample #
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "logsUnsubscribe",
  "params": [0]
}

Response #
{ "jsonrpc": "2.0", "result": true, "id": 1 }

programSubscribe RPC Method
Edit Page
Subscribe to a program to receive notifications when the lamports or data for an account owned by the given program changes

Parameters #
string required

Pubkey of the program_id, as base-58 encoded string

object optional

Configuration object containing the following fields:

commitment string optional

filters array optional

filter results using various filter objects

Info
The resultant account must meet ALL filter criteria to be included in the returned results

encoding string optional

Encoding format for Account data

Values: base58base64base64+zstdjsonParsed

Details
Result #
<integer> - Subscription id (needed to unsubscribe)

Code sample #
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "programSubscribe",
  "params": [
    "11111111111111111111111111111111",
    {
      "encoding": "base64",
      "commitment": "finalized"
    }
  ]
}
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "programSubscribe",
  "params": [
    "11111111111111111111111111111111",
    {
      "e


[User] What is the significance of the `getSetComputeUnitPriceInstruction` in the transaction message?

[Assistant]
The `getSetComputeUnitPriceInstruction` in the transaction message is used to specify the compute unit price for the transaction. This instruction allows the transaction sender to set a priority fee, which is expressed in microLamports.

In the provided code example, the instruction is included in the transaction message as follows:

```javascript
getSetComputeUnitPriceInstruction({
  microLamports: 200_000,
}),
```

Here, the compute unit price is set to 200,000 microLamports. This is significant because it allows the sender to influence the processing priority of their transaction. By setting a higher compute unit price, the sender can ensure that their transaction is prioritized by the network, which can be particularly important during times of high congestion or when immediate execution is desired.

Overall, this instruction plays a crucial role in managing transaction costs and prioritization on the Solana network.

actory({
  rpc,
  rpcSubscriptions,
});

const space = 0n; // any extra space in the account
const rentLamports = await rpc.getMinimumBalanceForRentExemption(space).send();
console.log("Minimum balance for rent exception:", rentLamports);

// todo: load your own signer with SOL
const signer = await generateKeyPairSigner();

// generate a new keypair and address to create
const newAccountKeypair = await generateKeyPairSigner();
console.log("New account address:", newAccountKeypair.address);

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

const transactionMessage = pipe(
  createTransactionMessage({ version: "legacy" }),
  tx => setTransactionMessageFeePayerSigner(signer, tx),
  tx => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, tx),
  tx =>
    appendTransactionMessageInstructions(
      [
        // add a priority fee
        getSetComputeUnitPriceInstruction({
          microLamports: 200_000,
        }),
        // create the new account
        getCreateAccountInstruction({
          lamports: rentLamports,
          newAccount: newAccountKeypair,
          payer: signer,
          space: space,
          // "wallet" accounts are owned by the system program
          programAddress: SYSTEM_PROGRAM_ADDRESS,
        }),
      ],
      tx,
    ),
);

const signedTransaction =
  await signTransactionMessageWithSigners(transactionMessage);
const signature = getSignatureFromTransaction(signedTransaction);

await sendAndConfirmTr


[User] How does DexScreener ensure the prevention of fraudulent use of user accounts through its cookies?

[Assistant]
DexScreener utilizes Session Cookies to help authenticate users and prevent fraudulent use of user accounts. These Session Cookies are essential for providing the services available on the website and enable users to utilize various features securely. Specifically, they help in verifying user identities and ensuring that unauthorized access is minimized.

Without these Session Cookies, the necessary authentication processes could not be effectively implemented, leading to potential vulnerabilities in user account security. Therefore, the use of Session Cookies is a critical component in maintaining the integrity and security of user accounts on DexScreener.

ated website statistics (for example, recording the popularity of a certain section and verifying system and server integrity).

Cookies can be "Persistent" or "Session" Cookies. Persistent Cookies remain on Your personal computer or mobile device when You go offline, while Session Cookies are deleted as soon as You close Your web browser. Learn more about cookies on the Privacy Policies website article.

We use both Session and Persistent Cookies for the purposes set out below:

Necessary / Essential Cookies

Type: Session Cookies

Administered by: Us

Purpose: These Cookies are essential to provide You with services available through the Website and to enable You to use some of its features. They help to authenticate users and prevent fraudulent use of user accounts. Without these Cookies, the services that You have asked for cannot be provided, and We only use these Cookies to provide You with those services.

Cookies Policy / Notice Acceptance Cookies

Type: Persistent Cookies

Administered by: Us

Purpose: These Cookies identify if users have accepted the use of cookies on the Website.

Functionality Cookies

Type: Persistent Cookies

Administered by: Us

Purpose: These Cookies allow us to remember choices You make when You use the Website, such as remembering your login details or language preference. The purpose of these Cookies is to provide You with a more personal experience and to avoid You having to re-enter your preferences every time You use the Website.

For mo


[User] What resources does Magic Eden provide for user support and FAQs?

[Assistant] Magic Eden provides user support and FAQs through their support articles. Users can reach out or reference these articles for assistance with user-oriented concerns. Additionally, users can find resources on their website, Discord, and Linktree.

directly in the wallet that enable you to connect anywhere and collect everywhere

Download Here:
Browser Extension

IOS app

Android app

Resources
Website

X

Discord

Linktree

The majority of these docs are intended to help developers build applications that interact with the Magic Eden Wallet. For user oriented concerns and FAQs, please reach out or reference our support articles here.

Diving into Bitcoin
The Magic Eden wallet has native support for all things Bitcoin, Ordinals and Runes. Since there are currently not as many go-to wallet frameworks, this section will give you a step by step walkthrough on how to integrate the ME wallet into your dApp. We'll also explore creating and signing PSBTs (partially signed Bitcoin transactions).

Direct Integration
The most straightforward way to interact with the ME wallet on the Bitcoin network is via the provider that is globally available at window.magicEden.bitcoin. This unique namespace ensures that the ME BTC provider is always available in the window. The ME BTC provider also attempts to inject at window.BitcoinProvider, but this can occasionally clash if users have multiple Bitcoin browser wallets installed.

The Bitcoin Wallet Standard
The ME Bitcoin wallet makes use of the Bitcoin Wallet Standard, an extension of the chain agnostic Wallet Standard. This standard makes use of a set of interfaces and conventions designed to improve the user experience and developer experience of wallets and applications. You can use t


[User] How do you initialize a new Client instance for QuickNode's Yellowstone gRPC in TypeScript?

[Assistant]
To initialize a new `Client` instance for QuickNode's Yellowstone gRPC in TypeScript, you need to import the `Client` class from the `@rpcpool/yellowstone-grpc` package and provide the necessary parameters, including the endpoint URL and an authentication token.

Here’s a step-by-step example:

1. **Install the required package** (if you haven't already):
   ```bash
   npm install @rpcpool/yellowstone-grpc
   ```

2. **Import the Client class** in your TypeScript file:
   ```typescript
   import { Client } from '@rpcpool/yellowstone-grpc';
   ```

3. **Define your endpoint and token**:
   ```typescript
   const ENDPOINT = 'https://example-guide-demo.solana-mainnet.quiknode.pro:10000';
   const TOKEN = '123456789';
   ```

4. **Create a new Client instance**:
   ```typescript
   const client = new Client(ENDPOINT, TOKEN, {});
   ```

This code snippet demonstrates how to set up a `Client` instance that can communicate with the Yellowstone plugin using the specified endpoint and authentication token.

 2024
Share this doc
Previous
Overview
Next
Setting up TypeScript
Overview
Authentication for Go Requests
Basic Authentication
x-token Authentication
Initiating the Go Project for Yellowstone gRPC
We ❤ Feedback!
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
Making Yellowstone gRPC (Geyser Plugin) Requests with TypeScript
Updated on
Dec 13, 2024
Overview
TypeScript is a strongly-typed superset of JavaScript, offering improved developer experience and tooling support. This document provides a step-by-step process for setting up a TypeScript environment for interacting with Yellowstone gRPC, including setting up a project, configuring dependencies, and implementing authentication mechanisms.

Authentication Required for TypeScript
Creates a client in order to communicate with a Yellowstone plugin. It uses an endpoint URL and an authentication token for secure access.

import { Client } from '@rpcpool/yellowstone-grpc';

// For HTTP Provider URL: https://example-guide-demo.solana-mainnet.quiknode.pro/123456789/

const ENDPOINT = 'https://example-guide-demo.solana-mainnet.quiknode.pro:10000';
const TOKEN = '123456789';
const client = new Client(ENDPOINT, TOKEN, {});

Note:
To learn how to split your Solana Yellowstone enabled URL into endpoint


[User] What interactive example is provided in the documentation for the getTokenAccountsByOwner method in ChainStack?

[Assistant] The documentation mentions an interactive example that fetches the GME tokens owned by an account on the Solana mainnet using the `getTokenAccountsByOwner` method. This example demonstrates how to retrieve a list of accounts owned by a specified wallet, filtered by their associated token.

ce",
10
  "params": [
11
    "3emsAVdmGKERbHjmGfQ6oZ1e35dkf5iYcS6U4CPKFVaa"
12
  ]
13
}
14
'
getTokenAccountsByOwner | Solana
post
https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/
📘
Not available on the Developer plan

The method is available only on the paid plans.

The Solana getTokenAccountsByOwner method retrieves a list of accounts owned by a specified wallet, filtered by their associated token.

This method is useful for identifying all accounts associated with a particular owner and a specific token, allowing for a comprehensive view of token distribution and ownership.

📘
The interactive example fetches the GME tokens owned by an account on Solana mainnet.

👍
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
delegatePubkey — the base-58 encoded string representing the public key of the account delegate to query.
filters — a JSON object with one of the following fields:
mint — the base-58 encoded string of the specific token Mint to limit accounts to.
programId — the base-58 encoded string of the Token program that owns the accounts.
config (optional) — configuration object containing the following fields:
commitment (optional) — the level of commitment desired for the query.
minContextSlot (optional) — te minimum slot that the request can be evaluated at.
dataSlice (optional) — request a slice of t


[User] What is the significance of excluding subdirectories in Solana's wildcard path matching rules?

[Assistant]
In Solana's wildcard path matching rules, excluding subdirectories is significant because it allows for more precise control over how requests are routed. When a wildcard path pattern is defined to match only a specific directory (e.g., `/actions/*`), it ensures that only the immediate paths under that directory are matched, while any deeper paths (subdirectories) are not included in the match.

This specificity can be crucial for several reasons:

1. **Controlled Routing**: By excluding subdirectories, developers can ensure that only certain endpoints are accessible through the wildcard rule. This prevents unintended access to deeper nested paths that may not be intended for public use or may require different handling.

2. **Simplified API Management**: It allows for clearer organization and management of API endpoints. For instance, if you have a structure where certain actions are grouped under a directory, you can easily manage those without affecting other parts of the API that might reside in subdirectories.

3. **Security**: Limiting the match to a specific directory can enhance security by reducing the attack surface. If only certain paths are exposed, it minimizes the risk of exposing sensitive endpoints that might exist in subdirectories.

4. **Performance Optimization**: By narrowing down the matching criteria, it can lead to performance improvements as the routing logic can be simpler and faster when it doesn’t have to consider deeper paths.

Here’s an example of a wildcard path matching rule that excludes subdirectories:

```json
{
  "rules": [
    {
      "pathPattern": "/actions/*",
      "apiPath": "/api/actions/*"
    }
  ]
}
```

In this example, only requests to paths directly under `/actions/` will be matched, such as `/actions/create` or `/actions/delete`, but not `/actions/subdir/create`. This ensures that the routing is intentional and controlled.

s
*	A single path segment, not including the surrounding path separator / characters.
**	Matches zero or more characters, including any path separator / characters between multiple path segments. If other operators are included, the ** operator must be the last operator.
?	Unsupported pattern.
Rules Examples #
The following example demonstrates an exact match rule to map requests to /buy from your site's root to the exact path /api/buy relative to your site's root:

actions.json
{
  "rules": [
    {
      "pathPattern": "/buy",
      "apiPath": "/api/buy"
    }
  ]
}

The following example uses wildcard path matching to map requests to any path (excluding subdirectories) under /actions/ from your site's root to a corresponding path under /api/actions/ relative to your site's root:

actions.json
{
  "rules": [
    {
      "pathPattern": "/actions/*",
      "apiPath": "/api/actions/*"
    }
  ]
}

The following example uses wildcard path matching to map requests to any path (excluding subdirectories) under /donate/ from your site's root to a corresponding absolute path https://api.dialect.com/api/v1/donate/ on an external site:

actions.json
{
  "rules": [
    {
      "pathPattern": "/donate/*",
      "apiPath": "https://api.dialect.com/api/v1/donate/*"
    }
  ]
}

The following example uses wildcard path matching for an idempotent rule to map requests to any path (including subdirectories) under /api/actions/ from your site's root to itself:

Info
Idempotent rules allow blink


[User] What does Alchemy return when the method 'getBlock' is called?

[Assistant]
When the method `getBlock` is called in Alchemy, it returns a "Confirmed Block" object containing the following fields:

- **blockhash**: A base-58 encoded string representing the blockhash of the given block.
- **previousBlockhash**: A base-58 encoded string representing the blockhash of this block's parent. If the parent block is not available due to ledger cleanup, this field will return "11111111111111111111111111111111".
- **parentSlot**: A `u64` value representing the slot index of this block's parent.
- **transactions**: A JSON array containing transaction details when queried with the "full" flag under transactionDetails.
- **transaction**: An object or an array containing the encoded transaction object.
- **meta**: An object containing transaction status metadata, which may include:
  - **err**: An object or null. If the transaction failed, it contains an error message; if it succeeded, it is null.
  - **fee**: A `u64` value representing the fee for this transaction.
  - **preBalances**: An array of `u64` values representing account balances from before the transaction was processed.
  - **postBalances**: An array of `u64` values representing account balances after the transaction was processed.
  - **innerInstructions**: An array or null, which lists inner instructions; it is null if not enabled during this transaction.
  - **preTokenBalances**: An array or undefined, which lists token balances from before the transaction was processed or is undefined if token balance recording was not yet enabled during this transaction.
  - **postTokenBalances**: An array or undefined, which lists token balances from after the transaction was processed or is undefined if token balance recording was not yet enabled during this transaction.

This structure provides comprehensive information about the block and its associated transactions.

ntent-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getBlock"
}
'

Returns
Confirmed Block
<object> - Object
blockhash: < base-58 encoded string> - blockhash of a given block
previousBlockhash:< base-58 encoded string> - the blockhash of this block's parent. If the parent block is not available due to ledger cleanup, this field will return "11111111111111111111111111111111"
parentSlot: <u64> - the slot index of this block's parent
transactions: <JSON array> - transaction details when queried with the "full" flag under transactionDetails
transaction: <object|[string,encoding]> - encoded transaction object
meta: <object> - transaction status metadata object, containing null or:
err: <object | null> - If transaction failed, error message. If transaction succeeded null.
fee: <u64> - fee for this transaction
preBalances: <array of u64s> - account balances from before the transaction was processed
postBalances: <array of u64s> - account balances after the transaction was processed
innerInstructions: <array|null> - List of inner instructions
null if not enabled during this transaction
preTokenBalances: <array|undefined> - List of token balances from before the transaction was processed or
Undefined if token balance recording was not yet enabled during this transaction
postTokenBalances: <array|undefined> - List of token balances from after the transaction was processed
Undefined if token balance recording was not yet enabled during this transa


[User] What is the significance of the boolean result returned by ChainStack's isBlockhashValid method?

[Assistant]
The boolean result returned by ChainStack's `isBlockhashValid` method is significant as it indicates whether a given blockhash is still valid for transaction submission.

- **True**: If the result is `true`, it means that the blockhash is valid and can be used for submitting transactions. This ensures that the transaction will not fail due to using an expired blockhash.

- **False**: If the result is `false`, it indicates that the blockhash is no longer valid and should not be used for transaction submission. Using an invalid blockhash could lead to transaction failures.

This method is crucial for developers to ensure that they are using up-to-date blockhashes, thereby enhancing the reliability of their transactions on the Solana blockchain.

son' \
5
     --data '
6
{
7
  "id": 1,
8
  "jsonrpc": "2.0",
9
  "method": "getTransaction",
10
  "params": [
11
    "4VAGET7z5g7ogVGmbmZ6KBtF6DS8ftLWzD65BXZWQJjwASUqLod7LhGB6mqThcqo97QcC7r7uNmBY8GwsnLAA52n",
12
    {
13
      "encoding": "jsonParsed",
14
      "maxSupportedTransactionVersion": 0
15
    }
16
  ]
17
}
18
'

isBlockhashValid | Solana
post
https://solana-mainnet.core.chainstack.com/83e0d6661ee0488e22e167c18818cb38/
The Solana isBlockhashValid method checks whether a given blockhash is still valid.

This method is useful for determining if a previously fetched blockhash can still be used for transaction submission. It helps prevent the use of expired blockhashes, which would cause transactions to fail.

👍
Get your 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
blockhash — the blockhash to validate, as a base-58 encoded string.
commitment — (optional) the level of commitment desired:
processed — the node has processed the block and the block may be on a fork.
confirmed — the block is confirmed by the cluster as not being on a fork.
finalized — the block is finalized by the cluster.
Response
result — a boolean indicating whether the blockhash is still valid:
true — the blockhash is valid and can be used for transaction submission.
false — the blockhash is no longer valid and should not be used.
Use case
A practical us


[User] What is the role of Prioritization Fees in Solana during periods of high demand?

[Assistant]
In Solana, Prioritization Fees play a crucial role during periods of high demand by ensuring that transactions are included in blocks despite the competition from other transactions. When the network experiences high demand, validators may choose to include transactions with higher economic value over others, which can lead to delays or even the dropping of valid transactions.

To mitigate this issue, users can add Prioritization Fees on top of the base Transaction Fee. These additional fees help to prioritize a transaction, increasing its chances of being included in a block. By incorporating a special Compute Budget instruction that sets the desired fee, users can signal the importance of their transaction, thereby enhancing its deliverability during congested times.

In summary, Prioritization Fees serve as a mechanism to ensure that transactions are processed in a timely manner when the network is busy, providing users with a way to enhance the likelihood of their transactions being executed.

h (Exception e) {
            return false;
        }
    }

    public static boolean _verifyPubkeyInternal(String maybePubkey) throws Exception
    {
        byte[] bytes = Base58.base58Decode(maybePubkey);
        return !(new CompressedEdwardsY(bytes)).decompress().isSmallOrder();
    }
}

Minimum Deposit & Withdrawal Amounts #
Every deposit and withdrawal of SOL must be greater or equal to the minimum rent-exempt balance for the account at the wallet address (a basic SOL account holding no data), currently: 0.000890880 SOL

Similarly, every deposit account must contain at least this balance.

curl https://api.devnet.solana.com -X POST -H "Content-Type: application/json" -d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getMinimumBalanceForRentExemption",
  "params": [0]
}'

Result
{ "jsonrpc": "2.0", "result": 890880, "id": 1 }

Prioritization Fees and Compute Units #
In periods of high demand, it's possible for a transaction to expire before a validator has included such transactions in their block because they chose other transactions with higher economic value. Valid Transactions on Solana may be delayed or dropped if Prioritization Fees are not implemented properly.

Prioritization Fees are additional fees that can be added on top of the base Transaction Fee to ensure transaction inclusion within blocks and in these situations and help ensure deliverability.

These priority fees are added to transaction by adding a special Compute Budget instruction that sets the de


[User] How can I check the validity of a blockhash in Solana?

[Assistant]
To check the validity of a blockhash in Solana, you can use the `getFeeCalculatorForBlockhash` request. This request will allow you to determine if a specific blockhash is still valid.

Here’s how you can do it:

1. Send a request to the Solana JSON RPC API with the `getFeeCalculatorForBlockhash` method.
2. Pass the blockhash you want to validate as a parameter.
3. Check the response: if the value returned is `null`, it indicates that the blockhash has expired. If a valid fee calculator is returned, the blockhash is still valid.

Here is an example of how you might implement this in JavaScript using the `@solana/web3.js` library:

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

async function checkBlockhashValidity(blockhash) {
    const connection = new Connection(clusterApiUrl('mainnet-beta'), 'confirmed');

    const feeCalculator = await connection.getFeeCalculatorForBlockhash(blockhash);

    if (feeCalculator === null) {
        console.log(`The blockhash ${blockhash} is expired.`);
    } else {
        console.log(`The blockhash ${blockhash} is valid.`);
    }
}

// Example usage
const blockhashToCheck = 'YOUR_BLOCKHASH_HERE';
checkBlockhashValidity(blockhashToCheck);
```

Replace `'YOUR_BLOCKHASH_HERE'` with the actual blockhash you want to check. This function will log whether the blockhash is valid or expired.

n check whether a particular blockhash is still valid by sending a getFeeCalculatorForBlockhash request with the blockhash as a parameter. If the response value is null, the blockhash is expired, and the withdrawal transaction using that blockhash should never succeed.

Validating User-supplied Account Addresses for Withdrawals #
As withdrawals are irreversible, it may be a good practice to validate a user-supplied account address before authorizing a withdrawal in order to prevent accidental loss of user funds.

Basic verification #
Solana addresses a 32-byte array, encoded with the bitcoin base58 alphabet. This results in an ASCII text string matching the following regular expression:

[1-9A-HJ-NP-Za-km-z]{32,44}

This check is insufficient on its own as Solana addresses are not checksummed, so typos cannot be detected. To further validate the user's input, the string can be decoded and the resulting byte array's length confirmed to be 32. However, there are some addresses that can decode to 32 bytes despite a typo such as a single missing character, reversed characters and ignored case

Advanced verification #
Due to the vulnerability to typos described above, it is recommended that the balance be queried for candidate withdraw addresses and the user prompted to confirm their intentions if a non-zero balance is discovered.

Valid ed25519 pubkey check #
The address of a normal account in Solana is a Base58-encoded string of a 256-bit ed25519 public key. Not all bit patterns


[User] Is there an option to start using ChainStack for free, and do I need a credit card for the initial sign-up?

[Assistant] Yes, you can start using ChainStack for free, and you do not need a credit card for the initial sign-up. You can sign up using your GitHub, X, Google, or Microsoft account. This allows you to begin building and deploying applications without any upfront payment.

C node.

Follow these steps to sign up on Chainstack, deploy a Solana RPC node, and find your endpoint credentials:

Sign up with Chainstack.
Deploy a node.
View node access and credentials.
Now you are ready to connect to the Solana blockchain and use the Solana API to build.

📘
See also

Build better with Solana

Updated 8 months ago

eth_uninstallFilter | Aurora
getAccountInfo | Solana
Did this page help you?

getAccountInfo | Solana
post
https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/
The Solana getAccountInfo method returns all the account data for a given public key.

This method provides detailed information about the account, including the account's current balance, owner, and executable state. It is useful for retrieving the state of an account at a specific commitment level.

👍
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
publicKey — the public key of the account to retrieve information for.
commitment — (optional) the level of commitment desired:
processed — the node has processed the block and the block may be on a fork.
confirmed — the block is confirmed by the cluster as not being on a fork.
finalized — the block is finalized by the cluster.
Response
value — the account information:
lamports — the account's current balance.
owner — the public key of the program that owns the account.
ex


[User] How does the 'getFirstAvailableBlock' RPC method function in Solana?

[Assistant]
The `getFirstAvailableBlock` RPC method in Solana is used to retrieve the slot of the lowest confirmed block that has not been purged from the ledger. This method does not require any parameters.

### Functionality
- **Returns**: The method returns a single value, which is a `<u64>` representing the slot number of the first available block.

### Example Code
Here is an example of how to use the `getFirstAvailableBlock` method with a `curl` command:

```bash
curl https://api.devnet.solana.com -s -X POST -H "Content-Type: application/json" -d '
{
  "jsonrpc":"2.0",
  "id":1,
  "method":"getFirstAvailableBlock"
}'
```

### Example Response
The response from the method will look like this:

```json
{
  "jsonrpc": "2.0",
  "result": 25000
}
```

In this example, the result indicates that the first available block is at slot number 25000.

    "slotsPerEpoch": 8192,
    "warmup": true
  },
  "id": 1
}

getFeeForMessage RPC Method
Edit Page
Get the fee the network will charge for a particular Message

Version Restriction
This method is only available in solana-core v1.9 or newer. Please use getFees for solana-core v1.8 and below.

Parameters #
string required

Base-64 encoded Message

object optional

Configuration object containing the following fields:

commitment string optional

minContextSlot number optional

The minimum slot that the request can be evaluated at

Result #
<u64|null> - Fee corresponding to the message at the specified blockhash
Code sample #
curl https://api.devnet.solana.com -s -X POST -H "Content-Type: application/json" -d '
{
  "id":1,
  "jsonrpc":"2.0",
  "method":"getFeeForMessage",
  "params":[
    "AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQAA",
    {
      "commitment":"processed"
    }
  ]
}
'

Response #
{
  "jsonrpc": "2.0",
  "result": { "context": { "slot": 5068 }, "value": 5000 },
  "id": 1
}

getFirstAvailableBlock RPC Method
Edit Page
Returns the slot of the lowest confirmed block that has not been purged from the ledger

Parameters #
None

Result #
<u64> - Slot
Code sample #
curl https://api.devnet.solana.com -s -X POST -H "Content-Type: application/json" -d '
  {
    "jsonrpc":"2.0","id":1,
    "method":"getFirstAvailableBlock"
  }
'

Response #
{ "jsonrpc": "2.0", "result": 25000


[User] What should users do to protect the confidentiality of the API and SDK according to Jupiter's guidelines?

[Assistant]
According to Jupiter's guidelines, users should take the following actions to protect the confidentiality of the API and SDK:

1. **Protect Confidential Information**: Users must safeguard the proprietary information and trade secrets contained within the API and SDK.

2. **Avoid Unauthorized Disclosure**: Users should refrain from disclosing the API or SDK to unauthorized individuals or entities.

3. **Prevent Unauthorized Use**: Users must ensure that the API and SDK are not used in ways that are not authorized by Jupiter.

By following these practices, users can help maintain the confidentiality of the API and SDK as per Jupiter's guidelines.

to provide consultations, support services or updates, upgrades, bug fixes or modifications to the API or SDK. Jupiter will promptly respond to inquiries from you with respect to the API Services and will implement systems and procedures to ensure that any User of the API will be treated with the same fairness and good faith as any other user of our API.

5.2. Jupiter reserves the right to change the method of access to the API or SDK at any time to ensure the safety and security of its environment. In the event of degradation or instability of Jupiter`s systems or in an emergency, you acknowledge and agree that Jupiter may, in its sole and absolute discretion, temporarily suspend your access to the API or SDK in order to minimize threats to and protect the operational stability and security of the Jupiter system.

6. Fees & Payment
6.1. Jupiter reserves the right to charge fees for future use of or access to Jupiter API or SDK. If Jupiter decides to charge for access to the API or SDK, you do not have any obligation to continue to use such API or SDK.

7. Confidentiality
7.1. The API and SDK contains valuable proprietary information and trade secrets of Jupiter and its suppliers that remain the property of Jupiter. You shall protect the confidentiality of, and avoid disclosure and unauthorized use of, the API or SDK.

8. No Warranty
8.1. The API, SDK, and Documentation are provided "AS-IS" without any warranty whatsoever. To the full extent allowed by law, the foregoing w


[User] What happens to the virtual price of LP tokens in Meteora when trading fees are earned?

[Assistant]
In Meteora, the virtual price of LP (Liquidity Provider) tokens increases when trading fees are earned. The virtual price reflects the value of the assets in the pool relative to the number of LP tokens outstanding.

Here's how it works:

1. **Initial State**: When a pool is created and liquidity is deposited, the virtual price starts at 1. For example, if Anne deposits $50 worth of liquidity, the pool has a total of $50, and the virtual price is 1.

2. **Earning Fees**: Over time, if the pool earns trading fees (let's say $50 in fees), the total liquidity in the pool increases. In this case, the pool would now have $150 in total liquidity.

3. **Updated Virtual Price**: After earning the fees, the virtual price is recalculated. In our example, the virtual price becomes 1.5, indicating that the pool value has grown by 50% due to the fees earned, separate from the initial deposits.

4. **Impact on LP Tokens**: Even though the number of LP tokens held by each liquidity provider (like Anne and Bob) remains the same, the value of those tokens increases because they now represent a larger share of the total pool value. For instance, if Anne has 50 out of 100 LP tokens, her share is worth $75 after the fees are accounted for (50/100 * $150).

In summary, the virtual price of LP tokens increases as trading fees are earned, reflecting the growth in the pool's total liquidity and the value of the LP tokens held by liquidity providers.

would not be a good measure of how much the pool is earning.

How do LP tokens, fees, and virtual price work for Dynamic Pools?
Simple Example
Let's say Anne creates a pool and deposits $50 worth of liquidity in the pool.
So, pool has $50

Anne has 50 LP tokens out of 50.

Virtual price = 1

Bob sees the pool and also adds $50 worth of liquidity in the pool
Pool has $100

Anne has 50 of 100 LP tokens

Bob has 50 of 100 LP tokens

Virtual price = 1

There are a 100 LP tokens total, and both Anne and Bob own 50% of the pool and if each withdrew from the pool, they would get 50% of the pool and $50 worth of their liquidity back.

Also the virtual price of the LP token is 1. All assets in the pool came from deposits and no fees were returned.

Now let's say over time the pool has earned $50 in trading fees
Pool now has $150 in liquidity

The virtual price is now 1.5 meaning the pool value grew 50% outside of deposits.

Anne still has 50 of 100 LP tokens

Bob still has 50 of 100 LP tokens.

If Anne were to exchange her 50 LP tokens to withdraw her assets, she would get $75 worth of assets, Then Bob would have 50 LP tokens out of 50 and would be entitled the rest.

But, instead, let's say Carl wants to add $50 worth of liquidity.

Well the virtual price of the LP token is now 1.5, so he would get ~33 LP tokens. So after his deposit... Pool has $200 in liquidity

Anne has 50 of 133 => 50/133200 = $75

Bob has 50 of 133

Carl has 33 of 133 => 33/133200 = $50

How


[User] What percentage of the fees collected by Raydium is redeposited into the liquidity pool as a reward for liquidity providers?

[Assistant] Raydium redeposits 88% of the fees collected from standard swaps into the liquidity pool as a reward for liquidity providers. For CLMM (Constant Product Automated Market Maker) pools, 84% of the fees are redeposited into the liquidity pool for the same purpose.

ls

88% is redeposited into the liquidity pool and acts as a reward for liquidity providers.

12% is used to buy back the RAY token

CLMM pool

84% is redeposited into the liquidity pool and acts as a reward for liquidity providers.

12% is used to buy back the RAY token

4% goes to the protocol treasury

Network fee: A nominal amount of SOL is also required to process Solana network fees on each trade. Most transactions cost between 0.0001 — 0.001 SOL.

Price impact is the difference between the current market price and the expected price for a trade. Price impact is primarily determined by the size of your trade relative to the amount of liquidity in the pool. As the number of tokens you buy from the pool increases, the price of the token increases as well. This unfavorable change in price is called price impact.

If you are swapping in a pool with very low liquidity, you may receive a very poor price for your swap. If you see a high price impact when swapping, try trading a smaller amount or swapping in a pool with higher liquidity.

Slippage is the difference between the expected price of a swap and its execution price.

Raydium allows users to set their slippage tolerance determining the maximum difference between the expected and execution price.
If the slippage exceeds the user's choice, the swap won't be executed.

Setting a high slippage tolerance may result in an unfavorable swap.

Insufficient SOL: SOL is required to pay network fees (gas), it's recommended to


[User] What is the significance of verifying the token address on Raydium, and how should users approach this process?

[Assistant]
Verifying the token address on Raydium is crucial for ensuring the authenticity and safety of the tokens users intend to interact with. Since the ticker and logo of a token can be set freely by the token creators, relying solely on these identifiers can lead to confusion or potential scams. The true identity of a token is represented by its token mint address.

Here’s how users should approach the process of verifying a token address:

1. **Copy and Paste Contract Addresses**: Users are advised to copy and paste the contract addresses directly from trusted sources rather than typing them in manually. This helps avoid errors that could result in interacting with the wrong token.

2. **Use Trusted Resources**: Always refer to official project websites, whitepapers, or verified community channels to obtain the correct token mint address.

3. **Cross-Verification**: If possible, cross-verify the token address with multiple sources or community discussions to ensure its legitimacy.

By following these steps, users can significantly reduce the risk of interacting with fraudulent tokens and ensure a safer experience on the Raydium platform.

Do your own research. Raydium like many other dAPP is a fully permissionless platform. Raydium smart contracts allow any project or community to create a pool or farm.

Verify the token address: Ticker and Logo are set freely by token creators, the token mint is the true identity of a token. It suggested for users to copy and paste contract addresses rather than typing in the ticker.

Read the documentation before interacting with smart contracts. If you have doubts about the implications of one of your actions, feel free to join the Raydium Discord or Telegram for 24/7 support.

Pay attention to warnings. Whether it is a slippage warning informing you of potential bad execution or a confirmation to add a new mint to your token list, always read the information before approving.

Make sure you have read and understand Raydium disclaimer.

FAQ
Use the contents bar on the right to jump directly to answers of frequently asked questions!

Questions about Raydium
What is Raydium and what makes it different?
Raydium is an automated market maker (AMM) platform built on Solana where users can swap, trade and provide liquidity to earn yield on digital assets. However, unlike other AMM platforms, Raydium's AMM provides on-chain liquidity to OpenBook's central limit order book, meaning that Raydium’s users and liquidity pools have access to the order flow and liquidity of the entire OpenBook ecosystem, and vice versa.

Raydium’s Best Price Swaps feature determines whether swapping w


[User] Where can I find the equivalent page on the CoinGecko website for NFT collections?

[Assistant] You can find the equivalent page on the CoinGecko website for NFT collections at the following URL: [https://www.coingecko.com/en/nft](https://www.coingecko.com/en/nft).

    "usd": "2024-02-29T11:45:08.150Z"
95
  }
96
}

💼 NFTs List with Market Data
get
https://pro-api.coingecko.com/api/v3/nfts/markets
This endpoint allows you to query all the supported NFT collections with floor price, market cap, volume and market related data on CoinGecko

👍
Tips

You may include values such as per_page and page to specify how many results you would like to show in the responses per page and which page of responses you would like to show
📘
Notes

Cache / Update Frequency: every 5 minutes
Exclusive for all Paid Plan Subscribers (Analyst, Lite, Pro and Enterprise)
CoinGecko equivalent page: https://www.coingecko.com/en/nft
Some collection with low liquidity may not be ranked by Market Cap value, learn more here. Sorting by Mcap ranking will first prioritise Market Cap value of liquid NFT collections, then followed by trading volume of illiquid NFT collections.
Query Params
asset_platform_id
string
filter result by asset platform (blockchain network)
*refers to /asset_platforms filter=nft

order
string
sort results by field
Default: market_cap_usd_desc

per_page
number
total results per page
Valid values: any integer between 1 and 250
Default: 100

page
number
page through results
Default: 1

Response

200
List all NFTs markets

Response body
array of objects
object
id
string
nft collection id

contract_address
string
nft collection contract address

asset_platform_id
string
nft collection asset platform id

name
string
nft collection name

symbol
string
nf