[User] How can you retrieve the recent block hash for an account's cluster using QuickNode?

[Assistant]
To retrieve the recent block hash for an account's cluster using QuickNode, you can utilize the `getConfirmedTransaction` method. This method allows you to obtain detailed information about a confirmed transaction, including the recent block hash.

Here’s how you can make a request using `curl` to get the recent block hash:

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

Replace `<TRANSACTION_SIGNATURE>` with the actual transaction signature you want to query.

In the response, you will find a field named `recentBlockhash`, which contains the recent block hash for the account's cluster. This field is part of the transaction details returned by the API.

Make sure to have your QuickNode endpoint set up and replace the URL with your specific endpoint if necessary.

donlySignedAccounts
The number of readonly accounts that also require a signature
numReadonlyUnsignedAccounts
The number of readonly accounts that do not require a signature
numRequiredSignatures
The number of signatures required to authorize the transaction
instructions
An array of instructions that were executed in the block's transactions
accounts
An array of base58-encoded public keys representing the accounts to be passed to the instruction
data
A string containing the encoded data to be passed to the instruction
programIdIndex
An integer representing the index of the program ID in the accountKeys array. The program ID is the public key of the on-chain program that executed the instruction
stackHeight
The current depth of the execution stack
recentBlockhash
The recent block hash for the account's cluster
signatures
An array of signatures strings corresponding to the transaction order in the block
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc": "2.0","id": 1,"method": "getConfirmedTransaction","params": ["3Pdh1xgS7HYXcPquN1JQQXs8C6Tn2ZTkHg86wXMwDEEnJxVVZsE3WgxHSx258boUtHcMVkKCGbT9dYWWfk7CWV2m","json"]}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getConfirmedSignaturesForAddress2
Next
getEpochInfo
Chat with our community
Check out our product changelog
Check on the status of our services
Read our blog for t


[User] What role does the root hash play in ensuring the integrity of compressed NFTs in Helius?

[Assistant]
The root hash plays a crucial role in ensuring the integrity of compressed NFTs in Helius by serving as a cryptographic proof of the state of the NFTs. Each compressed NFT is organized in a Merkle tree, and the root hash is derived from the data of all the NFTs within that tree. This root hash is stored in a single account.

When modifications to a compressed NFT are made, proof is required to verify that the NFT has not been maliciously altered. The integrity of the data returned by an indexer can be confirmed by comparing the root hash with what is stored in the root account. This process ensures that any data retrieved about the compressed NFTs is trustworthy and has not been tampered with.

In summary, the root hash acts as a secure reference point for validating the state of compressed NFTs, providing assurance that the information is accurate and reliable.

using its root hash, which is stored in a single account.

Modifications to a compressed NFT require proof to ensure that the NFT cannot be maliciously modified. The data returned by an indexer can also be verified by comparing the root hash with what is stored in the root account. For more details, see the Solana documentation and our blog explainer.

Helius simplifies NFT development by tracking compressed NFT states, providing faster look-ups, and returning data with cryptographic proof to ensure integrity.

How are compressed NFTs different?
Compressed NFTs are not native Solana tokens. They do not have a token account, mint account, or metadata.

One account exists per Merkle tree; each tree can hold millions of NFTs.

One collection can use multiple Merkle trees (recommended for larger collections).

A Merkle tree account can also hold multiple collections (not recommended).

A DAS API call is required to read any information about a compressed NFT (e.g., attributes, collection information, etc.). This would affect Solana dApps loading your assets, etc.

A compressed NFT can be converted to a regular NFT but not vice versa.

It is recommended to keep the tree size to 1 million or less for practical reasons. This is because the proof path will begin to exceed the Solana transaction account limit.

All cNFT modifications must occur through the Bubblegum program. You can refer to the methods here.

How does the indexer work?
Compressed NFT information is not stored in a


[User] What endpoint in GeckoTerminal would I use to obtain historical price and market cap data for a specific coin on a given date?

[Assistant]
To obtain historical price and market cap data for a specific coin on a given date, you would use the following endpoint in GeckoTerminal:

```
/coins/{id}/history
```

In this endpoint, replace `{id}` with the specific coin's ID. This endpoint will provide you with historical data, including price, market cap, and 24-hour volume for the specified coin on the given date.

ery all the supported coins on CoinGecko with coins id, name and symbol
/coins/markets	Query all the supported coins with price, market cap, volume and market related data
/coins/{id}	Query all the coin data of a coin (name, price, market .... including exchange tickers) on CoinGecko coin page based on a particular coin id
/coins/{id}/tickers	Query the coin tickers on both centralized exchange (cex) and decentralized exchange (dex) based on a particular coin id
/coins/{id}/history	Query the historical data (price, market cap, 24hrs volume, etc) at a given date for a coin based on a particular coin id
/coins/{id}/market_chart	Get the historical chart data of a coin including time in UNIX, price, market cap and 24hrs volume based on particular coin id
/coins/{id}/market_chart/range	Get the historical chart data of a coin within certain time range in UNIX along with price, market cap and 24hrs volume based on particular coin id.
/coins-id-ohlc	Get the OHLC chart (Open, High, Low, Close) of a coin based on particular coin id
💼 /coins/{id}/ohlc/range	Get the OHLC chart (Open, High, Low, Close) of a coin within a range of timestamp based on particular coin id
💼 /coins/top_gainers_losers	Query the top 30 coins with largest price gain and loss by a specific time duration
💼 /coins/list/new	Query the latest 200 coins that recently listed on CoinGecko
👑 /coins/{id}/circulating_supply_chart	Query historical circulating supply of a coin by number of days away from now based on provided co


[User] How does Solana utilize the `CounterInstruction` enum in instruction handling?

[Assistant]
In Solana, the `CounterInstruction` enum is utilized to define and manage different types of instructions that can be processed by a program. This enum serves as a way to categorize the instructions and unpack the associated data for each instruction type.

Here's how it works in detail:

1. **Defining Instructions**: The `CounterInstruction` enum contains variants that represent different operations. For example, it might include variants like `InitializeCounter` and `IncrementCounter`. Each variant can have associated data, such as an initial value for the counter.

   ```rust
   pub enum CounterInstruction {
       InitializeCounter { initial_value: u64 },
       IncrementCounter,
   }
   ```

2. **Unpacking Instruction Data**: The `unpack` method is implemented for the `CounterInstruction` enum. This method takes raw instruction data (a byte array) and converts it into the corresponding enum variant. It checks the first byte to determine the instruction type and extracts any necessary data.

   ```rust
   impl CounterInstruction {
       pub fn unpack(input: &[u8]) -> Result<Self, ProgramError> {
           let (tag, rest) = input.split_first().ok_or(ProgramError::InvalidInstructionData)?;
           match tag {
               0 => {
                   // Unpack the u64 value for InitializeCounter
                   let initial_value = u64::from_le_bytes(
                       rest.try_into().map_err(|_| ProgramError::InvalidInstructionData)?,
                   );
                   Ok(Self::InitializeCounter { initial_value })
               }
               1 => Ok(Self::IncrementCounter), // No additional data needed
               _ => Err(ProgramError::InvalidInstructionData),
           }
       }
   }
   ```

3. **Processing Instructions**: In the `process_instruction` function, the instruction data is unpacked using the `CounterInstruction::unpack` method. Based on the unpacked instruction, the program then matches the instruction type and calls the corresponding handler function to execute the business logic.

   ```rust
   pub fn process_instruction(
       program_id: &Pubkey,
       accounts: &[AccountInfo],
       instruction_data: &[u8],
   ) -> ProgramResult {
       // Unpack instruction data
       let instruction = CounterInstruction::unpack(instruction_data)?;

       // Match instruction type
       match instruction {
           CounterInstruction::InitializeCounter { initial_value } => {
               process_initialize_counter(program_id, accounts, initial_value)?
           }
           CounterInstruction::IncrementCounter => process_increment_counter(program_id, accounts)?,
       };
   }
   ```

In summary, the `CounterInstruction` enum is a crucial part of instruction handling in Solana programs. It allows for organized and type-safe management of different instructions, making it easier to implement the program's business logic based on the incoming instruction data.

unter, parse a u64 from the remaining bytes
                let initial_value = u64::from_le_bytes(
                    rest.try_into()
                        .map_err(|_| ProgramError::InvalidInstructionData)?,
                );
                Ok(Self::InitializeCounter { initial_value })
            }
            1 => Ok(Self::IncrementCounter), // No additional data needed
            _ => Err(ProgramError::InvalidInstructionData),
        }
    }
}

Instruction Handlers #
Instruction handlers refer to the functions that contain the business logic for each instruction. It's common to name handler functions as process_<instruction_name>, but you're free to choose any naming convention.

Add the following code to lib.rs. This code uses the CounterInstruction enum and unpack method defined in the previous step to route incoming instructions to the appropriate handler functions:

lib.rs
entrypoint!(process_instruction);

pub fn process_instruction(
    program_id: &Pubkey,
    accounts: &[AccountInfo],
    instruction_data: &[u8],
) -> ProgramResult {
    // Unpack instruction data
    let instruction = CounterInstruction::unpack(instruction_data)?;

    // Match instruction type
    match instruction {
        CounterInstruction::InitializeCounter { initial_value } => {
            process_initialize_counter(program_id, accounts, initial_value)?
        }
        CounterInstruction::IncrementCounter => process_increment_counter(program_id, accounts)?,
    };
}

fn proce


[User] What command should be run in the terminal to build the program in Solana after defining the message account?

[Assistant]
To build the program in Solana after defining the message account, you should run the following command in the terminal:

```bash
cargo build
```

This command compiles the Rust code and generates the necessary artifacts for your Solana program.

 field).

In this example, we're defining a MessageAccount struct to store a message created by users that contains three fields:

user - A Pubkey representing the user who created the message account.
message - A String containing the user's message.
bump - A u8 storing the "bump" seed used in deriving the program derived address (PDA). Storing this value saves compute by eliminating the need to rederive it for each use in subsequent instructions. When an account is created, the MessageAccount data will be serialized and stored in the new account's data field.
Later, when reading from the account, this data can be deserialized back into the MessageAccount data type. The process of creating and reading the account data will be demonstrated in the testing section.

Build the program again by running build in the terminal.

Terminal
build

We've defined what our message account will look like. Next, we'll implement the program instructions.

Implement Create Instruction #
Now, let's implement the create instruction to create and initialize the MessageAccount.

Start by defining the accounts required for the instruction by updating the Create struct with the following:

lib.rs
#[derive(Accounts)]
#[instruction(message: String)]
pub struct Create<'info> {
    #[account(mut)]
    pub user: Signer<'info>,

    #[account(
        init,
        seeds = [b"message", user.key().as_ref()],
        bump,
        payer = user,
        space = 8 + 32 + 4 + message.len() + 1
    )]
    pub


[User] What information about a Block can be retrieved using Bitquery?

[Assistant]
Using Bitquery, you can retrieve the following information about a Block:

1. **Time**: The timestamp of when the block was created.
2. **Date**: The date when the block was created.

Here is an example of how you might structure a query to retrieve this information:

```graphql
{
  ethereum {
    blocks(
      where: { number: { _eq: 12345678 } }
    ) {
      Time
      Date
    }
  }
}
```

In this example, replace `12345678` with the specific block number you are interested in. This query will return the time and date associated with that block.

 "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8" }
          }
        }
      }
    ) {
      Block {
        Time
        Date
      }
      Transaction {
        Signature
      }
      Instruction {
        AncestorIndexes
        CallerIndex
        Depth
        Data
        ExternalSeqNumber
        InternalSeqNumber
        Index
        Accounts {
          Address
          IsWritable
          Token {
            Mint
            Owner
            ProgramId
          }
        }
        CallPath
        Logs
        Program {
          AccountNames
          Method
          Json
          Name
          Arguments {
            Type
            Name
            Value {
              __typename
              ... on Solana_ABI_Integer_Value_Arg {
                integer
              }
              ... on Solana_ABI_String_Value_Arg {
                string
              }
              ... on Solana_ABI_Address_Value_Arg {
                address
              }
              ... on Solana_ABI_BigInt_Value_Arg {
                bigInteger
              }
              ... on Solana_ABI_Bytes_Value_Arg {
                hex
              }
              ... on Solana_ABI_Boolean_Value_Arg {
                bool
              }
              ... on Solana_ABI_Float_Value_Arg {
                float
              }
              ... on Solana_ABI_Json_Value_Arg {
                json
              }
            }
          }
        }
      }
    }
  }
}

Pair Creation


[User] What legal theories can be involved in claims against Magic Eden related to its APIs?

[Assistant]
According to the documentation, claims against Magic Eden related to its APIs can be based on several legal theories, including:

1. **Warranty** - This pertains to the guarantees or assurances made by Magic Eden regarding the performance or quality of its APIs.

2. **Contract** - This involves claims based on the terms and conditions agreed upon when using the Magic Eden APIs.

3. **Tort (including negligence)** - This refers to claims arising from wrongful acts that cause harm or loss to another party, which may include negligence in the provision of the APIs.

4. **Product Liability** - This involves claims related to the safety and effectiveness of the APIs as a product.

These legal theories can form the basis for claims regarding issues such as service interruptions, data loss, or other damages arising from the use of the Magic Eden APIs.

ONTAINED IN THE MAGIC EDEN APIS. WHILE MAGIC EDEN ATTEMPTS TO MAKE YOUR ACCESS TO AND USE OF THE MAGIC EDEN APIS AND ANY CONTENT THEREIN SAFE, MAGIC EDEN CANNOT AND DOES NOT REPRESENT OR WARRANT THAT THE MAGIC EDEN APIS, AND ANY CONTENT THEREIN, OR OUR SERVERS ARE FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS. WE CANNOT GUARANTEE THE SECURITY OF ANY DATA THAT YOU DISCLOSE ONLINE. YOU ACCEPT THE INHERENT SECURITY RISKS OF PROVIDING INFORMATION AND DEALING ONLINE OVER THE INTERNET AND WILL NOT HOLD US RESPONSIBLE FOR ANY BREACH OF SECURITY.

SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF CERTAIN WARRANTIES. ACCORDINGLY, SOME OF THE ABOVE DISCLAIMERS OF WARRANTIES MAY NOT APPLY TO YOU.

8.2 Limitation of Liability.

TO THE MAXIMUM EXTENT PERMITTED BY LAW, NEITHER MAGIC EDEN NOR ITS SERVICE PROVIDERS INVOLVED IN CREATING, PRODUCING, OR DELIVERING THE MAGIC EDEN APIS WILL BE LIABLE FOR ANY INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR DAMAGES FOR LOST PROFITS, LOST REVENUES, LOST SAVINGS, LOST BUSINESS OPPORTUNITY, LOSS OF DATA OR GOODWILL, SERVICE INTERRUPTION, COMPUTER DAMAGE OR SYSTEM FAILURE OR THE COST OF SUBSTITUTE SERVICES OF ANY KIND ARISING OUT OF OR IN CONNECTION WITH THESE TERMS OR FROM THE USE OF OR INABILITY TO USE THE MAGIC EDEN APIS, WHETHER BASED ON WARRANTY, CONTRACT, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR ANY OTHER LEGAL THEORY, AND WHETHER OR NOT MAGIC EDEN OR ITS SERVICE PROVIDERS HAVE BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGE, E


[User] What are the implications of the MissingRequiredSignature error in Solana?

[Assistant]
The `MissingRequiredSignature` error in Solana has specific implications related to the signing of accounts in transactions. This error occurs when an instruction requires an account to be a signer, but the expected signature is not present. Here are the key implications:

1. **Signer Requirement**: Some instructions in Solana programs necessitate that certain accounts provide a signature to authorize the action. If an account that is required to sign the transaction does not provide a signature, the `MissingRequiredSignature` error will be triggered.

2. **Cross-Program Invocations**: This error can also arise during cross-program invocations. If a program attempts to invoke another program and the invoked program requires a signed program address, the error will occur if the signer seeds passed to `invoke_signed` do not match the seeds used to create the program address with `create_program_address`.

3. **Transaction Failure**: When this error is encountered, the transaction will fail, meaning that any changes intended by the transaction will not be executed. This can lead to a loss of intended state changes and may require the user to correct the signing requirements and resubmit the transaction.

In summary, the `MissingRequiredSignature` error indicates a failure to meet the signing requirements for a transaction, which can stem from both direct account signing issues and complications arising from cross-program invocations. Users must ensure that all necessary accounts are properly signed to avoid this error.

ry packing and unpacking the instruction type T to determine the exact encoding the program expects.

MissingRequiredSignature #
Some instructions require the account to be a signer; this error is returned if an account is expected to be signed but is not.

An implementation of a program might also cause this error when performing a cross-program invocation that requires a signed program address, but the passed signer seeds passed to invoke_signed don't match the signer seeds used to create the program address create_program_address.

Stack #
SBF uses stack frames instead of a variable stack pointer. Each stack frame is 4KB in size.

If a program violates that stack frame size, the compiler will report the overrun as a warning.

For example:

Error: Function _ZN16curve25519_dalek7edwards21EdwardsBasepointTable6create17h178b3d2411f7f082E Stack offset of -30728 exceeded max offset of -4096 by 26632 bytes, please minimize large stack variables

The message identifies which symbol is exceeding its stack frame, but the name might be mangled.

Info
To demangle a Rust symbol use rustfilt.

The above warning came from a Rust program, so the demangled symbol name is:

rustfilt _ZN16curve25519_dalek7edwards21EdwardsBasepointTable6create17h178b3d2411f7f082E
curve25519_dalek::edwards::EdwardsBasepointTable::create

The reason a warning is reported rather than an error is because some dependent crates may include functionality that violates the stack frame restrictions even if the program


[User] What information is retrieved when using connection.getNonce with a NonceAccount's public key in Solana?

[Assistant]
When using `connection.getNonce` with a NonceAccount's public key in Solana, the following information is retrieved:

1. **authorizedPubkey**: This is the public key of the account authorized to use the nonce account.
2. **nonce**: This is the nonce value associated with the NonceAccount, which can be used in transactions.
3. **feeCalculator**: This provides information about the fee structure, specifically the `lamportsPerSignature`, which indicates the number of lamports charged per signature.

Here is an example of how the retrieved data might look:

```javascript
console.log(nonceAccountData);
// NonceAccount {
//   authorizedPubkey: PublicKey {
//     _bn: <BN: 919981a5497e8f85c805547439ae59f607ea625b86b1138ea6e41a68ab8ee038>
//   },
//   nonce: '93zGZbhMmReyz4YHXjt2gHsvu5tjARsyukxD4xnaWaBq',
//   feeCalculator: { lamportsPerSignature: 5000 }
// }
```

This output shows the authorized public key, the nonce value, and the fee calculator information for the NonceAccount.

, [
  account,
  nonceAccount,
]);

let nonceAccountData = await connection.getNonce(
  nonceAccount.publicKey,
  "confirmed",
);

console.log(nonceAccountData);
// NonceAccount {
//   authorizedPubkey: PublicKey {
//     _bn: <BN: 919981a5497e8f85c805547439ae59f607ea625b86b1138ea6e41a68ab8ee038>
//   },
//   nonce: '93zGZbhMmReyz4YHXjt2gHsvu5tjARsyukxD4xnaWaBq',
//   feeCalculator: { lamportsPerSignature: 5000 }
// }

let nonceAccountInfo = await connection.getAccountInfo(
  nonceAccount.publicKey,
  "confirmed",
);

let nonceAccountFromInfo = web3.NonceAccount.fromAccountData(
  nonceAccountInfo.data,
);

console.log(nonceAccountFromInfo);
// NonceAccount {
//   authorizedPubkey: PublicKey {
//     _bn: <BN: 919981a5497e8f85c805547439ae59f607ea625b86b1138ea6e41a68ab8ee038>
//   },
//   nonce: '93zGZbhMmReyz4YHXjt2gHsvu5tjARsyukxD4xnaWaBq',
//   feeCalculator: { lamportsPerSignature: 5000 }
// }

The above example shows both how to create a NonceAccount using SystemProgram.createNonceAccount, as well as how to retrieve the NonceAccount from accountInfo. Using the nonce, you can create transactions offline with the nonce in place of the recentBlockhash.

VoteAccount #
Source Documentation

Vote account is an object that grants the capability of decoding vote accounts from the native vote account program on the network.

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

let voteAccountInfo = await connection.getProgramAccounts(web3.VOTE_PROGRAM_ID);
let voteAccou


[User] How does the 'end_slot' parameter work in QuickNode's getConfirmedBlocks method?

[Assistant]
In QuickNode's `getConfirmedBlocks` method, the `end_slot` parameter specifies the ending slot for the range of confirmed blocks you want to retrieve. This parameter is encoded as a u64, which is a 64-bit unsigned integer.

When you provide the `end_slot` parameter, the method will return confirmed blocks between the `start_slot` and the `end_slot`, inclusive. If you do not provide an `end_slot`, the method will return confirmed blocks from the `start_slot` up to the latest confirmed block.

It's important to note that the maximum range allowed for the slots is 500,000, and for free accounts, there are limits on the block range that can be queried.

### Example Request

Here is an example of how to use the `getConfirmedBlocks` method with the `end_slot` parameter:

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

In this example, the request retrieves confirmed blocks starting from slot `94101945` to slot `94101948`.

lease note that for this RPC method, block range limits are set to 5 for free accounts and 1005 for all paid accounts, including Starters, Growth, and Business plans.
Parameters
start_slot
string
The start slot encoded as u64, 64-bit unsigned integer
end_slot
string
The end slot encoded as u64, 64-bit unsigned integer
object
array
The configuration object with the following fields:
commitment
string
The level of commitment required for the query. The options include:
finalized
string
The node will query the most recent block confirmed by the supermajority of the cluster as having reached maximum lockout, meaning the cluster has recognized this block as finalized
confirmed
string
The node will query the most recent block that has been voted on by the supermajority of the cluster
processed
string
The node will query its most recent block. Note that the block may not be complete
Returns
result
An array of u64 integers listing confirmed blocks between start_slot and either end_slot, if provided, or latest confirmed block, inclusive. The maximum range allowed is 500,000 slots
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlocks","params":[94101945, 94101948]}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getConfirmedBlock
Next
getConfirmedBlocksWithLimit
Chat with our community
Ch


[User] What happens when the signer seeds used in a cross-program invocation in Solana do not match the expected seeds?

[Assistant]
When the signer seeds used in a cross-program invocation in Solana do not match the expected seeds, the error returned is `MissingRequiredSignature`. This error occurs because the program expects a signer that corresponds to a specific program address created using the provided seeds, but the seeds passed to the `invoke_signed` function do not match those used to create the program address with `create_program_address`.

In summary, if the signer seeds are incorrect, the program will fail to execute the instruction that requires the signature, resulting in the `MissingRequiredSignature` error.


[User] What are the implications of using InlineNextActionLink in Solana's Action API?

[Assistant]
The use of `InlineNextActionLink` in Solana's Action API has several implications:

1. **Immediate User Experience**: By providing an inline next action, the application can present the next action to the user immediately after the current transaction is confirmed. This enhances the user experience by reducing the wait time and allowing for a seamless flow of actions without requiring an additional network request.

2. **Reduced Latency**: Since the next action is embedded within the current response, it eliminates the need for a separate callback to fetch the next action. This can lead to faster interactions as the user does not have to wait for another round trip to the server.

3. **Simplicity in Implementation**: Developers can streamline the implementation by embedding the next action directly within the response. This can simplify the logic on the client side, as it does not need to handle additional asynchronous requests to determine what to do next.

4. **Potential for Increased Complexity**: While inline actions can simplify some aspects, they may also introduce complexity in managing the state of the application. Developers need to ensure that the inline action is relevant and correctly reflects the current context, especially if the state can change rapidly.

5. **Error Handling**: If an error occurs during the execution of the inline action, the application must have a robust error handling mechanism to manage failures gracefully, as there won't be a separate callback to handle such scenarios.

6. **User Guidance**: Inline actions can be tailored to provide specific guidance or next steps based on the context of the previous action, enhancing the overall user engagement and interaction with the application.

In summary, using `InlineNextActionLink` can significantly enhance the user experience by providing immediate feedback and actions, but it also requires careful consideration of state management and error handling.

lback with the transaction signature for additional validation and logic on the Action API server
customized "success" messages by updating the displayed metadata (e.g. a new image and description)
To chain multiple actions together, in any ActionPostResponse include a links.next of either:

PostNextActionLink - POST request link with a same origin callback url to receive the signature and user's account in the body. This callback url should respond with a NextAction.
InlineNextActionLink - Inline metadata for the next action to be presented to the user immediately after the transaction has confirmed. No callback will be made.
export type NextActionLink = PostNextActionLink | InlineNextActionLink;

/** @see {NextActionPostRequest} */
export interface PostNextActionLink {
  /** Indicates the type of the link. */
  type: "post";
  /** Relative or same origin URL to which the POST request should be made. */
  href: string;
}

/**
 * Represents an inline next action embedded within the current context.
 */
export interface InlineNextActionLink {
  /** Indicates the type of the link. */
  type: "inline";
  /** The next action to be performed */
  action: NextAction;
}

NextAction #
After the ActionPostResponse included transaction is signed by the user and confirmed on-chain, the blink client should either:

execute the callback request to fetch and display the NextAction, or
if a NextAction is already provided via links.next, the blink client should update the displayed metadat


[User] What role does the keeper play in the Jupiter Limit Order system?

[Assistant]
In the Jupiter Limit Order system, the keeper plays a crucial role in monitoring the liquidity landscape and executing limit orders. Here are the key responsibilities of the keeper:

1. **Monitoring Prices**: The keeper continuously monitors the on-chain prices using the Jupiter Price API to detect when the market price reaches the specified limit set by the user.

2. **Executing Orders**: Once the keeper identifies that the market price matches the user's limit price, it proceeds to execute and fulfill the order.

3. **Handling Insufficient Liquidity**: If the order size is too large and there is insufficient liquidity available on-chain, the keeper attempts to execute the order in smaller chunks. This approach aims for partial fulfillment to ensure the best price with minimal price impact.

4. **Order Fulfillment**: The keeper continues to work until the order is fully filled, ensuring that any executed order, whether fully or partially fulfilled, is automatically transferred to the user's wallet.

Overall, the keeper acts as an intermediary that facilitates the execution of limit orders by ensuring that they are fulfilled based on real-time market conditions.

ied the limit order details and deposited the funds for the order to be created.

How Limit Order Works
Jupiter Limit Order executes your order based on the price you have set by matching it with the available liquidity on-chain across Solana. Once the order is placed, keepers will continuously monitor the liquidity landscape and execute the limit order when the market price reaches your specified limit.

Not an Order Book
This is not an order book system. The limit order system utilizes a keeper to monitor token prices on-chain and trigger the fulfillment of orders if liquidity is available.

Scenario

If a Limit Order is placed to buy 1 $SOL with 10 USDC at a rate of 10 USDC per $SOL.
The keeper will monitor the price on-chain using Jupiter Price API.
If the keeper detects that the on-chain price of $SOL reaches 10 USDC, it will proceed to execute and fulfill the order.
If the order size is too large, and there is insufficient liquidity on-chain, the keeper will attempt to execute the order in smaller chunks. It will aim for partial fulfillment to ensure the best price with minimal price impact, continuing until the order is fully filled.
The executed order, whether fully or partially fulfilled, will be automatically transferred to your wallet.
Key Benefits
Users are able to create limit orders, providing a Centralized Exchange (CEX) experience on Solana.
Liquidity from anywhere on Solana is utilized to fulfill the trade.
Users can place an order with an expiration time. At


[User] How can users stay updated with the latest announcements and features from QuickNode?

[Assistant]
Users can stay updated with the latest announcements and features from QuickNode by subscribing to the #Web3Vibes newsletter. This newsletter provides information about the coolest developments in Blockchain every month.

Additionally, users can check out the QuickNode product changelog for updates on new features and improvements, as well as monitor the status of QuickNode services to stay informed about any service-related announcements.

For direct communication and community engagement, users can also participate in discussions with the QuickNode community.

    defer cancel()

    latestBlockHash, err := client.GetLatestBlockhash(ctx, &pb.GetLatestBlockhashRequest{})
	if err != null {
		log.Fatalf("Failed to get latest blockhash: %v", err)
	}

	fmt.Printf("Latest Blockhash Information:\n")
	fmt.Printf("  Blockhash: %+v\n", latestBlockHash)

}
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getBlockHeight
Next
getSlot
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
getSlot gRPC Method
Retrieves the current slot number of the Solana blockchain. The API credit value for this method is 10.
Updated on
Oct 25, 2024
Please note that this RPC method requires the Yellowstone gRPC add-on enabled on your QuickNode endpoint.
Parameters
This method does not accept any parameters
Returns
slot
string
The current slot number on the Solana blockchain
Request

Go
package main

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

	pb "yellowstone/proto"

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

// QuickNode endpoints consist of two crucial components: the endpoint name and the corresponding token
// For eg: QN Endpoint: https://docs-demo.sol


[User] What information is logged in the `cpi.test.ts` file when invoking the `sol_transfer` instruction on Solana?

[Assistant]
The `cpi.test.ts` file logs a link to the transaction details on SolanaFM when invoking the `sol_transfer` instruction. This allows users to view the transaction details directly on the Solana blockchain explorer.

Additionally, the file demonstrates how to derive the Program Derived Address (PDA) using the seeds specified in the program. The relevant code snippet for deriving the PDA is as follows:

```javascript
const [PDA] = PublicKey.findProgramAddressSync(
  [Buffer.from("pda"), wallet.publicKey.toBuffer()],
  programId
);
```

This snippet shows how the PDA is derived using the seed "pda" and the public key of the wallet, along with the program ID.

lang::system_program::{transfer, Transfer};

declare_id!("3455LkCS85a4aYmSeNbRrJsduNQfYRY82A7eCD3yQfyR");

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

    pub fn sol_transfer(ctx: Context<SolTransfer>, amount: u64) -> Result<()> {
        let from_pubkey = ctx.accounts.pda_account.to_account_info();
        let to_pubkey = ctx.accounts.recipient.to_account_info();
        let program_id = ctx.accounts.system_program.to_account_info();

        let seed = to_pubkey.key();
        let bump_seed = ctx.bumps.pda_account;
        let signer_seeds: &[&[&[u8]]] = &[&[b"pda", seed.as_ref(), &[bump_seed]]];

        let cpi_context = CpiContext::new(
            program_id,
            Transfer {
                from: from_pubkey,
                to: to_pubkey,
            },
        )
        .with_signer(signer_seeds);

        transfer(cpi_context, amount)?;
        Ok(())
    }
}

#[derive(Accounts)]
pub struct SolTransfer<'info> {
    #[account(
        mut,
        seeds = [b"pda", recipient.key().as_ref()],
        bump,
    )]
    pda_account: SystemAccount<'info>,
    #[account(mut)]
    recipient: SystemAccount<'info>,
    system_program: Program<'info, System>,
}

The cpi.test.ts file shows how to invoke the Anchor program's sol_transfer instruction and logs a link to the transaction details on SolanaFM.

It shows how to derive the PDA using the seeds specified in the program:

const [PDA] = PublicKey.findProgramAddressSync(
  [Buffer.from("pda"), wallet.publicKey.to


[User] What API endpoint is used to set the referral fee in Jupiter?

[Assistant]
To set the referral fee in Jupiter, you use the `GET /quote` endpoint and include the `platformFeeBps` parameter in your request.

Here is an example of how to structure the request:

```http
GET https://quote-api.jup.ag/v6/quote?inputMint=So11111111111111111111111111111111111111112&outputMint=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v&amount=100000000&platformFeeBps=50
```

In this example, `platformFeeBps` is set to 50, which represents a 0.5% referral fee. Make sure to adjust the parameters according to your specific needs.

bps for 0.2% of the token input or output. If a platform fee is set by an integrator, Jupiter will take 2.5% of the platform fee charged by the integrators. It doesn't support Token2022 tokens.

Usage
Jupiter API
1. Obtain a referral account
Go to the referral dashboard to create your referral account. After creating your referral account, remember to find your Referral Key on the page. This is your referral account public key. You'll need this to gather platform fees.

2. Set your referral fee
Setting your referral fee with the Jupiter API is simple. You just add in the platformFeeBps parameter to the GET /quote endpoint:

GEThttps://quote-api.jup.ag/v6/quote
See this for a guide on how to get the route for a swap!

// Function to swap SOL to USDC with input 0.1 SOL and 0.5% slippage
async function getQuote() {
  try {
    // Create a new URL object for the quote API endpoint
    const url = new URL("https://quote-api.jup.ag/v6/quote");

    // Append query parameters to the URL
    // inputMint: The mint address of the input token (SOL)
    url.searchParams.append(
      "inputMint",
      "So11111111111111111111111111111111111111112"
    );

    // outputMint: The mint address of the output token (USDC)
    url.searchParams.append(
      "outputMint",
      "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
    );

    // amount: The amount of input tokens to be swapped (0.1 SOL in lamports, where 1 SOL = 1,000,000,000 lamports)
    url.searchParams.append("amount", 100000000)


[User] What is the purpose of the <UnifiedWalletProvider /> in Jupiter?

[Assistant]
The `<UnifiedWalletProvider />` in Jupiter serves as a wrapper component that allows you to integrate multiple wallet options into your application. It enables developers to support various wallets seamlessly, providing users with a unified experience when interacting with different wallet services.

When you use `<UnifiedWalletProvider />`, you can specify the wallets you want to support, configure settings such as auto-connection, and provide metadata about your wallet integration. This setup enhances the user experience by allowing them to choose from a range of wallets while ensuring that the integration is smooth and efficient.

Here’s a basic example of how to use `<UnifiedWalletProvider />`:

```javascript
import { UnifiedWalletProvider, UnifiedWalletButton } from '@jup-ag/wallet-adapter';

const ExampleBaseOnly = () => {
  return (
    <UnifiedWalletProvider
      wallets={[]} // Specify the wallets you want to support
      config={{
        autoConnect: false,
        env: 'mainnet-beta',
        metadata: {
          name: 'UnifiedWallet',
          description: 'UnifiedWallet',
          url: 'https://jup.ag',
          iconUrls: ['https://jup.ag/favicon.ico'],
        },
        notificationCallback: WalletNotification, // Callback for notifications
        walletlistExplanation: {
          href: 'https://station.jup.ag/docs/additional-topics/wallet-list', // Link for wallet list explanation
        },
      }}
    >
      <UnifiedWalletButton /> // Button for users to connect their wallet
    </UnifiedWalletProvider>
  );
};

export default ExampleBaseOnly;
```

In this example, the `<UnifiedWalletProvider />` is configured with metadata and a notification callback, and it includes a button for users to connect their wallets. This setup is essential for creating a user-friendly wallet integration in your application.

npm i @jup-ag/wallet-adapter

Wrap your app with <UnifiedWalletProvider /> and pass in as little to as many wallets you would like to support.
An Example from the Unified Wallet Kit Repository
const ExampleBaseOnly = () => {
  return (
    <UnifiedWalletProvider
      wallets={[]}
      config={{
        autoConnect: false,
        env: 'mainnet-beta',
        metadata: {
          name: 'UnifiedWallet',
          description: 'UnifiedWallet',
          url: 'https://jup.ag',
          iconUrls: ['https://jup.ag/favicon.ico'],
        },
        notificationCallback: WalletNotification,
        walletlistExplanation: {
          href: 'https://station.jup.ag/docs/additional-topics/wallet-list',
        },
      }}
    >
      <UnifiedWalletButton />
    </UnifiedWalletProvider>
  );
};

export default ExampleBaseOnly;

info
This kit also supports the attachment of custom elements to specific wallets

config={{
  walletAttachments: {
    'Phantom': {
      attachment:
Auto Confirm

    }
  }
}}

Rust Integration
thinking cat

Overview
Jupiter is one of the most widely integrated protocols, so a lot of work is involved in minimizing issues on new integrations and making each integration valuable to our users and partners.

Our top priority is securing the best prices and the best token selection for our users, so we will focus on DEXes that will bring the most benefits to them.

We do not charge fees for integ


[User] Can CoinGecko provide detailed information such as name, symbol, and description of a pool using its API?

[Assistant]
Yes, CoinGecko can provide detailed information about a pool using its API. You can access this information by using the following endpoint:

```
/onchain/networks/{network}/pools/{pool_address}/info
```

This endpoint will return data such as the pool's name, symbol, image URL, and description. You need to replace `{network}` with the specific network you are interested in and `{pool_address}` with the address of the pool you want to query.

Here is an example of how you might structure a request to this endpoint:

```http
GET /onchain/networks/ethereum/pools/0xYourPoolAddress/info
```

This request would return the detailed information for the specified pool on the Ethereum network.

erminal
/onchain/networks/{network}/new_pools - Display a list of new pools on a network on GeckoTerminal
/onchain/networks/{network}/pools - Display all the top pools on a network on GeckoTerminal

Pool Page (PORK/WETH)

/onchain/networks/{network}/pools/{address} - Display pool data such as price, transactions, volume and etc.
/onchain/networks/{network}/pools/{pool_address}/info - Display pool information such as name, symbol, image url, description and etc.
/onchain/networks/{network}/pools/{pool_address}/ohlcv/{timeframe} - Display the OHLCV chart of the pool
/onchain/networks/{network}/pools/{pool_address}/trades - Display the trades of the pool in the past 24 hours

Categories Page (GeckoTerminal)

/onchain/categories - Display list of onchain categories with market data
/onchain/categories/{id}/pools - Display list of pools with market data of a specific onchain category

Links
👶 Tutorials (Beginner-friendly)
Using CoinGecko API is super easy, even if you have no programming experience!

🔤 No Code
Import Crypto Prices in Google Sheets

Import Crypto Prices in Microsoft Excel

💻 Low Code
Create Portfolio Tracker in Google Sheets

👨💻 Code
Fetch Crypto Data Using Python

📄 Case Studies
Learn how forward-thinking industries adopt CoinGecko API as the #1 resource for real-time crypto assets data

Certik - Web 3 Security
FanMarketCap - Data Aggregation Platform
Zapper Fi - Social Web 3 Explorer
Zerion - Web 3 Smart Wallet
More case studies coming soon! You may view all ca


[User] How do I disable token authentication for a QuickNode endpoint?

[Assistant]
To disable token authentication for a QuickNode endpoint, you need to access the security settings for that specific endpoint. Here are the steps to do so:

1. Log in to your QuickNode account.
2. Navigate to the endpoint for which you want to disable token authentication.
3. In the security settings of the endpoint, look for the option to disable token authentication.
4. Toggle the setting to disable token authentication.

Once you have disabled token authentication, anyone will be able to make requests to the endpoint without needing to provide a token.

Make sure to consider the security implications of this action, as it allows unrestricted access to your endpoint.

n in the URL which looks something like this:

http://sample-endpoint-name.network.quiknode.pro/token-goes-here/
Approved Referrer List
For endpoints on the shared network, you are able to add a list of approved referrers. This requires any HTTP request to send a REFERRER header or any WebSocket request to send an ORIGIN header populated with one of the referrers you entered into our user panel.

Disabling Token Authentication
You can also disable the token authentication completely in your security settings for a given endpoint. This will allow anyone to make requests to the endpoint without the token.

JWT (JSON Web Tokens)
For additional security, you can also enable JWT for each of your deployed endpoints. JWT allows for stateless authentication between you and your endpoint. Learn how to use JWT with QuickNode in this step-by-step guide.

Multiple Authentication Tokens
Create multiple authentication tokens for each of your deployed endpoints. This allows you to revoke any tokens that may be comprised, without needing to restart your non-compromised endpoint.

To roll an individual authentication token, create an additional token and then delete the previous token. Learn more about multiple authentication tokens in this QuickNode guide.

Secure Your QuickNode Solana Endpoint
Enhance the security of your QuickNode RPC endpoints using the Endpoint Armor add-on. This add-on provides a secure URL for safer public and front-end usage, allowing you to control access, set rate


[User] What is the purpose of the Magic Eden Bug Bounty Program?

[Assistant] The purpose of the Magic Eden Bug Bounty Program is to invite users to explore the Magic Eden API and actively participate in identifying vulnerabilities. It aims to enhance the security of the platform by encouraging developers and users to report any security issues they may find. Participants can submit issues through HackerOne, which is the platform used for managing the bug bounty program. This initiative fosters a collaborative approach to improving the security of Magic Eden’s services.

Magic Eden’s API and most other assets are covered under our bug bounty program with HackerOne. We invite you to explore our API and actively participate in identifying vulnerabilities. To submit an issue or learn more about our program, check out our Bug Bounty Program.

Updated about 1 year ago

Get instruction to withdraw from escrow
Ordinals API Overview
Did this page help you?
Table of Contents
Security Issues and Bug Bounties

Ordinals API Overview
The Magic Eden Ordinals API is designed to empower developers in creating innovative experiences to gather data for https://magiceden.io/ordinals.

We offer these endpoints in the spirit of fostering composability and openness in the web3 space, extending the reach of this data to anyone desiring to build upon it. In return, if you utilize our data, we ask that you adhere to our Terms of Service.

Moreover, we make this API available free of charge and kindly request that you attribute Magic Eden on your website or within your app. When you leverage our API, please consider linking to the Magic Eden marketplace from the NFTs that you showcase, where it's appropriate.

Please be aware that our API is rate-limited and some endpoints are gated by an API key. For more info check out Ordinals API Keys

Clusters
Mainnet: api-mainnet.magiceden.dev/v2/ord - this uses the real Ordinals Mainnet cluster, the tokens are real and this is consistent with the data seen on https://magiceden.io/ordinals
Updated about 1 year ago

Frequently As


[User] What does the 'dynamicComputeUnitLimit' option do in the context of a Jupiter swap transaction?

[Assistant]
The `dynamicComputeUnitLimit` option in the context of a Jupiter swap transaction allows the transaction to dynamically adjust the compute unit limit based on the requirements of the transaction being executed. This means that instead of setting a fixed compute unit limit, the transaction can adapt to the actual compute needs as it processes, potentially leading to more efficient execution and successful completion of the swap.

By enabling this option, the transaction can handle varying complexities and resource requirements that may arise during the swap process, which is particularly useful in scenarios where the computational demands are not predictable in advance.

;
}

// Step 1: Fetch swap info
async function fetchSwapInfo() {
  const response = await fetch('https://quote-api.jup.ag/v6/quote?inputMint=mSoLzYCxHdYgdzU16g5QSh3i5K3z3KZK7ytfqcJm7So&outputMint=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v&amount=5000000&swapMode=ExactOut&slippageBps=50');
  const data = await response.json();
  return {
    inAmount: data.inAmount,
    otherAmountThreshold: data.otherAmountThreshold,
    quoteResponse: data
  };
}

// Step 2: Fetch the swap transaction
async function fetchSwapTransaction(swapUserKeypair, bobUSDCTokenAccount, swapInfo) {
  const requestBody = {
    userPublicKey: swapUserKeypair.publicKey.toBase58(),
    wrapAndUnwrapSol: true,
    useSharedAccounts: true,
    feeAccount: feeAccount.toBase58(),  // Use actual key
    trackingAccount: trackingAccount.toBase58(),  // Use actual key
    prioritizationFeeLamports: 0,  // No prioritization fee in this case
    asLegacyTransaction: false,
    useTokenLedger: false,
    destinationTokenAccount: bobUSDCTokenAccount.toBase58(),
    dynamicComputeUnitLimit: true,
    skipUserAccountsRpcCalls: true,
    quoteResponse: swapInfo.quoteResponse
  };

  const response = await fetch('https://quote-api.jup.ag/v6/swap', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(requestBody),
  });

  const { swapTransaction, lastValidBlockHeight } = await response.json();
  return { swapTransaction, lastValidBlockHeight };
}

// Step 3: Send


[User] How does Raydium's hybrid AMM model utilize liquidity from central limit order books?

[Assistant]
Raydium's hybrid AMM model uniquely integrates liquidity from central limit order books (CLOB) by allowing its automated market maker (AMM) to access and utilize liquidity that exists within these order books. This approach contrasts with traditional AMMs, which only draw liquidity from their own pools.

In Raydium's model, idle liquidity from AMM pools can be shared with the central limit order book, enabling users to benefit from deeper liquidity and tighter spreads when executing trades. This means that trades can be executed faster and at better prices, as the AMM can tap into the existing orders in the CLOB.

However, it’s important to note that Raydium's hybrid AMM pools are currently set to "Swap Only," which indicates that liquidity is not being shared with a third party at this time. This setup allows users to perform swaps within the AMM without accessing external liquidity sources.

This integration of AMM and CLOB functionalities provides a more efficient trading experience by combining the advantages of both models, ultimately enhancing liquidity and trading efficiency on the platform.

✌ Say Hello to Raydium
An on-chain order book AMM powering the evolution of DeFi

🧬 So, what is Raydium?

Raydium is an automated market maker (AMM) built on the Solana blockchain which enables lightning-fast trades, permissionless pool creation, and new features for earning yield.

👽 Why is Raydium different?

Raydium was the first hybrid AMM. Other AMM DEXs and DeFi protocols could only access liquidity within their own pools and had no access to a central order book. Raydium's novel AMM was able to share idle pool liquidity to central limit order books following the constant product formula. Raydium's hybrid AMM pools are currently set to Swap Only, which means liquidity is not being shared to a third party.

Raydium offers a few key advantages and products:

Faster and cheaper: Raydium leverages the efficiency of the Solana blockchain to achieve transactions magnitudes faster than Ethereum and gas fees which are a fraction of the cost.

Permissionless pool creation: Any user or project can create a concentrated liquidity pool (CLMM) or constant product pool (CPMM) for any asset.

Ecosystem Rewards: Any user or project can add token incentives to any pair or pool, boosting yield for liquidity providers.

🧐 What can I do on Raydium?

Trade and swap

Raydium's swap feature allows any two tokens to be exchanged quickly within liquidity pools.

Create a Pool

Create a pool for any asset in just a few clicks. Once live, your pool will be tradeable through Raydium's routin


[User] What JavaScript library is needed to interact with the StakeProgram in Solana?

[Assistant]
To interact with the StakeProgram in Solana using JavaScript, you need the `@solana/web3.js` library. This library provides the necessary tools to create a stake account, stake SOL, authorize accounts for withdrawal, deactivate your stake, and withdraw funds.

Here’s an example of how to import the library:

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

This library will allow you to work with the StakeProgram and perform various staking operations on the Solana network.

  [Object], [Object], [Object],
      [Object], [Object], [Object],
      [Object], [Object], [Object],
      [Object], [Object], [Object],
      [Object], [Object], [Object],
      [Object], [Object], [Object],
      [Object], [Object]
   ],
  epochCredits: [
    { epoch: 179, credits: 33723163, prevCredits: 33431259 },
    { epoch: 180, credits: 34022643, prevCredits: 33723163 },
    { epoch: 181, credits: 34331103, prevCredits: 34022643 },
    { epoch: 182, credits: 34619348, prevCredits: 34331103 },
    { epoch: 183, credits: 34880375, prevCredits: 34619348 },
    { epoch: 184, credits: 35074055, prevCredits: 34880375 },
    { epoch: 185, credits: 35254965, prevCredits: 35074055 },
    { epoch: 186, credits: 35437863, prevCredits: 35254965 },
    { epoch: 187, credits: 35672671, prevCredits: 35437863 },
    { epoch: 188, credits: 35950286, prevCredits: 35672671 },
    { epoch: 189, credits: 36228439, prevCredits: 35950286 },
    ...
  ],
  lastTimestamp: { slot: 104570916, timestamp: 1635730116 }
}
*/

Staking #
StakeProgram #
Source Documentation

The StakeProgram facilitates staking SOL and delegating them to any validators on the network. You can use StakeProgram to create a stake account, stake some SOL, authorize accounts for withdrawal of your stake, deactivate your stake, and withdraw your funds. The StakeInstruction class is used to decode and read more instructions from transactions calling the StakeProgram

Example Usage #
const web3 = require("@solana/web3.js")


[User] How does Helius provide information about transaction errors?

[Assistant]
Helius provides information about transaction errors through the `transactionError` object in the response structure. This object contains details regarding any errors that occurred during the transaction process.

When you make a request to Helius for transaction information, the response will include this `transactionError` object if there were any issues with the transaction.

Here is an example of how the response structure might look:

```json
{
  "signature": "yy5BT9benHhx8fGCvhcAfTtLEHAtRJ3hRTzVL16bdrTCWm63t2vapfrZQZLJC3RcuagekaXjSs2zUGQvbcto8DK",
  "transactionError": {
    "code": "TransactionErrorCode",
    "message": "Detailed error message describing what went wrong."
  },
  ...
}
```

In this example, the `transactionError` object contains a `code` that specifies the type of error and a `message` that provides a detailed description of the error encountered during the transaction. This allows users to understand what went wrong and take appropriate actions to resolve the issue.

CANDY_MACHINE_V3
CANDY_MACHINE_V2
CANDY_MACHINE_V1
UNKNOWN
SOLANART
SOLSEA
MAGIC_EDEN
HOLAPLEX
METAPLEX
OPENSEA
SOLANA_PROGRAM_LIBRARY
ANCHOR
PHANTOM
SYSTEM_PROGRAM
STAKE_PROGRAM
COINBASE
CORAL_CUBE
HEDGE
LAUNCH_MY_NFT
GEM_BANK
GEM_FARM
DEGODS
BSL
YAWWW
ATADIA
DIGITAL_EYES
HYPERSPACE
TENSOR
BIFROST
JUPITER
MERCURIAL
SABER
SERUM
STEP_FINANCE
CROPPER
RAYDIUM
ALDRIN
CREMA
LIFINITY
CYKURA
ORCA
MARINADE
STEPN
SENCHA
SAROS
ENGLISH_AUCTION
FOXY
HADESWAP
FOXY_STAKING
FOXY_RAFFLE
FOXY_TOKEN_MARKET
FOXY_MISSIONS
FOXY_MARMALADE
FOXY_COINFLIP
FOXY_AUCTION
CITRUS
ZETA
ELIXIR
ELIXIR_LAUNCHPAD
CARDINAL_RENT
CARDINAL_STAKING
BPF_LOADER
BPF_UPGRADEABLE_LOADER
SQUADS
SHARKY_FI
OPEN_CREATOR_PROTOCOL
BUBBLEGUM
NOVA
D_READER
RAINDROPS
W_SOL
DUST
SOLI
USDC
FLWR
HDG
MEAN
UXD
SHDW
POLIS
ATLAS
USH
TRTLS
RUNNER
INVICTUS
feeinteger
Example: 5000
feePayerstring
Example: "8cRrU1NzNpjL3k2BwjW3VixAcX6VFc29KHr4KZg8cs2Y"
signaturestring
Example: "yy5BT9benHhx8fGCvhcAfTtLEHAtRJ3hRTzVL16bdrTCWm63t2vapfrZQZLJC3RcuagekaXjSs2zUGQvbcto8DK"
slotinteger
Example: 148277128
timestampinteger
Example: 1656442333
nativeTransfersarray of NativeTransfer (object)

tokenTransfersarray of TokenTransfer (object)

accountDataarray of AccountData (object)

transactionErrorobject

instructionsarray of Instruction (object)

eventsobject
Events associated with this transaction. These provide fine-grained information about the transaction. They match the types returned from the event APIs.

Request

JavaScript
Copy
const response =


[User] How does the seeds parameter affect the uniqueness of the pda_account in Solana?

[Assistant]
In Solana, the `seeds` parameter is crucial for deriving a Program Derived Address (PDA) that is unique to specific inputs. The uniqueness of the `pda_account` is determined by the combination of the seeds used and the program ID.

In the provided example, the `seeds` parameter is defined as follows:

```rust
#[account(
    mut,
    seeds = [b"pda", recipient.key().as_ref()],
    bump,
)]
pda_account: SystemAccount<'info>,
```

Here, the seeds consist of a hardcoded byte string `b"pda"` and the public key of the `recipient` account. This means that the derived PDA will be unique for each recipient because the recipient's public key is included in the seed array.

When you derive the PDA using the seeds, the resulting address is computed based on both the seeds and the program ID. Therefore, even if the same hardcoded string `b"pda"` is used, the inclusion of different recipient public keys will yield different PDAs.

For example, the JavaScript equivalent to derive the PDA is shown as:

```javascript
const [PDA] = PublicKey.findProgramAddressSync(
  [Buffer.from("pda"), wallet.publicKey.toBuffer()],
  program.programId,
);
```

In this code, `wallet.publicKey.toBuffer()` would represent the recipient's public key, ensuring that each invocation with a different recipient will produce a different PDA.

In summary, the `seeds` parameter contributes to the uniqueness of the `pda_account` by allowing the combination of static and dynamic data (like the recipient's public key) to create a distinct address for each account derived from the same program.

 wallet.publicKey,
    })
    .rpc();

  console.log(
    `\nTransaction Signature: https://solana.fm/tx/${transactionSignature}?cluster=devnet-solana`,
  );
});

You can build, deploy, and run the test to view the transaction details on the SolanaFM explorer.

The transaction details will show that the custom program was first invoked (instruction 1), which then invokes the System Program (instruction 1.1), resulting in a successful SOL transfer.

Transaction Details
Transaction Details

Example 2 Explanation #
In the example code, the SolTransfer struct specifies the accounts required by the transfer instruction.

The sender is a PDA that the program must sign for. The seeds to derive the address for the pda_account include the hardcoded string "pda" and the address of the recipient account. This means the address for the pda_account is unique for each recipient.

#[derive(Accounts)]
pub struct SolTransfer<'info> {
    #[account(
        mut,
        seeds = [b"pda", recipient.key().as_ref()],
        bump,
    )]
    pda_account: SystemAccount<'info>,
    #[account(mut)]
    recipient: SystemAccount<'info>,
    system_program: Program<'info, System>,
}

The Javascript equivalent to derive the PDA is included in the test file.

const [PDA] = PublicKey.findProgramAddressSync(
  [Buffer.from("pda"), wallet.publicKey.toBuffer()],
  program.programId,
);

The following tabs present two approaches to implementing Cross Program Invocations (CPIs), each at a different level of ab


[User] What are the long-term benefits of using Jupiter's VA over traditional investment strategies?

[Assistant]
The long-term benefits of using Jupiter's Value Averaging (VA) strategy over traditional investment strategies include:

1. **Capitalizing on Market Volatility**: VA is designed to adjust investment amounts based on market performance. This means that during market downturns, you can invest more, and during market upswings, you can invest less. This approach allows you to take advantage of price fluctuations effectively.

2. **Consistent Portfolio Building**: VA can be a valuable tool for building a portfolio consistently over time, regardless of market conditions. It allows for steady accumulation in bear markets and profit-taking in bull markets, which can enhance overall portfolio performance.

3. **Protection Against Overpaying**: One of the key advantages of VA is that it helps protect you from overpaying for assets when the market is hot. By adjusting your contributions based on market conditions, you can avoid the pitfalls of investing fixed amounts, which may lead to poorer long-term returns.

4. **Improved Long-Term Returns**: By avoiding overpayment and adjusting your investment strategy according to market conditions, your long-term returns can be stronger compared to traditional strategies that do not account for market fluctuations.

5. **Flexibility in Order Execution**: VA allows for dynamic adjustments in order amounts based on market conditions, which can lead to more favorable average prices. This flexibility can mitigate the negative price impacts associated with executing large market orders, especially in low liquidity scenarios.

Overall, Jupiter's VA strategy offers a more responsive and strategic approach to investing that can lead to better long-term outcomes compared to traditional fixed contribution methods.

e fluctuations by adjusting investment amounts based on market performance. When prices drop, you invest more, and when prices rise, you invest less, effectively capitalizing on market volatility.

Long term strategy
Since VA is effective at capitalizing on market volatility, regardless of market conditions, VA can be a good tool to build portfolio and invest consistently based on market conditions. In bear market scenarios, VA can be used to steadily accumulate and contrastingly, VA can be used to take profit during a bull market. VA can be more attractive to than using a set contribution schedule is that you are somewhat protected from overpaying when the market is hot. If you avoid overpaying, your long-term returns will be stronger compared to people who invested set amounts no matter the market condition.

Splitting up large orders
Executing market orders, whether through decentralized or centralized exchanges, can lead to negative price impacts, particularly in times of exceptionally low liquidity or with a substantial capital. This is where Value Averaging (VA) proves invaluable. By adjusting your order amounts based on market conditions, you exert less buying/selling pressure on the market, ultimately securing a more favorable average price. With Jupiter's VA, you have the flexibility to adjust your orders dynamically. In essence, this transforms into a variation of a TWAP (time-weighted average price) strategy, a method frequently utilized by major investors to strat


[User] What does the 'updated_at' field indicate in the CoinGecko categories response?

[Assistant]
The 'updated_at' field in the CoinGecko categories response indicates the last time the category data was updated. This timestamp provides users with information about the freshness of the data, allowing them to understand how recent the market data is for that specific category.

For example, if the 'updated_at' field shows a date and time, it means that the market data for that category was last refreshed at that specific moment. This is important for users who rely on up-to-date information for making decisions based on market trends.

/www.coingecko.com/en/categories
Cache / Update Frequency: every 5 minutes for all the API plans
CoinGecko categories are different from GeckoTerminal categories
Query Params
order
string
sort results by field, default: market_cap_desc

Response

200
List all categories with market data

Response body
object
id
string
category id

name
string
category name

market_cap
number
category market cap

market_cap_change_24h
number
category market cap change in 24 hours

content
string
category description

top_3_coins_id
array of strings
ids of top 3 coins in the category

top_3_coins
array of strings
images of top 3 coins in the category

volume_24h
number
category volume in 24 hours

updated_at
string
category last updated time

Updated 21 days ago

Coins Categories List (ID Map)
Exchanges
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
Credentials
x-cg-pro-api-key

Log in to use your API keys
1
curl --request GET \
2
     --url https://pro-api.coingecko.com/api/v3/coins/categories \
3
     --header 'accept: application/json'

Try It!
RESPONSE
1
[
2
  {
3
    "id": "layer-1",
4
    "name": "Layer 1 (L1)",
5
    "market_cap": 2061406861196.14,
6
    "market_cap_change_24h": -0.66091235190398,
7
    "content": "",
8
    "top_3_coins_id": [
9
      "bitcoin",
10
      "ethereum",
11
      "binancecoin"
12
    ],
13
    "top_3_coins": [
14
      "https://assets.coingecko.com/coins/images/1/small/bitcoin.png?1696501400",
15
      "https://assets.coingecko.com/coins/im


[User] What assurance does permanently locking liquidity in Meteora provide to traders and the community?

[Assistant]
Permanently locking liquidity in Meteora provides assurance to traders and the community by demonstrating a commitment to the project's stability and integrity. When liquidity is permanently locked, it means that the liquidity provider cannot withdraw those funds, which helps to mitigate the risk of a "rug pull"—a scenario where developers withdraw liquidity, leading to a loss for investors.

This action reassures traders and the community that the liquidity is secure and that the project is dedicated to maintaining a stable trading environment. Additionally, projects that lock their liquidity can still claim compounding trading fees from the locked liquidity, which can further enhance the project's credibility and financial sustainability.

In summary, permanently locking liquidity signals to the community that the project is serious about its long-term viability and is taking steps to protect investors' interests.

s important that this is the market price or you will get arbitraged away. So if you create a SOL/USDC pool, you would need to add 75 USDC for every 1 SOL you add to the pool. If this is way off you can lose money as arbitragers take advantage of your low price.

You need a minimum of $600 in liquidity (combined value of token pair) for your pool to be picked up by Jupiter. This may take 30mins for the crawler to update. If at any time the liquidity goes below $600 then it will auto-delist from Jupiter, but once it goes above, it will auto-relist. Please visit here for the latest steps to get the token and pool listed on Jupiter.

It may take a few minutes for your pool to appear on the Meteora pools list, but if the transaction is successful then it will be created on-chain.

Claiming Fees from Permanently Locked Liquidity
If you are a memecoin or token project that wants to assure traders and your community, you can permanently lock your liquidity  (your lose this liquidity forever) in your dynamic pool.

Simply navigate to the "Burn" tab and lock your Meteora LP token in the pool.

After you permanently lock liquidity in the dynamic pool, you can even claim compounding trading fees from your locked liquidity, forever!

Adding liquidity with one address but allowing a different address to claim fees on the permanently locked liquidity
For developers, our Dynamic AMM program allows one address to add liquidity first then send their own Meteora LP token to a different lock


[User] What are the four trading methods available on Jupiter for spot trading?

[Assistant]
The four trading methods available on Jupiter for spot trading are:

1. **Swap**: This method allows you to swap between any token on Solana with the best prices and zero fees with a single click. Jupiter automatically minimizes slippage and sets priority fees for you.

2. **Limit Order (LO)**: With this method, you can specify a set price to execute your trade. When your desired price is hit, Jupiter’s Keepers attempt to fill the order for you.

3. **Dollar-Cost Averaging (DCA)**: This strategy involves buying a fixed dollar amount of a particular asset at regular intervals, regardless of its price.

4. **Value Averaging (VA)**: This method adjusts the amount you invest based on the asset's price, aiming to achieve a target value over time.

These methods provide flexibility and various strategies for trading tokens on the Solana network.

seamless experience for you. Read our guide on Bridge, Onramp, and CEX transferring.
General Guides: Discover general guides relating to the Solana ecosystem such as personal security, using a block explorer to verify swaps, actions & blinks, token guide for creators, the Jupiter Media Kit, and FAQs about the Jupiter Platform.
Welcome to the community, J4J (JUP 4 JUP)!

Spot Overview
spot-overview

Welcome to Jupiter Spot, the most powerful way to trade tokens on Solana.

Jupiter Spot relies on Jupiter Routing, a universal routing algorithm with over 22 AMMs on Solana, intelligently finding the best prices for your trades, and across all the tokens on Solana.

Jupiter Spot is made up of 4 trading methods to help you buy and sell spot assets on Solana:

Swap
Limit Order (LO)
Dollar-Cost Averaging (DCA)
Value Averaging (VA)
Let's go through them in this overview!

spot-swap

Swap between any token on Solana, with the best prices and 0 fees with a single click.

Jupiter also automatically minimizes slippage and set priority fees for you, while flagging potential concerns.
All you have to do is to set the max slippage & priority fees you are willing to pay, before swapping without worry.
Detailed walkthrough on how to swap on Jupiter & UI features: How to Swap
spot-lo

Specify a set price to execute your trade, across most tokens on Solana.

When your desired price is hit, Jupiter’s Keepers attempt to fill the order for you.
Note: You will get filled at exactly the rate you speci


[User] What should users do to ensure their LP positions are claimed before the Raydium Claim Portal is deprecated?

[Assistant]
To ensure that users claim their LP positions before the Raydium Claim Portal is deprecated, they should follow these steps:

1. **Access the Claim Portal**: Users need to visit the Claim Portal to view details on their affected LP positions.

2. **Check LP Position Details**: Once in the portal, users should check the details of their LP positions that were affected by the exploit.

3. **Submit Claims**: Users must submit their claims for asset compensation through the portal. It is crucial to complete this process before the portal is deprecated.

4. **Deadline Awareness**: Users should be aware that the Claim Portal will be deprecated from the UI on April 17, 2023. Therefore, they should ensure that all claims are submitted by this date.

5. **Monitor Timing**: Phase 1 of distribution was available from January 5, 2023, and remained open until March 6, 2023. Users who fall under Phase 2-A should note that this phase opened on January 20, 2023, and also has a deadline.

By following these steps and being mindful of the deadlines, users can ensure that they successfully claim their LP positions before the Claim Portal is no longer available.

25,026.71 RAY transferred directly to individual DetlaOne position accounts

44,036.51 RAY transferred directly to Tulip lending vaults for leveraged positions

Following the conclusion of the claims process, RAY contributed from team allocation that remains unclaimed will be returned to the team allocation.

Claim Portal
This portal can be used to claim asset compensation from the recent incident

The claim portal will be deprecated from the UI on April 17, 2023. Please ensure any LP positions have claimed by that time. For full details see the Medium post

Background
Following the initial proposal for the remediation of funds for the December 16th exploit, assets were allocated to obtain the affected assets needed to compensate users.

The next step is to use the obtained assets to restore losses to users that had liquidity positions in affected pools at the time of the incident.

You can also read the full Medium article on the compensation plan for more details.

Claim Portal
The claim portal UI allows users with LP positions affected by the exploit to view details on their affected LP positions and claim assets as remediation for funds lost.

Timing
Phase 1 of distribution will be available via the Claim Portal from January 5, 12:00 UTC. The portal will remain open for 2 months until March 6th.

Phase 2-A, which includes users who held and maintained a position on Francium, will be available via the Claim Portal from January 20, 12:30 UTC. The portal will remain open


[User] What is the purpose of the 'signer' object in Magic Eden when signing messages?

[Assistant]
In Magic Eden, the `signer` object is used to facilitate the signing of messages and transactions by the user. It represents an Ethereum account that can sign messages and transactions, allowing for secure interactions with the Ethereum blockchain.

When you obtain the `signer` object using the provider, it allows you to call the `signMessage` function directly, which simplifies the process of signing messages. This is particularly useful for verifying the identity of the user or for authorizing actions within the Magic Eden ecosystem.

Here’s an example of how to use the `signer` object to sign a message:

```javascript
const signer = await provider?.getSigner();
await signer!.signMessage(
  "Hello, World! 🌍 Welcome to the Magic Eden wallet on Ethereum"
);
```

In this example, the `signer` object is used to sign the message "Hello, World! 🌍 Welcome to the Magic Eden wallet on Ethereum". This signed message can then be used for various purposes, such as authentication or transaction verification.

t(2, "0"))
		.join("");
const sign = await provider.request({
	method: "personal_sign",
	params: [msg, address, "Example password"],
});
Using Ethers.js
Alternatively, you can make use of the popular web3 javascript library ethers.js to abstract away some of the above complexity. Instead of directly invoking personal_sign on the provider request, you can wrap the ME browser provider in a Web3Provider object from ethers. Doing so allows you to invoke the signMessage function directly.

Copy
 const signer = await provider?.getSigner();
 await signer!.signMessage(
   "Hello, World! 🌍 Welcome to the Magic Eden wallet on Ethereum"
 );

Sending a Transaction
To send a transaction, you must construct a valid transaction object and then prompt the user to sign the transaction with their private key.

Direct Sending
Triggering this directly would look make use of the provider request function and look like this:

Copy
const result = await provider.request({
        method: 'eth_sendTransaction',
        params: [
          {
            from: address,
            to: '0x6aDdF38602487b7a159D926bc08151eBaEEF2B70',
            value: '0x0',
            gasLimit: '0x5028',
            gasPrice: '0x2540be400',
            type: '0x0',
          },
        ],
});
However, there are several other parts of a transaction object that might need to be specfied, and therefore it is suggested to make use of a web3 library that abstracts away a lot of this complexity, like ethers.js

Using Ethers.j


[User] What does the supply command return for a newly created token in Solana?

[Assistant]
For a newly created token in Solana, running the supply command will return a value of 0. This indicates that the token initially has no supply.

For example, if you run the command:

```bash
spl-token supply 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg
```

You would receive an output showing that the supply is 0.

UwdzrCys3fvCdFxbLMnNvBstds76QZyE6cXag5NupBprSXwxPTzzjrC3cA6nvUZaLFTvmcKyzxrm1

New tokens initially have no supply. You can check the current supply of a token using the following command:

spl-token supply <TOKEN_ADDRESS>

Running the supply command for a newly created token will return a value of 0:

spl-token supply 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg

Under the hood, creating a new Mint Account requires sending a transaction with two instructions. Here is a Javascript example on Solana Playground.

Invoke the System Program to create a new account with enough space for the Mint Account data and then transfer ownership to the Token Program.

Invoke the Token Program to initialize the data of the new account as a Mint Account

Create Token Account #
To hold units of a particular token, you must first create a token account. To create a new token account, use the following command:

spl-token create-account [OPTIONS] <TOKEN_ADDRESS>

For example, running the following command in the Solana Playground terminal:

spl-token create-account 99zqUzQGohamfYxyo8ykTEbi91iom3CLmwCA75FK5zTg

Returns the following output:

AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9 is the address of the token account created to hold units of the token specified in the create-account command.
Terminal
Creating account AfB7uwBEsGtrrBqPTVqEgzWed5XdYfM1psPNLmf7EeX9

Signature: 2BtrynuCLX9CNofFiaw6Yzbx6hit66pup9Sk7aFjwU2NEbFz7NCHD9w9sWhrCfEd73XveAGK1DxFpJoQZPXU9tS1

By default the create-account


[User] How can you specify the encoding type for the response when using getProgramAccounts in ChainStack?

[Assistant]
When using the `getProgramAccounts` method in ChainStack, you can specify the encoding type for the response by including an options object in the `params` array. Specifically, you can set the `encoding` field within this options object.

Here’s how you can do it in a JSON-RPC request:

```json
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getProgramAccounts",
  "params": [
    "FsJ3A3u2vn5cTVofAjvy6y5kwABJAqYWpe4975bi2epH",
    {
      "encoding": "jsonParsed"
    }
  ]
}
```

In this example, the encoding type is set to `"jsonParsed"`,

or getProgramAccounts is to retrieve the current state of all accounts associated with a specific Solana program. This can be useful for wallets or other applications that need to display or make use of this information.

Try the getProgramAccounts RPC method yourself
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getProgramAccounts
getProgramAccounts
params
array
Defaults to FsJ3A3u2vn5cTVofAjvy6y5kwABJAqYWpe4975bi2epH,[object Object]

string

FsJ3A3u2vn5cTVofAjvy6y5kwABJAqYWpe4975bi2epH

string

[object Object]
Response

200
Program accounts details

Updated 7 days ago

getMultipleAccounts | Solana
getRecentBlockhash | Solana
Did this page help you?
Language

Shell

Node

Ruby

PHP

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

getRecentBlockhash | Solana
post
https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/
🚧
Deprecated

The getRecentBlockhashmethod is deprecated starting from the Solana client v1.9. This method only works on older outdated clients v1.8 and below.

For the currently supported and up-to-date metho


[User] Is it possible to filter the NFT query results by asset platform ID using CoinGecko's API?

[Assistant]
Yes, you can filter the NFT query results by asset platform ID using CoinGecko's API. The endpoint to query all supported NFTs allows you to specify parameters that can help filter the results.

Here is the relevant endpoint:

```
GET https://pro-api.coingecko.com/api/v3/nfts/list
```

You can use the `asset_platform_id` parameter to filter the NFTs based on the specific asset platform. Additionally, you can use other parameters like `per_page` to specify the number of results per page and `page` to paginate through the results.

### Example Request

Here’s an example of how you might structure your request to filter NFTs by asset platform ID:

```http
GET https://pro-api.coingecko.com/api/v3/nfts/list?asset_platform_id=your_platform_id&per_page=10&page=1
```

Replace `your_platform_id` with the actual asset platform ID you want to filter by. This will return a list of NFTs that belong to the specified asset platform.

ivatives/exchanges/list \
3
     --header 'accept: application/json'

Try It!
RESPONSE
1
[
2
  {
3
    "id": "binance_futures",
4
    "name": "Binance (Futures)"
5
  },
6
  {
7
    "id": "bybit",
8
    "name": "Bybit (Futures)"
9
  },
10
  {
11
    "id": "deepcoin_derivatives",
12
    "name": "Deepcoin (Derivatives)"
13
  }
14
]

NFTs List (ID Map)
get
https://pro-api.coingecko.com/api/v3/nfts/list
This endpoint allows you to query all supported NFTs with id, contract address, name, asset platform id and symbol on CoinGecko.

👍
Tips

You may use this endpoint to query the list of nfts for other endpoints that contain params like id (nft collection’s id) as well as asset_platform_id and contract_address
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

The responses are paginated to 100 items
Cache / Update Frequency: every 5 minutes for all the API plans
Query Params
order
string
use this to sort the order of responses

per_page
number
total results per page
Valid values: 1...250

page
number
page through results

Response

200
List all NFTs categories

Response body
object
id
string
nft collection id

contract_address
string
nft collection contract address

name
string
nft collection name

asset_platform_id
string
nft collection asset platform id

symbol
string
nft collection symbol

Updated 11 months ago

Derivatives Exchanges List (ID Ma


[User] What file path is shown for the keypair in the Solana CLI config?

[Assistant]
The file path shown for the keypair in the Solana CLI config is:

```
/Users/test/.config/solana/id.json
```

rust/lib'

Try these solutions:

Force install using the following command:
cargo build-sbf --force-tools-install

If the above doesn't work, clear the Solana cache:
rm -rf ~/.cache/solana/*

lock file version 4 requires `-Znext-lockfile-bump
You can fix this by changing the version field of Cargo.lock file

version = 3

See this issue for more information.

After applying either solution, attempt to run anchor build again.

If you are on Linux or WSL and encounter the following errors when running anchor test after creating a new Anchor project, it's may be due to missing Node.js or Yarn:

Permission denied (os error 13)

No such file or directory (os error 2)

Solana CLI Basics #
This section will walk through some common Solana CLI commands to get you started.

Solana Config #
To see your current config:

solana config get

You should see output similar to the following:

Config File: /Users/test/.config/solana/cli/config.yml
RPC URL: https://api.mainnet-beta.solana.com
WebSocket URL: wss://api.mainnet-beta.solana.com/ (computed)
Keypair Path: /Users/test/.config/solana/id.json
Commitment: confirmed

The RPC URL and Websocket URL specify the Solana cluster the CLI will make requests to. By default this will be mainnet-beta.

You can update the Solana CLI cluster using the following commands:

solana config set --url mainnet-beta
solana config set --url devnet
solana config set --url localhost
solana config set --url testnet

You can also use the following short options:

s


[User] How can I connect to the testnet Cluster using the Solana CLI?

[Assistant]
To connect to the testnet Cluster using the Solana CLI, you can use the following command:

```bash
solana config set --url https://api.testnet.solana.com
```

This command sets the URL for the Solana CLI to point to the testnet, allowing you to interact with the testnet environment.

 #
To connect to the testnet Cluster using the Solana CLI:

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

Testnet rate limits #
Maximum number of requests per 10 seconds per IP: 100
Maximum number of requests per 10 seconds per IP for a single RPC: 40
Maximum concurrent connections per IP: 40
Maximum connection rate per 10 seconds per IP: 40
Maximum amount of data per 30 second: 100 MB
Mainnet beta #
A permissionless, persistent cluster for Solana users, builders, validators and token holders.

Tokens that are issued on Mainnet Beta are real SOL
Gossip entrypoint for Mainnet Beta: entrypoint.mainnet-beta.solana.com:8001
Mainnet beta endpoint #
https://api.mainnet-beta.solana.com - Solana Labs hosted API node cluster, backed by a load balancer; rate-limited
Example solana command-line configuration #
To connect to the mainnet-beta Cluster using the Solana CLI:

solana config set --url https://api.mainnet-beta.solana.com

Mainnet beta rate limits #
Maximum number of requests per 10 seconds per IP: 100
Maximum number of requests per 10 seconds per IP for a single RPC: 40
Maximum concurrent connections per IP: 40
Maximum connection rate per 10 seconds per IP: 40
Maximum amount of data per 30 seconds: 100 MB
Info
The public RPC endpoints are not intended for production applications. Please use dedicated/private RPC servers when you launch your application, drop NFTs, etc. The public services are subject to abuse and rate limits may change without prior notice. Likewise,


[User] How do you specify the cluster to be used when deploying a program in Solana?

[Assistant]
To specify the cluster to be used when deploying a program in Solana with Anchor, you need to modify the `Anchor.toml` configuration file. By default, the cluster is set to `Localnet`. To change it to another cluster, such as `Devnet` or `Mainnet`, you need to update the `cluster` value under the `[provider]` section.

Here’s how you can do it:

1. Open your `Anchor.toml` file.
2. Locate the `[provider]` section.
3. Change the `cluster` value to your desired cluster.

For example, to change the cluster to `Devnet`, you would modify the file as follows:

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

If you want to deploy to `Mainnet`, you would update it similarly:

```toml
[provider]
cluster = "Mainnet"
wallet = "~/.config/solana/id.json"
```

After making this change, when you run the `anchor deploy` command, your program will be deployed to the specified cluster.

ul if you want to keep the validator running while you iterate on your program. It allows you to inspect accounts and transaction logs on the Solana Explorer while developing locally.

Open a new terminal and start a local Solana validator by running the solana-test-validator command.

Terminal
solana-test-validator

In a separate terminal, run the tests against the local cluster. Use the --skip-local-validator flag to skip starting the local validator since it's already running.

Terminal
anchor test --skip-local-validator

Deploy to Devnet #
By default, the Anchor.toml config file in an Anchor project specifies the localnet cluster.

Anchor.toml
[toolchain]

[features]
resolution = true
skip-lint = false

[programs.localnet]
my_program = "3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg"

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

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

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

To deploy your program to devnet, change the cluster value to Devnet. Note that this requires your wallet to have enough SOL on Devnet to cover deployment cost.

-cluster = "Localnet"
+cluster = "Devnet"

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

Now when you run anchor deploy, your program will be deployed to the devnet cluster. The anchor test command will also use the cluster specified in the Anchor.toml file.

anchor deploy

To deploy to mainnet, simply update


[User] What information can you find on the WebSocket Limits as mentioned in the QuickNode documentation?

[Assistant] The QuickNode documentation mentions that WebSocket limits are in place for the usage of WebSocket connections. However, the specific details regarding these limits, such as the maximum number of connections allowed or any rate limits, are not provided in the snippet. For comprehensive information about WebSocket limits, you would need to refer to the specific section of the QuickNode documentation that addresses WebSocket usage and limitations.

s dependencies like so:

pip install solana cachetools

Rust (HTTP)
Rust is a systems programming language designed for performance, memory safety, and concurrency. It provides a modern alternative to languages like C and C++. To install Rust on your system, you can visit the official Rust website for installation instructions.

Once Rust is installed, configure your project's dependencies by updating the Cargo.toml file with the following:

[dependencies]
reqwest = "0.11"
serde_json = "1.0"
tokio = { version = "1", features = ["full"] }

To execute your Rust code, use the command:

cargo run

JsonRpcClient
Generate JSON-RPC requests and parse responses in Python. Install it using the following command:

pip install jsonrpcclient

Requests
Requests is an elegant and simple HTTP library for Python, built for human beings. Install it using the following command:

python -m pip install requests

Axios
Axios is a promise-based HTTP Client for node.js and the browser. On the server-side it uses the native node.js http module, while on the client (browser) it uses XMLHttpRequests. Install it using the following command:

npm install axios

WebSocket cat (wscat)
WebSocket cat (wscat) is a simple tool for connecting to WebSocket APIs in your terminal. Install it using the following command:

npm install -g wscat

API Credits
Usage in our pricing plans is measured in API Credits. To learn more about the API Credits for Solana, please visit this page.

WebSocket Limits
WebSocket respon


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

[Assistant]
The `signatureSubscribe` method in Solana is used to subscribe to notifications regarding the status of a specific transaction signature. This allows clients to receive updates when the signature is either received by the RPC (Remote Procedure Call) or when the transaction associated with that signature has been processed.

### Key Features:
- **Subscription to Signature Status**: It allows you to track the status of a transaction by its signature.
- **Commitment Level**: You can specify the commitment level (e.g., "finalized") to determine when you want to be notified about the transaction's status.
- **Received Notification**: There is an option to enable notifications when the signature is received, in addition to when it is processed.

### Example Usage:
Here’s a code sample demonstrating how to use the `signatureSubscribe` method:

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

### Response:
Upon successfully subscribing, you will receive a response with a subscription ID:

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

### Notification Format:
When a notification occurs, it will be formatted as follows:

```json
{
  "jsonrpc": "2.0",
  "method": "signatureNotification",
  "params": {
    "slot": <u64>,
    "value": {
      "err": <object|null>
    }
  }
}
```

- The `slot` indicates the corresponding slot for the transaction.
- The `value` contains either a notification that the signature was received or the result of the transaction processing, indicating success or failure.

This method is essential for applications that need to monitor the status of transactions in real-time on the Solana blockchain.

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": {