[User] What steps should I take if my trade request on Jupiter was not executed successfully?

[Assistant]
If your trade request on Jupiter was not executed successfully, you should follow these steps:

1. **Wait for 45 Seconds**: If your trade request has not been executed within 45 seconds, it will be considered stale and will be rejected.

2. **Check for Token Return**: If your trade request is rejected, any tokens you deposited for the trade will be returned to you. This includes tokens deposited for collateral withdrawals or close position requests.

3. **Open a Support Ticket**: If your trade request was not executed or if you encounter any issues creating trade requests, you should open a support ticket on the Jupiter Discord support channel for assistance.

By following these steps, you can ensure that you address the issue with your trade request effectively.

s listed above and execute them by verifying the requests and submitting transactions that contain the actual program instructions for the trade request.

Frequently Asked Questions
Is the keeper code open-source?
The keeper code is not open-source. However, our keepers are audited and are tested extensively before they're deployed.

I submitted a trade request but my trade was not executed
Keepers may fail to execute requests due to a variety of reasons (network congestion, keeper downtime, etc.)

A trade request that has not been executed after 45 seconds is considered stale and will be rejected. Tokens deposited by the trader for the trade request will be returned to the trader. Tokens will be returned to the position for collateral withdrawals or close position requests.

info
Please open a support ticket on the Jupiter Discord support channel if your trade request was not executed or if you face any issues creating trade requests.

Can I host my own keeper?
We do not allow community members to run their own keepers at the moment. As mentioned above, our keepers are audited and tested extensively so they're able to execute trade requests reliably.

Where do I see the keeper accounts?
We currently run two keepers:

https://solscan.io/account/A2rCQdCqQB4wu72x9Q7iq1QugtdZmcyWsiSPfgfZzu2u
https://solscan.io/account/DFZcDnmEYNUK1khquZzx5dQYiEyjJ3N5STqaDVLZ88ZU

Frequently Asked Questions
1. I tried opening a position/adding collateral and it was not successful. Where are my f


[User] What is the significance of the 'confirmed' commitment level when establishing a connection to the Solana blockchain?

[Assistant]
The 'confirmed' commitment level in Solana is significant because it determines the level of assurance you have regarding the finality of the transactions you are observing or interacting with on the blockchain. When you establish a connection to the Solana blockchain with the 'confirmed' commitment level, you are indicating that you want to receive information about transactions that have been confirmed by the network.

In practical terms, this means that:

1. **Transaction Finality**: You will only receive updates about transactions that have been confirmed by the majority of validators in the network. This reduces the likelihood of working with stale or unconfirmed data.

2. **Reliability**: Using 'confirmed' ensures that the data you are working with is more reliable for applications that require a certain level of certainty, such as financial transactions or state changes in decentralized applications.

3. **Performance**: While 'confirmed' provides a balance between speed and reliability, it is generally faster than higher commitment levels like 'finalized', which require that a block is fully finalized and cannot be reverted.

Here is an example of how to establish a connection with the 'confirmed' commitment level:

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

// Establishing a connection with 'confirmed' commitment level
let connection = new web3.Connection(web3.clusterApiUrl("devnet"), "confirmed");
```

In this example, the connection to the Solana devnet is made with the 'confirmed' commitment level, ensuring that the application will only interact with confirmed transactions.

ot);
// 93186439

let blockTime = await connection.getBlockTime(slot);
console.log(blockTime);
// 1630747045

let block = await connection.getBlock(slot);
console.log(block);

/*
{
    blockHeight: null,
    blockTime: 1630747045,
    blockhash: 'AsFv1aV5DGip9YJHHqVjrGg6EKk55xuyxn2HeiN9xQyn',
    parentSlot: 93186438,
    previousBlockhash: '11111111111111111111111111111111',
    rewards: [],
    transactions: []
}
*/

let slotLeader = await connection.getSlotLeader();
console.log(slotLeader);
//49AqLYbpJYc2DrzGUAH1fhWJy62yxBxpLEkfJwjKy2jr

The above example shows only a few of the methods on Connection. Please see the source generated docs for the full list.

Transaction #
Source Documentation

A transaction is used to interact with programs on the Solana blockchain. These transactions are constructed with TransactionInstructions, containing all the accounts possible to interact with, as well as any needed data or program addresses. Each TransactionInstruction consists of keys, data, and a programId. You can do multiple instructions in a single transaction, interacting with multiple programs at once.

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

// Airdrop SOL for paying transactions
let payer = web3.Keypair.generate();
let connection = new web3.Connection(web3.clusterApiUrl("devnet"), "confirmed");

let airdropSignature = await connection.requestAirdrop(
  payer.publicKey,
  web3.LAMPORTS_PER_SOL,
);

await connection.c


[User] What is the expected format of the JSON-RPC request for the getVersion method in Tatum?

[Assistant]
The expected format of the JSON-RPC request for the `getVersion` method in Tatum is as follows:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getVersion"
}
```

In this request:
- `"jsonrpc"` specifies the version of the JSON-RPC protocol being used.
- `"id"` is a unique identifier for the request, which can be any integer.
- `"method"` indicates the name of the method being called, which in this case is `"getVersion"`.

,
  "result": 1574721591,
  "id": 1
}
Updated about 2 months ago

getfeeformessage
getversion
Did this page help you?
Table of Contents
How to Use It
Overview
Parameters
Return Object
JSON-RPC Request Example
JSON-RPC Response Example

getversion
Solana RPC

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

How to Use It
JavaScript

// yarn add @tatumio/tatum

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

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

const res = await tatum.rpc.getVersion()

await tatum.destroy() // Destroy Tatum SDK - needed for stopping background jobs
Overview
The getVersion method is used to retrieve the current Solana version running on the node. This information can be useful for troubleshooting, compatibility checks, or for understanding the node's capabilities based on its version.

Parameters
This method does not require any parameters.

Return Object
The result field will be a JSON object with the following fields:

solana-core: The software version of solana-core.
feature-set: The unique identifier of the current software's feature set.
JSON-RPC Request Example
JSON

jsonCopy code{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getVersion"
}
JSON-RPC Response Example
JSON

jsonCopy code{
  "jsonrpc": "2.0",
  "result": {
    "solana-core": "1.15.0"
  },
  "id": 1
}

getstakeactivation
Solana RPC

Archive Method
Only on the full archive nodes. Complex


[User] How can users ensure they are downloading wallet software from official sites on Jupiter?

[Assistant]
To ensure users are downloading wallet software from official sites on Jupiter, they should follow these best practices:

1. **Verify URLs**: Always double-check that the URL of the wallet software's website is correct. This helps avoid phishing sites that may look similar to legitimate ones.

2. **Use Official Sources**: Download wallet software only from official websites. Users can often find links to official wallets on reputable platforms or community resources related to Jupiter.

3. **Avoid Fake Sites**: Be cautious of typo-squatting, where attackers create fraudulent sites with URLs that are similar to legitimate ones. Learning to recognize the structure of URLs can help users avoid these scams.

By adhering to these practices, users can significantly reduce the risk of downloading malicious software.

and/or scan your file system.
Avoid installing any fake/pirated software as these often contain malware.
Install all wallet software from official sites only, double-check they are the correct URL before downloading as there are many fake wallet sites.
2 - Transaction Security
The second aspect of personal on-chain security is transaction security. This is different from private key security in that attackers do not need to get hold of your private key in order to steal your funds from you. All they need to do is to trick you to sign a transaction that does a malicious transfer of assets.

The good news is that preventing this type of attacks is easy and 100% within your control as long as you incorporate a few good practices to your journey on Solana.

Transaction Simulation
Transaction simulation by modern Solana wallets are extremely powerful tools to help safeguard you from loss of funds.

Example of a transaction simulation working

Always pay attention to what is written and if a transaction simulation fails or is reverted, as a general rule, do NOT sign the transaction. You really only want to break this rule if you are a thousand percent certain that the site you are on is a legitimate site and that there is a very good reason that you are aware of as to why the transaction is failing to simulate.

Understanding URL Structure
Learning to recognise the structure of URLs is very important so that you can avoid fraudulent sites. This practice is called typo-squatting and


[User] What benefits does Magic Eden provide by making their API available free of charge?

[Assistant]
Magic Eden provides several benefits by making their API available free of charge:

1. **Empowerment of Developers**: The API allows developers to create innovative experiences using NFTs and access marketplace data. This fosters creativity and encourages the development of new applications.

2. **Access to Comprehensive Data**: Developers can access NFT metadata and crucial components of the marketplace, such as events, collections, listings, and bids. This extensive data availability can enhance the functionality and features of applications built on top of the API.

3. **Facilitation of Composability and Openness**: By offering the API for free, Magic Eden promotes composability and openness in the web3 space. This means that developers can build upon existing data and services, leading to a more interconnected ecosystem.

4. **Encouragement of Community Engagement**: Free access to the API can lead to increased community involvement, as developers are more likely to experiment and build projects without the barrier of cost.

5. **Support for Innovation**: The ability to freely access and utilize the API can lead to innovative applications and success stories, as developers can focus on building rather than worrying about costs.

6. **Adherence to Terms of Service**: By providing the API for free, Magic Eden encourages developers to use the data responsibly and in accordance with their Terms of Service, fostering a healthy ecosystem.

Overall, the free availability of the API helps to stimulate growth, innovation, and collaboration within the web3 community.

Welcome to our Development Environment
API Capabilities: Fetch data for NFTs, Runes, Collection, Wallets and more. Generate and execute trading endpoints to interact directly with the Magic Eden marketplace

Project Showcase: Be inspired by our curated selection of example projects built using our API. Explore the innovative applications and success stories of developers like you. See the top projects from our NYC Hacker House Hackathon.

Upcoming Works: We are dedicated to improving your experience. Look forward to a smoother onboarding process and the release of our SDK for seamless API integration.

Happy building!

The Magic Eden Team

Solana API Overview
The Magic Eden Solana API is designed to empower developers in creating innovative experiences using NFTs and our abundant marketplace data. We offer a robust suite of endpoints that allows you to access NFT metadata along with crucial components of our marketplace, including events, collections, listings, bids, and more. With our API, you can not only access the data but also perform various actions that you would on our user interface, such as listing NFTs, buying NFTs, placing bids, and more.

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 y


[User] How does Helius define the priority fee estimate in the v2 algorithm?

[Assistant]
In Helius, the priority fee estimate in the v2 algorithm is defined using the following formula:

```plaintext
priority_estimate(p: Percentile, accounts: Accounts) =
    max(
        percentile(txn_fees, p),
        percentile(writable_account_fees(account1), p),
        percentile(writable_account_fees(account2), p),
        ...,
        percentile(writable_account_fees(accountN), p)
    )
```

This algorithm calculates the maximum priority fee estimate by considering the transaction fees at a specified percentile (`p`) and the writable account fees for each relevant account. Instead of calculating a single percentile for all accounts, v2 evaluates the percentile for each account separately, ensuring a more accurate estimate that reflects the maximum priority fee across all accounts involved in the transaction.

{
            "min": 0.0,
            "low": 2.0,
            "medium": 10082.0,
            "high": 100000.0,
            "veryHigh": 1000000.0,
            "unsafeMax": 50000000.0
        }
    },
    "id": "1"
}
Payload

Copy
{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "getPriorityFeeEstimate",
    "params": [{
        "accountKeys": ["2CiBfRKcERi2GgYn83UaGo1wFaYHHrXGGfnDaa2hxdEA"],
        "options": {
            "priorityLevel": "High"
        }
    }]
}
Response

Copy
{
    "jsonrpc": "2.0",
    "result": {
        "priorityFeeEstimate": 120000.0
    },
    "id": "1"
}
Version 2 (v2)
The v2 logic aligns more closely with the Agave scheduler's approach to prioritizing transactions. This updated algorithm is now the default for the current API.

Updated Algorithm
The new algorithm for priority_estimate is defined as:

Copy
priority_estimate(p: Percentile, accounts: Accounts) =
    max(
        percentile(txn_fees, p),
        percentile(writable_account_fees(account1), p),
        percentile(writable_account_fees(account2), p),
        ...,
        percentile(writable_account_fees(accountN), p)
    )
This approach ensures the fee estimate considers the maximum priority fee across all relevant accounts and transaction fees at the given percentile.

Key Differences from v1
Individual Account Consideration: Instead of calculating a single percentile for all accounts involved (account_fees(accounts)), v2 calculates the percentile for each account sep


[User] How does Bitquery handle the ordering of token supply updates in its queries?

[Assistant]
Bitquery handles the ordering of token supply updates in its queries by using the `orderBy` parameter. This parameter allows users to specify how the results should be ordered based on certain fields. For instance, you can order the token supply updates by the `Block_Time` in descending order to get the most recent updates first.

Here’s an example of how to use the `orderBy` parameter in a query to get the latest token supply updates:

```graphql
{
  Solana {
    TokenSupplyUpdates(
      limit: {count: 1}
      orderBy: {descending: Block_Time}
      where: {TokenSupplyUpdate: {Currency: {MintAddress: {is: "6D7NaB2xsLd7cauWu1wKk6KBsJohJmP2qZH9GEfVi5Ui"}}}}
    ) {
      TokenSupplyUpdate {
        Amount
        Currency {
          MintAddress
          Name
        }
        PreBalance
        PostBalance
      }
    }
  }
}
```

In this example, the query retrieves the latest token supply update for a specific token by ordering the results based on the `Block_Time` in descending order, ensuring that the most recent supply update is returned.

    }
  }
}

Get Supply of specific Token
This query will return the latest token supply of a specific token. We are getting here supply for this 6D7NaB2xsLd7cauWu1wKk6KBsJohJmP2qZH9GEfVi5Ui token PostBalance will give you the current supply for this token. Check the query here

{
  Solana {
    TokenSupplyUpdates(
      limit:{count:1}
      orderBy:{descending:Block_Time}
      where: {TokenSupplyUpdate: {Currency: {MintAddress: {is: "6D7NaB2xsLd7cauWu1wKk6KBsJohJmP2qZH9GEfVi5Ui"}}}}
    ) {
      TokenSupplyUpdate {
        Amount
        Currency {
          MintAddress
          Name
        }
        PreBalance
        PostBalance
      }
    }
  }
}

Get newly created Pump Fun tokens and their Metadata
Now you can track the newly created Pump Fun Tokens along with their dev address, metadata and supply. PostBalance will give you the current supply for the token. Check the query here

subscription {
  Solana {
    TokenSupplyUpdates(
      where: {Instruction: {Program: {Address: {is: "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"}, Method: {is: "create"}}}}
    ) {
      Block{
        Time
      }
      Transaction{
        Signer
      }
      TokenSupplyUpdate {
        Amount
        Currency {
          Symbol
          ProgramAddress
          PrimarySaleHappened
          Native
          Name
          MintAddress
          MetadataAddress
          Key
          IsMutable
          Fungible
          EditionNonce
          Decimals
          Wrapped


[User] How can the Rust Pack trait assist in working with instruction data in Solana programs?

[Assistant]
The Rust Pack trait can assist in working with instruction data in Solana programs by providing a way to serialize and deserialize data structures that represent instructions. This is particularly useful when dealing with the `InvalidInstructionData` error, which can occur if the structure passed in does not match exactly what the program expects.

When implementing the Rust Pack trait, you can ensure that your instruction types are correctly packed and unpacked, which helps in determining the exact encoding that the program expects. This can help avoid issues related to padding between fields or mismatched data structures.

Here’s a simple example of how you might implement the Pack trait for an instruction type:

```rust
use borsh::{BorshDeserialize, BorshSerialize};

#[derive(BorshSerialize, BorshDeserialize)]
pub struct MyInstruction {
    pub field_one: u32,
    pub field_two: String,
}

// Function to create an instruction
fn create_my_instruction(field_one: u32, field_two: String) -> MyInstruction {
    MyInstruction { field_one, field_two }
}

// Example of serializing the instruction
let instruction = create_my_instruction(42, "example".to_string());
let serialized_instruction = instruction.try_to_vec().unwrap();
```

In this example, the `MyInstruction` struct implements the `BorshSerialize` and `BorshDeserialize` traits, allowing it to be easily converted to and from a byte array. This ensures that when you send the instruction to the Solana program, it is in the correct format, reducing the likelihood of encountering the `InvalidInstructionData` error.

ry map #
The virtual address memory map used by Solana SBF programs is fixed and laid out as follows

Program code starts at 0x100000000
Stack data starts at 0x200000000
Heap data starts at 0x300000000
Program input parameters start at 0x400000000
The above virtual addresses are start addresses but programs are given access to a subset of the memory map. The program will panic if it attempts to read or write to a virtual address that it was not granted access to, and an AccessViolation error will be returned that contains the address and size of the attempted violation.

InvalidAccountData #
This program error can happen for a lot of reasons. Usually, it's caused by passing an account to the program that the program is not expecting, either in the wrong position in the instruction or an account not compatible with the instruction being executed.

An implementation of a program might also cause this error when performing a cross-program instruction and forgetting to provide the account for the program that you are calling.

InvalidInstructionData #
This program error can occur while trying to deserialize the instruction, check that the structure passed in matches exactly the instruction. There may be some padding between fields. If the program implements the Rust Pack trait then try 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 ret


[User] In the provided example, how is the transfer instruction added to a transaction in Solana?

[Assistant]
In the provided example, the transfer instruction is added to a transaction in Solana using the following steps:

1. **Create a Transfer Instruction**: The transfer instruction is created using the `SystemProgram.transfer` method, which specifies the sender's public key, the recipient's public key, and the amount to transfer (in lamports).

   ```javascript
   const transferInstruction = SystemProgram.transfer({
     fromPubkey: sender.publicKey,
     toPubkey: receiver.publicKey,
     lamports: transferAmount * LAMPORTS_PER_SOL, // Convert transferAmount to lamports
   });
   ```

2. **Create a Transaction**: A new transaction object is instantiated.

   ```javascript
   const transaction = new Transaction();
   ```

3. **Add the Transfer Instruction to the Transaction**: The transfer instruction created earlier is added to the transaction using the `add` method.

   ```javascript
   transaction.add(transferInstruction);
   ```

By following these steps, the transfer instruction is successfully incorporated into the transaction, which can then be signed and sent to the Solana network for processing.

m.

SOL Transfer
SOL Transfer

The sender account must be included as a signer (is_signer) on the transaction to approve the deduction of their lamport balance. Both the sender and recipient accounts must be mutable (is_writable) because the instruction modifies the lamport balance for both accounts.

Once the transaction is sent, the System Program is invoked to process the transfer instruction. The System Program then updates the lamport balances of both the sender and recipient accounts accordingly.

SOL Transfer Process
SOL Transfer Process

Simple SOL Transfer #
Here is a Solana Playground example of how to build a SOL transfer instruction using the SystemProgram.transfer method:

// Define the amount to transfer
const transferAmount = 0.01; // 0.01 SOL

// Create a transfer instruction for transferring SOL from wallet_1 to wallet_2
const transferInstruction = SystemProgram.transfer({
  fromPubkey: sender.publicKey,
  toPubkey: receiver.publicKey,
  lamports: transferAmount * LAMPORTS_PER_SOL, // Convert transferAmount to lamports
});

// Add the transfer instruction to a new transaction
const transaction = new Transaction().add(transferInstruction);

Run the script and inspect the transaction details logged to the console. In the sections below, we'll walk through the details of what's happening under the hood.

Transaction #
A Solana transaction consists of:

Signatures: An array of signatures included on the transaction.
Message: List of instructions to be processed


[User] What features can be extended when setting up a dedicated node in the Helius dashboard?

[Assistant] When setting up a dedicated node in the Helius dashboard, you can extend functionality with advanced Geyser plugins and Archival access. These features enhance the capabilities of your dedicated node, making it suitable for more complex use cases and providing additional data access options.

aged directly in the dashboard.

Configure RPC Access Control Rules in the Endpoints section of your dashboard.
Shared RPC Node Locations
Helius provides services through a globally distributed set of nodes strategically positioned in key locations: New York, Ashburn, Chicago, Vancouver, Los Angeles, Singapore, Tokyo, Frankfurt, and the UK. Helius automatically directs user requests to the closest node, guaranteeing the quickest and most efficient routing.

Dedicated Nodes
We offer dedicated private RPC nodes at industry-leading rates. These nodes are ideal for teams seeking an isolated environment with predictable performance and billing.

Extend functionality with advanced Geyser plugin and Archival access. Visit the Helius Dashboard to effortlessly set up your dedicated node!

If you need a dedicated fleet of nodes, contact our sales team. We will take your requirements, provision your nodes, and set up a custom fleet for you team.

Solana RPC Nodes
🏆
Dedicated Nodes
Private Dedicated Nodes optimized for low latency and high performance

Get a Dedicated Node in a specific region with no rate limits or credit limits.

Ideal for latency-sensitive use cases like trading, bots, sniping, and more or for teams that want an isolated environment with predictable performance and billing. Get a single node in a specific region to optimize server-to-server communication or set up a cluster of nodes with distributed geographic coverage. Extend functionality with advanced Geyser plu


[User] How does Raydium compare to Ethereum in terms of transaction speed and cost?

[Assistant]
Raydium is designed to address some of the limitations present in Ethereum, particularly in terms of transaction speed and cost.

1. **Transaction Speed**: Raydium operates on the Solana blockchain, which is known for its high throughput and fast transaction speeds. This allows Raydium to facilitate transactions much quicker than Ethereum, especially during times of high network congestion.

2. **Transaction Cost**: The cost of transactions on Raydium is significantly lower compared to Ethereum. Ethereum has experienced high gas fees that can wipe out potential earnings for users, particularly during peak times. In contrast, Raydium aims to provide a more cost-effective solution for users engaging in DeFi activities.

In summary, Raydium offers faster transaction speeds and lower costs compared to Ethereum, making it a more accessible option for users looking to engage in decentralized finance without the drawbacks of high fees and slow processing times.

Raytor launch on Raydium!

Protocol
🧬
The Raydium Protocol
View this article as originally published on Medium

An on-chain order book AMM powering the evolution of DeFi

In less than a year, Decentralized Finance (DeFi) has grown from a buzz word to an entire ecosystem that is setting new standards for personal financial autonomy and trust. DeFi embodies everything that decentralization and cryptocurrency is about. It allows everyone to access tools that have traditionally been the domain of large banks, corporations, venture funds and trading firms, without sacrificing autonomy.

Ethereum brought decentralized trading, lending, and yield earning to anyone with an internet connection. Furthermore, it did that while ensuring transparency, interoperability, and immutability through the blockchain. However, the current state of DeFi is far from perfect.

Legacy Blockchains are not Ready for DeFi
While DeFi holds enormous opportunity, it is very much limited by outdated blockchains.

💸 DeFi transactions are expensive
In a short time, we have seen gas fees jump to a level that completely wipes out potential earnings. Slow transactions exacerbate this as users bid up the price of gas, with failed transactions multiplying losses. As interacting with DeFi becomes prohibitively expensive, we are once again seeing common users left behind.

🧩 Market fragmentation
The nature of automated market makers (AMMs) on Ethereum means that liquidity is fragmented, and liquidity pools on one pro


[User] What are the steps involved in bridging assets using Jupiter?

[Assistant]
To bridge assets using Jupiter, you can follow these steps based on the basic bridging user flow:

1. **Start on the Bridge Application**: Navigate to the bridge application you intend to use for bridging assets.

2. **Connect Your Source Wallet**: Connect the wallet that will be funding the bridging transaction. This wallet is on the source chain.

3. **Select Source Token and Amount**: Choose the source token you want to bridge and input the amount you wish to use in the bridging transaction.

4. **Connect Your Destination Wallet**: Connect the wallet that will receive the funds from the bridging transaction. This wallet is on the destination chain.

5. **Select Destination Token**: Choose the token that you would like to bridge into on the destination chain.

6. **Review Transaction Preview**: Look over the transaction preview to understand the total fees that the transaction will require.

7. **Approve the Bridge Transactions**: Finally, approve the bridge transactions to complete the process.

These steps will guide you through the bridging process, ensuring that you successfully transfer assets across different blockchains.

 IOU can be redeemed at any time for the gold, a liquid staking token (LST) can be redeemed at any time for unstaked SOL. Unlike natively-staked SOL, this liquid staking token is transferable. It can be used in all of DeFi – borrow-lend, perps, stablecoin issuance, etc.

Bridging to Solana
The current cryptosphere is made up of numerous blockchains which can act as silos for assets and liquidity. With that in mind, cross-chain mobility for crypto assets is a highly desirable solution in this realm. To solve this issue, bridges were invented. Bridges are applications configured to manage asset custody and enable cross-chain asset swapping.

info
Most bridge applications work in the same way. They require connecting multiple wallets (source & destination chains), selecting the input / output tokens, and the input amount. They will also require at least 2 transactions confirming on both the source and destination chains.

Basic Bridging User Flow
Start on the bridge application you intend to use.
Next, connect your source wallet that will be funding the bridging transaction.
Select the source token and input the amount that you want to use in the bridging transaction.
Connect the destination wallet that will be receiving the funds from the bridging transaction.
Select the token that you would like to bridge into on the destination chain.
Review the transaction preview to understand the total fees that the transaction will require.
Approve the bridge transactions. There will be t


[User] Does Bitquery provide any information about the 'MarketAddress' for trades, and what is its relevance?

[Assistant]
Yes, Bitquery provides information about the 'MarketAddress' for trades in the Solana DEX Trades API. The 'MarketAddress' is included in the subscription query for recent trades executed on Solana's DEX platforms.

The relevance of the 'MarketAddress' lies in its ability to identify the specific market where the trade occurred. This address can be used to track trading activity, analyze market behavior, and integrate market-specific data into applications. By knowing the 'MarketAddress', developers and analysts can correlate trades with particular markets, which is essential for understanding liquidity, price movements, and overall market dynamics.

Here is a snippet of the relevant part of the subscription query that includes 'MarketAddress':

```graphql
subscription {
  Solana {
    DEXTrades {
      Trade {
        Market {
          MarketAddress
        }
        ...
      }
    }
  }
}
```

In this query, 'MarketAddress' is part of the 'Trade' object, allowing users to access the address associated with each trade's market.

me
          Key
          IsMutable
          Symbol
        }
      }
      sum(of: BalanceUpdate_AmountInUSD)
    }
  }
}

Solana DEX Trades API
In this section we will see how to get Solana DEX trades information using our API.

This Solana API is part of our Early Access Program (EAP), which is intended for evaluation purposes. This program allows you to test the data and its integration into your applications before full-scale implementation. Read more here.

Subscribe to Latest Solana Trades
This subscription will return information about the most recent trades executed on Solana's DEX platforms. You can find the query here

subscription {
  Solana {
    DEXTrades {
      Trade {
        Dex {
          ProgramAddress
          ProtocolFamily
          ProtocolName
        }
        Buy {
          Amount
          Account {
            Address
          }
          Currency {
            MetadataAddress
            Key
            IsMutable
            EditionNonce
            Decimals
            CollectionAddress
            Fungible
            Symbol
            Native
            Name
          }
          Order {
            LimitPrice
            LimitAmount
            OrderId
          }
          Price
        }
        Market {
          MarketAddress
        }
        Sell {
          Account {
            Address
          }
          Currency {
            IsMutable
            Decimals
            CollectionAddress
            Fungible
            Sy


[User] What tab do you navigate to in Meteora to lock your LP token in the pool?

[Assistant] To lock your LP token in the pool on Meteora, you need to navigate to the "Burn" tab.

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 is the purpose of the Subscribe RPC Method in QuickNode?

[Assistant]
The Subscribe RPC Method in QuickNode is used to subscribe to a program in order to receive notifications when the lamports or data for a given account owned by the program changes. This allows developers to monitor specific accounts and react to changes in real-time, enhancing the interactivity and responsiveness of their applications.

Here are the key details regarding the method:

- **API Credit Value**: The API credit value for this method is 20.
- **Parameters**:
  - `program_id`: A string representing the Pubkey encoded base-58 string.
  - `object`: An array that includes configuration options such as:
    - `commitment`: Specifies the level of confirmation for the queried block (finalized, confirmed, or processed).
    - `encoding`: Defines the format for account data (options include base58, base64, base64+zstd, or jsonParsed).
    - `filters`: Allows for filtering results based on specified criteria.

This method is particularly useful for applications that need to respond to changes in blockchain state efficiently.

t in seconds and start building
Get started for free
Previous
logsSubscribe
Next
programSubscribe
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
programSubscribe RPC Method
(Subscription Websocket) Subscribe to a program to receive notifications when the lamports or data for a given account owned by the program changes. The API credit value for this method is 20.
Updated on
Oct 4, 2023
Parameters
program_id
string
The Pubkey encoded base-58 string
object
array
The configuration object with the following fields:
commitment
All fields are strings.
finalized
the node will query the most recent block confirmed by supermajority of the cluster as having reached maximum lockout, meaning the cluster has recognized this block as finalized.
confirmed
the node will query the most recent block that has been voted on by supermajority of the cluster.
processed
the node will query its most recent block. Note that the block may not be complete.
encoding
string
The encoding format for account data. It can be one of base58 (slow), base64, base64+zstd or jsonParsed
filters
string
The filter results using various filter objects; The account must meet all filter criteria to be included in results
Returns
result
integer
The result will be an RpcResponse JSON object


[User] What options does Jupiter provide for determining the vesting start date?

[Assistant] Jupiter allows you to select any future date and time for the vesting start date. This selection is based on your current timezone.

our connected wallet.
Search for the token you wish to lock via contract address or ticker.
Fill in the required details:
Lock Title. Name this lock e.g. Team Tokens.
Lock Amount. You can see the amount of token within your wallet.
Recipient Wallet Address. The tokens can be claimable by this wallet after the defined vesting period.
Vesting Start Date. You can select any future date and time. This is based on your current timezone.
Vesting Duration and intervals. Vesting Duration determines the entire vesting schedule from the Start Date.
(Optional) Cliff Period & intervals. Cliff refers to a time period that has to pass before the tokens start vesting.
Unlock Schedule. This determines how much tokens is being vested and unlocked within that regular time interval.
Who can cancel the contract and who can change the recipient. Choose None, Only Creator, Only Recipient or Either Creator or Recipient
(Optional) Add more locks for the same token but with different parameters by clicking Add Another Lock button.
Press Proceed to review the token lock contract. After confirming all the details, click Create Contract button.
Navigate to Jupiter Lock home page is to view the lock that you’ve created!
View Locks & Claim Tokens

Navigate to https://lock.jup.ag/. You will be able to see All Locks powered by Jupiter Lock.
Click Connect Wallet at the upper right corner to check Your Locked Tokens and Locks You Created.
Your Locked Tokens include tokens that others and yourself have locked


[User] How can users determine the account balances before and after a transaction in Solana?

[Assistant]
In Solana, users can determine the account balances before and after a transaction by examining the `preBalances` and `postBalances` fields in the transaction status metadata object returned when querying for a transaction.

Here’s how you can access these fields:

1. **preBalances**: This field is an array that contains the balances of the accounts before the transaction was processed.
2. **postBalances**: This field is an array that contains the balances of the accounts after the transaction was processed.

When you query a transaction, you can specify that you want the full transaction details, which will include these fields. Here’s an example of how you might retrieve this information using a hypothetical function to get the transaction details:

```javascript
async function getTransactionDetails(transactionSignature) {
    const connection = new solanaWeb3.Connection(solanaWeb3.clusterApiUrl('mainnet-beta'));
    const transactionDetails = await connection.getTransaction(transactionSignature, { commitment: 'confirmed', encoding: 'jsonParsed' });

    if (transactionDetails) {
        const preBalances = transactionDetails.meta.preBalances;
        const postBalances = transactionDetails.meta.postBalances;

        console.log("Balances before transaction:", preBalances);
        console.log("Balances after transaction:", postBalances);
    } else {
        console.log("Transaction not found or not confirmed.");
    }
}

// Example usage with a transaction signature
getTransactionDetails('YOUR_TRANSACTION_SIGNATURE_HERE');
```

In this example, replace `'YOUR_TRANSACTION_SIGNATURE_HERE'` with the actual transaction signature you want to query. The `preBalances` and `postBalances` will provide you with the necessary information regarding the account balances before and after the transaction.

ect> - if block is confirmed, an object with the following fields:
blockhash: <string> - the blockhash of this block, as base-58 encoded string
previousBlockhash: <string> - the blockhash of this block's parent, as base-58 encoded string; if the parent block is not available due to ledger cleanup, this field will return "11111111111111111111111111111111"
parentSlot: <u64> - the slot index of this block's parent
transactions: <array> - present if "full" transaction details are requested; an array of JSON objects containing:
transaction: <object|[string,encoding]> - Transaction object, either in JSON format or encoded binary data, depending on encoding parameter
meta: <object> - transaction status metadata object, containing null or:
err: <object|null> - Error if transaction failed, null if transaction succeeded. TransactionError definitions
fee: <u64> - fee this transaction was charged, as u64 integer
preBalances: <array> - array of u64 account balances from before the transaction was processed
postBalances: <array> - array of u64 account balances after the transaction was processed
innerInstructions: <array|null> - List of inner instructions or null if inner instruction recording was not enabled during this transaction
preTokenBalances: <array|undefined> - List of token balances from before the transaction was processed or omitted if token balance recording was not yet enabled during this transaction
postTokenBalances: <array|undefined> - List of token balances from after the


[User] How does Solana's single-threaded environment affect the use of std::fs and std::net?

[Assistant]
In Solana's single-threaded environment, on-chain programs face specific limitations that affect the use of certain Rust libraries, particularly `std::fs` and `std::net`.

1. **No Access to `std::fs`**: The `std::fs` library is used for file system operations, which are not applicable in the context of on-chain programs. Since these programs run on the blockchain, they do not have access to a traditional file system. This limitation ensures that the programs remain deterministic and do not rely on external state or file I/O, which could introduce variability in execution.

2. **No Access to `std::net`**: Similarly, the `std::net` library is used for networking operations. On-chain programs cannot perform network requests or communicate with external services directly. This restriction is in place to maintain the integrity and security of the blockchain environment, as allowing network access could lead to non-deterministic behavior and potential vulnerabilities.

Overall, these limitations are designed to ensure that on-chain programs are deterministic and can execute in a resource-constrained environment without relying on external factors that could affect their execution.

2616

Limitations
Developing programs on the Solana blockchain have some inherent limitation associated with them. Below is a list of common limitation that you may run into.

Rust libraries #
Since Rust based onchain programs must run be deterministic while running in a resource-constrained, single-threaded environment, they have some limitations on various libraries.

On-chain Rust programs support most of Rust's libstd, libcore, and liballoc, as well as many 3rd party crates.

There are some limitations since these programs run in a resource-constrained, single-threaded environment, as well as being deterministic:

No access to
rand
std::fs
std::net
std::future
std::process
std::sync
std::task
std::thread
std::time
Limited access to:
std::hash
std::os
Bincode is extremely computationally expensive in both cycles and call depth and should be avoided
String formatting should be avoided since it is also computationally expensive.
No support for println!, print!, use the msg! macro instead.
The runtime enforces a limit on the number of instructions a program can execute during the processing of one instruction. See computation budget for more information.
Compute budget #
To prevent abuse of the blockchain's computational resources, each transaction is allocated a compute budget. Exceeding this compute budget will result in the transaction failing.

See the computational constraints documentation for more specific details.

Call stack depth - CallDepthExceeded error #
Solana p


[User] What is the purpose of the 'rentEpoch' field in Tatum?

[Assistant] The 'rentEpoch' field in Tatum indicates the epoch at which the account will next owe rent. This is relevant for accounts that are subject to rent fees in the blockchain ecosystem, as it helps determine when the account holder needs to take action to maintain their account status and avoid potential issues related to account rent.

he account, either as encoded binary data or in JSON format {program: state}
rentEpoch: The epoch at which the account will next owe rent.
size: The data size of the account
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTokenAccountsByOwner",
  "params": [
    "GgPpTKg78vmzgDtP1DNn72CHAYjRdKY7AV6zgszoHCSa",
    {
      "mint": "1YDQ35V8g68FGvcT85haHwAXv1U7XMzuc4mZeEXfrjE"
    },
    { "encoding": "jsonParsed" }
  ]
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 1114
    },
    "value": [
      {
        "account": {
          "data": {
            "program": "spl-token",
            "parsed": {
              "accountType": "account",
              "info": {
                "tokenAmount": {
                  "amount": "1",
                  "decimals": 1,
                  "uiAmount": 0.1,
                  "uiAmountString": "0.1"
                },
                "delegate": "4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T",
                "delegatedAmount": {
                  "amount": "1",
                  "decimals": 1,
                  "uiAmount": 0.1,
                  "uiAmountString": "0.1"
                },
                "state": "initialized",
                "isNative": false,
                "mint": "3wyAj7Rt1TWVPZVteFJPLa26JmLvdb1CAKEFZm3NY75E",
                "owner": "4Qkev8aNZcqFNSRhQzwyLMFSsi94jHqE8WNVTJzTP99F"
              },
              "type": "account"


[User] How does the reinvestment of trading fees into the JLP pool affect its liquidity?

[Assistant]
The reinvestment of trading fees into the JLP pool significantly enhances its liquidity. According to the documentation, 75% of the fees generated from trading activities, token swaps, and JLP minting/burning are reinvested directly into the JLP pool. This continuous influx of capital increases the pool's liquidity and overall value for token holders.

For example, if trading activities generate 10 SOL in fees, 7.5 SOL would be added to the JLP pool. This reinvestment strategy not only boosts the pool's holdings but also compounds its growth over time, similar to how accumulating ETFs reinvest dividends. As a result, the JLP token's price and intrinsic value are steadily increased, providing a more robust and liquid market for JLP holders.

In summary, the reinvestment of trading fees into the JLP pool directly contributes to improved liquidity, benefiting all participants in the ecosystem.

rated from Jupiter Perpetuals trading, token swaps, and JLP minting/burning are reinvested directly into the JLP pool.

This mechanism continuously enhances the pool's liquidity and value for token holders. The remaining 25% is allocated to Jupiter as protocol fees, supporting ongoing development and maintenance.

For example, if trading activities generate 10 SOL in fees, 7.5 SOL would be added to the JLP pool, increasing its SOL holdings and AUM.

Fees generated by the pool are reinvested directly back into the JLP pool, mirroring how accumulating ETFs reinvest dividends. This reinvestment strategy compounds the pool's growth, steadily increasing the JLP token's price and intrinsic value.

Exposure
The intrinsic value of the JLP token is linked to the price movements of the liquidity pool's underlying tokens (SOL, ETH, BTC, USDC, and USDT).

As a JLP holder, your portfolio is exposed to market movements, particularly to the performance of the non-stablecoin tokens: SOL, ETH, and BTC. If these tokens decrease in price, the value of your JLP position will likely decrease as well.

That said, JLP holders earn yield from fees generated by trading activities. When traders incur losses, these are reinvested into the JLP pool, benefiting JLP holders. Conversely, when traders profit, it comes at the expense of the JLP pool.

The JLP usually outperforms its underlying assets during sideways or bearish market conditions since traders often struggle to be profitable in bear markets. H


[User] What does the 'result' object contain when a QuickNode transaction simulation is successful?

[Assistant]
When a QuickNode transaction simulation is successful, the `result` object contains the following fields:

- **context**: An object that includes metadata about the current state of the Solana network at the time the request was processed.
- **apiVersion**: A string representing the version number of the API.
- **slot**: An integer indicating the current slot in the Solana cluster during which the transactions are processed and new blocks are added to the blockchain.
- **err**: This will be `null` if the transaction succeeds.
- **logs**: An array of log messages that the transaction instructions output during execution. If the simulation failed before the transaction was able to execute (for instance, due to an invalid blockhash or signature verification failure), this will be `null`.
- **preExecutionAccounts**: A list of accounts that returns the pre-transaction execution state.

This structure provides comprehensive information about the simulation's outcome and the state of the network at the time of processing.

imulationBank
string
(Optional) The bank to run the simulation against
skipSigVerify
boolean
(Optional) A boolean value indicating whether to enable signature verification before simulation
replaceRecentBlockhash
boolean
(Optional) A boolean value indicating whether to replace the simulated transaction's recent blockhash with the latest blockhash
accounts
object
The accounts configuration object containing the following fields:
addresses
string
An array of accounts to return, as base-58 encoded strings
encoding
string
The encoding format for account data. It can be one of base58 (slow), base64, base64+zstd or jsonParsed
Returns
result
object
Null if the account doesn't exist otherwise RpcResponse JSON object with the following fields:
context
object
An object that contains metadata about the current state of the Solana network at the time the request was processed
apiVersion
string
The version number
slot
integer
The current slot in the Solana cluster during which the transactions are processed and new blocks are added to the blockchain
err
string
Error code if the transaction failed or null if the transaction succeeds
logs
array
An array of log messages the transaction instructions output during execution, null if simulation failed before the transaction was able to execute (for example due to an invalid blockhash or signature verification failure)
preExecutionAccounts
array
A list of accounts to return the pre transaction execution state for. The length of the array must be


[User] How does the 'maxRetries' option function when sending a transaction in Tatum?

[Assistant]
The `maxRetries` option in Tatum's `sendTransaction` method specifies the maximum number of times the RPC node will attempt to resend the transaction to the leader if the initial attempt fails. This is useful for ensuring that transactions are not lost due to temporary network issues or node unavailability.

Here’s how it works:
- If a transaction fails to be sent successfully, the RPC node will retry sending it up to the number specified by `maxRetries`.
- If the transaction is successfully sent before reaching the maximum number of retries, the process stops, and no further attempts are made.
- If the maximum number of retries is reached and the transaction still fails, an error will be returned.

Here’s an example of how you might specify `maxRetries` in a transaction request:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "sendTransaction",
  "params": [
    "4hXTCkRzt9WyecNzV1XPgCDfGAZzQKNxLXgynz5QDuWWPSAZBZSHptvWRL3BjCvzUXRdKvHL2b7yGrRQcWyaqsaBCncVG7BFggS8w9snUts67BSh3EqKpXLUm5UMHfD7ZBe9GhARjbNQMLJ1QD3Spr6oMTBU6EhdB4RD8CP2xUxr2u3d6fos36PD98XS6oX8TQjLpsMwncs5DAMiD4nNnR8NBfyghGCWvCVifVwvA8B8TJxE1aiyiv2L429BCWfyzAme5sZW8rDb14NeCQHhZbtNqfXhcp2tAnaAT",
    {
      "maxRetries": 5
    }
  ]
}
```

In this example, the transaction will be retried up to 5 times if it fails to send successfully on the first attempt.

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

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

JSON-RPC Request Example
JSON

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


[User] How does Wrapped SOL (wSOL) function within the Jupiter platform?

[Assistant]
Wrapped SOL (wSOL) functions within the Jupiter platform as a representation of native SOL that has been wrapped using the Solana Token Program. This wrapping process allows wSOL to be treated like any other token within the Solana ecosystem, specifically SPL tokens.

The key benefits of using wSOL on the Jupiter platform include:

1. **Direct Trading**: Users can trade wSOL directly with any SPL token on Jupiter. This integration simplifies the trading process for users who frequently engage in transactions involving SOL.

2. **Transaction Efficiency**: By using wSOL, traders can avoid the need to wrap and unwrap SOL for each transaction. This reduces the number of transactions required, making the trading experience faster and more convenient.

In summary, wSOL enhances the trading capabilities on Jupiter by allowing seamless interactions with SPL tokens while improving transaction efficiency.

We currently support Fluxbeam, Meteora DLMM, Meteora CPMM, 1Intro, Pump.Fun, Raydium CLMM, Raydium CP, Raydium V4 and Whirlpools for Instant Routing.

To ensure your market gets routed on Jupiter after 14 days, your market must fit one of the following criteria:

Less than 30% price impact on $500
Using a benchmark position size of $500, a user should encounter less than 30% price impact after swapping in AND out of the token from the same pool.

Price Impact = ($500 - Final USD value) / $500

For example, a user swaps $500 worth of SOL into the token, then swaps the same output amount back into SOL. We then use the formula to calculate the price impact percentage.

If the price impact is more than 30%, it means that there is insufficient liquidity in the pool for the benchmark position size of $500.

price-impact-criteria

(For additional markets) Less than 20% price difference on new pools
For additional markets on already supported tokens, there should be a variance of less than 20% between the new pool and the pool existing in routing.

What is Wrapped SOL (wSOL)?
Wrapped SOL is native SOL that is wrapped using the Solana Token Program, which allows it to be treated like any other Token program token type.

tip
You can now use wSOL (wrapped SOL) to trade directly with any SPL token on Jupiter! This makes Jupiter even faster and more convenient for traders who trade frequently with SOL, since it avoids having to wrap/unwrap SOL, which might result in multiple transactions


[User] What is the significance of the 'amount' field in the token account information provided by QuickNode?

[Assistant]
The 'amount' field in the token account information provided by QuickNode represents the total quantity of tokens held in the specified token account. This field is crucial as it indicates the balance of tokens available for transactions or transfers associated with that account.

For example, if you query a token account and receive an 'amount' value of 1000, it means that the account currently holds 1000 tokens of the specified type. This information is essential for users to understand their token holdings and manage their assets effectively.

In summary, the 'amount' field is significant because it directly reflects the balance of tokens in the account, which is fundamental for any operations involving token transfers or balances.

ccounts
array of objects
An array of objects containing information about the specified token accounts:
account
object
The information about the specified token account:
address
string
The address of the token account
mint
string
The address of the mint account
owner
string
The address of the token account owner
amount
integer
The amount of tokens in the token account
delegated_amount
number
The amount of delegated tokens in the token account
frozen
boolean
Whether the token account is frozen
close_authority
string
The close authority for the token account
extentions
string
The extensions of the token account
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc": "2.0","id": 1,"method": "getTokenAccounts","params": {"mintAddress": "So11111111111111111111111111111111111111112", "limit": 2}}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getNftEditions
Next
searchAssets
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
searchAssets RPC Method
Returns the list of assets given search criteria. The API credit value for this method is 60.
Updated on
Oct 23, 2024
Please note that this RPC method r


[User] What version of the JSON-RPC protocol is required when using QuickNode services?

[Assistant]
When using QuickNode services, the version of the JSON-RPC protocol required is specified as a parameter called `jsonrpc`. This parameter is mandatory for the requests you make to the QuickNode API.

For example, when making a request, you would include it like this:

```json
{
  "jsonrpc": "2.0",
  "method": "your_method_name",
  "params": [],
  "id": 1
}
```

In this example, `"2.0"` is the version of the JSON-RPC protocol being used.

1111112", "outputMint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "amount": 1000000, "slippageBps": 1}, "id": 1}
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
/limit-orders/history
Next
/ws (Swap Websocket)
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
Swap Websocket RPC Method
Subscribe to receive a notification from the Jupiter API you can use from the quote you get from /quote.
Updated on
Sep 20, 2024
Please note that this method is only available for paid subscribers of Metis - Jupiter V6 Swap API.
To establish a WebSocket connection, you need to simply append '/ws' to your endpoint URL. For parameters, you can include them as URL arguments referred to as "params".
Solana Web3.js 2.0 includes the ability to customize RPC methods and transports, allowing you to seamlessly integrate QuickNode Marketplace add-ons into your applications. For more information on how to use QuickNode Marketplace add-ons with Solana Web3.js 2.0, check out these guides: How to Use QuickNode Add-ons using Solana Web3.js 2.0 (Part 1) and How to Use QuickNode Add-ons using Solana Web3.js 2.0 (Part 2)
Parameters
jsonrpc
string
REQUIRED
The version of the JSON-RPC protocol being used
method


[User] Can a stake account on Solana be destroyed, and if so, what steps lead to its destruction?

[Assistant]
Yes, a stake account on Solana can be effectively destroyed, but this occurs under specific conditions. Here are the steps that lead to its destruction:

1. **Withdraw All Tokens**: The stake account must have all of its tokens withdrawn to a wallet address. This means that the balance of the stake account must be reduced to 0 SOL.

2. **No Delegation**: The stake account must not be delegated. If the stake account is currently delegated to a validator, it cannot be destroyed until the delegation is revoked.

3. **Effectively Destroyed**: Once the balance is 0 SOL and the account is not delegated, the stake account is no longer tracked on the Solana network. It will need to be manually re-created if you wish to use that address again.

In summary, to destroy a stake account, ensure that it has a balance of 0 SOL and is not currently delegated to any validator.

llet or updating the withdraw authority is not allowed.

A lockup can only be added when a stake account is first created, but it can be modified later, by the lockup authority or custodian, the address of which is also set when the account is created.

Destroying a Stake Account #
Like other types of accounts on the Solana network, a stake account that has a balance of 0 SOL is no longer tracked. If a stake account is not delegated and all of the tokens it contains are withdrawn to a wallet address, the account at that address is effectively destroyed, and will need to be manually re-created for the address to be used again.

Viewing Stake Accounts #
Stake account details can be viewed on the Solana Explorer by copying and pasting an account address into the search bar.

Stake Programming
To maximize stake distribution, decentralization, and censorship resistance on the Solana network, staking can be performed programmatically. The team and community have developed several on-chain and offchain programs to make stakes easier to manage.

Stake-o-matic aka Auto-delegation Bots #
This offchain program manages a large population of validators staked by a central authority. The Solana Foundation uses an auto-delegation bot to regularly delegate its stake to "non-delinquent" validators that meet specified performance requirements.

Stake Pools #
This on-chain program pools together SOL to be staked by a manager, allowing SOL holders to stake and earn rewards without managing stake


[User] What is the endpoint used for posting transaction bundles in Pump Portal?

[Assistant]
The endpoint used for posting transaction bundles in Pump Portal is:

```
https://mainnet.block-engine.jito.wtf/api/v1/bundles
```

This endpoint is used to send the encoded signed transactions as part of a request to create a bundle.

 "buy", "sell", or "create"
            "mint": "2xHkesAQteG9yz48SDaVAtKdFU6Bvdo9sXS3uQCbpump",
            "denominatedInSol": "false",
            "amount": 1000,
            "slippage": 50,
            "priorityFee": 0.0001, # priority fee on the first tx is used for jito tip
            "pool": "pump"
        },
        {
            "publicKey": str(signerKeypairs[1].pubkey()),
            "action": "buy",  # "buy", "sell", or "create"
            "mint": "2xHkesAQteG9yz48SDaVAtKdFU6Bvdo9sXS3uQCbpump",
            "denominatedInSol": "false",
            "amount": 1000,
            "slippage": 50,
            "priorityFee": 0.0001, # priority fee after first tx is ignored
            "pool": "pump"
        }
        # use up to 5 transactions
    ]
)

if response.status_code != 200:
    print("Failed to generate transactions.")
    print(response.reason)
else:
    encodedTransactions = response.json()
    encodedSignedTransactions = []
    txSignatures = []

    for index, encodedTransaction in enumerate(encodedTransactions):
        signedTx = VersionedTransaction(VersionedTransaction.from_bytes(base58.b58decode(encodedTransaction)).message, [signerKeypairs[index]])
        encodedSignedTransactions.append(base58.b58encode(bytes(signedTx)).decode())
        txSignatures.append(str(signedTx.signatures[0]))

    jito_response = requests.post(
        "https://mainnet.block-engine.jito.wtf/api/v1/bundles",
        headers={"Content-Type": "application/json"},
        js


[User] What are the implications of the allocate function being the 8th position in the instruction enum for developers using Solana?

[Assistant]
The implication of the allocate function being in the 8th position in the instruction enum for developers using Solana is primarily related to how developers construct and interpret transactions involving the SystemProgram.

1. **Instruction Indexing**: The index value of 8 indicates that when developers are encoding instructions for the SystemProgram, they need to use this specific index to reference the allocate function. This means that in the payload sent to the blockchain, the first byte will indicate the instruction type, and for the allocate function, this byte will be set to 8.

2. **Payload Construction**: When constructing a transaction that includes the allocate function, developers must ensure that they correctly format the payload according to the specified structure. The payload must include the instruction index (8) and any additional parameters required by the function, such as the space to allocate. This is done using the buffer-layout library, which helps in creating the appropriate buffer format for the Rust programs on Solana to interpret.

3. **Error Handling**: If a developer mistakenly uses the wrong index when invoking the allocate function, the transaction will likely fail. This emphasizes the importance of referencing the correct instruction enum and understanding the order of functions within it.

4. **Documentation and Maintenance**: Developers need to be aware of the instruction enum's structure, as any changes to the enum (such as adding new instructions) could potentially shift the indices of existing functions. This requires ongoing attention to the Solana documentation and updates to ensure that their code remains functional.

In summary, the position of the allocate function in the instruction enum necessitates careful attention to indexing when constructing transactions, proper payload formatting, and awareness of potential changes in the instruction set that could affect existing code.

transaction, defaulting to the pubkey of the first signer in the transaction. keys represents all accounts that the program's allocate function will interact with. Since the allocate function also required space, we created params to be used later when invoking the allocate function.

let allocateStruct = {
  index: 8,
  layout: struct([u32("instruction"), ns64("space")]),
};

The above is created using u32 and ns64 from @solana/buffer-layout to facilitate the payload creation. The allocate function takes in the parameter space. To interact with the function we must provide the data as a Buffer format. The buffer-layout library helps with allocating the buffer and encoding it correctly for Rust programs on Solana to interpret.

Let's break down this struct.

{
  index: 8, /* <-- */
  layout: struct([
    u32('instruction'),
    ns64('space'),
  ])
}

index is set to 8 because the function allocate is in the 8th position in the instruction enum for SystemProgram.

/* https://github.com/solana-labs/solana/blob/21bc43ed58c63c827ba4db30426965ef3e807180/sdk/program/src/system_instruction.rs#L142-L305 */
pub enum SystemInstruction {
    /** 0 **/CreateAccount {/**/},
    /** 1 **/Assign {/**/},
    /** 2 **/Transfer {/**/},
    /** 3 **/CreateAccountWithSeed {/**/},
    /** 4 **/AdvanceNonceAccount,
    /** 5 **/WithdrawNonceAccount(u64),
    /** 6 **/InitializeNonceAccount(Pubkey),
    /** 7 **/AuthorizeNonceAccount(Pubkey),
    /** 8 **/Allocate {/**/},
    /** 9 **/AllocateWithS


[User] Which protocol does Raydium recommend for viewing and managing existing Serum orders after the deprecation?

[Assistant] After the deprecation of Serum integration on the Raydium trading page, users are recommended to access and manage their existing Serum orders through Step Finance. Users can view, cancel, and settle their existing orders and unsettled funds by connecting a wallet on Step Finance.

lify the process of moving your balances over.

Serum DEX Deprecation
The Raydium trading page will deprecate Serum integration December 14.
The Raydium trading page ('Trading' tab on left navigation of the site) is a graphical user interface (GUI) that allowed users to access the central order book of the Project Serum DEX through its relevant smart contracts.

Due to recent events, it seems unlikely that Project Serum will be further developing or supporting the Serum order book. As a result, the Raydium trading GUI will fully deprecate Serum integration on December 14.

Note: All other Raydium features, including swaps, pools, farms and staking will continue to operate as normal. Only the trading page (dex.raydium.io) is affected.

Users should cancel and settle existing Serum orders immediately, before December 14!

Placing new orders is already disabled. Existing orders can still be canceled and settled until December 14.

On December 14, the trading page will be deprecated and the UI will no longer integrate with Serum. All interactions with the Serum order book will be disabled.

Where to access Serum after December 14?
There are several other protocols that host GUIs for the Project Serum DEX where orders can be managed. However, note that some protocols may also have plans to deprecate Serum markets.

Existing orders and unsettled funds can be viewed, cancelled and settled by connecting a wallet on Step Finance.

Other protocols hosting Serum GUIs, :

Vybe Network


[User] How are refunds processed at DexScreener, and what payment method is used?

[Assistant]
Refunds at DexScreener are processed through a specific procedure outlined in their documentation. Here’s how the refund process works:

1. **Contact Customer Support**: Users must reach out to the customer support team at support@dexscreener.com. The email should be sent from the same address used to submit the order and must include the order number, token address, and the reason for the refund, along with any other relevant details.

2. **Evaluation**: The support team will evaluate the refund request based on specific eligibility criteria.

3. **Refund Decision**: If the request meets the eligibility criteria, the refund will be initiated, and the user will be informed.

4. **Refund Disbursal**: Refunds are processed using the original payment method. DexScreener issues refunds in batches weekly, and it can take up to 4 weeks for the refunds to be processed. Additionally, users should be aware that their financial institution may require extra time to reflect the refund on their account statement.

In summary, refunds are processed using the original payment method, and the entire process involves contacting customer support, evaluation, and then disbursal.

not qualify for refunds:

If you are unsatisfied and want to cancel an order that has already been completed.

If a problem on your end prevents the token from going live on DEX Screener supported pools and exchanges.

If your token is inactive.

If you want to delete your existing token profile.

Community Takeover (CTO) orders that do no get approved.

1.3. Refund Process
The refund request and disbursal process is as follows:

(a) Contact Customer Support:

Please contact the customer support team at support@dexscreener.com. The email should be sent from the same address that was used to submit the order. Mention the order number, token address and reason for refund. Include any other relevant details.

(b) Evaluation:

The support team will evaluate your request according to the criteria outlined in Section 1.1.

(c) Refund Decision:

If your request meets the eligibility criteria, the refund will be initiated and you’ll be intimated.

(d) Refund disbursal:

The refund will be processed using the original payment method. We issue refunds in batches weekly and it can take up to 4 weeks for the refunds to be processed. Please be aware that your financial institution may require additional time to reflect this refund on your account statement.

1.4. Credits
Pre-sale orders where the token does not go live and Community Takeover (CTO) orders that are not approved are not eligible for refunds. However, the support team may, at their discretion, offer a credit.

This credit ca


[User] How long can users expect a response from DexScreener during working days?

[Assistant] Users can expect a response from DexScreener within up to 24 hours during working days.

 *Please note that even if the process has been completed successfully, we and our partner reserve the right not to promote the project on the website.

Note that a response may take up to 24 hours during a working day and up to 72 hours during holidays and weekends.

Alternative communication meanings like Telegram are also available and will be confirmed by email (to prevent fake impersonators) from an official email address.


[User] What specific checks must be performed on a withdrawal address according to Solana's guidelines?

[Assistant]
According to Solana's guidelines, the following specific checks must be performed on a withdrawal address:

1. **Ownership Check**: The withdrawal address must be owned by the System Program.

2. **Account Data Check**: The withdrawal address must have no account data associated with it.

3. **SOL Balance Check**: The address must have no SOL balance. If it does have a balance, user confirmation should be obtained before proceeding with the withdrawal.

These checks ensure that the withdrawal address is valid and secure before executing any transfer.

t1tEqg5BN
  Recipient: 6VzWGL51jLebvnDifvcuEDec17sK6Wupi4gYhm5RzfkV
Signature: 3R6tsog17QM8KfzbcbdP4aoMfwgo6hBggJDVy7dZPVmH2xbCWjEj31JKD53NzMrf25ChFjY7Uv2dfCDq4mGFFyAj

Depositing #
Since each (wallet, mint) pair requires a separate account onchain. It is recommended that the addresses for these accounts be derived from SOL deposit wallets using the Associated Token Account (ATA) scheme and that only deposits from ATA addresses be accepted.

Monitoring for deposit transactions should follow the block polling method described above. Each new block should be scanned for successful transactions referencing user token-account derived addresses. The preTokenBalance and postTokenBalance fields from the transaction's metadata must then be used to determine the effective balance change. These fields will identify the token mint and account owner (main wallet address) of the affected account.

Note that if a receiving account is created during the transaction, it will have no preTokenBalance entry as there is no existing account state. In this case, the initial balance can be assumed to be zero.

Withdrawing #
The withdrawal address a user provides must be that of their SOL wallet.

Before executing a withdrawal transfer, the exchange should check the address as described above. Additionally this address must be owned by the System Program and have no account data. If the address has no SOL balance, user confirmation should be obtained before proceeding with the withdrawal. All other


[User] In Bitquery, how are the total buy and sell amounts calculated for trades on Raydium?

[Assistant]
In Bitquery, the total buy and sell amounts for trades on Raydium are calculated using the `sum` function in the GraphQL query. Specifically, the `DEXTradeByTokens` query allows you to sum the amounts based on the trade side (buy or sell) and the amount in USD.

Here is an example of how the total buy and sell amounts are calculated in the query:

```graphql
{
  Solana {
    DEXTradeByTokens(
      orderBy: {descendingByField: "sell"}
      where: {
        Trade: {
          Currency: {
            MintAddress: {
              notIn: ["So11111111111111111111111111111111111111112", "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"]
            }
          },
          Dex: {ProtocolFamily: {is: "Raydium"}},
          Transaction: {Result: {Success: true}}
        }
      }
      limit: {count: 100}
    ) {
      Trade {
        Currency {
          Symbol
          Name
          MintAddress
        }
      }
      buy: sum(of: Trade_Side_AmountInUSD, if: {Trade: {Side: {Type: {is: buy}}}})
      sell: sum(of: Trade_Side_AmountInUSD, if: {Trade: {Side: {Type: {is: sell}}}})
    }
  }
}
```

In this query:
- The `buy` amount is calculated by summing the `Trade_Side_AmountInUSD` where the trade side type is `buy`.
- The `sell` amount is calculated by summing the `Trade_Side_AmountInUSD` where the trade side type is `sell`.

This allows you to get the total amounts for both buying and selling trades on the Raydium DEX.

okens on Solana
This query will give you most sold Solana Tokens on Raydium. You can find the query here

{
  Solana {
    DEXTradeByTokens(
      orderBy: {descendingByField: "sell"}
      where: {Trade: {Currency: {MintAddress: {notIn: ["So11111111111111111111111111111111111111112", "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"]}}, Dex: {ProtocolFamily: {is: "Raydium"}}}, Transaction: {Result: {Success: true}}}
      limit: {count: 100}
    ) {
      Trade {
        Currency {
          Symbol
          Name
          MintAddress
        }
      }
      buy: sum(of: Trade_Side_AmountInUSD, if: {Trade: {Side: {Type: {is: buy}}}})
      sell: sum(of: Trade_Side_AmountInUSD, if: {Trade: {Side: {Type: {is: sell}}}})
    }
  }
}

Arranged in the descending order of sold - bought on DEXrabbit.

image

Check data here on DEXrabbit.

Get Top Traded Pairs
This query will give you top traded pairs data. You can find the query here

query ($time_10min_ago: DateTime, $time_1h_ago: DateTime, $time_3h_ago: DateTime) {
  Solana {
    DEXTradeByTokens(
      where: {Transaction: {Result: {Success: true}}, Block: {Time: {after: $time_3h_ago}}, any: [{Trade: {Side: {Currency: {MintAddress: {is: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"}}}}}, {Trade: {Currency: {MintAddress: {not: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"}}, Side: {Currency: {MintAddress: {is: "So11111111111111111111111111111111111111112"}}}}}, {Trade: {Currency: {MintAddress: {notIn: ["So1111111111111111111111111


[User] Are there any circumstances under which Pump Portal may be available for use in restricted jurisdictions?

[Assistant]
According to the documentation, Pump Portal does not allow interaction with digital wallets located in or associated with certain prohibited localities, including countries and regions subject to sanctions enforced by the United States, the United Kingdom, or the European Union. The documentation explicitly states that users must not use any software or networking techniques, such as a Virtual Private Network (VPN), to circumvent this prohibition.

Therefore, there are no circumstances mentioned in the documentation under which Pump Portal may be available for use in restricted jurisdictions. Users are solely responsible for compliance with all applicable laws and regulations, and Pump Portal has no obligation to inform users of potential liabilities or violations related to access from these jurisdictions.

ability of our Interface to any person, geographic area, or jurisdiction, at any time and at our sole and absolute discretion.

Prohibited Localities. PumpPortal does not interact with digital wallets located in, established in, or a resident of Myanmar (Burma), Cote D'Ivoire (Ivory Coast), Cuba, Crimea and Sevastopol, Democratic Republic of Congo, Iran, Iraq, Libya, Mali, Nicaragua, Democratic People’s Republic of Korea (North Korea), Somalia, Sudan, Syria, Yemen, Zimbabwe or any other state, country or region that is subject to sanctions enforced by the United States, the United Kingdom or the European Union. You must not use any software or networking techniques, including use of a Virtual Private Network (VPN) to modify your internet protocol address or otherwise circumvent or attempt to circumvent this prohibition."

Non-Circumvention. You agree not to access the Interface using any technology for the purposes of circumventing these Terms.

2. Compliance Obligations
The Interface may not be available or appropriate for use in all jurisdictions. By accessing or using the Interface, you agree that you are solely and entirely responsible for compliance with all laws and regulations that may apply to you. You further agree that we have no obligation to inform you of any potential liabilities or violations of law or regulation that may arise in connection with your access and use of the Interface and that we are not liable in any respect for any failure by you to comply with


[User] What role does the 'Rent::get()?.minimum_balance' function play in the Solana account creation process?

[Assistant]
In the Solana account creation process, the `Rent::get()?.minimum_balance` function is used to determine the minimum amount of lamports required to create and maintain an account for a specified length of data. This is crucial because every account on the Solana blockchain must maintain a minimum balance to avoid being evicted due to rent.

Here's how it fits into the account creation process:

1. **Account Initialization**: When creating a new account, you need to ensure that it has enough lamports to cover the rent-exempt threshold. This is where `Rent::get()?.minimum_balance(INITIAL_ACCOUNT_LEN)` comes into play. It calculates the minimum balance required based on the size of the account data (`INITIAL_ACCOUNT_LEN`).

2. **Creating the Account**: After determining the required lamports, this value is used in the `system_instruction::create_account` function to specify how many lamports should be transferred to the new account at the time of its creation.

Here’s a snippet illustrating this process:

```rust
let lamports_required = Rent::get()?.minimum_balance(INITIAL_ACCOUNT_LEN);
let create_pda_account_ix = system_instruction::create_account(
    &funding_account.key,
    &pda_account.key,
    lamports_required,
    INITIAL_ACCOUNT_LEN.try_into().unwrap(),
    &_program_id,
);
```

In summary, `Rent::get()?.minimum_balance` ensures that the new account is created with sufficient funds to remain rent-exempt, thereby preventing it from being deactivated or evicted from the blockchain.

nts.iter();

  let funding_account = next_account_info(accounts_iter)?;
  let pda_account = next_account_info(accounts_iter)?;
  let system_program = next_account_info(accounts_iter)?;

  match instruction {
    WhitelistInstruction::Initialize => {
      msg!("Initialize");

      let (pda, pda_bump) = Pubkey::find_program_address(
          &[
            b"customaddress",
            &funding_account.key.to_bytes(),
          ],
          _program_id,
      );

      let signers_seeds: &[&[u8]; 3] = &[
          b"customaddress",
          &funding_account.key.to_bytes(),
          &[pda_bump],
      ];

      if pda.ne(&pda_account.key) {
          return Err(ProgramError::InvalidAccountData);
      }

      let lamports_required = Rent::get()?.minimum_balance(INITIAL_ACCOUNT_LEN);
      let create_pda_account_ix = system_instruction::create_account(
          &funding_account.key,
          &pda_account.key,
          lamports_required,
          INITIAL_ACCOUNT_LEN.try_into().unwrap(),
          &_program_id,
      );

      invoke_signed(
          &create_pda_account_ix,
          &[
              funding_account.clone(),
              pda_account.clone(),
              system_program.clone(),
          ],
          &[signers_seeds],
      )?;

      let mut pda_account_state = WhiteListData::try_from_slice(&pda_account.data.borrow())?;

      pda_account_state.is_initialized = true;
      pda_account_state.white_list = Vec::new();
      pda_account_state.ser


[User] How can a user unsubscribe from root notifications in Solana using the rootUnsubscribe RPC method?

[Assistant]
To unsubscribe from root notifications in Solana using the `rootUnsubscribe` RPC method, you need to provide the subscription ID that you received when you initially subscribed to root notifications.

Here’s how you can do it:

### Parameters
- **subscription id**: This is a required parameter that indicates the ID of the subscription you want to cancel.

### Code Example
Here’s a sample JSON-RPC request to unsubscribe from root notifications:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "rootUnsubscribe",
  "params": [0]  // Replace 0 with your actual subscription ID
}
```

### Response
If the unsubscribe request is successful, you will receive a response indicating the success of the operation:

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

This response confirms that you have successfully unsubscribed from the root notifications. Make sure to replace `0` in the `params` array with the actual subscription ID you received during the subscription process.

t": true, "id": 1 }

rootSubscribe RPC Method
Edit Page
Subscribe to receive notification anytime a new root is set by the validator.

Parameters #
None

Result #
integer - subscription id (needed to unsubscribe)

Code sample #
{ "jsonrpc": "2.0", "id": 1, "method": "rootSubscribe" }

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

Notification Format: #
The result is the latest root slot number.

{
  "jsonrpc": "2.0",
  "method": "rootNotification",
  "params": {
    "result": 42,
    "subscription": 0
  }
}

rootUnsubscribe RPC Method
Edit Page
Unsubscribe from root notifications

Parameters #
number required

subscription id to cancel

Result #
<bool> - unsubscribe success message

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

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

signatureSubscribe RPC Method
Edit Page
Subscribe to receive a notification when the transaction with the given signature reaches the specified commitment level.

Caution
This is a subscription to a single notification. It is automatically cancelled by the server once the notification, signatureNotification, is sent by the RPC.

Parameters #
string required

transaction signature, as base-58 encoded string

Info
The transaction signature must be the first signature from the transaction (see transaction id for more details).

object optional

Configuration object containing the following fields:

commitment string optional

enableReceiv


[User] What is the default rate limit for Jito requests per second per IP per region?

[Assistant] The default rate limit for Jito requests is 5 requests per second per IP per region.

le": 1e-05,
    "landed_tips_75th_percentile": 3.6196500000000005e-05,
    "landed_tips_95th_percentile": 0.0014479055000000002,
    "landed_tips_99th_percentile": 0.010007999,
    "ema_landed_tips_50th_percentile": 9.836078125000002e-06
  }
]
WebSocket showing tip amounts:
wscat -c wss://bundles.jito.wtf/api/v1/bundles/tip_stream
Tip Dashboard
To view dashboard please click here .

Rate Limits
Default Limits
Q: What are the defaults?

5 requests per second per IP per region.

Rate Limit Operation
Q: How do they work?

You no longer need an approved auth key for default sends.

Exceeding Limits
Q: What happens if the rate limit is exceeded?

429 or rate limit error indicating what you hit.

Authorization Issues
Q: What happens if I see The supplied pubkey is not authorized to generate a token?

This indicates that you’re either using the auth-key parameter or your keypair variable is being set to check for this key unnecessarily. In most cases, you can simply use Null or None for these fields. Many of the new SDKs will have this built-in by default, so you won’t need to specify it manually.

Rate Limits Form
Please ensure to provide valid contact information so we can send you acknowledgment submit form

Troubleshooting
Priority Fee
Q: How to know how much to set priority fee?

Please see Tip Amount for sendTransaction

Tip Amount
Q: How to know how much to set a tip?

The minimum tips is 1000 lamports

Bundle Landing
Q: My bundle/transaction is not landing, how d


[User] What is the purpose of the Solana.py library mentioned in QuickNode's documentation?

[Assistant]
The Solana.py library is a Python library designed for interacting with the Solana blockchain. It is important to note that Solana.py is community-maintained, which means that updates may not be available at the same time as the Solana Web3 API. To use this library, you need to install it along with its dependencies using the following command:

```bash
pip install solana cachetools
```

This library allows developers to build applications that can communicate with the Solana blockchain using Python, facilitating tasks such as sending transactions, querying account information, and interacting with smart contracts.

VNET	✅	✅
TESTNET	✅	✅
MAINNET	✅	✅
Making Solana API Requests
In this documentation, you will see example requests made with various programming languages for each supported Solana method. This section will explain how to execute each one of them on your machine.

cURL
Most *nix based systems have cURL support out of the box. cURL is a command line tool and library for transferring data with URLs. Check if you have it by running the following:

curl -h

Solana/Web3.js (v2.x, latest)
Solana Web3.js 2.0 is a significant update to the JavaScript library for interacting with the Solana blockchain. It introduces a new API design focusing on composability, modularity, and improved developer experience. You can install it with the following command:

npm install @solana/web3.js@2

Note
To know more about Solana Web3.js 2.0 you can checkout our blog here

Solana/Web3.js (v1.x)
To use an older version of the Solana/Web3.js JSON RPC library, you can install it with the following command:

npm install @solana/web3.js@1

Solana.py
Solana.py is a Python library for interacting with Solana. It is important to note that Solana.py is community-maintained and updates may not be available at the same time as the Solana Web3 API. If you'd like to use this library, please be sure to install it and its 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


[User] How can a user ensure they properly manage resources when using slot updates subscriptions on ChainStack?

[Assistant]
To properly manage resources when using slot updates subscriptions on ChainStack, a user should utilize the `slotsUpdatesUnsubscribe` method to cancel any active subscriptions when they are no longer needed. This helps prevent unnecessary resource consumption and ensures efficient use of WebSocket connections.

Here’s how you can implement this:

1. **Subscribe to Slot Updates**: First, you need to subscribe to slot updates using the `slotsUpdatesSubscribe` method, which will return a subscription ID.

2. **Manage the Subscription**: When you no longer need the slot updates, you should call the `slotsUpdatesUnsubscribe` method with the subscription ID to unsubscribe.

3. **Check the Response**: The response will be a boolean indicating whether the unsubscription was successful.

### Example Code

Here’s a simple example demonstrating how to manage slot updates subscriptions:

```javascript
// Assuming you have a WebSocket connection established
const subscriptionId = await slotsUpdatesSubscribe();

// Later in your code, when you no longer need the updates
const unsubscribeSuccess = await slotsUpdatesUnsubscribe(subscriptionId);

if (unsubscribeSuccess) {
    console.log("Successfully unsubscribed from slot updates.");
} else {
    console.log("Failed to unsubscribe from slot updates.");
}
```

### Use Case

Using the `slotsUpdatesUnsubscribe` method is crucial for:
- **Cleanup**: It allows you to remove detailed slot updates when they are no longer relevant, freeing up resources.
- **Resource Management**: It prevents your application from maintaining unnecessary connections, which can lead to performance issues.

By following this approach, users can ensure efficient resource management while working with slot updates subscriptions on ChainStack.

per insights into the blockchain's operation and implement more sophisticated timing and monitoring systems.

slotsUpdatesUnsubscribe | Solana
The slotsUpdatesUnsubscribe method in Solana allows a client to unsubscribe from a slots updates subscription. This method can be used to cancel an existing subscription to detailed slot updates.

See also slotsUpdatesSubscribe | Solana.

👍
Get your own Solana node endpoint today

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

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

Parameters
integer - The ID of the subscription that you want to cancel. This is the subscription ID that was returned when calling slotsUpdatesSubscribe.
Response
boolean - A boolean value indicating if the subscription was removed successfully. true if removed successfully, false if not.
slotsUpdatesUnsubscribe code examples
📘
Note that subscriptions require a WebSocket connection. You can use a WebSocket client library for your programming language of choice to interact with Solana's WebSocket API.

wscat

$ wscat -c YOUR_CHAINSTACK_WEBSOCKET_ENDPOINT
# Wait for the connection to be established

Connected (press CTRL+C to quit)

> {"jsonrpc":"2.0","id":1,"method":"slotsUpdatesUnsubscribe","params":[0]}
Use case
The slotsUpdatesUnsubscribe method is important for proper resource management in applications that use slots updates subscriptions. Common use cases include:

Cleanup: Remove detailed slot m