[User] What context is needed to understand how programs use PDAs for signing in Solana's Cross Program Invocations (CPIs)?

[Assistant]
To understand how programs use Program Derived Addresses (PDAs) for signing in Solana's Cross Program Invocations (CPIs), it's essential to grasp the following concepts:

1. **Program Derived Addresses (PDAs)**: PDAs are addresses that are deterministically derived using a combination of user-defined seeds, a bump seed, and a program's ID. They do not have a corresponding private key and fall off the Ed25519 curve. This means that they cannot be directly controlled or signed by a user, but a program can sign on behalf of a PDA.

2. **Signing with PDAs**: Since PDAs do not have private keys, the program that derives the PDA can "sign" transactions on behalf of the PDA. This is crucial for allowing programs to interact with each other securely and efficiently. The program must be the one that derived the PDA to be able to sign transactions involving that PDA.

3. **Cross Program Invocations (CPIs)**: CPIs allow one program to call another program. When a program invokes another program, it can pass along accounts, including PDAs. The invoking program must ensure that it has the right to access and manipulate the PDA, which is typically established through the PDA's derivation logic.

4. **Account Creation**: It's important to note that deriving a PDA does not automatically create an on-chain account at that address. An account using a PDA as its address must be explicitly created through the program that uses it. This means that before a PDA can be used in a CPI, the corresponding account must exist.

5. **Bump Seed**: The bump seed is a mechanism used to ensure that the derived PDA is unique and does not collide with existing accounts. This is particularly important when multiple accounts might be derived from the same seeds.

By understanding these concepts, one can better appreciate how PDAs function within the context of CPIs, enabling secure and efficient interactions between different Solana programs.

ich are derived from its program ID.
You can think of PDAs as a way to create hashmap-like structures on-chain from a predefined set of inputs (e.g. strings, numbers, and other account addresses).

The benefit of this approach is that it eliminates the need to keep track of an exact address. Instead, you simply need to recall the specific inputs used for its derivation.

Program Derived Address
Program Derived Address

It's important to understand that simply deriving a Program Derived Address (PDA) does not automatically create an on-chain account at that address. Accounts with a PDA as the on-chain address must be explicitly created through the program used to derive the address. You can think of deriving a PDA as finding an address on a map. Just having an address does not mean there is anything built at that location.

Info
This section will cover the details of deriving PDAs. The details on how programs use PDAs for signing will be addressed in the section on Cross Program Invocations (CPIs) as it requires context for both concepts.

Key Points #
PDAs are addresses derived deterministically using a combination of user-defined seeds, a bump seed, and a program's ID.

PDAs are addresses that fall off the Ed25519 curve and have no corresponding private key.

Solana programs can programmatically "sign" on behalf of PDAs that are derived using its program ID.

Deriving a PDA does not automatically create an on-chain account.

An account using a PDA as its address must be expl


[User] How often should a 'getHealth' call be sent to Helius, and why is it important?

[Assistant]
A 'getHealth' call should be sent every second using the same endpoint and API key that you use for sending transactions. This practice is important because it helps to warm the Helius regional caches, which can minimize tail latency when sending transactions. By keeping the connection active and the caches warm, you can improve the overall performance and responsiveness of your transaction submissions, particularly for latency-sensitive trading applications.

In summary, sending a 'getHealth' call every second is a recommended optimization for ensuring faster transaction processing and better connection reliability with Helius.

h skipPreflight set to true

Want to go deeper? We cover all fundamentals in this blog post.

Recommended Optimizations for Traders
We recommend the following optimizations for latency-sensitive traders. You must already be applying the best practices for sending transactions mentioned above.

Send transactions from Eastern US or Western Europe.

Choose Frankfurt or Pittsburg if you want to co-locate with Helius transaction-sending servers.

Avoid sending regions far away from the validator network (e.g. LATAM or South Africa).

Warm the Helius regional caches to minimize tail latency.

Send a getHealth call every second using the same endpoint & API key you use for sending transactions.

Only one warming thread is required per region. Any more will have zero benefit.

The benefits will only be noticeable to experienced traders. We recommend the Sending Smart Transactions section instead for app developers.

Staked Connections
Staked Connections help you land transactions faster with an increased land rate. Helius provides two methods to access staked connections with any standard paid plan (not available on Dedicated Nodes).

Shared Staked Endpoint (default)

Requirements:

Priority fees meet or exceed the recommended value provided by the Priority Fee API

Set maxRetries to 0

Endpoint: https://mainnet.helius-rpc.com/?api-key=xxx

Cost: 1 credit per request

Tips:

Check if you're getting staked connections by logging the X-Helius-ConnectionType response header. The valu


[User] What is the significance of the 'state' field in the account information provided in the snippet?

[Assistant]
The 'state' field in the account information snippet indicates the current status of the account. In the provided example, the state is set to "initialized," which signifies that the account has been created and is ready for use. This state is important as it helps determine the account's readiness for transactions or other operations within the blockchain environment.

Other potential states (not explicitly mentioned in the snippet) could include statuses like "uninitialized," which would indicate that the account has not been set up for use yet. Understanding the state of an account is crucial for developers and users to ensure that they are interacting with accounts that are in the appropriate condition for their intended operations.

                "uiAmountString": "0.1"
                },
                "delegate": "4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T",
                "delegatedAmount": {
                  "amount": "1",
                  "decimals": 1,
                  "uiAmount": 0.1,
                  "uiAmountString": "0.1"
                },
                "state": "initialized",
                "isNative": false,
                "mint": "3wyAj7Rt1TWVPZVteFJPLa26JmLvdb1CAKEFZm3NY75E",
                "owner": "CnPoSPKXu7wJqxe59Fs72tkBeALovhsCxYeFwPCQH9TD"
              },
              "type": "account"
            },
            "space": 165
          },
          "executable": false,
          "lamports": 1726080,

getinflationgovernor
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.getInflationGovernor()

await tatum.destroy() // Destroy Tatum SDK - needed for stopping background jobs
Overview
The getInflationGovernor method is used to retrieve the current inflation governor in the Solana blockchain.

Parameters
options (object, optional): Configuration object containing the following fields:
commitment(string, optional): Specifies the level of commitment to apply when fetching data.
Values: fina


[User] What type of object is returned as part of the RpcResponse in the getRecentBlockhash method in Solana?

[Assistant]
The `getRecentBlockhash` method in Solana returns an `RpcResponse` containing a JSON object. This JSON object consists of the following fields:

- `blockhash`: A string representing a Hash as a base-58 encoded string.
- `feeCalculator`: An object of type `FeeCalculator`, which includes the fee schedule for the block hash.

The complete structure of the response can be summarized as follows:

```json
{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": <number>
    },
    "value": {
      "blockhash": <string>,
      "feeCalculator": <object>
    }
  },
  "id": <number>
}
```

Here, the `value` field contains the `blockhash` and `feeCalculator` as specified.

 296
    }
  },
  "id": 1
}

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

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

Parameters #
string required

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

object optional

Configuration object containing the following fields:

commitment string optional

Result #
An RpcResponse containing a JSON object consisting of a string blockhash and FeeCalculator JSON object.

RpcResponse<object> - RpcResponse JSON object with value field set to a JSON object including:
blockhash: <string> - a Hash as base-58 encoded string
feeCalculator: <object> - FeeCalculator object, the fee schedule for this block hash
Code sample #
curl https://api.devnet.solana.com -s -X POST -H "Content-Type: application/json" -d '
  {"jsonrpc":"2.0","id":1, "method":"getRecentBlockhash"}
'

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

getSignatureConfirmation RPC Method
Edit Page
Fetch the current status of a transaction signature (processed, confirmed, finalized).

Deprecated Method
This method is expected to be removed in solana-core v2.0. Plea


[User] What is the significance of the inflationary issuance in Solana's protocol-based rewards system?

[Assistant]
The inflationary issuance in Solana's protocol-based rewards system is significant for several reasons:

1. **Incentivization of Participation**: The inflationary rewards are designed to incentivize validation clients to participate in the network. By providing rewards based on a predefined issuance schedule, it encourages validators to contribute to the security and operation of the network.

2. **Economic Stability**: The protocol-based rewards, derived from inflation, help maintain a predictable supply of tokens. This predictability is crucial for long-term economic stability, as it allows participants to understand the potential rewards for their contributions over time.

3. **Support for Network Security and Decentralization**: By aligning participant incentives with the security and decentralization of the network, inflationary issuance plays a critical role in ensuring that enough validators are active and engaged. This is essential for maintaining the integrity and robustness of the Solana blockchain.

4. **Distribution Mechanism**: The rewards generated from inflation are calculated per epoch and distributed among the active delegated stake and validator set. This mechanism ensures that rewards are fairly allocated based on each validator's commission and their contribution to the network.

Overall, the inflationary issuance is a foundational aspect of Solana's economic model, promoting active participation, ensuring stability, and supporting the network's security and decentralization.

-economic system is designed to promote a healthy, long term self-sustaining economy with participant incentives aligned to the security and decentralization of the network. The main participants in this economy are validation-clients. Their contributions to the network, state validation, and their requisite incentive mechanisms are discussed below.

The main channels of participant remittances are referred to as protocol-based rewards and transaction fees. Protocol-based rewards are generated from inflationary issuances from a protocol-defined inflation schedule. These rewards will constitute the total protocol-based reward delivered to validation clients, the remaining sourced from transaction fees. In the early days of the network, it is likely that protocol-based rewards, deployed based on predefined issuance schedule, will drive the majority of participant incentives to participate in the network.

These protocol-based rewards are calculated per epoch and distributed across the active delegated stake and validator set (per validator commission). As discussed further below, the per annum inflation rate is based on a pre-determined disinflationary schedule. This provides the network with supply predictability which supports long term economic stability and security.

Transaction fees are participant-to-participant transfers, attached to network interactions as a motivation and compensation for the inclusion and execution of a proposed transaction. A mechanism for long-term


[User] In what scenarios might access to Jupiter's Interface or Protocol become degraded or unavailable?

[Assistant]
Access to Jupiter's Interface or Protocol may become degraded or unavailable in several scenarios, including:

1. **Technical Interruptions**: Any unexpected technical issues or failures in the system can lead to degraded performance or complete unavailability.

2. **Network Congestion/Failure**: High traffic or congestion on the network can hinder the ability to access the Interface or Protocol effectively.

3. **Security Vulnerabilities**: If there are identified security issues, access may be restricted to protect users and the system.

4. **Cyberattacks or Malicious Activity**: Any form of cyberattack, such as Distributed Denial of Service (DDoS) attacks, can disrupt access to the Interface or Protocol.

5. **Significant Volatility or Volume**: During periods of high market volatility or transaction volume, access to the Interface or Protocol may be degraded or unavailable.

In these scenarios, users may experience delays in support response times and may not be able to interact with third-party services as expected.

 any reason.

The Interface and the Protocol may rely on or utilise a variety of external third party services or software, including without limitation oracles, decentralised cloud storage services, analytics tools, hence the Interface or the Protocol may be adversely affected by any number of risks related to these third party services/software. These may include technical interruptions, network congestion/failure, security vulnerabilities, cyberattacks, or malicious activity. Access to the Interface or the Protocol may become degraded or unavailable during times of significant volatility or volume. This could result in the inability to interact with third-party services for periods of time and may also lead to support response time delays. The Company cannot guarantee that the Interface or the Protocol will be available without interruption and neither does it guarantee that requests to interact with third-party services will be successful. You agree that you shall not hold the Company responsible for any losses which occur due to any of the foregoing.

4. Your Use of Interface
By using or accessing the Interface, you represent and warrant that you understand that there are inherent risks associated with virtual currency, and the underlying technologies including, without limitation, cryptography and blockchain, and you agree that Jupiter is not responsible for any losses or damages associated with these risks. You specifically acknowledge and agree that the Interface fac


[User] What do I receive for a LONG-position when I close it successfully in Jupiter?

[Assistant]
When you close a LONG-position successfully in Jupiter, you will receive the underlying asset associated with that position. Specifically, you will receive:

- SOL for a SOL-Long position
- ETH for an ETH-Long position
- wBTC for a wBTC-Long position

This means that the asset you receive corresponds directly to the type of LONG position you had opened.

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

Frequently Asked Questions
1. I tried opening a position/adding collateral and it was not successful. Where are my funds?
Under normal circumstances, funds will be returned to your wallet in about 1-2 minutes. During periods of congestion on the Solana network there might be a delay for your funds to be returned to your wallet. If this is the case, you can close your expired request under the Expired Orders tab.

Follow these steps on how to find your funds.
Go to the Transaction ID
Returned1

Scroll down to CreateIncreasePositionMarketRequest
Returned2

Click on Position Request address
Returned3

Click on the latest successful transaction
Returned4

You could find your returned fund here:
For SOL, check SOL Balance Change tab

Returned5

For ALL other token, check Token Balance Change tab

Returned6

info
Wallet service providers might not be fully parsing the transactions, so, it is always a better idea to check on-chain. If you still couldn’t locate your fund although it was shown that it’s returned on the explorers, please contact your wallet service provider accordingly.

2. I closed my position with profit and I have not received my funds.
You will receive the underlying asset for a LONG-position, i.e. SOL for SOL-Long, ETH for ETH-Long, wBTC for wBTC-Long.

You will receive either USDC or USDT for all SHORT-positions.

Perform these steps to check for funds from closed positions.
Under


[User] Which API key is required to access the CoinGecko Pro API?

[Assistant] To access the CoinGecko Pro API, you need to use the `x-cg-pro-api-key` as your API key. This key is required for authentication when making requests to the Pro API endpoints. Make sure to log in to obtain your API keys before making any requests.

ty (auto):
1 day from now = hourly data
2 days & above from now = daily data
Exclusive for all Paid Plan Subscribers (Analyst, Lite, Pro and Enterprise)
The last completed UTC day (00:00) is available 5 minutes after midnight on the next UTC day (00:05). The cache will always expire at 00:05 UTC. If you wish to get the latest daily data (00:00 UTC), you can make request at 00:05 UTC or later.
Cache / Update Frequency: every 1 minute
Query Params
days
string
required
data up to number of days ago
Valid values: any integer

1
vs_currency
string
target currency of market cap, default: usd
*refers to /simple/supported_vs_currencies

Response

200
Get cryptocurrency global market cap chart data

Response body
object
market_cap_chart
object
market_cap
array of arrays of numbers
array of numbers
Updated 4 months ago

Global De-Fi Market Data
Companies (Beta)
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
Credentials
x-cg-pro-api-key

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

Try It!
RESPONSE
1
{
2
  "market_cap_chart": {
3
    "market_cap": [
4
      [
5
        1367193600000,
6
        1661441770
7
      ],
8
      [
9
        1367280000000,
10
        1592765051
11
      ],
12
      [
13
        1367366400000,
14
        1378705103
15
      ]
16
    ]
17
  }
18
}

Public Companies Holdings
get
https://pro-api.coingecko.com/ap


[User] What are the implications of using the Bid-Ask strategy in terms of rebalancing frequency for LPs on Meteora?

[Assistant]
The Bid-Ask strategy in Meteora is characterized by an allocation of capital primarily towards both ends of the price range, which is the inverse of the Curve strategy. This approach is designed to capture larger volatility swings away from the current price.

However, one of the key implications of using the Bid-Ask strategy is that it may require more frequent rebalancing compared to other strategies, such as Spot. The increased complexity of the Bid-Ask strategy means that liquidity providers (LPs) need to actively manage their positions to ensure they remain effective. This frequent rebalancing is necessary to adapt to market conditions and to maximize fee capture during periods of significant price fluctuations.

In summary, while the Bid-Ask strategy has the potential for high fee capture during volatile market conditions, LPs should be prepared for the necessity of more regular adjustments to their positions to maintain optimal performance.

ided for a DCA in or out strategy. It can be used to capture volatility in a stable or pegged pair.

Take note that it is important for LPs to closely monitor their positions and adjust accordingly to market conditions to manage the risk of impermanent loss.

Read more details on:
DLMM Strategies & Use Cases

DLMM FAQ

Alpha Vault for DLMM

DLMM Strategy Sessions / Jam Sessions

Strategies & Use Cases
Through allocating different amounts of tokens at diverse price points, we are able to build a desired liquidity shape with the DLMM that best fits our LP goals.

Spot: Provides a uniform distribution of liquidity that is flexible and suitable for any type of market and conditions. It is the most straightforward volatility strategy to deploy for new LPs who want to rebalance their position less frequently. This is similar to setting a CLMM price range.

Curve: Ideal for a concentrated approach that aims to maximize capital efficiency by allocating capital mostly in the middle of your price range. This is great for stables or pairs where the price does not change very often.

Bid-Ask: Bid-Ask is an inverse Curve distribution, where most of your capital is allocated towards both ends of the range. This strategy can be used to capture bigger volatility swings away from the current price. Bid-Ask is more complex than Spot and may require more frequent rebalancing to be effective, but has a high potential for fee capture during situations where prices fluctuate wildly around the cur


[User] What happens to the wSOL received from swaps when wSOL mode is active on Jupiter?

[Assistant]
When wSOL mode is active on Jupiter, all trades will transact in wSOL instead of SOL by default. This means that when you execute swaps, the wSOL received will not be automatically unwrapped to native SOL. You will retain the wSOL in your wallet, and it will remain in that form until you decide to manually unwrap it back to SOL.

In summary, with wSOL mode enabled:
- Trades are conducted in wSOL.
- wSOL received from swaps is not automatically unwrapped.
- You have the option to manually wrap SOL into wSOL or unwrap wSOL back to SOL.

wSOL disabled and/or off)
The regular mode that most users will experience is where the wSOL feature is disabled and/or off. There is no difference to the day-to-day trades that you are currently doing - for any transactions involving SOL, Jupiter will automatically do the wrapping and unwrapping of wSOL behind the scenes to facilitate your token swaps.

info
Jupiter will still be able to detect if you have wSOL and provide an option to unwrap it back to SOL.

wSOL mode (wSOL enabled and switched on)
The wSOL mode is for advanced users who are familiar dealing with the wSOL token and wish to experience better performance and control for their swaps.

With wSOL switched on, all trades will transact in wSOL instead of SOL by default. This means that so long you have sufficient wSOL, you can immediately execute your swaps. The wSOL received will also not be automatically unwrapped to native SOL.
You will be able to manually wrap SOL and unwrap wSOL.
wSOL2

Wrap SOL - wSOL feature
Easily wrap SOL into wSOL by either clicking on "Manage" or "Wrap SOL now" link in wSOL enabled mode.
Unwrap wSOL feature
Our unwrap wSOL feature currently only processes unwrapping of all existing wSOL in your wallet to SOL, we do not support partial unwrapping.
To read more about closing SOL accounts, click here.

Frequently Asked Questions
Jupiter Swap Aggregator
Does Jupiter swap charge any fees?
Jupiter does not charge any fees, the transaction fees that you see in the details, are the Solana fees


[User] What is the significance of the ed25519 public key in the context of Solana accounts?

[Assistant]
In the context of Solana accounts, the ed25519 public key serves as the address for a normal account. This public key is a 256-bit value that is Base58-encoded, allowing it to be represented as a string. The significance of the ed25519 public key in Solana includes the following points:

1. **Account Identification**: Each account on the Solana blockchain is uniquely identified by its ed25519 public key. This means that all transactions and interactions with an account are associated with this specific public key.

2. **Security**: The ed25519 public key is part of a cryptographic system that ensures the security of transactions. It is derived from a private key, and only the holder of the corresponding private key can sign transactions, providing a secure way to manage account ownership and authorization.

3. **Validation**: Not all bit patterns are valid public keys for the ed25519 curve. Therefore, it is essential to validate user-supplied addresses to ensure they are correct ed25519 public keys. This helps prevent errors and potential security issues when interacting with accounts.

4. **Interoperability**: The use of a standardized public key format (ed25519) allows for interoperability within the Solana ecosystem and with other systems that utilize the same cryptographic standards.

In summary, the ed25519 public key is crucial for identifying, securing, and validating accounts on the Solana blockchain, ensuring that only authorized users can perform actions associated with those accounts.

intentions if a non-zero balance is discovered.

Valid ed25519 pubkey check #
The address of a normal account in Solana is a Base58-encoded string of a 256-bit ed25519 public key. Not all bit patterns are valid public keys for the ed25519 curve, so it is possible to ensure user-supplied account addresses are at least correct ed25519 public keys.

Java #
Here is a Java example of validating a user-supplied address as a valid ed25519 public key:

The following code sample assumes you're using the Maven.

pom.xml:

<repositories>
  ...
  <repository>
    <id>spring</id>
    <url>https://repo.spring.io/libs-release/</url>
  </repository>
</repositories>

...

<dependencies>
  ...
  <dependency>
      <groupId>io.github.novacrypto</groupId>
      <artifactId>Base58</artifactId>
      <version>0.1.3</version>
  </dependency>
  <dependency>
      <groupId>cafe.cryptography</groupId>
      <artifactId>curve25519-elisabeth</artifactId>
      <version>0.1.0</version>
  </dependency>
<dependencies>

import io.github.novacrypto.base58.Base58;
import cafe.cryptography.curve25519.CompressedEdwardsY;

public class PubkeyValidator
{
    public static boolean verifyPubkey(String userProvidedPubkey)
    {
        try {
            return _verifyPubkeyInternal(userProvidedPubkey);
        } catch (Exception e) {
            return false;
        }
    }

    public static boolean _verifyPubkeyInternal(String maybePubkey) throws Exception
    {
        byte[] bytes = Base58.base58Decode(mayb


[User] Is it possible to use the QuickNode API without having an account, and what does the documentation suggest for new users?

[Assistant]
According to the documentation, you cannot use the QuickNode API without having an account. It explicitly states, "Don't have an account yet? Create your QuickNode endpoint in seconds and start building." This indicates that an account is required to access the API and utilize its features.

For new users, the documentation suggests creating an account to get started. It encourages users to "Get started for free," implying that there is a free tier available for new users to explore the QuickNode services.

olana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc": "2.0","id": 1,"method": "getAssetProof","params": {"id": "D85MZkvir9yQZFDHt8U2ZmS7D3LXKdiSjvw2MBdscJJa"}}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getAssets
Next
getAssetProofs
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
getAssetProofs RPC Method
Returns the merkle tree proof information for compressed assets. The API credit value for this method is 60.
Updated on
Oct 23, 2024
Please note that this RPC method requires the Solana DAS (Digital Asset Standard) API add-on enabled on your QuickNode endpoint.
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
ids
array of strings
REQUIRED
The ids of the assets
Returns
result
array of objects
An array of objects containing the merkle tree proof infor


[User] What should LPs in Meteora understand about holding tokens separately versus depositing them in a pool?

[Assistant]
Liquidity Providers (LPs) in Meteora should understand the concept of impermanent loss (IL) when deciding between holding tokens separately or depositing them in a liquidity pool.

Impermanent loss occurs when the relative price of the tokens in the pool changes, leading to a situation where the value of the LP's initial token deposit becomes less than if they had simply held the tokens outside of the pool. This is particularly relevant in traditional (constant product) liquidity pools.

For example, if an LP deposits tokens A and B into a liquidity pool and the value of token A increases significantly against token B, the LP will end up with a larger quantity of token B and a reduced quantity of token A when they withdraw their liquidity. As a result, the total value of their holdings may be lower compared to if they had held onto the tokens separately without depositing them in the pool.

In summary, LPs must consider the risk of impermanent loss when providing liquidity, as it can impact their overall returns compared to simply holding their tokens. Understanding this risk is crucial for effective liquidity management in Meteora.

oadcasts/1RDGllnNWNEGL

Day 2: https://twitter.com/MeteoraAG/status/1779177132478128131

Day 3: https://twitter.com/MeteoraAG/status/1779541597568586119

Boot Camp #2
Day 1: https://x.com/MeteoraAG/status/1781714717276586143

Day 2: https://x.com/MeteoraAG/status/1782075825443254567

Boot Camp #3
Day 1: https://x.com/MeteoraAG/status/1786786461813268637

Day 2: https://x.com/MeteoraAG/status/1787150160268833274

Boot Camp #4
Day 1: https://x.com/MeteoraAG/status/1796922782691074112

Day 2: https://x.com/MeteoraAG/status/1797280928164876750

Boot Camp #5
Day 1: https://x.com/MeteoraAG/status/1814663188883120188

Day 2: https://x.com/MeteoraAG/status/1815024510116258208

Boot Camp #6
Day 1: https://x.com/i/broadcasts/1djGXrmmNEdxZ

Day 2: https://x.com/i/broadcasts/1OwxWNmqDzmJQ

Boot Camp #7
Day 1: https://x.com/MeteoraAG/status/1837447097760862711

Day 2: https://x.com/MeteoraAG/status/1837809490311500294

isk of Impermanent Loss (IL)
Impermanent loss, also called divergence loss, is the most common liquidity provider risk associated with traditional (constant product) liquidity pools. It occurs when the relative price of the tokens in the pool changes and the value of the LP’s initial token deposit in the pool becomes less compared to holding the tokens separately without depositing them in a pool. LPs must learn to manage IL.

Consider a scenario where you LP into an A/B pool and the value of token A increases against token B; you will end up with more of token B and l


[User] How does the locking of liquidity in Meteora benefit traders and liquidity providers?

[Assistant]
Locking liquidity in Meteora benefits both traders and liquidity providers in several ways:

1. **Increased Confidence for Traders**: When liquidity is permanently locked, it assures traders that the project is committed to its longevity. This builds trust and encourages more trading activity, as traders feel safer knowing that the liquidity is not subject to sudden withdrawals by the project team.

2. **Earning Fees from Locked Liquidity**: Liquidity providers can earn fees from the permanently locked liquidity. When a liquidity provider creates a new memecoin pool, the liquidity they provide is automatically sent to a lock token account, ensuring it is permanently locked. Despite being locked, the liquidity provider can still claim fees and yield from this liquidity indefinitely. This creates a financial incentive for liquidity providers to contribute to the pool, as they can benefit from trading volume without needing to sell their allocations.

3. **Long-term Alignment**: By allowing projects to lock up more or all of their supply and earn fees through trading volume, there is a stronger alignment between the interests of the project and its holders. This can lead to more sustainable growth for memecoins, as projects are incentivized to focus on increasing trading volume rather than liquidating their holdings for funding.

4. **Immediate Fee Capture**: If a project locks liquidity before the pool starts trading, they can capture swap fees from the moment trading begins. This ensures that the project can start benefiting from trading activity right away, further incentivizing them to maintain a healthy trading environment.

In summary, locking liquidity enhances trust among traders, provides ongoing financial benefits to liquidity providers, and fosters a sustainable ecosystem for memecoins on Meteora.

emecoin discoverability by traders, bots, and LPs.

Note: Currently, only the memecoin-type Dynamic Pools have Dynamic Fee and Protocol Fee. And only the Meteora team is able to change these fees; projects have no backend access.

How Memecoin Pool Fees Work
Claim fees from permanently-locked liquidity
Memecoin projects permanently lock liquidity to give traders confidence. However, on most DEX platforms, fees earned by this liquidity are lost, limiting a project's financial options.

On Meteora, when a liquidity provider creates a new memecoin pool, the liquidity provided is automatically sent to a lock token account to be permanently locked. Fees and yield are still claimable by the liquidity provider (the wallet that provided the liquidity) forever.

By allowing creators to earn fees from locked liquidity, a creator can choose to lock up more or all of the supply and earn fees by growing volume instead of selling allocations as a source of funding. We believe this will help more memecoins improve and grow over the long-run by creating long-term alignment between projects and holders.

Important reminder
If the project wants to permanently lock liquidity in the Memecoin pool, they should ideally lock the liquidity BEFORE the pool starts trading, so that swap fees from locked liquidity are captured the second trading starts.

In a scenario where:

The pool started trading - t0

Liquidity gets deposited to the pool by the project, but not locked - t1

Subsequently, that li


[User] How can I retrieve the hourly borrow rates for JLP assets in Jupiter?

[Assistant]
To retrieve the hourly borrow rates for JLP assets in Jupiter, you can use one of the following methods:

1. **From the Trade Form**: You can find the hourly borrow rates in the Borrow rate field of the Jupiter Perpetuals trade form.

2. **On-chain Data**: You can also fetch the hourly borrow rates on-chain by accessing the `funding_rate_state.hourly_funding_dbps` field of the custody account. This field represents the hourly borrow rates in basis points.

Here’s a brief example of how you might access the on-chain data:

```javascript
// Access the custody account's funding rate state
const hourlyFundingDbps = custody.fundingRateState.hourlyFundingDbps;

// Convert basis points to percentage
const hourlyBorrowRatePercentage = hourlyFundingDbps / 1000;
```

This code snippet retrieves the hourly borrow rate in basis points and converts it to a percentage for easier interpretation.

unt of tokens locked across all open positions
Total Tokens in Pool: The amount of tokens deposited into the pool for the position's underlying token
Hourly Borrow Rate: The base rate for the hourly borrow fees (calculation shown below)
Position Size: The size (USD) of the leveraged position
hourly-borrow-fee

info
The hourly borrow rates for JLP assets can be retrieved from the Borrow rate field of the Jupiter Perpetuals trade form or fetched onchain via the custody account's funding_rate_state.hourly_funding_dbps field. Note that these rates represent the maximum charged at 100% utilization.

Calculating Utilization Rate
To determine the current utilization rate, access the asset's on-chain account (as shown here) and apply the following calculation:

// Calculate utilization percentage
if (custody.assets.owned > 0 AND custody.assets.locked > 0) then
    utilizationPct = custody.assets.locked / custody.assets.owned
else
    utilizationPct = 0

// Get hourly funding rate in basis points
hourlyFundingDbps = custody.fundingRateState.hourlyFundingDbps

// Convert basis points to percentage and apply utilization
hourlyBorrowRate = (hourlyFundingDbps / 1000) * utilizationPct

info
Read more about how the base rate for each token is decided from Gauntlet's recommendations.

Worked Example
For example, assume the price of SOL is $100. The SOL liquidity pool has 1,000 SOL under custody and has lent out 100 SOL (i.e, utilization is 10%). A trader opens a 100 SOL position with an init


[User] How can I query exchanges and NFT data using CoinGecko?

[Assistant]
To query exchanges and NFT data using CoinGecko, you can utilize specific endpoints provided by the CoinGecko API. Here’s how you can do it:

### Querying Exchange Data

To get information about exchanges, you can use the `/exchanges` endpoint. This endpoint provides a list of all exchanges along with their details.

**Example Request:**
```plaintext
GET https://pro-api.coingecko.com/api/v3/exchanges?x_cg_pro_api_key=YOUR_API_KEY
```

This request will return a list of exchanges with their respective data.

### Querying NFT Data

For NFT data, you can use the `/nfts` endpoint. This endpoint allows you to retrieve information about NFTs available on various platforms.

**Example Request:**
```plaintext
GET https://pro-api.coingecko.com/api/v3/nfts?x_cg_pro_api_key=YOUR_API_KEY
```

This request will return a list of NFTs along with their details.

### Summary

- Use the `/exchanges` endpoint to get exchange data.
- Use the `/nfts` endpoint to retrieve NFT data.
- Make sure to include your API key in the request for authentication.

By following these examples, you can successfully query exchanges and NFT data from CoinGecko.

ion attributable to a specific token across all available pools.

⏱ 10-mins Tutorial Guide
New to CoinGecko API? Fret not. Whether you’re a programmer or someone with zero coding experience, we’ve got you covered!

If you are not a developer and prefer to learn only specific tutorials on Google Sheet/Excel, feel free to check 👶 Tutorials (Beginner-friendly)

Tutorial Steps	Description
1. Get data by ID or Address	Learn how to use different endpoints by obtaining Coin ID and token's contract address at first
2. Get Historical Data	Learn how to get historical data of a coin by using different historical endpoints
3. Get Exchanges & NFT Data	Learn how to query exchanges and NFT data by accessing different endpoints
4. Get On-Chain Data	Learn how to use on-chain/ GT endpoints to query on-chain data
Updated 11 months ago

👀 Common Use Cases
1. Get data by ID or Address
Did this page help you?

. Get data by ID or Address
Methods to query price & market data of coins
a. Coin ID
Using /simple/price endpoint as example:

https://pro-api.coingecko.com/api/v3/simple/price?ids=bitcoin&vs_currencies=usd&x_cg_pro_api_key=YOUR_API_KEY

The provided endpoint URL includes parameters such as ids=bitcoin and vs_currencies=usd, indicating that the intention to retrieve the current price of Bitcoin in US Dollars.

How to obtain Coin ID aka API ID? There are 3 options:

Use /coins/list endpoint

Example of responses:

json

[
  ......
  {
  "id": "bitcoin", 👈
  "symbol": "btc",
  "name": "Bitcoi


[User] How does Solana handle cross-program invocations in terms of call depth limits?

[Assistant]
In Solana, cross-program invocations (CPI) allow programs to invoke other programs directly. However, there is a constraint on the call depth for these invocations. The maximum allowed depth for cross-program invocations is currently limited to 4 frames.

If a program exceeds this allowed call depth limit during a cross-program invocation, it will receive a `CallDepth` error. This ensures that the execution remains efficient and does not lead to excessive resource consumption.

Here is a simple example of how a cross-program invocation might be structured in Rust:

```rust
// Example of a cross-program invocation in Solana
use solana_program::program::invoke;
use solana_program::pubkey::Pubkey;

pub fn call_other_program(
    other_program_id: &Pubkey,
    accounts: &[AccountInfo],
    data: &[u8],
) -> ProgramResult {
    // Invoke another program
    invoke(
        &Instruction::new_with_bytes(*other_program_id, data, accounts.to_vec()),
        accounts,
    )?;
    Ok(())
}
```

In this example, the `invoke` function is used to call another program, but care must be taken to ensure that the total depth of calls does not exceed the limit of 4 frames to avoid a `CallDepth` error.

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 programs are constrained to run quickly, and to facilitate this, the program's call stack is limited to a max depth of 64 frames.

When a program exceeds the allowed call stack depth limit, it will receive the CallDepthExceeded error.

CPI call depth - CallDepth error #
Cross-program invocations allow programs to invoke other programs directly, but the depth is constrained currently to 4.

When a program exceeds the allowed cross-program invocation call depth, it will receive a CallDepth error

Float Rust types support #
Programs support a limited subset of Rust's float operations. If a program attempts to use a float operation that is not supported, the runtime will report an unresolved symbol error.

Float operations are performed via software libraries, specifically LLVM's float built-ins. Due to the software emulated, they consume more compute units than integer operations. In general, fixed point operations are recommended where possible.

The Solana Program Library math tests will report the performance of some math operations. To run the test, sync the repo and run:

cargo test-sbf -- --nocapture --test-threads=1

Recent results show the float operations take more instructions compared to integers equivalents. Fixed point implementations may vary but will also be less than


[User] What is the significance of the 'limit' and 'offset' parameters in the Magic Eden API request?

[Assistant]
In the Magic Eden API request, the `limit` and `offset` parameters are used for pagination when retrieving listings or data.

- **limit**: This parameter specifies the maximum number of results to return in a single response. For example, if you set `limit=100`, the API will return up to 100 results.

- **offset**: This parameter determines the starting point from which to return results. It allows you to skip a certain number of results before starting to return data. For instance, if you set `offset=0`, the API will start returning results from the very first entry. If you set `offset=100`, it will skip the first 100 results and start returning from the 101st result onward.

Together, these parameters enable you to control the amount of data you retrieve and navigate through large datasets efficiently.

### Example
Here’s a sample API request using both parameters:

```shell
curl --request GET \
     --url 'https://api-mainnet.magiceden.dev/v2/ord/btc/raresats/listings?sortBy=priceAsc&limit=100&offset=0' \
     --header 'accept: application/json'
```

In this example, the request is set to return the first 100 listings sorted by price in ascending order. If you wanted the next set of results, you could change the `offset` to 100:

```shell
curl --request GET \
     --url 'https://api-mainnet.magiceden.dev/v2/ord/btc/raresats/listings?sortBy=priceAsc&limit=100&offset=100' \
     --header 'accept: application/json'
```

This would return the next 100 listings, allowing you to paginate through the results.

Price
integer
Filter by minimum listed price in satoshis

maxPrice
integer
Filter by maximum listed price in satoshis

minUtxoSize
integer
Filter by minimum utxo size in satoshis

maxUtxoSize
integer
Filter by maximum utxo size in satoshis

minSatRange
integer
Filter by minimum sat range in sats

maxSatRange
integer
Filter by maximum sat range in sats

minBlockNumber
integer
Filter listings that only contain sats that were created after the given block number

maxBlockNumber
integer
Filter listings that only contain sats that were created before the given block number

minBlockTimestamp
integer
Filter listings that only contain sats that were created after the given timestamp

maxBlockTimestamp
integer
Filter listings that only contain sats that were created before the given timestamp

Response

200
Successful response

Updated 10 months ago

Get tokens
Get Rare Sats by Address
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request GET \
2
     --url 'https://api-mainnet.magiceden.dev/v2/ord/btc/raresats/listings?sortBy=priceAsc&limit=100&offset=0' \
3
     --header 'accept: application/json'

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

200

Get Rare Sats by Address
get
https://api-mainnet.magiceden.dev/v2/ord/btc/raresats/wallet/utxos
Get Rare Sats by Address

Log in to see full request history
time	status	user agent
Make a request to see history.

Query Params
walletAddress


[User] How can I remove the unknown tag from my token on Jupiter's lists?

[Assistant]
To remove the unknown tag from your token on Jupiter's lists and get it onto the Jupiter Strict Token List, you will need to follow the verification process outlined in the documentation.

Here’s a brief overview of the steps you should take:

1. **Verification Submission**: You need to submit a request for your token to be verified. This typically involves providing details about your token and ensuring that it meets the necessary criteria set by Jupiter.

2. **Compliance with Standards**: Ensure that your token complies with the standards required by Jupiter. This may include having a clear and accessible project website, a functioning community, and proper documentation.

3. **Follow Up**: After submission, keep an eye on any communications from the Jupiter team regarding the status of your token verification.

For more detailed instructions on how to get your token verified and routed on Jupiter, you can refer to the documentation provided by Jupiter.

prevent potential frontrunning .
For more information on how Jupiter DCA works - How DCA Works
Jupiter Space Station
How do I add my protocol / project into Jupiter Space Station partners page?
To add your protocol or project into Jupiter Station partners page, simply submit a PR to our Space Station public repo and share a little about how you utilizing or integrating Jupiter.
Here is a sample PR - https://github.com/jup-ag/space-station/pull/98
Can I contribute to Jupiter Space Station? If yes, how?
Yes, we welcome anyone to contribute and help us improve Space Station alongside with us.
You can submit a PR to our Space Station public repo, it can be in the form of updating some misinformation / outdated information that we have in Space Station, or you can come up with a community guide to help users and community members to navigate around the Solana ecosystem. Here is an example done by SolanaFM on How to verify swaps using block explorer
New Token & Token Validation
How do I get my new project token to be available to trade on Jupiter?
All new tokens on supported AMMs are instantly routed on Jupiter for 14 days, and are marked with a '⚠’ label to encourage users to double-check that the mint addresses are the right ones before trading.
Learn more about how to get your token verified and routed on Jupiter here.
How do I get my new token to the strict list / remove the unknown tag?
To get on to the Jupiter Strict Token List/ removing the unknown token tag through our pub


[User] How does Magic Eden handle message signing after the user has connected their wallet?

[Assistant]
After a user has connected their wallet to the Magic Eden application, message signing can be handled using the `provider.request` function. This allows the application to prompt the user to sign messages, which is a common practice among decentralized applications (dApps). Signing messages helps verify ownership of the wallet without incurring transaction fees.

Here’s how you can implement message signing after the wallet connection:

1. **Connect the Wallet**: First, ensure that the wallet is connected using the `eth_requestAccounts` method.
2. **Prepare the Message**: Create the message that you want the user to sign.
3. **Sign the Message**: Use the `personal_sign` method to prompt the user to sign the prepared message.

Here’s a code example demonstrating this process:

```javascript
const connect = async () => {
  if (!provider) return;
  try {
    const accounts = await provider.request({ method: "eth_requestAccounts" });
    const address = accounts[0]; // Get the connected address

    // Prepare the message to be signed
    const message = "Hello, World! 🌍 Welcome to the Magic Eden wallet on Ethereum";
    const msg = "0x" + Array.from(message)
      .map((c) => c.charCodeAt(0).toString(16).padStart(2, "0"))
      .join("");

    // Sign the message
    const sign = await provider.request({
      method: "personal_sign",
      params: [msg, address, "Example password"],
    });

    console.log("Signed Message:", sign);
    // You can now use the signed message for verification or other logic
  } catch (err) {
    console.error(err);
  }
};
```

In this example:
- The `connect` function connects to the wallet and retrieves the user's address.
- A message is prepared and converted into a hexadecimal format.
- The `personal_sign` method is called to prompt the user to sign the message, and the signed message is logged for further use.

This approach allows the application to verify that the user owns the wallet associated with the signed message.

he default way to prompt a connection with a user's ME wallet is with the window.ethereum.request function and passing in the eth_requestAccounts method.

Copy
const connect = async () => {
  if (!provider) return;
  try {
    const accounts = await provider.request({ method: "eth_requestAccounts" });
    console.log(accounts[0]);
    // 0x6aDdF38602487b7a159D926bc08151eBaEEF2B70

    // do some logic here to update your app context with the connected account
  } catch (err) {
      console.error(err);
  }
};
The eth_requestAccounts method will return a Promise that resolves into an array where the connected address is at the 0th index.

Signing a Message
Once a web application has connected to the ME Ethereum wallet, it can prompt users to sign messages. Signing is commonplace amongst many dApps, as it gives application owners the ability to verify ownership of the wallet, without requiring any transaction fees.

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

Copy
const message =
	"Hello, World! 🌍 Welcome to the Magic Eden wallet on Ethereum";

// can also use Buffer.from for a simpler implementation, but polyfills :/
const msg =
	"0x" +
	Array.from(message)
		.map((c) => c.charCodeAt(0).toString(16).padStart(2, "0"))
		.join("");
const sign = await provider.request({
	method: "personal_sign",
	params: [msg, address, "Example password"],
});
Using Ethers.js
Alternatively, you can make use of the popular


[User] Can a user modify or distribute content from Jupiter's Interface without permission?

[Assistant] No, a user cannot modify or distribute content from Jupiter's Interface without permission. According to the documentation, all intellectual property and other rights in the Interface and its contents are owned by Jupiter. Users are expressly prohibited from copying, modifying, adapting, renting, licensing, selling, publishing, distributing, or otherwise permitting any third party to access or use the Interface or any of its contents unless they have been expressly authorized by Jupiter to do so.

r access and use of the Interface. We do not endorse or assume any responsibility for any such resources or promotions. If you access any such resources or participate in any such promotions, you do so at your own risk, and you understand that the Terms do not apply to your dealings or relationships with any third parties. You expressly relieve us of any and all liability arising from your use of any such resources or participation in any such promotions.

7. Intellectual Proprietary Rights
We own all intellectual property and other rights in the Interface and its contents, including, but not limited to, software, text, images, trademarks, service marks, copyrights, patents, and designs. Unless expressly authorized by us, you may not copy, modify, adapt, rent, license, sell, publish, distribute, or otherwise permit any third party to access or use the Interface or any of its contents. Accessing or using the Interface does not constitute a grant to you of any proprietary intellectual property or other rights in the Interface or its contents.

You will retain ownership of all intellectual property and other rights in any information and materials you submit through the Interface. However, by uploading such information or materials, you grant us a worldwide, royalty-free, irrevocable license to use, copy, distribute, publish and send this data in any manner in accordance with applicable laws and regulations.

You may choose to submit comments, bug reports, ideas, or other feedb


[User] Can you provide details on how to create a position using the example codes in Meteora?

[Assistant]
To create a position using the Meteora SDK, you can refer to the example codes provided for key DLMM actions. Below is a general outline of how to create a position based on the information available in the documentation.

### Steps to Create a Position

1. **Install Dependencies**: Ensure you have the necessary SDK dependencies installed. You can do this by running the following command:

   ```bash
   npm i @meteora-ag/dlmm @coral-xyz/anchor @solana/web3.js
   ```

2. **Initialize the DLMM Instance**: Import the DLMM module and create an instance of it in your code.

   ```javascript
   import DLMM from '@meteora-ag/dlmm';

   const dlmm = new DLMM();
   ```

3. **Create a Position**: Use the appropriate function provided in the SDK to create a position. While the exact code for creating a position is not detailed in the snippet, it typically involves calling a method on the `dlmm` instance that handles position creation.

   Here is a hypothetical example of how you might call the function to create a position:

   ```javascript
   const positionData = {
       // Fill in the necessary parameters for the position
       tokenA: 'TOKEN_A_ADDRESS',
       tokenB: 'TOKEN_B_ADDRESS',
       amountA: 100, // Amount of token A
       amountB: 200, // Amount of token B
       // Additional parameters as required
   };

   dlmm.createPosition(positionData)
       .then((result) => {
           console.log('Position created successfully:', result);
       })
       .catch((error) => {
           console.error('Error creating position:', error);
       });
   ```

### Note
- Make sure to replace `'TOKEN_A_ADDRESS'` and `'TOKEN_B_ADDRESS'` with the actual token addresses you are working with.
- The `createPosition` method and its parameters are hypothetical; please refer to the specific SDK documentation or example codes for the exact method and parameters required for creating a position.

For more detailed examples and specific implementations, you can check the example codes for key DLMM actions in the Meteora SDK repository.

: https://github.com/MeteoraAg/dlmm-sdk

Get help on Discord: https://discord.com/channels/841152225564950528/864859354335412224

Logo
GitHub - MeteoraAg/dlmm-sdk: An SDK for building applications on top of Dynamic CLMM
GitHub
List of sections
CPI call example

Rust examples

Example codes for key DLMM actions

Static functions

DLMM instance functions

CPI call example
Access this repo in the SDK, import, CPI:

https://github.com/MeteoraAg/dlmm-sdk/tree/main/programs/lb_clmm

Rust examples
Access these repos in the SDK, import, and use the necessary functions:

https://github.com/MeteoraAg/dlmm-sdk/tree/main/cli

https://github.com/MeteoraAg/dlmm-sdk/tree/main/market_making

Example codes for key DLMM actions
Below we have provided example codes for the key DLMM actions:

Getting the active bin

Creating a position

Getting the list of positions

Adding liquidity to an existing position

Removing liquidity from an existing position

Swapping tokens within a specified pool

We have also provided a list of the necessary static functions and DLMM instance functions. To view other SDK files on github, click here.

Main Steps for SDK testing
Copy
1. cd ts-client
2. anchor localnet -- --features localnet
3. pnpm run test
Install
Install dependencies

You will need to first install these SDK dependencies in order for it to function properly

Copy
npm i @meteora-ag/dlmm @coral-xyz/anchor @solana/web3.js
Initialize DLMM instance

Copy
import DLMM from '@meteora-ag/dlmm'

const USD


[User] What is the format of the transaction signature returned in the subscription object from ChainStack?

[Assistant] The transaction signature returned in the subscription object from ChainStack is provided as a base-58 encoded string. This format is used to represent the signature of the transaction in a way that is both compact and human-readable.

d when querying state. Default is "finalized".
Response
result - An integer subscription id (needed to unsubscribe)
subscription - An object containing log information:
signature - The transaction signature as base-58 encoded string
err - Error if transaction failed, null if transaction succeeded
logs - Array of string log messages
logsSubscribe code examples
This example subscribes to all logs from the pump.fun program.

📘
Note that subscriptions require a WebSocket connection and WebSocket cat for you to use this method in the console.

Install WebSocket cat with:

npm install -g wscat

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":"logsSubscribe","params":[{"mentions":["6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"]},{"commitment":"finalized"}]}
Use case
The logsSubscribe method in Solana is used to subscribe to the network and receive real-time updates on new log messages. This can be useful in various real-world scenarios, including:

Debugging and monitoring: Developers can use this method to receive instant notifications about log messages related to their applications, helping them debug issues and monitor performance in real-time.
Event tracking: dApps can utilize this method to track specific events or actions on the blockchain by subscribing to logs mentioning particular accounts or programs.
Analytics: Blockchain analytics services can use this s


[User] What is the significance of the page parameter in QuickNode's order history response?

[Assistant]
The `page` parameter in QuickNode's order history response is significant because it indicates the current page number of the results being returned. This is particularly important when there are more orders available than can be displayed on a single page, as it allows users to paginate through the order history.

When making a request to the order history endpoint, the `page` parameter can be used to specify which set of results to retrieve. For example, if there are multiple pages of order history, you can increment the `page` parameter to access subsequent pages.

Here’s an example of how to use the `page` parameter in a cURL request:

```bash
curl --location --request GET 'https://public.jupiterapi.com/limit-orders/history?wallet=AEtL29wgARtujVynpgoDtUMLvM7NmZ6WALcjD2NjU8Dk&page=1'
```

In this example, `page=1` retrieves the first page of order history. If you wanted to access the second page, you would change it to `page=2`, and so on. This functionality is crucial for managing large datasets effectively, ensuring that users can navigate through their order history without overwhelming them with too much information at once.

The mint address of the output token
inputAmount
string
The amount of input tokens used in the fill
outputAmount
string
The amount of output tokens received from the fill
feeMint
string
The mint address of the token used for fees
feeAmount
string
The amount of fees charged for the fill
txId
string
The transaction signature for the fill
confirmedAt
string
Timestamp when the fill was confirmed
action
string
The type of action performed (e.g., 'Fill')
productMeta
null
Additional product metadata, if any
hasMoreData
boolean
Indicates if there are more orders available in subsequent pages
page
integer
Current page number of the results
Request

Curl
curl --location --request GET 'https://public.jupiterapi.com/limit-orders/history?wallet=AEtL29wgARtujVynpgoDtUMLvM7NmZ6WALcjD2NjU8Dk&page=1'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
/limit-orders/fee
Next
/ws (Quote 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
Quote RPC Method
Subscribe to receive a notification from the Jupiter API to get the best priced 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 conn


[User] How can I filter tokens by rarity rank using the 'minRarityRank' and 'maxRarityRank' parameters in Magic Eden?

[Assistant]
To filter tokens by rarity rank in Magic Eden, you can use the `minRarityRank` and `maxRarityRank` parameters in your request. These parameters allow you to specify the minimum and maximum rarity ranks for the tokens you want to retrieve.

Here’s how you can use these parameters:

- **`minRarityRank`**: This parameter should be set to an integer value greater than or equal to 1. It filters the tokens to include only those with a rarity rank that is equal to or higher than the specified value.

- **`maxRarityRank`**: This parameter should also be set to an integer value greater than or equal to 1. It filters the tokens to include only those with a rarity rank that is equal to or lower than the specified value.

### Example Request

Here is an example of how you might structure a request to filter tokens by rarity rank:

```json
{
  "minRarityRank": 5,
  "maxRarityRank": 20
}
```

In this example, the request will return tokens that have a rarity rank between 5 and 20, inclusive.

### Important Note
Keep in mind that rarity ranks are not available for collections that have over 100,000 tokens. Therefore, ensure that the collection you are querying falls within this limit to utilize the rarity rank filters effectively.

string
Domain of the order source. Example opensea.io (Only listed tokens are returned when filtering by source)

nativeSource
string
Domain of the order source. Example www.apecoinmarketplace.com. For a native marketplace, return all tokens listed on this marketplace, even if better prices are available on other marketplaces.

minRarityRank
integer
≥ 1
Get tokens with a min rarity rank (inclusive), no rarity rank for collections over 100k

maxRarityRank
integer
≥ 1
Get tokens with a max rarity rank (inclusive), no rarity rank for collections over 100k

minFloorAskPrice
number
Get tokens with a min floor ask price (inclusive); use native currency

maxFloorAskPrice
number
Get tokens with a max floor ask price (inclusive); use native currency

flagStatus
number
Allowed only with collection and tokens filtering!
-1 = All tokens (default)
0 = Non flagged tokens
1 = Flagged tokens

collectionsSetId
string
Filter to a particular collection set. Example: 8daa732ebe5db23f267e58d52f1c9b1879279bcdf4f78b8fb563390e6946ea65

community
string
Filter to a particular community. Example: artblocks

contract
array of strings

ADD string
tokenSetId
string
Filter to a particular token set. Example: token:0xa7d8d9ef8d8ce8992df33d8b8cf4aebabd5bd270:129000685

sortBy
string
Defaults to floorAskPrice
Order the items are returned in the response. Options are floorAskPrice, tokenId, rarity, and updatedAt. No rarity rank for collections over 100k.

floorAskPrice
sortDirection
string

currencies
array


[User] What is the role of `sendAndConfirmTransaction` in the Solana transaction process?

[Assistant]
The `sendAndConfirmTransaction` function in the Solana transaction process is responsible for sending a signed transaction to the Solana network and waiting for confirmation that the transaction has been processed. This function ensures that the transaction is not only sent but also confirmed by the network, providing feedback on whether the transaction was successful or if it failed.

Here’s a breakdown of its role:

1. **Sending the Transaction**: It takes the signed transaction as input and submits it to the Solana cluster.

2. **Confirmation**: After sending the transaction, it listens for confirmation from the network. This means it checks that the transaction has been included in a block and is finalized.

3. **Error Handling**: If the transaction fails (for example, due to insufficient funds or a program error), `sendAndConfirmTransaction` will throw an error, allowing developers to handle it appropriately.

4. **Return Value**: Upon successful confirmation, it typically returns the transaction signature, which can be used for further verification or logging.

Here’s a simple example of how `sendAndConfirmTransaction` might be used in a code snippet:

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

// Assume `connection` is a valid connection to the Solana cluster
// and `transaction` is a signed transaction.

try {
  const signature = await sendAndConfirmTransaction(connection, transaction, {
    commitment: 'confirmed',
  });
  console.log('Transaction confirmed with signature:', signature);
} catch (error) {
  console.error('Transaction failed:', error);
}
```

In this example, the transaction is sent to the network, and the code waits for confirmation. If successful, it logs the transaction signature; if it fails, it catches and logs the error.

actory({
  rpc,
  rpcSubscriptions,
});

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

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

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

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

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

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

await sendAndConfirmTr


[User] How is the 'assetMint' parameter used within the Magic Eden API?

[Assistant]
The 'assetMint' parameter in the Magic Eden API is a required string that represents the public key of the mint account of the asset you are interacting with. This parameter is essential for identifying the specific asset that you want to transact with in the context of the API operations.

For example, when fulfilling a buy or sell transaction, you would include the 'assetMint' parameter in your request to specify which asset's mint account you are referring to. This helps the API to accurately process the transaction related to that particular asset.

Here is a sample code snippet demonstrating how the 'assetMint' parameter might be included in a request to fulfill a buy:

```bash
curl --request GET \
  --url 'https://api-mainnet.magiceden.dev/v2/instructions/mmm/sol-fulfill-buy?pool=<pool>&assetAmount=<amount>&minPaymentAmount=<min_payment>&seller=<seller>&assetMint=<asset_mint>&assetTokenAccount=<asset_token_account>' \
  --header 'accept: application/json'
```

In this example, replace `<pool>`, `<amount>`, `<min_payment>`, `<seller>`, `<asset_mint>`, and `<asset_token_account>` with the appropriate values for your transaction. The 'assetMint' parameter is crucial for ensuring that the API knows which asset you are dealing with.

Query Params
pool
string
required
Public key of pool to interact with

assetAmount
number
required
Amount of asset to transact

minPaymentAmount
number
required
Minimum payment amount acceptible by the seller, in SOL

seller
string
required
Public key of seller of asset

assetMint
string
required
Public key of mint account of asset

assetTokenAccount
string
required
Public key of token account of asset

allowlistAuxAccount
string
The allowlist aux account used for token authentication

skipDelist
boolean
Whether to skip trying to delist the NFT if it is detected to be listed

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

Response

200
successful operation

Updated about 1 year ago

Get instruction to close a pool after all assets and payment have been withdrawn
Get instruction to have a pool fulfill a sell
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
Credentials
Bearer
auth-scheme
token

URL

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

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

200

Get instruction to have a pool fulfill a sell
get
https://api-mainnet.magiceden.dev/v2/instructions/mmm/sol-fulfill-sell
Log in to see full request history
time	status	user


[User] What information does the 'programId' provide in a QuickNode transaction?

[Assistant] In a QuickNode transaction, the `programId` provides the ID of the program that executed the instruction within the transaction. This identifier is crucial as it helps to determine which specific program was responsible for processing the transaction, allowing developers to trace the execution flow and understand the context of the transaction better.

e token between accounts
wallet
Wallet is used for managing and storing assets
type
The type of the block. It can be used to differentiate between regular blocks and special blocks such as snapshot or transaction confirmation blocks
program
The data associated with the program that was executed in the block's transactions
programId
The ID of the program that executed the instruction
recentBlockhash
The recent block hash for the account's cluster
signatures
The list of transaction signatures contained within a particular block
version
The transaction version. It's undefined if maxSupportedTransactionVersion is not set in the requested parameters
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc": "2.0","id": 1,"method": "getTransaction","params": ["D13jTJYXoQBcRY9AfT5xRtsew7ENgCkNs6mwwwAcUCp4ZZCEM7YwZ7en4tVsoDa7Gu75Jjj2FgLXNUz8Zmgedff",{"encoding": "jsonParsed","maxSupportedTransactionVersion":0}]}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getTokenSupply
Next
getTransactionCount
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
getTransactionCount RPC Method
Returns the current trans


[User] Is there any liability assumed by Jupiter for third-party resources accessed through its Interface?

[Assistant] According to the documentation, Jupiter does not assume any responsibility for third-party resources or promotions accessed through its Interface. If you access such resources or participate in promotions, you do so at your own risk, and the Terms do not apply to your dealings or relationships with those third parties. Jupiter expressly relieves itself of any and all liability arising from your use of any such resources or participation in any such promotions.


[User] What does the eventAuthority represent in the Jupiter DCA Program, and what is its public key?

[Assistant]
In the Jupiter DCA Program, the `eventAuthority` represents the authority responsible for handling events related to the DCA (Dollar-Cost Averaging) transactions. It is a designated public key that is used within the program for event management.

The public key for the `eventAuthority` is:
`Cspp27eGUDMXxPEdhmEXFVRn6Lt1L7xJyALF3nmnWoBj`

e seed -> 'dca', user public key, input token public key, output token public key and a uid (use a unix timestamp). See code example below	false	true
user	This is the user's pubkey. Needs to be a signer of the transaction.	true	false
payer	This is the payer's pubkey. Needs to be a signer of the transaction. Pays for the rent to open token accounts needed as well as user's DCA (PDA) account. This can be the same as user.	true	true
inputMint	Token to sell	false	false
outputMint	Token to buy	false	false
userAta	User's token account holding the token to sell. Does not necessarily need to be a associated token account. Will transfer inputMint tokens from this account to DCA PDA's inputMint ATA	false	true
inAta	The associated token account's address of DCA PDA for inputMint. Example: getAssociatedTokenAddressSync(inputMint, dcaPubKey, true) from @solana/spl-token library	false	true
outAta	The associated token account's address of DCA PDA for outputMint. Example: getAssociatedTokenAddressSync(outputMint, dcaPubKey, true) from @solana/spl-token library	false	true
systemProgram	The usual new PublicKey("11111111111111111111111111111111")	false	false
tokenProgram	new PublicKey('TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA'); DCA has not been tested to work with Token 2022 yet	false	false
associatedTokenProgram	new PublicKey('ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL');	false	false
eventAuthority	new PublicKey('Cspp27eGUDMXxPEdhmEXFVRn6Lt1L7xJyALF3nmnWoBj') This is DCA Program's event


[User] What happens to a trade request once it is fetched by a keeper on Jupiter?

[Assistant]
Once a trade request is fetched by a keeper on Jupiter, the following process occurs:

1. **Verification**: The keeper verifies the trade request to ensure its validity.

2. **Execution**: After verification, the keeper creates and submits another transaction to execute the trade.

3. **Confirmation**: The trade is executed when the transaction succeeds and is confirmed by the Solana blockchain. This process updates the position or any associated take profit (TP) or stop loss (SL) requests.

In summary, the keeper plays a crucial role in automating the execution of trade requests by verifying them and submitting the necessary transactions to the blockchain.

der
Close TP / SL order
The trader performs the actions above through the Jupiter Perpetuals platform or via the API. The frontend or API server then verifies the action and submits a transaction on the Solana blockchain containing the trader's request.

For example, if the trader created an open position request, the transaction would contain data such as the trade size, collateral size, position side, and other data required to fulfil the request and ultimately open the position.

Fulfil trade request
Jupiter hosts two keepers that continuously poll the Solana blockchain for trade requests.

Once a trade request is fetched by a keeper, it verifies the trade request before creating and submitting another transaction to execute the trade.

The trade is executed when the transaction succeeds and is confirmed by the Solana blockchain, thus updating the position or TP / SL request.

This means there are two transactions required to complete a trade request: one for the trade request and another one to fulfil the trade request.

info
Keepers are offchain services that listen to onchain events and perform actions corresponding to the event. They enable automatic and timely execution of trade requests without manual intervention.

Jupiter Perpetuals' keepers listen to the trade requests 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


[User] What are the maximum number of requests per 10 seconds for a single RPC on the Solana testnet?

[Assistant] The maximum number of requests per 10 seconds for a single RPC on the Solana testnet is 40.

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

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

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

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

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

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


[User] What is the return object of the 'getHighestSnapshotSlot' method in Tatum when a snapshot is available?

[Assistant]
When the `getHighestSnapshotSlot` method in Tatum is called and a snapshot is available, the return object is a JSON object that contains the following fields:

- **full**: The highest full snapshot slot.
- **incremental**: The highest incremental snapshot slot based on the full snapshot slot, if available.

Here is an example of the return object when a snapshot is available:

```json
{
  "jsonrpc": "2.0",
  "result": {
    "full": 100,
    "incremental": 110
  },
  "id": 1
}
```

In this example, `full` is 100 and `incremental` is 110, indicating the highest snapshot slots available.

hestSnapshotSlot()

await tatum.destroy() // Destroy Tatum SDK - needed for stopping background jobs
Overview
The getHighestSnapshotSlot method provides the highest slot information for which the node has snapshots. It determines the highest full snapshot slot and, if available, the highest incremental snapshot slot based on the full snapshot slot.

This method can be used in a variety of scenarios, including managing data storage and synchronisation of blockchain data. By knowing the highest snapshot slot, developers can estimate the amount of data that needs to be downloaded to sync a new node, or to ensure the node is up to date with the current state of the blockchain.

Parameters
None

Return Object
When the node has a snapshot, this method returns a JSON object with the following fields:

full: The highest full snapshot slot.
incremental: The highest incremental snapshot slot based on the full snapshot slot, if available.
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getHighestSnapshotSlot"
}
JSON-RPC Response Example
Here is an example response when the node has a snapshot:

JSON

{
  "jsonrpc": "2.0",
  "result": {
    "full": 100,
    "incremental": 110
  },
  "id": 1
}
In case the node does not have a snapshot, the response would be:

JSON

{
  "jsonrpc": "2.0",
  "error": { "code": -32008, "message": "No snapshot" },
  "id": 1
}
Updated about 2 months ago

gettokenaccountbalance
getfeeformessage
Did this page help you?

getfeeformess


[User] What is the purpose of the getBlockCommitment method in ChainStack, and how does it relate to block production?

[Assistant]
The `getBlockCommitment` method in ChainStack is used to retrieve the commitment information for a specific block in the Solana network. This method provides detailed insights into the consensus level for that block by reporting on the number of cluster nodes that have voted on it and the total stake of those nodes.

The relationship between `getBlockCommitment` and block production lies in the consensus mechanism of the network. While block production refers to the creation of new blocks by validators, the commitment of a block indicates how many validators have confirmed that block as valid. This is crucial for understanding the stability and reliability of the blockchain, as higher commitment levels suggest stronger agreement among validators regarding the validity of the block.

Here's a brief overview of how you might call the `getBlockCommitment` method:

### Example of Calling `getBlockCommitment`

```shell
curl --request POST \
     --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/ \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getBlockCommitment",
  "params": [<block_number>]
}'
```

In this example, replace `<block_number>` with the specific block number you want to query. The response will provide you with the commitment details, which can help you assess the block's acceptance within the network.

A practical use case for getBlockProduction is to track the efficiency of the network and the performance of validators. This can be useful for network monitoring tools or other applications that need to display or make use of this information.

Try the getBlockProduction RPC method yourself
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getBlockProduction
getBlockProduction
Response

200
Block production details

Updated 11 months ago

getBlock | Solana
getBlockCommitment | Solana
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request POST \
2
     --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/ \
3
     --header 'accept: application/json' \
4
     --header 'content-type: application/json' \
5
     --data '
6
{
7
  "id": 1,
8
  "jsonrpc": "2.0",
9
  "method": "getBlockProduction"
10
}
11
'
getBlockCommitment | Solana
post
https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/
Solana getBlockCommitment method
The Solana getBlockCommitment method returns the commitment information for a given block.

This method provides detailed information about the number of cluster nodes that have voted on the block, and the total stake of those nodes. It is useful for determining the level of consensus for a block in the network.

👍
Get you own node endpoint today

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

You can sign up


[User] What constitutes 'reasonable security measures' when protecting user data in applications using Magic Eden?

[Assistant]
The documentation does not provide specific details on what constitutes 'reasonable security measures' for protecting user data in applications using Magic Eden. However, it does emphasize that your application must use reasonable security measures to protect the private data of your users.

Generally, reasonable security measures could include:

1. **Data Encryption**: Encrypting sensitive user data both in transit and at rest to prevent unauthorized access.
2. **Access Controls**: Implementing strict access controls to ensure that only authorized personnel can access user data.
3. **Regular Security Audits**: Conducting regular security audits and vulnerability assessments to identify and mitigate potential security risks.
4. **Secure Authentication**: Utilizing secure authentication methods, such as multi-factor authentication (MFA), to protect user accounts.
5. **Data Minimization**: Collecting only the data that is necessary for your application’s functionality and ensuring that it is stored securely.
6. **Incident Response Plan**: Having a process in place to respond to any vulnerabilities or data breaches promptly.

While these measures are not explicitly outlined in the documentation, they represent common practices in the industry for safeguarding user data. It is important to assess your specific application and implement appropriate security measures accordingly.

out of certain types of communication.
3.9 Feedback. If you give feedback about the Magic Eden APIs to Magic Eden, you hereby grant to Magic Eden a non-exclusive, transferable, worldwide, perpetual, irrevocable, fully-paid, royalty-free license, with the right to sublicense, under any and all intellectual property rights that you own or control to use, copy, modify, create derivative works based upon and otherwise exploit the feedback you give to Magic Eden. You will not give feedback that is subject to a license that requires Magic Eden to license its software or documentation to third parties because Magic Eden includes your feedback in them.
3.10 Non-Exclusivity. The Terms are non-exclusive. You acknowledge that Magic Eden may develop products or services that may compete with the Magic Eden API or any other products or services.
SECTION 4. SECURITY OF THE APPLICATION
4.1 Application Security. You warrant that your Application has been developed to operate with Magic Eden API content in a secure manner. Your network, operating system and the software of your servers, databases, and computer systems (collectively, “Systems”) must be properly configured to securely operate your Application and store content collected through your Application (including the Magic Eden API content). Your Application must use reasonable security measures to protect the private data of your users. You must have a process to respond to any vulnerabilities in your Application, and in the case of


[User] What is the purpose of the 'wsEndpoint' parameter when creating a connection in QuickNode's Solana Web3.js?

[Assistant]
The `wsEndpoint` parameter in QuickNode's Solana Web3.js is used to specify the WebSocket endpoint for real-time notifications. When you create a connection to the Solana blockchain, this parameter allows you to receive updates about events such as slot changes, which are essential for applications that need to react to blockchain state changes in real time.

Here is an example of how to use the `wsEndpoint` parameter when creating a connection:

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

(async () => {
  const solanaConnection = new web3.Connection("https://docs-demo.solana-mainnet.quiknode.pro/", {
    wsEndpoint: "wss://docs-demo.solana-mainnet.quiknode.pro/",
  });

  solanaConnection.onSlotChange((slotInfo) =>
    console.log("Updated slot info: ", slotInfo)
  );
})();
```

In this example, the `wsEndpoint` is set to the WebSocket URL provided by QuickNode, allowing the application to listen for slot changes and receive updates as they occur.

nytime a slot is processed by the validator.
Updated on
Sep 20, 2024
Parameters
This method does not accept any parameters
Returns
result
The result will be an RpcResponse JSON object with id equal to the subscription id (needed to unsubscribe)
Notification Format:
The notification format is the same as seen in the getAccountInfo RPC HTTP method
parent
The parent slot
root
The current root slot
slot
The newly set slot
Request

Solana Web3.js (v1.x)
const web3 = require("@solana/web3.js");
(async () => {
  const solanaConnection = new web3.Connection("https://docs-demo.solana-mainnet.quiknode.pro/", {
    wsEndpoint: "wss://docs-demo.solana-mainnet.quiknode.pro/",
  });
  solanaConnection.onSlotChange((slotInfo) =>
    console.log("Updated slot info: ", slotInfo)
  );
})();

Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
signatureUnsubscribe
Next
slotUnsubscribe
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
slotUnsubscribe RPC Method
(Subscription Websocket) Unsubscribe from slot notifications. The API credit value for this method is 20.
Updated on
Sep 20, 2024
Parameters
number
The account id for subscription to cancel
Returns
result
The result will be boolean value with u


[User] What is the difference between 'writable' and 'readonly' accounts in Tatum?

[Assistant]
In Tatum, the difference between 'writable' and 'readonly' accounts pertains to the permissions associated with those accounts during a transaction:

1. **Writable Accounts**: These are accounts that can be modified during the transaction. They are included in an ordered list of base-58 encoded addresses for accounts that can be written to.

2. **Readonly Accounts**: These accounts cannot be modified during the transaction. They are included in an ordered list of base-58 encoded addresses for accounts that are only readable.

This distinction is important for ensuring that the correct permissions are applied when executing transactions on the blockchain.

For example, in a transaction response, you might see:

```json
{
  "writable": [
    "address1",
    "address2"
  ],
  "readonly": [
    "address3",
    "address4"
  ]
}
```

In this example, `address1` and `address2` can be altered, while `address3` and `address4` can only be accessed for reading data.

 the account that received the reward
lamports:Number of reward lamports credited or debited by the account, as a i64
postBalance: Account balance in lamports after the reward was applied
rewardType: Type of reward: currently only "rent", other types may be added in the future
commission: Vote account commission when the reward was credited, only present for voting and staking rewards
loadedAddresses: Transaction addresses loaded from address lookup tables. Undefined if maxSupportedTransactionVersion is not set in request params.
writable: Ordered list of base-58 encoded addresses for writable loaded accounts
readonly: Ordered list of base-58 encoded addresses for readonly loaded accounts
returnData: The most-recent return data generated by an instruction in the transaction, with the following fields:
programId: The program that generated the return data, as base-58 encoded Pubkey
data: The return data itself, as base-64 encoded binary data
computeUnitsConsumed: Number of compute units consumed by the transaction
version: Transaction version. Undefined if maxSupportedTransactionVersion is not set in request params.
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTransaction",
  "params": [
    "4CgnQtRfnUekfn21meTyHYvoAc6pBYK3DhimeiZL6a6o2QXMTHqDomninDkaZLmSfdiEzZfyfLGN4mrDvs8HmnBh",
    {
      "encoding": "jsonParsed"
    }
  ]
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "result": {
    "meta": {
      "err": null,
      "fee":


[User] How does ChainStack facilitate tracking network progress using the getSlot method?

[Assistant]
ChainStack facilitates tracking network progress through the Solana `getSlot` method, which returns the current slot in the Solana network. A slot is a unit of time that indicates the progress of the network, making it essential for monitoring the state of the blockchain.

### How to Use the `getSlot` Method

The `getSlot` method does not require any parameters, and you can call it using a POST request to your ChainStack node endpoint. Here’s an example of how to use the `getSlot` method with a `curl` command:

```bash
curl --request POST \
     --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/ \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '{
       "id": 1,
       "jsonrpc": "2.0",
       "method": "getSlot",
       "params": []
     }'
```

### Response

The response will include the current slot value, which can be used for various applications, such as:

- **Network Monitoring Tools**: Displaying the current status of the Solana network.
- **Progress Tracking**: Applications that need to keep track of the network's progress can utilize this information effectively.

### Use Case

A practical use case for the `getSlot` method is in network monitoring tools that need to provide real-time updates about the blockchain's state. By regularly calling this method, developers can ensure their applications reflect the latest network conditions.

In summary, ChainStack's implementation of the `getSlot` method allows developers to easily track the progress of the Solana network, enabling better monitoring and application performance.

EkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
13
    ],
14
    {
15
      "searchTransactionHistory": true
16
    }
17
  ]
18
}
19
'

getSlot | Solana
post
https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/
Solana getSlot method
The Solana getSlot method returns the current slot.

This method provides the current slot, which is a unit of time in the Solana network. It is useful for tracking the progress of the network.

👍
Get you own node endpoint today

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

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

Parameters
This method does not require any parameters.

Response
value — the current slot.
Use case
A practical use case for getSlot is to track the progress of the network. This can be useful for network monitoring tools or other applications that need to display or make use of this information.

Try the getSlot RPC method yourself
Body Params
id
integer
Defaults to 1
1
jsonrpc
string
Defaults to 2.0
2.0
method
string
Defaults to getSlot
getSlot
params
array
Defaults to
Response

200
Slot details

Updated 11 months ago

getSignatureStatuses | Solana
getSlotLeader | Solana
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request POST \
2
     --url https://nd-326-444-187.p2pify.com/9de47db917d4f69168e3fed02217d15b/ \
3
     --header 'accept: application/json' \
4
     --header 'content-type: appl