[User] How does Jupiter recover the rent when closing the PDA in-token account?

[Assistant]
When Jupiter closes the PDA (Program Derived Address) in-token account, it utilizes the rent that has been recovered to open your wallet's token account. This process occurs when there are still tokens that have not been transferred to you, particularly if you have closed your wallet’s token account for the purchased token partway through the VA (Virtual Account) cycle.

Here's a brief overview of how it works:

1. **Closing the PDA in-token account**: If you close your wallet's token account while there are remaining tokens, the VA program will close the associated PDA in-token account.

2. **Recovering rent**: The rent that was incurred for the PDA in-token account is then recovered. This recovered rent is used to open your wallet's token account.

3. **Transferring remaining tokens**: After the wallet's token account is opened, the program can then transfer the remaining purchased tokens to your wallet.

It's important to note that you will only receive 2/3 of the rent incurred to initialize your VA account, as 1/3 of the rent is not absorbed by any third-party and remains recoverable by you if you decide to close your associated token account.

This mechanism ensures that you can still receive your tokens even if you close your token account during the VA cycle. However, it is crucial to withdraw or swap tokens before closing your token account to avoid any potential loss of tokens.

r SOL: Jupiter takes care to open/close your wrapped account.

Alternatively, if you would like to manually claim/withdraw the purchased tokens, you can toggle to the Manual option before confirming the VA order.

Auto Close
Auto Close
At the end of your VA orders, you do not need to perform any additional actions. Any remaining tokens and rent will be transferred to your wallet account directly.

By default, if your wallet’s ATA remains open, your purchase tokens are automatically transferred to you on every order (the program only allows your tokens to be sent to your wallet and no one else’s).

However, if there are still tokens yet to be transferred to you (ie. if you close your wallet’s token account for your purchase token halfway through the VA cycle as described in auto-withdrawal section), the VA program will close the PDA in-token account and utilize the rent recovered to open your wallet's token account.

This allows the program to transfer the remaining purchased tokens to you. As such, you would only receive 2/3 of the rent incurred to initialise your VA account. Having said that, this 1/3 rent is not absorbed by any third-party. This rent will remain recoverable by you if you decide to close your ATA that “holds” your purchased token.

danger
Do not close your ATA without first withdrawing the tokens or swapping them for other tokens. Doing so can result in the loss of tokens. This is not unique to Jupiter or Jupiter’s VA. This has to do with how Solana wallets


[User] What kind of transactions does the simulateBundle method deal with in QuickNode?

[Assistant]
The `simulateBundle` method in QuickNode deals with Jito bundles, specifically for simulating transactions that are part of these bundles. This method is exclusively available to Jito-Solana validators and requires the Lil' JIT - JITO Bundles and transactions add-on to be enabled on your QuickNode endpoint.

The method allows you to simulate one or more base64-encoded, serialized transactions. These transactions are provided in an array as part of the method's parameters.

Here's a brief overview of the parameters involved:

- **encodedTransactions**: An array containing one or more base64-encoded, serialized transactions for simulation.
- **simulationBank** (optional): A string that specifies the bank to run the simulation against.
- **skipSigVerify** (optional): A boolean that indicates whether to enable signature verification before simulation.

This setup allows developers to test and validate the behavior of transaction bundles before executing them on the Solana blockchain.

dpoint in seconds and start building
Get started for free
Previous
sendBundle
Next
simulateBundle
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
simulateBundle RPC Method
Simulates a Jito bundle – exclusively available to Jito-Solana validator.
Updated on
Sep 20, 2024
Please note that this RPC method requires the Lil' JIT - JITO Bundles and transactions 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
object
object
REQUIRED
An object containing the following fields:
encodedTransactions
array
An array of one or more base64-encoded, serialized transactions for simulation
object
array
The configuration object with the following fields:
simulationBank
string
(Optional) The bank to run the simulation against
skipSigVerify
boolean
(Optional) A boolean value indicating whether to enable signature verification before simulation
replaceRec


[User] Can you explain the difference between subscribing to 'all' blocks and to a specific program ID in ChainStack?

[Assistant]
In ChainStack, when using the `blockSubscribe` method in Solana, you have the option to subscribe to either 'all' blocks or to a specific program ID. Here’s the difference between the two:

1. **Subscribing to 'all' blocks**:
   - When you subscribe to 'all' blocks, you receive a stream of updates for every new block added to the blockchain. This includes full transaction details for each block.
   - This is useful for applications that need to monitor the entire blockchain and stay updated with all transactions and state changes.
   - Example command:
     ```bash
     > {"jsonrpc":"2.0","id":"1","method":"blockSubscribe","params":["all",{"encoding":"json","maxSupportedTransactionVersion":0,"transactionDetails":"full","rewards":false}]}
     ```

2. **Subscribing to a specific program ID**:
   - When you subscribe to a specific program ID, you only receive updates for transactions that involve that particular program. This means you will not get updates for blocks that do not contain transactions related to the specified program ID.
   - This is beneficial for applications that are focused on a specific smart contract or program, allowing them to reduce data processing and focus only on relevant transactions.
   - Example command:
     ```bash
     > {"jsonrpc":"2.0","id":"1","method":"blockSubscribe","params":["program id",{"encoding":"json","maxSupportedTransactionVersion":0,"transactionDetails":"full","rewards":false}]}
     ```

In summary, subscribing to 'all' blocks provides comprehensive updates across the entire blockchain, while subscribing to a specific program ID narrows the focus to only those transactions that are relevant to that program, enhancing efficiency for targeted applications.

aking"
blockTime - Estimated production time, as Unix timestamp (seconds since the Unix epoch)
blockHeight - The number of blocks beneath this block
blockSubscribe code examples
📘
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, all
wscat, program id

$ 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":"blockSubscribe","params":["all",{"encoding":"json","maxSupportedTransactionVersion":0,"transactionDetails":"full","rewards":false}]}
Examples:

wscat, all — generates a stream of all blocks with full transaction details in the blocks
wscat, program id — generates a stream only of the transactions that involve the pump.fun program id.
Use blockUnsubscribe | Solana to remove the subscription.

Use case
The blockSubscribe method in Solana is used to subscribe to the network and receive real-time updates on new blocks added to the chain. This can be useful in various real-world scenarios, including:

Decentralized applications (dApps): dApps can use this method to stay synchronized with the latest state of the blockchain. By receiving notifications about new blocks, they can update their internal state and provide users with the most current information.

Block explorers: Block explorer services can utilize this method to receive instant notificatio


[User] What information does the 'lamports' field in the getAccountInfo response represent in Solana?

[Assistant]
In the response of the `getAccountInfo` RPC method in Solana, the `lamports` field represents the number of lamports assigned to the queried account. It is returned as a `u64` value. Lamports are the smallest unit of SOL, the native cryptocurrency of the Solana blockchain, and this field indicates the balance of the account in lamports.

For example, if the `lamports` field in the response is `1000000000`, it means that the account has 1 SOL (since 1 SOL = 1,000,000,000 lamports).

ine where it stands in relation to the cluster

getAccountInfo RPC Method
Edit Page
Returns all information associated with the account of provided Pubkey

Parameters #
string required

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

object optional

Configuration object containing the following fields:

commitment string optional

encoding string optional

Encoding format for Account data

Values: base58base64base64+zstdjsonParsed

Details
dataSlice object optional

Request a slice of the account's data.

length: <usize> - number of bytes to return
offset: <usize> - byte offset from which to start reading
Info
Data slicing is only available for base58, base64, or base64+zstd encodings.

minContextSlot number optional

The minimum slot that the request can be evaluated at

Result #
The result will be an RpcResponse JSON object with value equal to:

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


[User] What specific field in the Bitquery's liquidity removal response indicates the remaining balance after a liquidity removal event?

[Assistant] In Bitquery's liquidity removal response, the specific field that indicates the remaining balance after a liquidity removal event is `Base.PostAmount`. This field provides the amount of the base currency remaining in the pool after the liquidity removal has occurred.

mount
          PostAmountInUSD
          PriceInUSD
        }
        Base {
          PostAmount
        }
      }
    }
  }
}

Liquidity Removal from a Pool for a Token
This query allows you to subscribe to updates on liquidity removal from a specific pool on the Solana network. The subscription is filtered by a particular token, identified by the base currency name or smart contract. It returns information on the amount of liquidity removed and the remaining balance.

{
  Solana(network: solana) {
    DEXPools(
      where: {
        Pool: {
          Base: { ChangeAmount: { lt: "0" } }
          Market: {
            BaseCurrency: {
              MintAddress: {
                is: "7M9KJcPNC65ShLDmJmTNhVFcuY95Y1VMeYngKgt67D1t"
              }
            }
          }
        }
      }
    ) {
      Pool {
        Market {
          MarketAddress
          BaseCurrency {
            MintAddress
            Symbol
            Name
          }
          QuoteCurrency {
            MintAddress
            Symbol
            Name
          }
        }
        Dex {
          ProtocolFamily
          ProtocolName
        }
        Quote {
          PostAmount
          PriceInUSD
          PostAmountInUSD
          ChangeAmount
        }
        Base {
          PostAmount
          ChangeAmount
        }
      }
    }
  }
}

Pump Fun Pool Liquidity Addition
This query returns the instances where liquidity was added to the pools related to the Pump protocol on Solana.

{
  So


[User] Where can I find guides on using QuickNode add-ons with Solana Web3.js 2.0?

[Assistant]
You can find guides on using QuickNode add-ons with Solana Web3.js 2.0 in the documentation. Specifically, there are two guides available:

1. **How to Use QuickNode Add-ons using Solana Web3.js 2.0 (Part 1)**
2. **How to Use QuickNode Add-ons using Solana Web3.js 2.0 (Part 2)**

These guides will provide you with detailed instructions on integrating QuickNode Marketplace add-ons into your applications using Solana Web3.js 2.0.

ut 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
/price REST API Endpoint
Returns the precise and real-time pricing for all SPL tokens.
Updated on
Sep 20, 2024
Please note that this method is only available for paid subscribers of Metis - Jupiter V6 Swap API.
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)
Query Parameters
ids
string
REQUIRED
Supports symbol or address of a token. You can also pass in an array of ids with a comma as a separator. Address and symbol modes both are case-sensitive
vsToken
string
The token to compare price versus (supports symbol or address of a token). The default value is set to USDC
useQNMarketCache
boolean
When set to true, the response includes your added pools/markets
restrictIntermediateTokens
boolean
Default is true. Restrict intermediate tokens to a top token set that has stable liquidity. This will help improve latency on /price requests.
onlyDirectRoutes
boolean
Default is fa


[User] How can I check the status of QuickNode services as mentioned in the snippet?

[Assistant]
To check the status of QuickNode services, you can visit the QuickNode status page. The documentation snippet indicates that you can check on the status of their services, but it does not provide a direct link or method for doing so.

For the most accurate and up-to-date information regarding service status, you would typically navigate to the QuickNode website or their dedicated status page. If you have any specific issues or need assistance, you might also consider reaching out to their support or community channels.

 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
signatureUnsubscribe RPC Method
(Subscription Websocket) Unsubscribe from signature confirmation notification.
Updated on
Oct 4, 2023
Parameters
number
The account id for subscription to cancel
Returns
boolean
The result will be boolean value with unsubscribed success message
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.removeSignatureListener(0);
})();

Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
signatureSubscribe
Next
slotSubscribe
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
slotSubscribe RPC Method
(Subscription Websocket) Subscribe to receive notification anytime 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


[User] Is there any information provided by QuickNode about using Rust for HTTP requests with Solana?

[Assistant]
The documentation snippet provided does mention Rust in the context of HTTP requests, stating that Rust is a systems programming language designed for performance, memory safety, and concurrency. However, it does not provide specific details or examples regarding how to use Rust for making HTTP requests with Solana.

If you need further information or examples, please refer to additional resources or documentation specific to using Rust with Solana.

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

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

curl -h

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

npm install @solana/web3.js@2

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

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

npm install @solana/web3.js@1

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

pip install solana cachetools

Rust (HTTP)
Rust is a systems programming language designed for performance, memory safety, and concurrency. It provides a modern alternative to


[User] What does the `StakeProgram.createAccount` function accomplish in the Solana ecosystem?

[Assistant]
The `StakeProgram.createAccount` function is used to create a new stake account in the Solana ecosystem. A stake account is essential for participating in the staking process, which allows users to earn rewards by locking up their SOL tokens to support the network's security and operations.

Here’s a breakdown of what the function accomplishes:

1. **Account Creation**: It creates a new stake account that can hold staked SOL tokens.
2. **Authorization**: It sets up an `Authorized` structure that defines who can manage the stake account (both for staking and withdrawing).
3. **Lockup Parameters**: It allows for the specification of lockup parameters through the `Lockup` structure, which can enforce restrictions on when the staked SOL can be withdrawn.
4. **Funding the Account**: The function specifies the amount of lamports (the smallest unit of SOL) to fund the new stake account.

Here is an example of how to use the `StakeProgram.createAccount` function:

```javascript
const { Keypair } = require('@solana/web3.js');
const { StakeProgram, Authorized, Lockup } = require('@solana/stake-program');

let account = Keypair.generate();
let stakeAccount = Keypair.generate();
let authorized = new Authorized(account.publicKey, account.publicKey);
let lockup = new Lockup(0, 0, account.publicKey);

let createStakeAccountInstruction = StakeProgram.createAccount({
  fromPubkey: account.publicKey,
  authorized: authorized,
  lamports: 1000,
  lockup: lockup,
  stakePubkey: stakeAccount.publicKey,
});
```

In this example:
- `fromPubkey` is the public key of the account funding the creation of the stake account.
- `authorized` specifies the account that has the authority to manage the stake account.
- `lamports` is the amount of lamports to fund the new stake account.
- `lockup` defines the lockup conditions for the stake account.
- `stakePubkey` is the public key of the newly created stake account.

Overall, the `StakeProgram.createAccount` function is a fundamental part of enabling staking functionality within the Solana blockchain.

nt = Keypair.generate();
let stakeAccount = Keypair.generate();
let authorized = new Authorized(account.publicKey, account.publicKey);
let lockup = new Lockup(0, 0, account.publicKey);

let createStakeAccountInstruction = StakeProgram.createAccount({
  fromPubkey: account.publicKey,
  authorized: authorized,
  lamports: 1000,
  lockup: lockup,
  stakePubkey: stakeAccount.publicKey,
});

The above code creates a createStakeAccountInstruction to be used when creating an account with the StakeProgram. The Lockup is set to 0 for both the epoch and Unix timestamp, disabling lockup for the account.

See StakeProgram for more.

Getting Started with Anchor
The Anchor framework is a tool that simplifies the process of building Solana programs. Whether you're new to blockchain development or an experienced programmer, Anchor simplifies the process of writing, testing, and deploying Solana programs.

In this section, we'll walk through:

Creating a new Anchor project
Building and testing your program
Deploying to Solana clusters
Understanding the project file structure
Prerequisites #
For detailed installation instructions, visit the installation page.

Before you begin, ensure you have the following installed:

Rust: The programming language for building Solana programs.
Solana CLI: Command-line tool for Solana development.
Anchor CLI: Command-line tool for the Anchor framework.
To verify Anchor CLI installation, open your terminal and run:

Terminal
anchor --version

Expected output:


[User] How do Address Lookup Tables enhance the transaction process in Jupiter?

[Assistant]
Address Lookup Tables (ALTs) enhance the transaction process in Jupiter by allowing account addresses to be stored in on-chain tables rather than directly in the transaction. This change leads to several benefits:

1. **Reduced Transaction Size**: By using ALTs, the space that would normally be occupied by account addresses in a transaction is freed up. This allows for more instructions to be included in a single transaction, effectively increasing the composability of transactions.

2. **Improved Composability**: With the ability to fit more instructions into a single transaction, users can perform more complex operations without needing multiple transactions. This is particularly beneficial for swaps and other multi-step operations that Jupiter facilitates.

3. **Automatic Construction**: Jupiter automatically constructs transactions to use the correct lookup tables, simplifying the process for developers. While developers can create their own on-chain lookup tables for additional customization, the automatic handling by Jupiter ensures that users can easily take advantage of this feature without needing to manage the details themselves.

In summary, Address Lookup Tables streamline the transaction process by optimizing space usage, enhancing the ability to compose multiple instructions, and simplifying the developer experience when working with Jupiter.

requently. For Jupiter, this meant that we were limited to two-hop swaps and used up all the transaction size just to fit the two swaps into a single transaction.

Summary of constraints that affect composability
By utilizing Versioned Transactions with Address Lookup Tables, all Jupiter swaps can now be done in a single transaction with approximately 50% of the transaction size freed for anyone to add their own instructions.

What are Versioned Transactions?
Versioned Transactions are the new transaction format that allows for additional functionality in the Solana runtime, including Address Lookup Tables. Address Lookup Tables let you store the account addresses in on-chain tables instead of being stored directly in the transaction which will free up space for other instructions.

You do not need to use Address Lookup Tables to compose with Jupiter.
We automatically construct the transactions to use the correct Jupiter lookup tables for you. However, using your own on-chain lookup tables will allow you to fit more instructions into the transaction.

1. Get the Jupiter swap transaction from the API.

You can refer to the example code in Using the API for retrieving a Jupiter swap transaction.

// Some more imports you will need
import { TransactionMessage, VersionedMessage, TransactionInstruction, sendAndConfirmRawTransaction, SystemProgram, AddressLookupTableAccount } from '@solana/web3.js';
import { ASSOCIATED_TOKEN_PROGRAM_ID, Token, TOKEN_PROGRAM_ID } from '@solana/spl-t


[User] Can you explain the role of the DYNAMIC_AMM_PROGRAM_ID in the context of Meteora?

[Assistant]
The `DYNAMIC_AMM_PROGRAM_ID` in Meteora is used as an identifier for the Dynamic Automated Market Maker (AMM) program when creating a new pool. It is a crucial component in the process of setting up a dynamic pool, as it specifies which program is being interacted with for the creation and management of the liquidity pool.

In the provided code snippet, `DYNAMIC_AMM_PROGRAM_ID` is passed as an argument to the `createPool` function, which is responsible for creating a new liquidity pool with the specified configurations. This indicates that the pool being created will utilize the functionalities provided by the Dynamic AMM program.

Here’s a relevant portion of the code that illustrates its use:

```javascript
const poolPubkey = await createPool(
    connection,
    mintAInfo.mint,
    mintBInfo.mint,
    poolConfig.publicKey,
    DYNAMIC_AMM_PROGRAM_ID
);
```

In summary, `DYNAMIC_AMM_PROGRAM_ID` serves as a reference to the specific AMM program that facilitates the creation and operation of dynamic liquidity pools within the Meteora ecosystem.

olAddressWithConfig(
    mintAInfo.mint,
    mintBInfo.mint,
    poolConfig.publicKey,
    DYNAMIC_AMM_PROGRAM_ID
  );

  console.log("Pool created", poolPubkey.toBase58());

  // 3. Create the alpha vault
  const initPermissionlessVaultTx = await AlphaVault.createPermissionedVault(
    connection,
    {
      baseMint: mintAInfo.mint,
      quoteMint: mintBInfo.mint,
      poolType: PoolType.DYNAMIC,
      vaultMode: VaultMode.PRORATA,
      poolAddress: poolPubkey,
      config: poolConfig.account.vaultConfigKey,
    },
    payer.publicKey
  );

  console.log("Creating vault");
  const txHash = await sendAndConfirmTransaction(
    connection,
    initPermissionlessVaultTx,
    [payer]
  );
  console.log(txHash);
}

const connection = new Connection(clusterApiUrl("devnet"));
const payer = loadKeypairFromFile(process.env.KEYPAIR_PATH);

/**
 * This example shows how to create dynamic pool with permissioned vault
 * Please contact meteora team if the existing pool and vault config doesn't meet the requirement
 * Currently only dynamic pool support permissioned vault
 */
createDynamicPoolWithPermissionedVault(connection, payer)
  .then(() => {
    console.log("Done");
  })
  .catch(console.error);
Whitelisted wallet csv file Example
https://github.com/MeteoraAg/alpha-vault-sdk/blob/main/ts-client/src/examples/permissioned/whitelist_wallet.csv?plain=1

3. Create Merkle Root Config
This example shows how to create a merkle root config after generating a merkle tree, which is requ


[User] How does Bitquery define the 'ProtocolFamily' and 'ProtocolName' in the context of DEX trades?

[Assistant]
In the context of DEX trades within the Bitquery API, the `ProtocolFamily` and `ProtocolName` are defined as follows:

- **ProtocolFamily**: This refers to the broader category or family of the decentralized exchange (DEX) protocol. It helps to classify the DEX based on its underlying technology or framework.

- **ProtocolName**: This specifies the exact name of the DEX protocol being used for the trade. It provides a more specific identification of the DEX within its family.

These attributes are part of the `Dex` object in the DEX trades subscription query. Here’s a snippet of how they are structured in the GraphQL query:

```graphql
subscription {
  Solana {
    DEXTrades {
      Trade {
        Dex {
          ProgramAddress
          ProtocolFamily
          ProtocolName
        }
        ...
      }
    }
  }
}
```

In this query, `ProtocolFamily` and `ProtocolName` can be accessed to understand the specific DEX protocol involved in the trade.

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

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

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

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

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


[User] What programming languages does CoinGecko provide examples for using its API?

[Assistant]
CoinGecko provides examples for using its API in the following programming languages:

1. Shell
2. Node
3. Ruby
4. PHP
5. Python

These examples can help developers understand how to interact with the CoinGecko API using their preferred programming language.

larity

precision
string
decimal place for currency price value

Response

200
Get historical market data include price, market cap, and 24h volume

Response body
object
prices
array of arrays of numbers
array of numbers
market_caps
array of arrays of numbers
array of numbers
total_volumes
array of arrays of numbers
array of numbers
Updated 5 days ago

Coin Data by Token Address
Coin Historical Chart Data within Time Range by Token Address
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
Credentials
x-cg-pro-api-key

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

Try It!
RESPONSE
1
{
2
  "prices": [
3
    [
4
      1711843200000,
5
      69702.3087473573
6
    ],
7
    [
8
      1711929600000,
9
      71246.9514406015
10
    ],
11
    [
12
      1711983682000,
13
      68887.7495158568
14
    ]
15
  ],
16
  "market_caps": [
17
    [
18
      1711843200000,
19
      1370247487960.09
20
    ],
21
    [
22
      1711929600000,
23
      1401370211582.37
24
    ],
25
    [
26
      1711983682000,
27
      1355701979725.16
28
    ]
29
  ],
30
  "total_volumes": [
31
    [
32
      1711843200000,
33
      16408802301.8374
34
    ],
35
    [
36
      1711929600000,
37
      19723005998.215
38
    ],
39
    [
40
      1711983682000,
41
      30137418199.6431
42
    ]
43
  ]
44
}

Coin Historical Chart Data within Time Ran


[User] How does Magic Eden allow developers to bypass boilerplate code when connecting to the provider?

[Assistant]
Magic Eden allows developers to bypass boilerplate code when connecting to the provider by enabling direct access to the provider through the `magicEden` object injected into the window of web pages. This object provides a streamlined way to interact with the Bitcoin provider without needing to go through the extensive setup typically required by wallet standard libraries.

Specifically, developers can connect directly to the provider using the `window.magicEden.bitcoin` namespace. This approach simplifies the integration process, as it eliminates much of the boilerplate associated with the Bitcoin Wallet Standard. By directly accessing the provider, developers can focus on implementing their application logic rather than dealing with the complexities of the wallet standard.

Additionally, the documentation mentions that by connecting directly to the provider, developers can ignore a lot of the boilerplate from the wallet standard libraries, which further enhances the ease of integration.

Here’s a brief example of how a developer might access the provider:

```javascript
// Access the Bitcoin provider directly
const bitcoinProvider = window.magicEden.bitcoin;

// Now you can use bitcoinProvider methods without additional boilerplate
bitcoinProvider.getAddress().then(address => {
    console.log("User's Bitcoin Address:", address);
});
```

This code snippet demonstrates how to access the Bitcoin provider and retrieve the user's Bitcoin address with minimal setup.

ain agnostic Wallet Standard. This standard makes use of a set of interfaces and conventions designed to improve the user experience and developer experience of wallets and applications. You can use these libraries to connect to the ME wallet without locating the provider directly if you so choose.

Sats-Connect
The provider also extends methods from sats-connect, an easy-to-understand javascript library that allows apps to interact with Bitcoin wallets. Sats Connect enables developers to easily retrieve user wallet addresses + interact with PSBTs

Demo
You can find a code demo here that illustrates how to integrate with the ME Wallet, create viable PSBTs, and utilize core sats-connect functions.

Note:

This demo assumes use of the Bitcoin Wallet Standard. By connecting directly to the provider, you can ignore a lot of the boilerplate from the wallet standard libraries
Detecting the Provider
The ME wallet injects a magicEden object into the window of most any web page that a user may visit. To interact with the Bitcoin provider directly, you can access at the unique namespace window.magicEden.bitcoin.

Simultaneously, the Bitcoin provider is injected into window.BitcoinProvider. There are a few different reasons for this, but occasionally the BitcoinProvider can be overwritten by other wallets who occupy the same namespace. Therefore, we make use of the Bitcoin extension of the Wallet Standard to successfully identify the correct provider in this case.

We recommend interac


[User] What is JupSOL and what does it represent in the context of Jupiter?

[Assistant]
JupSOL is a liquid staking token that represents staked Solana (SOL) tokens with Jupiter’s validator, which is hosted and managed by Triton. When users deposit SOL into JupSOL, those tokens are staked, and the staking rewards accrued from that SOL are passed on to the holders of the JupSOL token.

Initially, JupSOL starts at a 1:1 ratio with SOL, but its value grows over time relative to SOL as staking rewards accumulate. It is important to note that while JupSOL will always increase in value relative to SOL, it may still lose value in dollar terms.

The yield generated from JupSOL comes from staking yields and Maximal Extractable Value (MEV) kickbacks from Jupiter’s validator, which operates without fees. Additionally, the Jupiter team has delegated 100K SOL to the Jupiter validator to further enhance the yield for stakers.

n open up to 9 positions at one time:

Long SOL
Long wETH
Long wBTC
Short SOL (USDC)
Short SOL (USDT)
Short wETH (USDC)
Short wETH (USDT)
Short wBTC (USDC)
Short wBTC (USDT)
When a trader opens multiple positions for the same side (long / short) and token:

Open positions: Price and fee calculations are based on the existing open position. This is essentially increasing or decreasing the size of an open position.
Deposits, withdrawals, and closing: Price, PNL, and fee calculations are also based on the existing open position.

JupSOL Overview
JupSOL - A Liquid Staking Token
JupSOL represents staked Solana (SOL) tokens with Jupiter’s validator, which is hosted and managed by Triton. Jupiter passes all validator rewards collected and 100% of MEV (Maximal Extractable Value) along to stakers for maximum yield. The JupSOL token is issued through Sanctum.

Review the official JupSOL announcement forum post Here.

How does JupSOL Work?
SOL that’s deposited into JupSOL is staked. The staking rewards from that SOL accrue to the JupSOL token, which starts at 1:1 with SOL and grows in value over time relative to SOL. (Note that while JupSOL will always increase relative to SOL, it may still lose value in dollar terms.) By simply holding JupSOL, you will earn staking rewards.

Where does the yield come from?
JupSOL earns staking yields and MEV kickbacks from Jupiter’s validator, which has no fees. Additionally, the Jupiter team has delegated 100K SOL to the Jupiter validator. They will u


[User] What does the 'version' field signify in Tatum transactions, and when might it be undefined?

[Assistant]
In Tatum transactions, the 'version' field signifies the transaction version. This field is undefined if the `maxSupportedTransactionVersion` is not set in the request parameters. This means that if you do not specify the maximum supported transaction version in your request, the version of the transaction will not be provided in the response.

To ensure that the 'version' field is included in your transaction details, you should include the `maxSupportedTransactionVersion` parameter in your request.

 Account balance in lamports after the reward was applied
rewardType: Type of reward: "fee", "rent", "voting", "staking"
commission: Vote account commission when the reward was credited, only present for voting and staking rewards
DEPRECATED: status: Transaction status
"Ok": Transaction was successful
"Err": Transaction failed with TransactionError
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.
signatures: An array of signatures strings, corresponding to the transaction order in the block. This field is present if "signatures" are requested for transaction details.
rewards: Block-level rewards, present if rewards are requested.
blockTime: Estimated production time, as Unix timestamp (seconds since the Unix epoch).
blockHeight: The number of blocks beneath this block.
JSON-RPC Request Example


[User] Can users host their own keepers on Jupiter, and what is the rationale behind this policy?

[Assistant] No, users cannot host their own keepers on Jupiter at the moment. The rationale behind this policy is that Jupiter's keepers are audited and tested extensively to ensure they can execute trade requests reliably. Allowing community members to run their own keepers could compromise the reliability and security of the trading system.

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

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

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

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

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

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

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

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

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


[User] How does Tatum's getGenesisHash method return the genesis hash of the Solana network?

[Assistant]
The `getGenesisHash` method in Tatum's SDK is used to retrieve the genesis hash of the Solana network. The genesis hash represents the initial block in the blockchain and is crucial for various purposes such as verifying data integrity and serving as a reference point.

### How to Use the `getGenesisHash` Method

To use the `getGenesisHash` method, you need to follow these steps:

1. **Install the Tatum SDK**:
   You can install the Tatum SDK using Yarn:
   ```bash
   yarn add @tatumio/tatum
   ```

2. **Import and Initialize the SDK**:
   Import the necessary modules and initialize the SDK for the Solana network:
   ```javascript
   import { TatumSDK, Solana, Network } from '@tatumio/tatum';

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

3. **Call the `getGenesisHash` Method**:
   You can then call the `getGenesisHash` method to retrieve the genesis hash:
   ```javascript
   const res = await tatum.rpc.getGenesisHash();
   ```

4. **Destroy the SDK Instance**:
   After you are done, it is good practice to destroy the SDK instance to stop any background jobs:
   ```javascript
   await tatum.destroy();
   ```

### Return Value
The `getGenesisHash` method returns a string that is a base-58 encoded hash. This hash represents the genesis block of the Solana network.

### Example of JSON-RPC Request and Response
When you call the `getGenesisHash` method, it internally makes a JSON-RPC request that looks like this:
```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getGenesisHash"
}
```

The response from this request will be in the following format:
```json
{
  "jsonrpc": "2.0",
  "result": "GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC",
  "id": 1
}
```
In this response, the `result` field contains the genesis hash of the Solana network.

This method is essential for developers working with the Solana blockchain, as it provides a foundational piece of information necessary for various blockchain operations.

ncur 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.getGenesisHash()

await tatum.destroy() // Destroy Tatum SDK - needed for stopping background jobs
Overview
The getGenesisHash method returns the genesis hash of the Solana network. The genesis hash is an important piece of information in the blockchain world. It is the initial block or the very first block in a blockchain. The genesis hash can be used for various use cases such as to verify the integrity of data, as a reference point in the blockchain, and for debugging purposes.

Parameters
None

Return Object
Returns a string, which is a Hash as base-58 encoded string.
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getGenesisHash"
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "result": "GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC",
  "id": 1
}
getaccountinfo
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.getAccountInfo('ChkH4bTk7c5NSGbxvXx89yY2oU7rFJsr3Cq1gPNCCPVe')

await tatum.destroy() // Destroy Tatum SDK


[User] How does the QuickNode SDK facilitate the creation of optimized transactions?

[Assistant]
The QuickNode SDK facilitates the creation of optimized transactions through its methods designed to streamline the transaction assembly process. Specifically, it provides two key methods: `sendSmartTransaction` and `prepareSmartTransaction`.

### Key Features:

1. **sendSmartTransaction**: This method creates and sends a transaction with optimized settings. It handles the complexities of transaction assembly, including priority fees and compute unit limits.

   **Example Usage**:
   ```javascript
   const signature = await endpoint.sendSmartTransaction({
       transaction,
       keyPair: sender,
       feeLevel: "recommended",
   });
   ```

2. **prepareSmartTransaction**: This method prepares an optimized transaction, allowing developers to set up the transaction parameters before sending it.

### Steps for Optimization:
The SDK helps in optimizing transactions by guiding users through the following steps:
- Creating a transaction with the necessary instructions.
- Fetching and adding priority fees.
- Adding a priority fee instruction to the transaction based on the recommended value from the Priority Fee API.
- Simulating the transaction with a compute unit limit instruction.
- Adding a compute unit limit instruction based on the simulation results.
- Fetching and adding a recent blockhash to the transaction.
- Signing and sending the transaction.

By using these methods, developers can ensure that their transactions are optimized for performance and cost-efficiency on the Solana network. For more detailed information, users can refer to the QuickNode documentation.

e Units Resources
Guide: How to Optimize Solana Transactions - Priority Fees
Optimize Compute in Solana Programs
Introduction to Solana Compute Units and Transaction Fees
Transaction Assembly Best Practices
Combine priority fees and compute unit optimization in your transaction assembly:

Create a transaction with your instructions
Fetch and add priority fees
Add a priority fee instruction to the transaction (with fee level set to the recommended value returned from the Priority Fee API)
Simulate the transaction with a compute unit limit instruction
Add a compute unit limit instruction to the transaction with the computed limit from the simulation
Fetch and add a recent blockhash to the transaction
Sign and send the transaction
Check out our sample code here.

Utilize QuickNode SDK - Smart Transaction
The QuickNode SDK provides methods for handling the above steps for your:

sendSmartTransaction: Creates and sends a transaction with optimized settings.
prepareSmartTransaction: Prepares an optimized transaction.
Example usage:

const signature = await endpoint.sendSmartTransaction({
    transaction,
    keyPair: sender,
    feeLevel: "recommended",
});

Check out our docs for more details.

Use Jito Bundles
For advanced transaction optimization and bundling, consider using the Lil' JIT marketplace add-on. This add-on enables the creation of Jito Bundles, allowing for atomic execution of multiple transactions.

The add-on enables you to provide a tip to Jito validator producing


[User] What information is returned in the Bitquery response when querying for DEX trades on Solana?

[Assistant]
When querying for DEX trades on Solana using Bitquery, the response includes the following information:

1. **Block Information**: This includes the date of the block in which the trade occurred. You can specify a date range using the `Date` field with `minimum`, `since`, and `till` parameters.

2. **Trade Information**: This includes details about the trade itself:
   - **Dex**: The decentralized exchange where the trade took place, which includes the `ProtocolFamily` (e.g., Raydium).
   - **Market**: Information related to the trading market.

Here is an example of how the query might look:

```graphql
query {
  Solana(dataset: archive) {
    DEXTradeByTokens(
      where: {
        Trade: {
          Dex: {
            ProtocolFamily: {
              is: "Raydium"
            }
          }
        }
      }
      limit: {
        count: 100
      }
    ) {
      Block {
        Date(minimum: Block_Date
        selectWhere: {
          since: "2024-10-01"
          till: "2024-11-01"
        })
      }
      Trade {
        Dex {
          ProtocolFamily
        }
        Market {
          # Additional market-related fields can be included here
        }
      }
    }
  }
}
```

This query structure allows you to retrieve historical DEX trades on Solana, specifically filtering for trades on the Raydium protocol within a specified date range.

Arg {
                float
              }
              ... on Solana_ABI_Json_Value_Arg {
                json
              }
            }
          }
        }
      }
    }
  }
}

Pair Creation time for a specific pair
You can use the following query to get the pair creation time for a specific pair on Raydium DEX on Solana. But you need to use keyword query obviously.

You can run this query using this link.

  Solana {
    Instructions(
      where: {Transaction: {Result: {Success: true}}, Instruction: {Program: {Method: {is: "initializeUserWithNonce"}, Address: {is: "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8"}}, Accounts: {includes: {Address: {is: "CSyP9JXCVuVoobWrdtBqQeq7s7VWwNAJ7FFBhLnLFUCE"}}}}}
    ) {
      Block {
        Time
      }
      Transaction {
        Signature
      }
    }
  }
}

Get the historical Created pairs on any Solana DEX
This query will return information about the historical created pairs according to the selected date frame. You can find the query here

query{
  Solana(dataset: archive) {
    DEXTradeByTokens(
      where: {
        Trade: {
          Dex: {
            ProtocolFamily: {
              is: "Raydium"
            }
                    }
        }
      }
      limit: {
      count: 100
    }) {
      Block {
        Date(minimum: Block_Date
        selectWhere: {
          since: "2024-10-01"
          till: "2024-11-01"
        })
      }
      Trade {
        Dex {
          ProtocolFamily
        }
        Market{


[User] What does 'targetSignaturesPerSlot' represent in QuickNode's fee rate governor configuration?

[Assistant] In QuickNode's fee rate governor configuration, the `targetSignaturesPerSlot` represents the optimal signature rate within the cluster. This value indicates the desired number of signatures that should be processed in each slot, helping to guide the fee structure and performance of transactions within the network.

ted object that contains the current fee rate governor configuration:
burnPercent
The percentage of fees collected to be destroyed
maxLamportsPerSignature
The maximum achievable value of lamportsPerSignature for the upcoming slot
minLamportsPerSignature
The minimum achievable value of lamportsPerSignature for the upcoming slot
targetLamportsPerSignature
The target fee rate within the cluster
targetSignaturesPerSlot
The optimal signature rate within the cluster
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","id":1, "method":"getFeeRateGovernor"}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getFeeForMessage
Next
getFees
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
getFees RPC Method
Returns a recent block hash from the ledger, a fee schedule that can be used to compute the cost of submitting a transaction using it, and the last slot in which the blockhash will be valid. The API credit value for this method is 30.
Updated on
Aug 21, 2024
Please note that this method is deprecated, no longer available on Devnet and Testnet, and will be removed from Mainnet soon. For a simila


[User] How would I structure a cURL request to get token info from CoinGecko's API?

[Assistant]
To structure a cURL request to get token info from CoinGecko's API, you can use the following command. This example demonstrates how to retrieve specific token information by providing the required token contract address.

Here’s the cURL request format:

```bash
curl --request GET \
     --url https://pro-api.coingecko.com/api/v3/onchain/networks/{network}/tokens/{address}/info \
     --header 'accept: application/json' \
     --header 'x-cg-pro-api-key: YOUR_API_KEY'
```

Make sure to replace `{network}` with the appropriate network (e.g., `ethereum` for Ethereum tokens) and `{address}` with the specific token contract address you want to query. Additionally, replace `YOUR_API_KEY` with your actual CoinGecko API key.

For example, if you want to get information about the Tether USD token on the Ethereum network, the request would look like this:

```bash
curl --request GET \
     --url https://pro-api.coingecko.com/api/v3/onchain/networks/ethereum/tokens/0xdac17f958d2ee523a2206206994597c13d831ec7/info \
     --header 'accept: application/json' \
     --header 'x-cg-pro-api-key: YOUR_API_KEY'
```

This request will return a JSON response containing the token's information, including its name, symbol, and other relevant attributes.

ring
required
token contract address

Response

200
Get specific token info on a network

Response body
object
data
object
id
string
type
string
attributes
object

attributes object
Updated about 1 month ago

Tokens Data by Token Addresses
Pool Tokens Info by Pool Address
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/onchain/networks/network/tokens/address/info \
3
     --header 'accept: application/json'

Try It!
RESPONSE
1
{
2
  "data": {
3
    "id": "eth_0xdac17f958d2ee523a2206206994597c13d831ec7",
4
    "type": "token",
5
    "attributes": {
6
      "address": "0xdac17f958d2ee523a2206206994597c13d831ec7",
7
      "name": "Tether USD",
8
      "symbol": "USDT",
9
      "image_url": "https://assets.coingecko.com/coins/images/325/small/Tether.png?1696501661",
10
      "coingecko_coin_id": "tether",
11
      "websites": [
12
        "https://tether.to/"
13
      ],
14
      "description": "Tether (USDT) is a cryptocurrency with a value meant to mirror the value of the U.S. dollar...",
15
      "gt_score": 92.6605504587156,
16
      "discord_url": null,
17
      "telegram_handle": null,
18
      "twitter_handle": "Tether_to",
19
      "categories": [],
20
      "gt_categories_id": []
21
    }
22
  }
23
}

Pool Tokens Info by Pool Address
get
https://pro-api.coingecko.com/api/v3/onchain/networks/{network}/pools/{pool_address}/inf


[User] What happens if the requested block in QuickNode contains a transaction with a higher version than 'maxSupportedTransactionVersion'?

[Assistant]
If the requested block in QuickNode contains a transaction with a higher version than the specified `maxSupportedTransactionVersion`, an error will be returned. This parameter is used to ensure that only transactions up to the specified version are processed. If `maxSupportedTransactionVersion` is omitted, only legacy transactions will be returned, and any block containing a versioned transaction will also prompt an error.

Here’s an example of how you might set the `maxSupportedTransactionVersion` in a request:

```json
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "getFeeForMessage",
  "params": [
    "AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQAA",
    {
      "commitment": "processed",
      "maxSupportedTransactionVersion": 1
    }
  ]
}
```

In this example, if the block contains a transaction with a version higher than 1, an error will be returned.

nized this block as finalized
confirmed
string
The node will query the most recent block that has been voted on by the supermajority of the cluster
processed
string
The node will query its most recent block. Note that the block may not be complete
maxSupportedTransactionVersion
number
The maximum supported transaction version to return in responses. If the requested block contains a transaction with a higher version, an error will be returned. If this parameter is omitted, only legacy transactions will be returned, and a block containing any versioned transaction will prompt an error
Returns
result
Null if the transaction message is not found otherwise RpcResponse JSON object with the following fields:
context
The information about the current state of the program
apiVersion
The version of the Solana RPC API to use
slot
An integer representing the slot for which to retrieve the fee calculator
value
(u64 | null) The fee corresponding to the message at the specified blockhash
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  -d '
    {
      "id":1,
      "jsonrpc":"2.0",
      "method":"getFeeForMessage",
      "params":[
        "AQABAgIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAQAA",
        {
          "commitment":"processed"
        }
      ]
    }
'
Don't have an account yet?
Create your QuickNode endpoint in secon


[User] What does the 'currency' query parameter specify in the CoinGecko OHLCV request, and what is its default value?

[Assistant]
The 'currency' query parameter in the CoinGecko OHLCV request specifies the currency in which the OHLCV (Open, High, Low, Close, Volume) data should be returned. The available option for this parameter is to return the OHLCV data in either USD or the quote token.

The default value for the 'currency' parameter is 'usd'.

 to /networks

pool_address
string
required
pool contract address

timeframe
string
required
timeframe of the OHLCV chart

day
Query Params
aggregate
string
time period to aggregate each OHLCV
Available values (day) : 1
Available values (hour) : 1 , 4 , 12
Available values (minute) : 1 , 5 , 15
Default value: 1

before_timestamp
integer
return ohlcv data before this timestamp (integer seconds since epoch)

limit
integer
number of ohlcv results to return, maximum 1000
Default value: 100

currency
string
return ohlcv in USD or quote token
Default value: usd

token
string
return ohlcv for token
use this to invert the chart
Available values: 'base', 'quote' or token address

Response

200
Get OHLCV data of a pool

Response body
object
data
object
id
string
type
string
attributes
object

attributes object
meta
object
base
object

base object
quote
object

quote object
Updated 3 months ago

Most Recently Updated Tokens List
Trades
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/onchain/networks/network/pools/pool_address/ohlcv/day \
3
     --header 'accept: application/json'

Try It!
RESPONSE
1
{
2
  "data": {
3
    "id": "bc786a99-7205-4c80-aaa1-b9634d97c926",
4
    "type": "ohlcv_request_response",
5
    "attributes": {
6
      "ohlcv_list": [
7
        [
8
          1712534400,
9
          3454.61590249189,
10
          3660.859549


[User] How can I find the total trading volume for a coin on CoinGecko?

[Assistant]
To find the total trading volume for a coin on CoinGecko, you can access the `total_volume` object associated with the specific coin's data. The `total_volume` object provides the trading volume in the specified currency.

Here is an example of how you might retrieve the total trading volume using a hypothetical API call:

```json
{
  "id": "bitcoin",
  "total_volume": {
    "usd": 30000000000
  }
}
```

In this example, the total trading volume for Bitcoin is 30 billion USD. You would replace `"bitcoin"` with the ID of the coin you are interested in to get its respective total trading volume.

mber
market cap to total value locked ratio

fdv_to_tvl_ratio
number
fully diluted valuation to total value locked ratio

roi
number
coin return on investment

ath
object
coin all time high (ath) in currency

ath object
ath_change_percentage
object
coin all time high (ath) change in percentage

ath_change_percentage object
ath_date
object
coin all time high (ath) date

ath_date object
atl
object
coin all time low (atl) in currency

atl object
atl_change_percentage
object
coin all time low (atl) change in percentage

atl_change_percentage object
atl_date
object
coin all time low (atl) date

atl_date object
market_cap
object
coin market cap in currency

market_cap object
market_cap_rank
number
coin rank by market cap

fully_diluted_valuation
object
coin fully diluted valuation (fdv) in currency

fully_diluted_valuation object
market_cap_fdv_ratio
number
market cap to fully diluted valuation ratio

total_volume
object
coin total trading volume in currency

total_volume object
high_24h
object
coin 24h price high in currency

high_24h object
low_24h
object
coin 24h price low in currency

low_24h object
price_change_24h
number
coin 24h price change in currency

price_change_percentage_24h
number
coin 24h price change in percentage

price_change_percentage_7d
number
coin 7d price change in percentage

price_change_percentage_14d
number
coin 14d price change in percentage

price_change_percentage_30d
number
coin 30d price change in percentage

price_change_percentage_60d
n


[User] How does Solana's Anchor framework facilitate the resolution of accounts using PDA seeds defined in the program's IDL?

[Assistant]
The Anchor framework facilitates the resolution of accounts using Program Derived Address (PDA) seeds defined in the program's IDL (Interface Definition Language) by automatically resolving these accounts when constructing instructions in the Anchor client.

In the provided example, a PDA is defined using a static seed (`b"hello_world"`) and a dynamic seed (the signer's public key). This is done in the context of the program's accounts structure, which is annotated with the `#[account(...)]` attribute to specify the seeds and the bump.

Here's a breakdown of how this works:

1. **Program Definition**: The program defines the PDA using specific seeds. In the example, the PDA is derived from the static seed `b"hello_world"` and the dynamic seed, which is the signer's public key.

2. **IDL Generation**: The seeds defined in the program are included in the program's IDL file. This IDL serves as a contract that describes the program's interface, including the accounts and their constraints.

3. **Client Resolution**: When the Anchor client constructs instructions to interact with the program, it uses the IDL to automatically resolve the accounts based on the defined PDA seeds. This means that developers do not have to manually derive the PDA addresses; the Anchor framework handles this for them.

Here’s the relevant code snippet from the example:

```rust
#[derive(Accounts)]
pub struct InstructionAccounts<'info> {
    pub signer: Signer<'info>,
    #[account(
        seeds = [b"hello_world", signer.key().as_ref()],
        bump,
    )]
    pub pda_account: SystemAccount<'info>,
}
```

In this structure:
- The `signer` is a required account that must be a signer of the transaction.
- The `pda_account` is derived using the specified seeds, which includes the static seed and the signer's public key, along with a bump.

By using this approach, Anchor simplifies the process of working with PDAs, making it easier for developers to create and manage accounts in their Solana programs.

dress (PDA) seeds defined in the seeds constraint are included in the program's IDL file. This allows the Anchor client to automatically resolve accounts using these seeds when constructing instructions.

This example below shows the relationship between the program, IDL, and client.

Program
IDL
Client
The program below defines a pda_account using a static seed (b"hello_world") and the signer's public key as a dynamic seed.

use anchor_lang::prelude::*;

declare_id!("BZLiJ62bzRryYp9mRobz47uA66WDgtfTXhhgM25tJyx5");

#[program]
mod hello_anchor {
    use super::*;
    pub fn test_instruction(ctx: Context<InstructionAccounts>) -> Result<()> {
        msg!("PDA: {}", ctx.accounts.pda_account.key());
        Ok(())
    }
}

#[derive(Accounts)]
pub struct InstructionAccounts<'info> {
    pub signer: Signer<'info>,
    #[account(
        seeds = [b"hello_world", signer.key().as_ref()],
        bump,
    )]
    pub pda_account: SystemAccount<'info>,
}

CPIs with Anchor
Cross Program Invocations (CPI) refer to the process of one program invoking instructions of another program, which enables the composability of programs on Solana.

This section will cover the basics of implementing CPIs in an Anchor program, using a simple SOL transfer instruction as a practical example. Once you understand the basics of how to implement a CPI, you can apply the same concepts for any instruction.

Cross Program Invocations #
Let's examine a program that implements a CPI to the System Program's tr


[User] What does the 'range' field in the return object of Tatum's getBlockProduction method indicate?

[Assistant]
The 'range' field in the return object of Tatum's `getBlockProduction` method indicates the block production slot range. It contains two fields:

- **firstSlot**: This field indicates the first slot for which block production information is returned (inclusive).
- **lastSlot**: This field indicates the last slot for which block production information is returned (inclusive).

This allows users to understand the specific range of slots for which the block production data is relevant.

- needed for stopping background jobs
Overview
The getBlockProduction method provides information about the recent block production from the current or previous epoch. This can be used to monitor the performance and activity of validators on the Solana network.

Parameters
options (object, optional): This object can contain the following fields:
commitment(string, optional): Specifies the level of commitment to apply when fetching data.
Values: finalized confirmed processed
identity (string, optional): Only return results for this validator identity (base-58 encoded).
range (object, optional): Slot range to return block production for.
firstSlot (number): First slot to return block production information for (inclusive).
lastSlot (number, optional): Last slot to return block production information for (inclusive).
Return Object
The result will be a JSON object with value equal to object with the following fields:

byIdentity (object): A dictionary of validator identities, as base-58 encoded strings. The value is a two-element array containing the number of leader slots and the number of blocks produced.
range (object): Block production slot range with fields firstSlot and lastSlot indicating the first and last slot of block production information respectively.
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBlockProduction"
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 9887
    },
    "val


[User] How does Jito's 'jsonrpc' field facilitate communication with the API?

[Assistant]
In Jito's API, the `jsonrpc` field is a crucial part of the JSON-RPC protocol, which is used for communication between the client and the server. This field specifies the version of the JSON-RPC protocol being used.

According to the documentation, the `jsonrpc` field should be set to "2.0", indicating that the API follows the JSON-RPC 2.0 specification. This version provides a standard way to structure requests and responses, ensuring that both the client and server can understand the format of the messages being exchanged.

Here’s an example of how the `jsonrpc` field is used in a request:

```json
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "sendBundle",
  "params": [
    [
      "base58_encoded_bundle_1",
      "base58_encoded_bundle_2",
      "base58_encoded_bundle_3"
    ],
    {
      "encoding": "base64"
    }
  ]
}
```

In this example:
- The `jsonrpc` field is set to "2.0", which informs the server that the client is using the JSON-RPC 2.0 protocol.
- The `method` field specifies the action to be performed (in this case, `sendBundle`).
- The `params` field contains the parameters required for the method.

By adhering to this structure, Jito's API can reliably process requests and return appropriate responses, facilitating smooth communication between clients and the server.

zj8FTKBu8ndFClGLdh/38acclb7JwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM5VmqzBOi86PgXATWyyLk9tLPT8SstEH1LaVXnHY/BoAQECAAAMAgAAAAMAAAAAAAAA",
      "AfrPPQSnIBDrEXHWUV8l7rMa7Whibfdj69/d12d44PaLxhfQtROXz/x7obKe5M3oJK/fMiMlzoKLU8tno4D4MwYBAAEDZAJMcn3luKBgXdzj8FTKBu8ndFClGLdh/38acclb7Jx4Uhyxec67hYm1VqLV7JTSSYaC/fm7KvWtZOSRzEFT2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAzlWarME6Lzo+BcBNbLIuT20s9PxKy0QfUtpVecdj8GgBAgIAAQwCAAAAAAAAAAAAAAA="
    ],
    {
      "encoding": "base64"
    }
  ]
}'
Request Example base58
curl https://mainnet.block-engine.jito.wtf:443/api/v1/bundles -X POST -H "Content-Type: application/json" -d '{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "sendBundle",
  "params": [
    [
      "AKkzFdN4gPSEKhWoavYAEg7uGiKmuAwsMEVJ5uM8jxP27c86GERzygxbzGMWDQiPhKKmkwtZh9s8LdeBvuXLY8TEjxtsn7AnZ6JYJP8hsnbNAEprxFVfP4FpVRJM2n35u3DGX4pXsAVQ2ABxGuoRkDQTADCQExcQYf7BzLPFKgyd79MyuHwUBHr3mLbTpLsrRt1Hh5xuuZzuS6dKUSEaH1zWcxNAV57p2yQDnbL21ZQVPijcqgYutCVe7",
      "APtbdutAzvCRteQbcARea4yG88mxABQzzhuyzQYDYtXGjhqdnucwC2VBZhx7ebvnUDsMpU6tBZRzZzwF7C7Qd3GfbgNCgcqoyckRfazUUqWkPHGTtYZsi17tdJAwC2ptHtR7Rt3rnKCBog16tERmu2AJbezFdFnPfDTvH2YTWnzycgkah4u8Y2d5CJZewd8fyQxyWHWARfBmhrxtaC5gALvyYDUKyiehkN2VLNnKH3zwVoBJvRGhe8bPM",
      "DXPV292U8Q3kzS1BVroCWd563WG4yvMCZYcHfbTitkSDEPt49u2ivX2fpYag82MqekNn7E8KD2eM3Uy1whqEU6nNbpMPtkGZn4ukq9arsCdTB5QGR5h1vsWJA7ho8fmzbsrLBDNaV1SeqyeWo85v43YzVyjyv8WDF2ki46Wzvd1BYJ4gu9WJVNryMLknjq747oKsq8xT4tUSDSZNVcfzHN99d3FevzU8FHjyg7paSYdHW8HsDj16Hez


[User] How does QuickNode define the minimum slot at which a request can be evaluated?

[Assistant]
In QuickNode, the minimum slot at which a request can be evaluated is defined by the `minContextSlot` parameter. This parameter is an integer that specifies the earliest slot number from which the request can be processed. It ensures that the request is evaluated only if the current slot is greater than or equal to this minimum slot value.

This functionality is particularly useful for ensuring that the data being queried is relevant and has been finalized in the blockchain's state.

For example, when making a request to get the balance of an account, you can specify the `minContextSlot` to ensure that the balance is retrieved based on a certain point in the blockchain's history.

If you were to use this in a request, it might look something like this:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBalance",
  "params": [
    "7cVfgArCheMR6Cs4t6vz5rfnqd56vZq4ndaBrY5xkxXy",
    {
      "minContextSlot": 12345678
    }
  ]
}
```

In this example, the request to get the balance would only be evaluated if the current slot is at least 12,345,678.

 recent block that has been voted on by the supermajority of the cluster
processed
string
The node will query its most recent block. Note that the block may not be complete
minContextSlot
integer
The minimum slot at which the request can be evaluated
Returns
result
Null if the account doesn't exist otherwise RpcResponse JSON object with the following fields:
context
An object that contains metadata about the current state of the Solana network at the time the request was processed
apiVersion
The version number
slot
The current slot in the Solana cluster during which the transactions are processed and new blocks are added to the blockchain
value
The balance of the account of provided Pubkey
Request

Curl
curl https://docs-demo.solana-mainnet.quiknode.pro/ \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["7cVfgArCheMR6Cs4t6vz5rfnqd56vZq4ndaBrY5xkxXy"]}'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getAccountInfo
Next
getBlock
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

getBlock RPC Method
Returns identity and transaction information about a confirmed block in the ledger. The API credit value for t


[User] How does Solana allow for customized action metadata based on a user's wallet address?

[Assistant]
Solana allows for customized action metadata based on a user's wallet address through the use of Action chaining. When an Action is initiated, developers can tailor the metadata that is presented to the user by leveraging the specific wallet address involved in the transaction.

Here's how it works:

1. **Action Chaining**: After an Action's transaction is confirmed on-chain, the next action can be obtained. This allows developers to create a sequence of actions that can respond to the user's wallet address.

2. **Customized Metadata**: By accessing the user's wallet address, developers can generate customized action metadata. This can include personalized messages, images, or descriptions that are relevant to the user’s specific context or transaction history.

3. **Dynamic Experiences**: This capability enables developers to build more complex and dynamic user experiences within their applications, providing a more engaging interaction based on the user's unique wallet address.

For example, if a user has a specific NFT in their wallet, the action metadata can reflect that by displaying relevant information or images associated with that NFT.

While the documentation does not provide explicit code examples for this specific feature, the general approach would involve querying the user's wallet address and then using that information to modify the action metadata before presenting it to the user.

, the client must reject the transaction as malicious.

Action Errors #
Actions APIs should return errors using ActionError in order to present helpful error messages to the user. Depending on the context, this error could be fatal or non-fatal.

ActionError
export interface ActionError {
  /** simple error message to be displayed to the user */
  message: string;
}

When an Actions API responds with an HTTP error status code (i.e. 4xx and 5xx), the response body should be a JSON payload following ActionError. The error is considered fatal and the included message should be presented to the user.

For API responses that support the optional error attribute (like ActionGetResponse), the error is considered non-fatal and the included message should be presented to the user.

Action Chaining #
Solana Actions can be "chained" together in a successive series. After an Action's transaction is confirmed on-chain, the next action can be obtained and presented to the user.

Action chaining allows developers to build more complex and dynamic experiences within blinks, including:

providing multiple transactions (and eventually sign message) to a user
customized action metadata based on the user's wallet address
refreshing the blink metadata after a successful transaction
receive an API callback with the transaction signature for additional validation and logic on the Action API server
customized "success" messages by updating the displayed metadata (e.g. a new image and description)
To


[User] How does the 'lamports' value in the rewards array reflect the financial activity of an account in Solana?

[Assistant]
In Solana, the 'lamports' value in the rewards array represents the number of reward lamports that have been credited or debited to an account as a result of financial activities. This value is crucial for understanding the financial activity of an account because it indicates the net change in the account's balance due to various types of rewards.

The rewards array contains JSON objects with the following relevant fields:

- **pubkey**: The public key of the account that received the reward.
- **lamports**: The number of reward lamports credited (positive value) or debited (negative value) by the account.
- **postBalance**: The account balance in lamports after the reward was applied.
- **rewardType**: The type of reward, which can include "fee", "rent", "voting", or "staking".

For example, if an account receives a reward of 100 lamports for staking, the 'lamports' value would be +100, indicating an increase in the account's balance. Conversely, if the account incurs a fee of 50 lamports, the 'lamports' value would be -50, indicating a decrease.

This financial activity can be tracked over time by observing the changes in the 'lamports' values, allowing users to assess the performance and activity of their accounts in the Solana ecosystem.

xSupportedTransactionVersion is not set in request params, or if jsonParsed encoding is set in request params.
writable: <array[string]> - Ordered list of base-58 encoded addresses for writable loaded accounts
readonly: <array[string]> - Ordered list of base-58 encoded addresses for readonly loaded accounts
returnData: <object|undefined> - the most-recent return data generated by an instruction in the transaction, with the following fields:
programId: <string> - the program that generated the return data, as base-58 encoded Pubkey
data: <[string, encoding]> - the return data itself, as base-64 encoded binary data
computeUnitsConsumed: <u64|undefined> - number of compute units consumed by the transaction
version: <"legacy"|number|undefined> - Transaction version. Undefined if maxSupportedTransactionVersion is not set in request params.
signatures: <array> - present if "signatures" are requested for transaction details; an array of signatures strings, corresponding to the transaction order in the block
rewards: <array|undefined> - block-level rewards, present if rewards are requested; an array of JSON objects containing:
pubkey: <string> - The public key, as base-58 encoded string, of the account that received the reward
lamports: <i64>- number of reward lamports credited or debited by the account, as a i64
postBalance: <u64> - account balance in lamports after the reward was applied
rewardType: <string|undefined> - type of reward: "fee", "rent", "voting", "staking"
commission:


[User] In Solana's getMultipleAccounts method, how do I request a specific slice of an account's data?

[Assistant]
To request a specific slice of an account's data using the `getMultipleAccounts` RPC method in Solana, you can use the `dataSlice` parameter in your request. The `dataSlice` object allows you to specify the `length` and `offset` for the slice you want to retrieve.

Here’s how you can structure your request:

1. **length**: This specifies the number of bytes you want to return from the account's data.
2. **offset**: This indicates the byte offset from which to start reading the data.

Here’s an example of how to use the `getMultipleAccounts` method with the `dataSlice` parameter:

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getMultipleAccounts",
  "params": [
    [
      "YourPubkey1",
      "YourPubkey2"
    ],
    {
      "dataSlice": {
        "length": 64,  // Number of bytes to return
        "offset": 16   // Byte offset to start reading
      },
      "encoding": "base64" // Optional: specify the encoding format
    }
  ]
}
```

In this example:
- Replace `"YourPubkey1"` and `"YourPubkey2"` with the actual base-58 encoded Pubkeys of the accounts you want to query.
- The `dataSlice` requests a slice of 64 bytes starting from the 16th byte of the account's data.

Make sure that the `encoding` parameter is set according to your needs, as it determines how the returned account data will be formatted.

, "result": 500, "id": 1 }

getMultipleAccounts RPC Method
Edit Page
Returns the account information for a list of Pubkeys.

Parameters #
array required

An array of Pubkeys to query, as base-58 encoded strings (up to a maximum of 100)

object optional

Configuration object containing the following fields:

commitment string optional

minContextSlot number optional

The minimum slot that the request can be evaluated at

dataSlice object optional

Request a slice of the account's data.

length: <usize> - number of bytes to return
offset: <usize> - byte offset from which to start reading
Info
Data slicing is only available for base58, base64, or base64+zstd encodings.

encoding string optional

Default: base64
encoding format for the returned Account data

Values: jsonParsedbase58base64base64+zstd

Details
Result #
The result will be a JSON object with value equal to an array of:

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


[User] What happens after the program is successfully deployed in Solana?

[Assistant]
After a program is successfully deployed in Solana, you can invoke its instructions. This means that you can interact with the deployed program by sending transactions that call the functions defined within the program.

To summarize the steps that follow a successful deployment:

1. **Invoke Instructions**: You can start invoking the program's instructions, which allows you to execute the logic defined in your program.

2. **Program Address**: The address of the deployed program is now available and can be used to interact with it. This address is specified in the `declare_id!()` macro within your program.

3. **Transaction Handling**: You will need to construct and send transactions that include the necessary accounts and data required by the program's instructions.

4. **Account Management**: If your program creates or modifies accounts, you will manage those accounts according to the logic defined in your program.

5. **Testing**: It is common to test the program by invoking its instructions in a controlled environment, such as a local test validator or on the devnet.

By following these steps, you can effectively utilize your deployed program within the Solana ecosystem.

Accounts)]
pub struct Initialize<'info> {
    #[account(init, payer = signer, space = 8 + 8)]
    pub new_account: Account<'info, NewAccount>,
    #[account(mut)]
    pub signer: Signer<'info>,
    pub system_program: Program<'info, System>,
}

The #[account] macro is used to define a struct that represents the data structure of an account created and owned by the program.

#[account]
pub struct NewAccount {
  data: u64
}

Build and Deploy Program #
To build the program, simply run build in the terminal.

Terminal
build

Notice that the address in declare_id!() has been updated. This is your program's on-chain address.

Output
Terminal
$ build
Building...
Build successful. Completed in 1.46s.

Once the program is built, run deploy in the terminal to deploy the program to the network (devnet by default). To deploy a program, SOL must be allocated to the on-chain account that stores the program.

Before deployment, ensure you have enough SOL. You can get devnet SOL by either running solana airdrop 5 in the Playground terminal or using the Web Faucet.

Terminal
deploy

Output
Terminal
$ deploy
Deploying... This could take a while depending on the program size and network conditions.
Warning: 1 transaction not confirmed, retrying...
Deployment successful. Completed in 19s.

Alternatively, you can also use the Build and Deploy buttons on the left-side panel.

Build and Deploy
Build and Deploy

Once the program is deployed, you can now invoke its instructions.

Test Program #
Inclu


[User] In Solana, how can you confirm a transaction after requesting an airdrop?

[Assistant]
In Solana, after requesting an airdrop, you can confirm the transaction by using the `confirmTransaction` method from the `Connection` class. Here’s how you can do it:

1. First, you need to request an airdrop using the `requestAirdrop` method, which returns a signature.
2. Then, you can confirm the transaction using the signature returned from the airdrop request.

Here’s a code example demonstrating this process:

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

// Generate a new keypair
let fromPublicKey = web3.Keypair.generate();
let connection = new web3.Connection(web3.clusterApiUrl("devnet"), "confirmed");

// Request an airdrop
let airdropSignature = await connection.requestAirdrop(
  fromPublicKey.publicKey,
  web3.LAMPORTS_PER_SOL,
);

// Confirm the transaction
await connection.confirmTransaction(airdropSignature);
```

In this example:
- A new keypair is generated.
- An airdrop of 1 SOL (1 SOL = 1,000,000,000 lamports) is requested to the public key of the generated keypair.
- The transaction is confirmed using the signature returned from the `requestAirdrop` method.

This ensures that the airdrop transaction has been processed and the funds are available in the account.

{ethAddress.toString("hex")}`);

// Ethereum Address: 0xadbf43eec40694eacf36e34bb5337fba6a2aa8ee

// Fund a keypair to create instructions
let fromPublicKey = web3.Keypair.generate();
let connection = new web3.Connection(web3.clusterApiUrl("devnet"), "confirmed");

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

await connection.confirmTransaction({ signature: airdropSignature });

// Sign Message with Ethereum Key
let plaintext = Buffer.from("string address");
let plaintextHash = Buffer.from(keccak_256.update(plaintext).digest());
let { signature, recid: recoveryId } = secp256k1.ecdsaSign(
  plaintextHash,
  secp256k1PrivateKey,
);

// Create transaction to verify the signature
let transaction = new Transaction().add(
  web3.Secp256k1Program.createInstructionWithEthAddress({
    ethAddress: ethAddress.toString("hex"),
    plaintext,
    signature,
    recoveryId,
  }),
);

// Transaction will succeed if the message is verified to be signed by the address
await web3.sendAndConfirmTransaction(connection, transaction, [fromPublicKey]);

Message #
Source Documentation

Message is used as another way to construct transactions. You can construct a message using the accounts, header, instructions, and recentBlockhash that are a part of a transaction. A Transaction is a Message plus the list of required signatures required to execute the transaction.

Example Usage #
const { Buffer } = require("buffer");
const bs


[User] What is the process to add Dedicated staked connections to Helius services?

[Assistant]
To add Dedicated staked connections to Helius services, you need to contact Helius directly. The documentation specifies that dedicated staked connections can be added on to any existing plan by reaching out to their support or sales team.

There are no specific steps or forms mentioned in the documentation, so initiating contact is the primary method to proceed with adding dedicated staked connections.

Welcome
☀
What is Helius?
Solana's Leading RPC & API Platform

Helius is an enterprise-grade Solana development platform offering best-in-class RPCs, APIs, data streaming tools, and 24/7 customer support. Helius also runs the top Solana validator and offers both individual stakers and institutional staking partners 0% fees and 100% MEV rewards.

Solana RPCs 🏎
To read data from and write data to Solana, applications require an RPC node. Our globally distributed fleet of RPCs are powered by top-of-the-line hardware, offer 99.99% uptime SLAs, and are trusted by the largest wallets and applications on Solana.

We offer two types of RPC nodes:

Shared RPC nodes — rate-limited plans ideal for new projects that have moderate to high request loads

Dedicated RPC nodes — ideal for large-scale applications that require low latencies with no rate limits

Our battle-tested nodes are globally distributed across New York, Ashburn, Chicago, Vancouver, Los Angeles, Singapore, Tokyo, Frankfurt, and the UK. For Shared RPC nodes, we automatically send your requests to the closest node, guaranteeing the quickest and most efficient routing.

Staked Connections
Staked connections can improve transaction landing rates. As we run the largest validator on Solana, you can send transactions through our staked connections.

We offer two types of staked connections:

Shared staked connections — available through all of our paid standard plans

Dedicated staked connections — contact us to add on to any


[User] What limitations does the Jupiter agreement impose on the Licensee regarding the copying of the API or SDK?

[Assistant]
The Jupiter agreement imposes the following limitation on the Licensee regarding the copying of the API or SDK:

- The Licensee may copy the API or SDK only as necessary to exercise its rights under the agreement. This means that any copying beyond what is necessary for the Licensee to utilize the API or SDK as permitted by the agreement is not allowed.

This limitation ensures that the Licensee does not make excessive copies or distribute the API or SDK beyond the scope of their authorized use.

o this Agreement are duly organized and validly existing in good standing with all requisite power and authority to enter into this Agreement and conduct its business as is now being conducted. Neither Party is identified on, or engages in any transactions with anyone else listed on, any sanctions list maintained by the U.S. Department of the Treasury’s Office of Foreign Asset Control (“OFAC”) and have shared with each other a copy of their Articles of Incorporation and Significant Shareholder list.

2.5 Independent Contractor Relationship. The relationship between the Parties is that of independent contractors. Nothing in this Agreement shall be construed to create anything like the relationship of an employer and employee, joint venture, partnership, or joint association.

3. Other Rights and Limitations
3.1. Copies. Licensee may copy the API or SDK only as necessary to exercise its rights hereunder.

3.2. No Reverse Engineering. Licensee shall have no rights to any source code for any of the software in the API, except for the explicit rights to use the source code as provided to Licensee hereunder. Licensee may not reverse engineer, decompile, modify, disassemble or otherwise alter the API or any part thereof or otherwise reduce the API to human-perceivable form in whole or in part, except and only to the extent that such activity is expressly permitted by this Agreement or applicable laws.

3.3. Third Party Software. Licensee acknowledges that effective utilization of t


[User] What does the 'err' field indicate in the response from the signatureSubscribe method in ChainStack?

[Assistant]
In the response from the `signatureSubscribe` method in ChainStack, the `err` field indicates the result of the transaction status. Specifically:

- If the transaction failed, the `err` field will contain an error object detailing the reason for the failure.
- If the transaction succeeded, the `err` field will be `null`.

This allows developers to easily determine whether a transaction was successful or if there was an issue that needs to be addressed.

Here's a brief example of how the response might look:

```json
{
  "result": 1,
  "subscription": {
    "err": null,  // Indicates the transaction succeeded
    "status": "finalized",
    "confirmations": 5
  }
}
```

In this example, the `err` field is `null`, indicating that the transaction was successful.

CK_WEBSOCKET_ENDPOINT
# Wait for the connection to be established

Connected (press CTRL+C to quit)

> {"jsonrpc":"2.0","id":1,"method":"rootUnsubscribe","params":[0]}
Updated 18 days ago

signatureSubscribe | Solana
The signatureSubscribe method in Solana allows developers to receive real-time notifications about the status of a transaction signature. This subscription-based method provides updates when a transaction's status changes.

Parameters
string - Transaction signature to monitor, as base-58 encoded string
<config> - (optional) Configuration object:
commitment - The level of commitment desired when querying state:
"processed" - Most recent block that has reached the node
"confirmed" - Block that has reached 1 confirmation by supermajority of the cluster
"finalized" - Block that has been finalized by supermajority of the cluster
enableReceivedNotification - (optional) Boolean to enable notifications when transaction is received by the node. Default: false
Response
result - An integer subscription id (needed to unsubscribe)
subscription - An object containing signature status:
err - Error if transaction failed, null if transaction succeeded
status - Transaction status:
"received" - Transaction received by node (if enableReceivedNotification is enabled)
"processed" - Transaction has been processed
"confirmed" - Transaction has been confirmed
"finalized" - Transaction has been finalized
confirmations - Number of blocks since transaction was processed (null if finalized)


[User] What type of wallets does the example code demonstrate using with the Solana wallet adapter?

[Assistant]
The example code demonstrates the use of the `UnsafeBurnerWalletAdapter` as the wallet type with the Solana wallet adapter. This adapter is included in the `wallets` array, which is passed to the `WalletProvider`.

Here’s the relevant part of the code:

```javascript
const wallets = useMemo(
    () => [
        new UnsafeBurnerWalletAdapter(),
    ],
    [network]
);
```

This indicates that the application is set up to use the Unsafe Burner Wallet for connecting to the Solana network.

 --save \
    @solana/wallet-adapter-base \
    @solana/wallet-adapter-react \
    @solana/wallet-adapter-react-ui \
    @solana/wallet-adapter-wallets \
    @solana/web3.js@1 \
    react

The WalletProvider can than be setup to connect to a user's wallet and later send transactions.

import React, { FC, useMemo } from 'react';
import { ConnectionProvider, WalletProvider } from '@solana/wallet-adapter-react';
import { WalletAdapterNetwork } from '@solana/wallet-adapter-base';
import { UnsafeBurnerWalletAdapter } from '@solana/wallet-adapter-wallets';
import {
    WalletModalProvider,
    WalletDisconnectButton,
    WalletMultiButton
} from '@solana/wallet-adapter-react-ui';
import { clusterApiUrl } from '@solana/web3.js';

// Default styles that can be overridden by your app
require('@solana/wallet-adapter-react-ui/styles.css');

export const Wallet: FC = () => {
    // The network can be set to 'devnet', 'testnet', or 'mainnet-beta'.
    const network = WalletAdapterNetwork.Devnet;

    // You can also provide a custom RPC endpoint.
    const endpoint = useMemo(() => clusterApiUrl(network), [network]);

    const wallets = useMemo(
        () => [
            new UnsafeBurnerWalletAdapter(),
        ],
        // eslint-disable-next-line react-hooks/exhaustive-deps
        [network]
    );

    return (
        <ConnectionProvider endpoint={endpoint}>
            <WalletProvider wallets={wallets} autoConnect>
                <WalletModalProvider>
                    <Wa