[User] What percentage of MET is allocated for DAO contributors according to the Meteora proposal?

[Assistant] According to the Meteora proposal, 2% of MET is allocated for DAO contributors.

th, energize participation in the DAO, and drive liquidity growth on Solana.

In the longer term, we want the MET DAO to become a major governing body for the ecosystem to come together to improve the long-term sustainability of liquidity protocol and providers.

DAO Formation
To kick off the DAO, 20% of MET will soon be distributed as ve-locked MET to MER stakeholders as per the Feb 2022 snapshot and calculations to give our stakeholders governance voting power.

The remaining 80% will remain under DAO governance. We will suggest early guidelines for how we believe the 80% can be leveraged for maximum benefit over the long run, but the DAO will have technical control of the tokens from day one. The only portion of the DAO that will be set aside from day 1 will be 10% for individual MER holders who have assets in FTX. This will be gradually released when there is a confirmed verifiable way of validating the MER holdings of individuals.

In addition, the DAO’s primary role will be to decide on key MET tokenomics, distributions, team incentives, and certain risk parameters for Meteora protocols, such as lending pool utilization thresholds for dynamic vaults.

Bringing Expertise Into The DAO
One of the most important (and oft neglected aspects of DAO formations) is to ensure that the people who are the most connected to the actual state of liquidity and ecosystem have the necessary incentives to participate.

We intend to propose allocating 2% of MET for DAO contributors when we


[User] What metadata properties are required to upload an image file for a Solana NFT?

[Assistant]
To upload an image file for a Solana NFT, the following metadata properties are required:

1. **name**: A string representing the name of the NFT.
2. **symbol**: A string representing the symbol for the NFT (can be an empty string).
3. **uri**: A string that points to the metadata URI, which contains additional information about the NFT.
4. **seller_fee_basis_points**: An integer that specifies the seller fee in basis points (e.g., 500 means a 5% fee).
5. **external_url**: A string that provides an external URL related to the NFT.
6. **attributes**: An array of objects, where each object contains `trait_type` and `value` to describe the attributes of the NFT.
7. **collection**: An object that contains the `name` and `family` of the collection the NFT belongs to.
8. **properties**: An object that includes:
   - **files**: An array of objects, each containing:
     - **uri**: A string that points to the image file (e.g., "image.png").
     - **type**: A string that indicates the type of the file (e.g., "image/png").
   - **category**: A string that specifies the category of the asset (e.g., "image").
   - **maxSupply**: An integer that indicates the maximum supply of the NFT (0 for unlimited).
   - **creators**: An array of objects, each containing:
     - **address**: A string representing the creator's wallet address.
     - **share**: An integer that specifies the share of the creator.

Here’s an example of how these properties might look in the metadata:

```javascript
const metadata = {
  name: "Custom NFT #1",
  symbol: "",
  uri: "https://example.com/metadata.json",
  seller_fee_basis_points: 500,
  external_url: "https://www.customnft.com/",
  attributes: [
    {
      trait_type: "NFT type",
      value: "Custom",
    },
  ],
  collection: {
    name: "Test Collection",
    family: "Custom NFTs",
  },
  properties: {
    files: [
      {
        uri: "https://example.com/image.png",
        type: "image/png",
      },
    ],
    category: "image",
    maxSupply: 0,
    creators: [
      {
        address: "CBBUMHRmbVUck99mTCip5sHP16kzGj3QTYB8K3XxwmQx",
        share: 100,
      },
    ],
  },
};
```

This structure ensures that the NFT is properly defined and can be uploaded successfully.

y custom NFT #1",
    seller_fee_basis_points: 500,
    external_url: "https://www.customnft.com/",
    attributes: [
      {
        trait_type: "NFT type",
        value: "Custom",
      },
    ],
    collection: {
      name: "Test Collection",
      family: "Custom NFTs",
    },
    properties: {
      files: [
        {
          uri: imageUrl,
          type: "image/png",
        },
      ],
      category: "image",
      maxSupply: 0,
      creators: [
        {
          address: "CBBUMHRmbVUck99mTCip5sHP16kzGj3QTYB8K3XxwmQx",
          share: 100,
        },
      ],
    },
    image: imageUrl,
  };

  const metadataString = JSON.stringify(metadata);

  const metadataTransaction = await arweave.createTransaction({
    data: metadataString,
  });

  metadataTransaction.addTag("Content-Type", "application/json");

  await arweave.transactions.sign(metadataTransaction, wallet);

  console.log("metadata txid", metadataTransaction.id);

  const txnResult = await arweave.transactions.post(metadataTransaction);

  console.log(txnResult);
})();

Mint the NFT #
mint-nft.ts
import { createUmi } from "@metaplex-foundation/umi-bundle-defaults";
import {
  generateSigner,
  percentAmount,
  keypairIdentity,
} from "@metaplex-foundation/umi";
import { clusterApiUrl } from "@solana/web3.js";
import {
  createNft,
  fetchDigitalAsset,
  mplTokenMetadata,
} from "@metaplex-foundation/mpl-token-metadata";
import "dotenv/config";

(async () => {
  try {
    console.log("Loading


[User] How does the #[instruction(message: String)] annotation function in the context of Solana's Create struct?

[Assistant]
The `#[instruction(message: String)]` annotation in Solana's Create struct is used to enable the struct to access parameters passed to the instruction when it is invoked. Specifically, in the context of the Create struct, this annotation allows the `message` parameter to be directly accessible within the struct.

Here’s how it functions:

1. **Parameter Binding**: When a transaction is sent to invoke the instruction, the parameters defined in the annotation (in this case, `message: String`) are extracted from the instruction data. This means that when the instruction is called, the string provided will be automatically bound to the `message` field in the Create struct.

2. **Ease of Access**: By using this annotation, developers can easily access the input parameters without needing to manually parse the instruction data. This simplifies the code and reduces the likelihood of errors in handling input data.

3. **Integration with Instruction Logic**: The `message` can then be utilized within the instruction logic, such as when creating a new account or processing the message in some way.

Here’s a simplified example of how it might look in the code:

```rust
#[derive(Accounts)]
pub struct Create<'info> {
    #[account(mut)]
    pub user: Signer<'info>,
    #[account(init, payer = user, space = 8 + std::mem::size_of::<MessageAccount>())]
    pub message_account: Account<'info, MessageAccount>,
    pub system_program: Program<'info, System>,
}

#[derive(AnchorSerialize, AnchorDeserialize)]
pub struct CreateMessage {
    pub message: String,
}

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

    pub fn create(ctx: Context<Create>, message: String) -> ProgramResult {
        // The message parameter is accessible here
        msg!("Creating message: {}", message);
        // Logic to create the message account goes here
        Ok(())
    }
}
```

In this example, the `message` parameter passed to the `create` function is directly accessible and can be used as needed within the function logic.

 is only for our understanding and has no effect on account validation, however, it is recommended to use descriptive account names.

The Create struct defines the accounts required for the create instruction.

user: Signer<'info>

Represents the user creating the message account
Marked as mutable (#[account(mut)]) as it pays for the new account
Must be a signer to approve the transaction, as lamports are deducted from the account
message_account: Account<'info, MessageAccount>

The new account created to store the user's message
init constraint indicates the account will be created in the instruction
seeds and bump constraints indicate the address of the account is a Program Derived Address (PDA)
payer = user specifies the account paying for the creation of the new account
space specifies the number of bytes allocated to the new account's data field
system_program: Program<'info, System>

Required for creating new accounts
Under the hood, the init constraint invokes the System Program to create a new account allocated with the specified space and reassigns the program owner to the current program.
The #[instruction(message: String)] annotation enables the Create struct to access the message parameter from the create instruction.

The seeds and bump constraints are used together to specify that an account's address is a Program Derived Address (PDA).

lib.rs
seeds = [b"message", user.key().as_ref()],
bump,

The seeds constraint defines the optional inputs used to derive the P


[User] How does Meteora determine the deposit amount for each token type in a pair when adding liquidity to a pool?

[Assistant]
In Meteora, when adding liquidity to a DLMM (Dynamic Liquidity Market Maker) pool, the deposit amount for each token type in a pair is determined based on the ratio of the two token types in the pool, rather than requiring a fixed 50:50 deposit.

Specifically, if the price range you set covers the active bin, the deposit will be made according to the existing ratio of the two token types in the pool. This means that you can deposit different amounts of each token based on your trading and volatility strategy.

For example, if you are depositing into a BONK-SOL pool, the amounts you choose to deposit do not need to be equal in value or quantity. Instead, it depends on your strategy regarding how you plan to trade or manage volatility, such as whether you intend to sell more of one token over the other at certain price bins.

Here’s a simplified code example to illustrate how you might determine your deposit amounts based on a specific strategy:

```python
# Example of determining deposit amounts based on token ratios
def calculate_deposit_amounts(total_deposit, token_ratio):
    token_a_amount = total_deposit * token_ratio[0] / sum(token_ratio)
    token_b_amount = total_deposit * token_ratio[1] / sum(token_ratio)
    return token_a_amount, token_b_amount

# Assuming we want to deposit $1000 into a BONK-SOL pool
total_deposit = 1000
# Example ratio: 70% BONK and 30% SOL
token_ratio = [0.7, 0.3]

bonk_amount, sol_amount = calculate_deposit_amounts(total_deposit, token_ratio)
print(f"Deposit {bonk_amount} in BONK and {sol_amount} in SOL")
```

This example shows how you can calculate the deposit amounts based on your desired ratios for the tokens in the pool.

Wait for the price to return within your range, especially if it is not too far out

Or if you want to continue earning fees immediately, rebalance by withdrawing your liquidity and opening a new position with a new price range / use additional funds to open a new position with a new price range

When adding liquidity, why does the wallet simulation pop-up show a different token amount from the UI?

When you add liquidity to a DLMM pool, the function does a balanced deposit for the active bin, based on the token ratio in the active bin. There’s usually a tiny discrepancy between what is shown on the UI vs what is on the wallet simulation. We are making improvements so that they would show the exact amount as the simulation.

When adding liquidity, do the two token types in a pair need to be in a 50:50 deposit for the active bin?

No. When you deposit, if the price range covers the active bin, you will deposit according to the ratio of the 2 token types in the pool.

What determines the deposit amount for each token type in a pair on DLMM? For example, if depositing into a BONK-SOL pool, should the two tokens be of the same ratio and have the same value in USDT (50:50 autofill)?

Depends on your trading and volatility strategy. For example, whether you aim to sell more of a particular token e.g. BONK or SOL at certain bins and bin prices, within the range you set when using the Spot, Curve, or Bid Ask volatility strategy.

Why can’t I set a wider price range than what is imme


[User] How does QuickNode handle the destinationTokenAccount when it belongs to a different user?

[Assistant]
In QuickNode, when the `destinationTokenAccount` belongs to a different user, it is important to ensure that the account is not closed unintentionally. To handle this scenario, the `closeDestinationTokenAccount` parameter is set to true by default. This means that the system will not attempt to close the `destinationTokenAccount`, thus preventing any unauthorized actions on an account that does not belong to the user initiating the transaction.

This approach helps maintain the integrity of user accounts and ensures that only the rightful owner can manage their token accounts.

tinationTokenAccount is set because the destinationTokenAccount may belong to a different user that we have no authority to close. By default, it is set to true
useSharedAccounts
boolean
This enables the usage of shared program accountns. That means no intermediate token accounts or open orders accounts need to be created for the users. But it also means that the likelihood of hot accounts is higher. By default, it is set to true
feeAccount
string
The fee token account is derived using the seeds ['referral_ata', referral_account, mint], along with the REFER4ZgmyYx9c6He5XfaTMiGfdLwRnkV4RPp9t9iF3 referral contract. Only pass in if you set a feeBps and make sure that the feeAccount has been created
computeUnitPriceMicroLamports
integer
The compute unit price to prioritize the transaction, the additional fee will be computeUnitLimit (1400000) * computeUnitPriceMicroLamports. If auto is used, Jupiter will automatically set a priority fee and it will be capped at 5,000,000 lamports / 0.005 SOL
prioritizationFeeLamports
integer
Prioritization fee lamports paid for the transaction in addition to the signatures fee. Mutually exclusive with compute_unit_price_micro_lamports. If auto is used, Jupiter will automatically set a priority fee and it will be capped at 5,000,000 lamports / 0.005 SOL
asLegacyTransaction
boolean
Request a legacy transaction rather than the default versioned transaction, needs to be paired with a quote using asLegacyTransaction otherwise the transaction might be


[User] What is the significance of the `try_from_slice` method when working with PDA accounts in Solana?

[Assistant]
The `try_from_slice` method is significant when working with Program Derived Addresses (PDAs) in Solana because it is used to deserialize the account data stored in the PDA into a structured format that can be easily manipulated in your program.

When you create a PDA, you typically store some state information in its associated account. This data is stored as a byte array, and to work with it in a structured way (e.g., to access specific fields), you need to convert this byte array into a Rust struct. The `try_from_slice` method facilitates this conversion.

Here is an example of how `try_from_slice` is used in the context of a PDA:

```rust
let mut pda_account_state = HelloState::try_from_slice(&pda_account.data.borrow())?;
```

In this line:
- `HelloState` is a struct that represents the state of the PDA.
- `pda_account.data.borrow()` retrieves the raw byte data from the PDA account.
- `try_from_slice` attempts to deserialize this byte data into an instance of `HelloState`.

If the byte data does not match the expected format of `HelloState`, `try_from_slice` will return an error, allowing you to handle it appropriately. This method is crucial for ensuring that the data you read from the PDA is valid and correctly structured, which is essential for the integrity of your program's logic.

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

    // Setting state for PDA
    let mut pda_account_state = HelloState::try_from_slice(&pda_account.data.borrow())?;
    pda_account_state.is_initialized = true;
    pda_account_state.serialize(&mut &mut pda_account.data.borrow_mut()[..])?;

    Ok(())
}

One can send the required accounts via client as follows

create-pda-client.ts
import {
  clusterApiUrl,
  Connection,
  Keypair,
  LAMPORTS_PER_SOL,
  PublicKey,
  sendAndConfirmTransaction,
  SystemProgram,
  Transaction,
  TransactionInstruction,
} from "@solana/web3.js";

const PAYER_KEYPAIR = Keypair.generate();

(async () => {
  const connection = new Connection(clusterApiUrl("devnet"), "confirmed");
  const latestBlockHash = await connection.getLatestBlockhash();
  const programId = new PublicKey(
    "6eW5nnSosr2LpkUGCdznsjRGDhVb26tLmiM1P8RV1QQp",
  );

  // Airdrop to Payer
  await connection.confirmTransaction(
    {
      blockhash: latestBlockHash.blockhash,
      lastValidBlockHeight: latestBlockHash.lastValidBlockHeight,
      signature: await connection.requestAirdrop(
        PAYER_KEYPAIR.publicKey,
        LAMPORTS_PER_SOL,
      ),
    },
    "confirmed",
  );

  const [pda, bump] = await PublicKey.findProgramAddress(
    [Buffer.from("customaddress"), PAYER_KEYPAIR.publicKey.toBuffer()],
    programId,
  );

  console.log(`PDA Pubkey: ${pda.toString()}`);

  const createPDAIx = new Transacti


[User] How is the total AUM calculated in Jupiter, and what does it represent?

[Assistant]
In Jupiter, the total Assets Under Management (AUM) is calculated as the sum of the AUM from all custody accounts. The AUM for each custody account is determined using the following formula:

1. **Calculate Net Asset Value (NAV)**:
   - The NAV is calculated using the formula:
     ```
     nav = available_tokens * current_token_price
     ```
   - Where `available_tokens` is the difference between `owned` tokens and `locked` tokens.

2. **Calculate Guaranteed USD**:
   - The guaranteed USD is calculated as:
     ```
     guaranteed_usd = size of all trades (USD) - collateral of all trades (USD)
     ```
   - This value represents an estimate of the total size of all long positions and is updated when positions are opened or closed.

3. **Update NAV with Guaranteed USD**:
   - The NAV is then adjusted by adding the guaranteed USD:
     ```
     nav += guaranteed_usd
     ```

4. **Calculate AUM**:
   - The AUM for each custody is calculated based on the unrealized profit and loss (PnL):
     - If traders are losing on short positions:
       ```
       aum = nav + unrealized_pnl
       ```
     - If traders are not losing on short positions:
       ```
       aum = nav - unrealized_pnl
       ```

5. **Calculate Total AUM**:
   - Finally, the total AUM is calculated as:
     ```
     total_aum = Σ(aum)
     ```
   - This means summing the AUM of all custody accounts.

### What Total AUM Represents:
The total AUM represents the overall value of assets managed by the pool, taking into account both the current value of the assets and the unrealized profits or losses from trading positions. It provides a comprehensive view of the financial health and performance of the pool, reflecting both the assets held and the impact of trading activities.

lobal_short_sizes * (|global_short_average_prices - current_price|)) / global_short_average_prices)

tip
If current_price > global_short_average_prices, traders are losing on short positions.

Net Asset Value (NAV):
available_tokens = owned - locked

nav = available_tokens * current_token_price

guaranteed_usd = size of all trades (USD) - collateral of all trades (USD)

nav += guaranteed_usd

info
The guaranteed_usd value in each Custody account represents an estimate of the total size of all long positions. It is only an estimate as guaranteed_usd is only updated when positions are updated (i.e. opening / closing positions, updating collateral). It does not update in real-time when asset prices change.

guaranteed_usd is used to calculate the pool's AUM as well as the overall PnL for all long positions efficiently.

Assets Under Management (AUM)
If traders are losing on short positions, the losses are added to the pool's AUM:

aum = nav + unrealized_pnl

Otherwise, traders' profits are deducted from the pool's AUM:

aum = nav - unrealized_pnl

The Total AUM is then calculated as the sum of all the custodies' AUM:

total_aum = Σ(aum)

note
The pool sizes displayed on the Earn page do not add up to the pool's AUM. This discrepancy occurs because the Earn page shows each custody's owned value in USD without accounting for the traders' unrealized PnL.

This simplified representation on the Earn page provides a quick overview of the pool's holdings but doesn't reflect the JLP poo


[User] How does Jupiter handle suspicions of illegal activities such as money laundering or terrorism financing?

[Assistant]
Jupiter has specific measures in place to handle suspicions of illegal activities, including money laundering and terrorism financing. According to the documentation, if there is a suspicion that a user is using the Interface or the Protocol in connection with any illegal activity, Jupiter may refuse to provide access to the Interface until requested information is provided. This information may include, but is not limited to, identification documents such as passports, driver's licenses, utility bills, and government identification cards.

Furthermore, Jupiter reserves the right to take preventive actions against money laundering, terrorism financing, or other illegal activities. This may include blocking a user's access to the Interface or the Protocol and providing user information to regulatory authorities if necessary.

In summary, Jupiter actively monitors for illegal activities and has the authority to take action to prevent such activities, ensuring compliance with relevant regulations.

t limited to, passports, driver's licenses, utility bills, photographs of associated individuals, government identification cards or sworn statements before notaries or other equivalent professionals. Notwithstanding anything herein, we may, in its sole discretion, refuse to provide access to the Interface to you until such requested information is provided, or in the event that, based on information available to us, you are suspected of using the Interface or the Protocol in connection with any money laundering, terrorism financing, or any other illegal activity. In addition, we shall be entitled to use any possible efforts for preventing money laundering, terrorism financing or any other illegal activity, including without limitation blocking of your access to the Interface or the Protocol, or providing your information to any regulatory authority.

6. Disclaimers
You understand and agree that the Interface enables access to an online, decentralized, and autonomous protocol and environment, and associated decentralized networks, that are not controlled by Jupiter. We do not have access to your private key and cannot initiate an interaction with your virtual currency or otherwise access your virtual currency. We are not responsible for any activities that you engage in when using your wallet, or the Interface.

Jupiter cannot and does not represent or guarantee that any of the information available through the Interface is accurate, reliable, current, complete or appropriat


[User] What actions should a parent take if they believe their child has submitted data to Jupiter?

[Assistant] If a parent believes their child has submitted data to Jupiter, they should contact Jupiter using the information provided in the privacy policy. Upon receiving the request, Jupiter will take steps to delete the data from their interface.

uestions about exercising any of the above rights. If You wish to learn more about the GDPR and Your rights, the Information Commissioner’s Office website is a reliable source.

7. Privacy of children
Our Interface is not directed to collect any data from people under the age of 18. We do not knowingly allow anyone under 18 years old to submit any data to our Interface. If you believe your child may have provided us with their data, you can contact us using the information in this Policy and we will delete the data from our Interface.

8. Transfer of Personal Data
Transfers to third countries shall be made subject to appropriate safeguards, namely Standard Contractual Clauses adopted by the supervisory authority and approved by the Commission. Copy of the foregoing appropriate safeguards may be obtained by you upon a prior written request sent. We may instruct you on further steps to be taken with the purpose of obtaining such a copy, including your obligation to assume confidentiality commitments in connection with being disclosed the Jupiter proprietary and personal information of third parties as well as terms of their relationships with Jupiter.

Keep in mind that the use of the Interface based on public blockchains is intended to immutably record transactions across wide networks of computer systems. Many blockchains are open to forensic analysis which can lead to deanonymization and the unintentional revelation of Personal Data, in particular when blockchain data is c


[User] What does Meteora mean by 'Zero Slippage' in trading within an active bin?

[Assistant]
In Meteora, 'Zero Slippage' refers to the trading condition within an active bin where trades can be executed without any price impact or deviation from the expected price. This means that when a trader executes a swap within an active bin, the price at which the trade is executed is exactly the same as the price that was anticipated, ensuring that there are no additional costs incurred due to slippage.

This feature allows Liquidity Providers (LPs) to concentrate their liquidity more effectively, as they can be confident that their trades will not suffer from slippage, thereby capturing more volume and fees than they could in traditional trading environments where slippage is a common issue.

ciency.

Zero Slippage: Trading within an active bin has zero slippage or price impact. This makes it easier for LPs to concentrate their liquidity even further and capture more volume and fees than they could before.

Dynamic Fees: LPs earn dynamic swap fees during high market volatility to compensate for impermanent loss. This is because the fees charged on swaps increase with volatility, which helps to offset the losses that LPs can experience in volatile markets.

Flexible Liquidity: LPs can build flexible liquidity distributions according to their strategies. For example, an LP could concentrate their liquidity in a narrow price range around the current market price to minimize slippage, or they could spread their liquidity across a wider price range to reduce effects of impermanent loss.

For Project Teams
New Creative Ways to Launch Tokens: DLMM opens up new creative ways for project teams to launch their tokens. For example, a project team could use DLMM to implement a bonding curve, which is a type of token sale mechanism that rewards early buyers.

Flexible Token Design: Project teams can design their own bonding curves depending on how they plan to sell their tokens. For example, a project team could use a bonding curve to sell tokens and use the funds there to support a minimum token buyback price guaranteeing a token floor price.

Organic Liquidity Growth: DLMM can help project teams organically grow liquidity for their tokens. For example, a project team could u


[User] Does ChainStack support real-time notifications through the programSubscribe method in Solana?

[Assistant]
Yes, ChainStack supports real-time notifications through the `programSubscribe` method in Solana. This method allows developers to receive updates whenever any account owned by a specific program is modified.

To use the `programSubscribe` method, you would typically establish a WebSocket connection to your ChainStack Solana node endpoint and send a subscription request with the public key of the program you want to monitor.

Here’s a brief example of how you might use it:

1. First, connect to your ChainStack WebSocket endpoint using a WebSocket client:

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

2. Once connected, you can subscribe to a program by sending a JSON-RPC request like this:

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

This will allow you to receive real-time notifications about changes to all accounts owned by the specified program.

 method in Solana allows a client to unsubscribe from a specific account subscription. This method can be used to cancel an existing subscription to account updates.

See also accountSubscribe | Solana.

👍
Get your own Solana node endpoint today

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

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

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

wscat

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

Connected (press CTRL+C to quit)

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

programSubscribe | Solana
The programSubscribe method in Solana allows developers to receive real-time notifications about changes to all accounts owned by a specific program. This subscription-based method provides updates whenever any account owned by the monitored program is modified.

Parameters
publicKey - The progr


[User] What type of information can I retrieve using the 'getBundleStatuses' method in QuickNode?

[Assistant]
The `getBundleStatuses` method in QuickNode allows you to retrieve the statuses of specific bundles. When you use this method, you can obtain the following information for each bundle:

1. **bundle_id**: The unique identifier for the bundle.
2. **status**: The current status of the bundle, which can be one of the following:
   - **Pending**: The bundle has not yet failed, landed, or been marked invalid.
   - **Failed**: All regions have marked the bundle as failed, and it hasn't been forwarded.
   - **Landed**: The bundle has successfully landed on-chain, verified through RPC or the `bundles_landed` table.
3. **landed_slot**: The slot in which the bundle landed, or null if the bundle is invalid.

### Example Request

Here’s an example of how to use the `getBundleStatuses` method with a cURL command:

```bash
curl 'https://docs-demo.solana-mainnet.quiknode.pro/' \
--header 'Content-Type: application/json' \
--data '
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getBundleStatuses",
  "params": [
    [
      "b31e5fae4923f345218403ac1ab242b46a72d4f2a38d131f474255ae88f1ec9a",
      "e3c4d7933cf3210489b17307a14afbab2e4ae3c67c9e7157156f191f047aa6e8",
      "a7abecabd9a165bc73fd92c809da4dc25474e1227e61339f02b35ce91c9965e2"
    ]
  ]
}
'
```

In this example, you would replace the bundle IDs in the `params` array with the specific bundle IDs you want to check the statuses for. The response will provide you with the status and other relevant details for each of the specified bundles.

le ID is not found in the system (5-minute look back). It is Pending when the bundle has not failed, landed, or been marked invalid. The status is Failed when all regions have marked the bundle as failed and it hasn't been forwarded. The status is Landed when the bundle has successfully landed on-chain, verified through RPC or the bundles_landed table.
landed_slot
integer
The slot this bundle landed in, otherwise null if it is invalid
Request

Curl
curl 'https://docs-demo.solana-mainnet.quiknode.pro/' \
--header 'Content-Type: application/json' \
--data '
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getInflightBundleStatuses",
  "params": [
    [
    "b31e5fae4923f345218403ac1ab242b46a72d4f2a38d131f474255ae88f1ec9a",
    "e3c4d7933cf3210489b17307a14afbab2e4ae3c67c9e7157156f191f047aa6e8",
    "a7abecabd9a165bc73fd92c809da4dc25474e1227e61339f02b35ce91c9965e2",
    "e3934d2f81edbc161c2b8bb352523cc5f74d49e8d4db81b222c553de60a66514",
    "2cd515429ae99487dfac24b170248f6929e4fd849aa7957cccc1daf75f666b54"
    ]
  ]
}
'
Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
getBundleStatuses
Next
getTipAccounts
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
getTipAccounts RPC Method
Retr


[User] What additional cost considerations should be taken into account when using Tatum's archive method for complex queries?

[Assistant]
The documentation snippet mentions that using the archive method on full archive nodes for complex queries might take longer and incur additional costs. However, it does not provide specific details on what those additional costs might be or how they are calculated.

To summarize, when using Tatum's archive method for complex queries, you should consider the following:

1. **Time Consumption**: Complex queries may take longer to process, which could affect the overall performance of your application.
2. **Cost Implications**: There may be additional costs associated with executing complex queries on archive nodes, but the specifics of these costs are not detailed in the provided documentation.

For precise cost details, it would be advisable to consult Tatum's official pricing documentation or reach out to their support for clarification on how costs are structured for using the archive method.

ll. The balance, using mint-prescribed decimals DEPRECATED
uiAmountString: The balance as a string, using mint-prescribed decimals
If withContext is set to true, the response will also include a context object:

context: An object containing details about the context in which the data was fetched.
slot: The slot at which the data was fetched.
JSON-RPC Request Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "getTokenAccountBalance",
  "params": [
    "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
    {
      "commitment": "finalized",
      "encoding": "base64"
    }
  ]
}
JSON-RPC Response Example
JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "context": {
      "slot": 123456
    },
    "value": {
      "amount": "10000",
      "decimals": 6,
      "uiAmount": 0.01,
      "uiAmountString": "0.01"
    }
  }
}
Updated about 2 months ago

gettokenlargestaccounts
gethighestsnapshotslot
Did this page help you?

gethighestsnapshotslot
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.getHighestSnapshotSlot()

await tatum.destroy() // Destroy Tatum SDK - needed for stopping background jobs
Overview
The getHighestSnapshotSlot method provides the highest slot information for which the node


[User] How can users see their full request history when using the Magic Eden API?

[Assistant]
To see the full request history when using the Magic Eden API, users need to log in to their account. Once logged in, they will have access to their request history, which will display details such as the time of the request, status, and user agent.

Unfortunately, the documentation does not provide specific API endpoints or methods for retrieving the request history directly, as it is tied to the user account interface. Therefore, users should ensure they are logged in to view their request history within the platform.

equired
Defaults to 1d
Time window

1d
limit
integer
≤ 100
Defaults to 12
Limit

12
Response

200
Successful response

Updated about 1 year ago

Get collection stats
Get collection statistics
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request GET \
2
     --url 'https://api-mainnet.magiceden.dev/v2/ord/btc/popular_collections?window=1d&limit=12' \
3
     --header 'accept: application/json'

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

200

Get collection statistics
get
https://api-mainnet.magiceden.dev/collection_stats/search/bitcoin
Get collection statistics

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

Query Params
window
string
Defaults to 1d
Time window

1d
sort
string
Defaults to volume
Sort by

volume
direction
string
Defaults to desc
Sort direction

desc
offset
integer
1 to 1000
Defaults to 0
Offset

0
limit
integer
1 to 1000
Defaults to 100
Limit

100
Response
200
Successful response

Updated 11 months ago

Get popular collection stats
Activities
Did this page help you?
Language

Shell

Node

Ruby

PHP

Python
1
curl --request GET \
2
     --url 'https://api-mainnet.magiceden.dev/collection_stats/search/bitcoin?window=1d&sort=volume&direction=desc&offset=0&limit=100'

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

Get activities
get
https://api-mainnet.magiceden.dev/v2/ord/btc/activities


[User] What does the 'boosts' object represent in the DexScreener response?

[Assistant]
In the DexScreener response, the 'boosts' object represents the boost status of a trading pair. Specifically, it includes the following property:

- **active**: This indicates the number of active boosts for the trading pair.

In the context of the response, it is represented as follows:

```json
"boosts": {
    "active": 0
}
```

This means that in the example provided, there are currently no active boosts for the trading pair.

    "quoteToken": {
        "address": "text",
        "name": "text",
        "symbol": "text"
      },
      "priceNative": "text",
      "priceUsd": "text",
      "liquidity": {
        "usd": 0,
        "base": 0,
        "quote": 0
      },
      "fdv": 0,
      "marketCap": 0,
      "pairCreatedAt": 0,
      "info": {
        "imageUrl": "https://example.com",
        "websites": [
          {
            "url": "https://example.com"
          }
        ],
        "socials": [
          {
            "platform": "text",
            "handle": "text"
          }
        ]
      },
      "boosts": {
        "active": 0
      }
    }
  ]
}
Search for pairs matching query (rate-limit 300 requests per minute)
GEThttps://api.dexscreener.com/latest/dex/search
Query parameters

Response

200
Ok

Body

application/json
schemaVersionstring
pairsarray of Pair (object)

Request

JavaScript
Copy
const response = await fetch('https://api.dexscreener.com/latest/dex/search?q=text', {
    method: 'GET',
    headers: {},
});
const data = await response.json();
Test it
Response

200
Copy
{
  "schemaVersion": "text",
  "pairs": [
    {
      "chainId": "text",
      "dexId": "text",
      "url": "https://example.com",
      "pairAddress": "text",
      "labels": [
        "text"
      ],
      "baseToken": {
        "address": "text",
        "name": "text",
        "symbol": "text"
      },
      "quoteToken": {
        "address": "text",
        "name": "text",
        "symbol": "text"


[User] In Solana, how can the mint authority of a mint be changed to allow minting tokens within a program?

[Assistant]
To change the mint authority of a mint in Solana, you can use the example titled "PDA Mint Authority." This example demonstrates how to change the mint authority so that tokens can be minted from within a program.

Here’s a general outline of the steps involved:

1. **Create a Program Derived Address (PDA)**: This address will serve as the new mint authority.
2. **Invoke the Token Program**: Use the Solana Token Program to change the mint authority.

Here is a simplified code example using the Anchor framework:

```rust
use anchor_lang::prelude::*;
use anchor_spl::token::{self, Mint, SetAuthority};

#[derive(Accounts)]
pub struct ChangeMintAuthority<'info> {
    #[account(mut)]
    pub mint: Account<'info, Mint>,
    pub current_authority: Signer<'info>,
    #[account(seeds = [b"mint_authority", mint.key().as_ref()], bump)]
    pub new_authority: UncheckedAccount<'info>,
}

pub fn change_mint_authority(ctx: Context<ChangeMintAuthority>) -> Result<()> {
    let cpi_accounts = SetAuthority {
        current_authority: ctx.accounts.current_authority.to_account_info(),
        account: ctx.accounts.mint.to_account_info(),
    };
    let cpi_program = token::ID;
    let authority = ctx.accounts.new_authority.key();

    token::set_authority(
        CpiContext::new(cpi_program, cpi_accounts),
        AuthorityType::MintTokens,
        Some(authority),
    )?;

    Ok(())
}
```

### Explanation:
- **Accounts Structure**: The `ChangeMintAuthority` struct defines the accounts needed for the operation, including the mint account and the current authority.
- **PDA**: The new authority is derived from a seed, ensuring that it is unique and can be used as the mint authority.
- **CPI Call**: The `set_authority` function from the token program is called to change the mint authority to the new PDA.

This code snippet demonstrates how to change the mint authority, allowing your program to mint tokens using the new authority. Make sure to handle any necessary error checking and validations as per your application's requirements.

 can find many examples on how to mint, transfer, burn tokens and even how to interact with them in programs.

Example Name	Description	Language
Create Token	How to create a token and add metaplex metadata to it.	Anchor, Native
NFT Minter	Minting only one amount of a token and then removing the mint authority.	Anchor, Native
PDA Mint Authority	Shows you how to change the mint authority of a mint, to mint tokens from within a program.	Anchor, Native
SPL Token Minter	Explains how to use Associated Token Accounts to be able to keep track of token accounts.	Anchor, Native
Token Swap	Extensive example that shows you how to build a AMM (automated market maker) pool for SPL tokens.	Anchor
Transfer Tokens	Shows how to transfer SPL token using CPIs into the token program.	Anchor, Native
Token-2022	See Token 2022 (Token extensions).	Anchor, Native
Token 2022 (Token Extensions) #
Token 2022 is a new standard for tokens on Solana. It is a more flexible and lets you add 16 different extensions to a token mint to add more functionality to it. A full list of the extensions can be found in the Getting Started Guide

Example Name	Description	Language
Basics	How to create a token, mint and transfer it.	Anchor
Default account state	This extension lets you create token accounts with a certain state, for example frozen.	Native
Mint Close Authority	With the old token program it was not possible to close a mint. Now it is.	Native
Multiple Extensions	Shows you how you can add multiple extensions to


[User] How does Solana handle Cross Program Invocations (CPI) within its programs?

[Assistant]
In Solana, Cross Program Invocations (CPI) allow one program to call another program, enabling composability between different Solana programs. The process involves specifying the program to be invoked, the accounts required for that invocation, and the instruction data.

Here’s how Solana handles CPIs within its programs:

1. **Define the Accounts**: You need to define the accounts that will be used in the CPI. This is typically done using a struct that specifies the required accounts for the invoked program.

   Example:
   ```rust
   let transfer_accounts = Transfer {
       from: ctx.accounts.user.to_account_info(),
       to: ctx.accounts.vault_account.to_account_info(),
   };
   ```

2. **Create a CpiContext**: A `CpiContext` is created to specify the program to be invoked and the accounts defined earlier. This context is essential for the invocation.

   Example:
   ```rust
   let cpi_context = CpiContext::new(
       ctx.accounts.system_program.to_account_info(),
       transfer_accounts,
   );
   ```

3. **Invoke the Instruction**: Finally, you call the desired instruction from the invoked program using the `CpiContext`. You pass in the context along with any necessary parameters, such as the amount to be transferred.

   Example:
   ```rust
   transfer(cpi_context, 1_000_000)?;
   ```

In this example, the `transfer` function is invoked from the System Program, transferring 1,000,000 lamports (equivalent to 0.001 SOL) from the user's account to a vault account.

This structured approach allows Solana programs to interact with each other efficiently, leveraging the functionality of existing programs while maintaining security and integrity.

ctx.accounts.vault_account.to_account_info(),
+       };
+       let cpi_context = CpiContext::new(
+           ctx.accounts.system_program.to_account_info(),
+           transfer_accounts,
+       );
+       transfer(cpi_context, 1_000_000)?;
        Ok(())
    }

Explanation
In the update instruction, we implement a Cross Program Invocation (CPI) to invoke the System Program's transfer instruction. This demonstrates how to perform a CPI from within our program, enabling the composability of Solana programs.

The Transfer struct specifies the required accounts for the System Program's transfer instruction:

from - The user's account (source of funds)

to - The vault account (destination of funds)

lib.rs
let transfer_accounts = Transfer {
    from: ctx.accounts.user.to_account_info(),
    to: ctx.accounts.vault_account.to_account_info(),
};

The CpiContext specifies:

The program to be invoked (System Program)

The accounts required in the CPI (defined in the Transfer struct)

lib.rs
let cpi_context = CpiContext::new(
    ctx.accounts.system_program.to_account_info(),
    transfer_accounts,
);

The transfer function then invokes the transfer instruction on the System Program, passing in the:

The cpi_context (program and accounts)

The amount to transfer (1,000,000 lamports, equivalent to 0.001 SOL)

lib.rs
transfer(cpi_context, 1_000_000)?;

The setup for a CPI matches how client-side instructions are built, where we specify the program, accounts, and instruction data for a


[User] What is the Long-term Inflation Rate expected to be on the Solana network?

[Assistant] The Long-term Inflation Rate on the Solana network is the stable, long-term Inflation Rate that can be expected after the initial inflation adjustments. However, the specific percentage value for the Long-term Inflation Rate is not provided in the documentation snippet. For precise figures, you may need to refer to the official Solana documentation or community resources that outline the current inflation parameters.

tion Rate [%]: The starting Inflation Rate for when inflation is first enabled. Token issuance rate can only decrease from this point.
Disinflation Rate [%]: The rate at which the Inflation Rate is reduced.
Long-term Inflation Rate [%]: The stable, long-term Inflation Rate to be expected.
Effective Inflation Rate [%] #
The inflation rate actually observed on the Solana network after accounting for other factors that might decrease the Total Current Supply. Note that it is not possible for tokens to be created outside of what is described by the Inflation Schedule.

While the Inflation Schedule determines how the protocol issues SOL, this neglects the concurrent elimination of tokens in the ecosystem due to various factors. The primary token burning mechanism is the burning of a portion of each transaction fee. 50% of each transaction fee is burned, with the remaining fee retained by the validator that processes the transaction.
Additional factors such as loss of private keys and slashing events should also be considered in a holistic analysis of the Effective Inflation Rate. For example, it's estimated that 10-20% of all BTC have been lost and are unrecoverable and that networks may experience similar yearly losses at the rate of 1-2%.
Staking Yield [%] #
The rate of return (aka interest) earned on SOL staked on the network. It is often quoted as an annualized rate (e.g. "the network staking yield is currently 10% per year").

Staking yield is of great interest to validators


[User] What type of object is returned when a slot is processed by the validator in QuickNode?

[Assistant]
When a slot is processed by the validator in QuickNode, the returned object is an RpcResponse JSON object. This object includes an `id` that corresponds to the subscription id, which is necessary for unsubscribing from the notifications.

The notification format for the slot information is similar to that seen in the `getAccountInfo` RPC HTTP method, and it includes details such as the parent slot, the current root slot, and the newly set slot.

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

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

Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
signatureUnsubscribe
Next
slotUnsubscribe
Chat with our community
Check out our product changelog
Check on the status of our services
Read our blog for the latest announcements
Want the latest news in Web3?
We send out the #Web3Vibes newsletter with the coolest stuff in Blockchain every month. Sign up below!

hi@example.com
slotUnsubscribe RPC Method
(Subscription Websocket) Unsubscribe from slot notifications. The API credit value for this method is 20.
Updated on
Sep 20, 2024
Parameters
number
The account id for subscription to cancel
Returns
result
The result will be boolean value with u


[User] Where can I find a list of open source software associated with certain Magic Eden APIs?

[Assistant] You can find a list of open source software associated with certain Magic Eden APIs in the documentation provided for those specific APIs. The documentation will detail any open source software that is required by or included in the Magic Eden APIs. Be sure to check the relevant API documentation for this information.

en APIs or developer accounts.
3.6 API Limitations. Magic Eden sets and enforces limits on your use of the Magic Eden APIs (e.g. limiting the number of API requests that you may make or the number of users you may serve), in our sole discretion. You agree to, and will not attempt to circumvent, such limitations documented with each Magic Eden API. If you would like to use any Magic Eden API beyond these limits, you must obtain Magic Eden’s express consent (and Magic Eden may decline such request or condition acceptance on your agreement to additional terms and/or charges for that use).
3.7 Open Source Software. Some of the software required by or included in the Magic Eden APIs may be offered under an open source license. Open source software licenses constitute separate written agreements. For certain Magic Eden APIs, open source software is listed in the documentation. To the limited extent the open source software license expressly supersedes the Terms, the open source license instead sets forth your agreement with Magic Eden for the applicable open source software.
3.8 Communication with Magic Eden. We may send you certain communications in connection with your use of the Magic Eden APIs. Please review the applicable Magic Eden API documentation for information about opting out of certain types of communication.
3.9 Feedback. If you give feedback about the Magic Eden APIs to Magic Eden, you hereby grant to Magic Eden a non-exclusive, transferable, worldwide, perpetual, i


[User] How does Jupiter handle requests that do not meet the 'jupiterMinimumOut' requirement during token swaps?

[Assistant]
In Jupiter, when a request involves token swaps (such as opening or closing positions or updating position sizes), it is required that the output amount of the token swap must be greater than or equal to the `jupiterMinimumOut`. If the swap does not satisfy this requirement, the request will fail.

This ensures that users do not execute swaps that would result in receiving less than the minimum expected output, thereby protecting them from unfavorable trading conditions.

Here’s a brief example to illustrate this:

```json
{
  "requestType": "Market",
  "side": "Long",
  "priceSlippage": 0.05,
  "jupiterMinimumOut": 100,
  "preSwapAmount": 150,
  "triggerPrice": 50,
  "triggerAboveThreshold": true
}
```

In this example, if the token swap does not yield at least 100 units as output, the request will fail, ensuring compliance with the `jupiterMinimumOut` requirement.

ase for close position and collateral withdrawal requests.

requestType: Market for all position requests except for TP / SL requests, which have a Trigger requestType.

side: Long for long positions, Short for short positions

priceSlippage: The maximum price with slippage for the position request when opening, closing, or updating the position size.

When increasing the size of a long position or decreasing the size of a short position, the request will fail if the current price of the position's token is greater than priceSlippage.
When decreasing the size of a long position or increasing the size of a short position, the request will fail if priceSlippage is greater than the current price of the position's token.
jupiterMinimumOut: For requests that require token swaps (e.g. opening or closing positions, updating position sizes), the output amount of the token swap must be greater than or equal to jupiterMinimumOut. The request will fail if the swap does not satisfy jupiterMinimumOut.

preSwapAmount: This is an internal attribute used by the program to calculate the collateralDelta for position requests that require token swaps.

triggerPrice: The price (USD) used for TP / SL position requests.

triggerAboveThreshold: When triggerAboveThreshold is true, the TP / SL position request will be triggered when the position's token price is greater than or equal to triggerPrice. When triggerAboveThreshold is false, the TP / SL position request will be triggered when the position


[User] What should I keep in mind regarding Docker's bridge IP when using Jito's bridge networking setup?

[Assistant]
When using Jito's bridge networking setup, you should keep the following points in mind regarding Docker's bridge IP:

1. **Manual Exposure of Destinations**: In a bridge networking setup, you need to manually expose each destination. This means that you have to configure the network settings for each service that needs to communicate with others.

2. **Local Shred Listeners**: For shred listeners that are running locally on the Docker host, you should use Docker’s bridge IP, which is typically `172.17.0.1`. This IP allows the Docker containers to communicate with services running on the host machine.

3. **Non-local Endpoints**: For endpoints that are not local (i.e., services running outside of the Docker host), you should use their regular IP addresses instead of the bridge IP.

4. **Variability of Bridge IP**: Be aware that Docker’s bridge IP can vary. This means that if you are relying on a specific IP address, you should confirm the current bridge IP, as it may change depending on your Docker configuration or environment.

These considerations are crucial for ensuring proper communication and functionality within your Jito setup when using bridge networking.

140.240, 202.8.8.174, 64.130.52.138, 64.130.55.26, 64.130.55.174

🇩🇪 Frankfurt

145.40.93.84, 145.40.93.41, 64.130.50.14, 64.130.57.46, 64.130.57.99, 64.130.57.171

🇺🇸 New York

141.98.216.96, 64.130.48.56, 64.130.51.137

🇺🇸 Salt Lake City

64.130.53.8, 64.130.53.57, 64.130.53.88, 64.130.53.90

🇯🇵 Tokyo

202.8.9.160, 202.8.9.19, 202.8.9.22

Troubleshooting
Ensure ShredStream is running correctly by configuring the SOLANA_METRICS_CONFIG in your RPC setup. Refer to Solana Clusters Documentation for details.

To verify, query the number of packets received before and after configuring ShredStream in InfluxDB:

SELECT shred_count FROM "shred_fetch" WHERE time > now() - 1h

Host Networking (Recommended)
This exposes all ports, bypassing Docker NAT.

docker run -d \
--name jito-shredstream-proxy \
--rm \
--env RUST_LOG=info \
--env BLOCK_ENGINE_URL=https://mainnet.block-engine.jito.wtf \
--env AUTH_KEYPAIR=my_keypair.json \
--env DESIRED_REGIONS=amsterdam,ny \
--env DEST_IP_PORTS=127.0.0.1:8001,10.0.0.1:8001 \
--network host \
-v $(pwd)/my_keypair.json:/app/my_keypair.json \
jitolabs/jito-shredstream-proxy shredstream
🚝 Bridge Networking
Use bridge networking in environments where Docker host networking is unavailable. This setup requires manual exposure of each destination. For shred listeners running locally on the Docker host, use Docker’s bridge IP (typically 172.17.0.1). For non-local endpoints, use their regular IP addresses. Note that Docker’s bridge IP can vary, so confi


[User] What type of data structure is used to represent the `depositAmount` in the Meteora example?

[Assistant]
In the Meteora example, the `depositAmount` is represented using the `BN` class, which stands for "Big Number." This is evident from the line:

```javascript
const depositAmount = new BN(100_000);
```

The `BN` class is typically used to handle large integers that exceed the safe limits of standard JavaScript number types, ensuring accurate arithmetic operations in financial applications or blockchain interactions.

const depositorProof = tree
    .getProof(payer.publicKey, nativeDepositCap)
    .map((buffer) => {
      return Array.from(new Uint8Array(buffer));
    });

  const [merkleRootConfig] = deriveMerkleRootConfig(
    alphaVault.pubkey,
    new BN(0),
    new PublicKey(PROGRAM_ID["mainnet-beta"])
  );

  // 4. Deposit
  const depositTx = await alphaVault.deposit(depositAmount, payer.publicKey, {
    merkleRootConfig,
    maxCap: nativeDepositCap,
    proof: depositorProof,
  });

  console.log(`Depositing ${depositAmount.toString()}`);
  const txHash = await sendAndConfirmTransaction(connection, depositTx, [
    payer,
  ]);
  console.log(txHash);

  const escrow = await alphaVault.getEscrow(payer.publicKey);
  console.log("Escrow info");
  console.log(escrow);
}

// Alpha vault to be deposited to
const vault = new PublicKey("ARGqVVUPPqtqH9UeBHvYsv7AtZv623YdEaEziZ1pdDUs");
const depositAmount = new BN(100_000);
const payer = loadKeypairFromFile(process.env.KEYPAIR_PATH);
const whitelistWalletCsvFilepath =
  "src/examples/permissioned/whitelist_wallet.csv";

/**
 * This example shows how to deposit to permissioned alpha vault. Deposit can only happen before the deposit close.
 */
depositToPermissionedAlphaVault(
  vault,
  depositAmount,
  whitelistWalletCsvFilepath,
  payer
)
  .then(() => {
    console.log("Done");
  })
  .catch(console.error);
5. Configure Alpha Vault Timings
If you are integrating the Alpha Vault program and need to view and select the predefined timings for


[User] How does the `uiTokenAmount` structure work in Solana for displaying token amounts?

[Assistant]
In Solana, the `uiTokenAmount` structure is used to represent the amount of a token in a user-friendly format. This structure typically contains the following fields:

1. **amount**: This is a string that represents the raw amount of the token, which is usually in the smallest unit (like lamports for SOL). For example, if the amount is "15489767829", it indicates the total number of tokens in the smallest unit.

2. **decimals**: This is an integer that specifies the number of decimal places the token supports. For instance, if a token has 6 decimals, it means that the smallest unit can be divided into 1 million parts.

3. **uiAmount**: This is a floating-point number that represents the amount in a user-friendly format, taking into account the decimals. For example, if the `amount` is "15489767829" and `decimals` is 6, the `uiAmount` would be 15489.767829.

4. **uiAmountString**: This is a string representation of the `uiAmount`, which is useful for displaying the amount in user interfaces. It provides a formatted version of the `uiAmount`, such as "15489.767829".

Here’s an example of how the `uiTokenAmount` structure might look in practice:

```json
{
  "uiTokenAmount": {
    "uiAmount": 15489.767829,
    "decimals": 6,
    "amount": "15489767829",
    "uiAmountString": "15489.767829"
  }
}
```

In this example, the token amount is represented in both raw and user-friendly formats, making it easier for applications to display the token amount to users.

boeD8CRkNBSkYk",
                    "programId": "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"
                  },
                  {
                    "accountIndex": 10,
                    "mint": "Saber2gLauYim4Mvftnrasomsv6NvAuncvMEZwcLpD1",
                    "uiTokenAmount": {
                      "uiAmount": null,
                      "decimals": 6,
                      "amount": "0",
                      "uiAmountString": "0"
                    },
                    "owner": "CL9wkGFT3SZRRNa9dgaovuRV7jrVVigBUZ6DjcgySsCU",
                    "programId": "TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb"
                  },
                  {
                    "accountIndex": 11,
                    "mint": "Saber2gLauYim4Mvftnrasomsv6NvAuncvMEZwcLpD1",
                    "uiTokenAmount": {
                      "uiAmount": 15489.767829,
                      "decimals": 6,
                      "amount": "15489767829",
                      "uiAmountString": "15489.767829"
                    },
                    "owner": "BeiHVPRE8XeX3Y2xVNrSsTpAScH94nYySBVQ4HqgN9at",
                    "programId": "TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb"
                  }
                ],
                "rewards": []
              }
            }
          ],
          "blockTime": 1639926816,
          "blockHeight": 101210751
        },
        "err": null
      }
    },
    "subscription": 14
  }
}

blockUnsubscribe RPC Method
Edit Page
Unsubscribe fro


[User] How does the prioritization fee in Solana influence transaction processing?

[Assistant]
The prioritization fee in Solana is an optional fee that users can include with their transactions to influence the order in which their transactions are processed by validators. By paying this fee, users can effectively boost the priority of their transactions, making it more likely that they will be processed sooner than others that do not include a prioritization fee.

This mechanism allows users to manage the urgency of their transactions, especially during times of high network congestion when many transactions are competing for processing. By offering a higher prioritization fee, a user can incentivize validators to prioritize their transaction over others, potentially leading to faster confirmations.

In summary, the prioritization fee serves as a way for users to influence transaction processing order, providing a means to expedite their transactions in a competitive environment.

Concepts
Build a strong understanding of the core concepts that make Solana different from other blockchains. Understanding the "Solana programming model" through these core concepts is very important to maximize your success as a Solana blockchain developer.

Solana Account Model #
On Solana, all data is stored in what are referred to as "accounts”. The way data is organized on the Solana blockchain resembles a key-value store, where each entry in the database is called an "account".

Learn more about Accounts here.

Transactions and Instructions #
On Solana, we send transactions to interact with the network. Transactions include one or more instructions, each representing a specific operation to be processed. The execution logic for instructions is stored on programs deployed to the Solana network, where each program stores its own set of instructions.

Learn more about Transactions and Instructions here.

Fees on Solana #
The Solana blockchain has a few different types of fees and costs that are incurred to use the permissionless network. These can be segmented into a few specific types:

Transaction Fees - A fee to have validators process transactions/instructions
Prioritization Fees - An optional fee to boost transactions processing order
Rent - A withheld balance to keep data stored on-chain
Learn more about Fees on Solana here.

Programs on Solana #
In the Solana ecosystem, "smart contracts" are called programs. Each program is an on-chain account that stores executabl


[User] How do account addresses fit into the message structure of a Solana transaction?

[Assistant]
In a Solana transaction, account addresses are a crucial component of the message structure. They are included in the transaction message to specify which accounts are required for the execution of the instructions within that transaction.

### Structure of a Transaction Message

The transaction message consists of several parts, including:

1. **Message Header**: This specifies the number of signers and read-only accounts.
2. **Account Addresses**: An array of account addresses that are required by the instructions in the transaction.
3. **Recent Blockhash**: This serves as a timestamp for the transaction.
4. **Instructions**: An array of instructions that will be executed atomically.

### Role of Account Addresses

- **Account Addresses Array**: This array contains the addresses of all accounts that the instructions in the transaction will interact with. Each account address is typically represented as a 32-byte identifier.
- **Signers and Read-Only Accounts**: The message header indicates how many of these accounts are signers (accounts that need to authorize the transaction) and how many are read-only (accounts that will not be modified).

### Example

Here is a simplified representation of how account addresses fit into the transaction message structure:

```json
{
  "message": {
    "header": {
      "numRequiredSignatures": 1,
      "numReadonlySignedAccounts": 0,
      "numReadonlyUnsignedAccounts": 1
    },
    "accountKeys": [
      "AccountAddress1", // Signer
      "AccountAddress2"  // Read-only account
    ],
    "recentBlockhash": "RecentBlockhashValue",
    "instructions": [
      {
        "programId": "ProgramAddress",
        "accounts": [
          "AccountAddress1",
          "AccountAddress2"
        ],
        "data": "InstructionData"
      }
    ]
  }
}
```

In this example:
- `AccountAddress1` is a signer, meaning it must authorize the transaction.
- `AccountAddress2` is a read-only account, which will be accessed but not modified during the transaction.

This structure ensures that all necessary accounts are specified and allows the Solana network to validate and execute the transaction correctly.

ails of what's happening under the hood.

Transaction #
A Solana transaction consists of:

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

The structure of a transaction message comprises of:

Message Header: Specifies the number of signer and read-only account.
Account Addresses: An array of account addresses required by the instructions on the transaction.
Recent Blockhash: Acts as a timestamp for the transaction.
Instructions: An array of instructions to be executed.
Transaction Message
Transaction Message

Transaction Size #
The Solana network adheres to a maximum transmission unit (MTU) size of 1280 bytes, consistent with the IPv6 MTU size constraints to ensure fast and reliable transmission of cluster information over UDP. After accounting for the necessary headers (40 bytes for IPv6 and 8 bytes for the fragment header), 1232 bytes remain available for packet data, such as serialized transactions.

This means that the total size of a Solana transaction is limited to 1232 bytes. The combination of the signatures and the message cannot exceed this limit.

Signatures: Each signature requires 64 bytes. The number of signatures can vary, depending on the transaction's requirements.
Message: The message includes instructions, accounts, and additional metadata, with each account requiring 32 bytes. The combined size of the accounts plus metadata can vary, depending


[User] What parameters are required to sign a message using the signMessage function in Magic Eden?

[Assistant]
To sign a message using the `signMessage` function in Magic Eden, the following parameters are required within the `payload` object:

1. **network**: This is an object that specifies the network type.
   - **type**: This should be set to `BitcoinNetworkType.Mainnet` for the main Bitcoin network.

2. **address**: This is a string representing the user's connected address, specifically the 'payment' address returned after establishing a connection to the Magic Eden wallet.

3. **message**: This is a string containing the message that you want the user to sign.

Here is an example of how to structure these parameters in the `signMessage` function:

```javascript
import { BitcoinNetworkType, signMessage } from 'sats-connect';

const nativeSegwitAddress = 'bc1qcdmvsc8qqk8sr2st3mttu6fsmfrjzh5xrf4dch';

async function signWalletMessage() {
  try {
    await signMessage({
      payload: {
        network: {
          type: BitcoinNetworkType.Mainnet, // Required network type
        },
        address: nativeSegwitAddress, // Required user's connected address
        message: 'Hello World. Welcome to the Magic Eden wallet!', // Required message to sign
      },
      onFinish: (response) => {
        alert(`Successfully signed message: ${response}`);
      },
      onCancel: () => {
        alert('Request canceled');
      },
    });
  } catch (error) {
    console.error('Error signing message:', error);
  }
}
```

In this example, the `signMessage` function is called with the required parameters to sign a message successfully.

allet address objects, defined as:

Copy
type address = {
    address: string;
    publicKey: string;
    purpose: "payment" | "ordinals";
}
Where:

address field
Description
address

The user’s connected  address

publicKey

A hex string representing the bytes of the public key of the account.

purpose

The purpose of the address:

payment is used to manage the user’s bitcoin

ordinals is used to manage the user’s ordinals

Signing a Message
When a web application has established a connection to the ME wallet, it can prompt users to sign a message. This is commonplace amongst many dApps, as it gives application owners the ability to verify ownership of the wallet. Signing a message does not require any transaction fees.

Sats Connect provides an easy way to request message signing. Let's take a look at the code below.

Copy
import { BitcoinNetworkType, signMessage } from 'sats-connect';

// in a real app, you'll use the ME 'payment' address returned after a connection
const nativeSegwitAddress = 'bc1qcdmvsc8qqk8sr2st3mttu6fsmfrjzh5xrf4dch'

async function signWalletMessage() {
  try {
    await signMessage({
      payload: {
        network: {
          type: BitcoinNetworkType.Mainnet,
        },
        address: nativeSegwitAddress,
        message: 'Hello World. Welcome to the Magic Eden wallet!',
      },
      onFinish: (response) => {
        alert(`Successfully signed message: ${response}`);
      },
      onCancel: () => {
        alert('Request canceled');
      }


[User] Which country does DexScreener identify as its location in the Privacy Policy?

[Assistant] According to the Privacy Policy, DexScreener identifies its location as Delaware, United States.

e law protects You.

We use Your Personal data to provide and improve the Service. By using the Service, You agree to the collection and use of information in accordance with this Privacy Policy. This Privacy Policy has been created with the help of the Privacy Policy Generator.

Interpretation and Definitions
Interpretation
The words of which the initial letter is capitalized have meanings defined under the following conditions. The following definitions shall have the same meaning regardless of whether they appear in singular or in plural.

Definitions
For the purposes of this Privacy Policy:

Account means a unique account created for You to access our Service or parts of our Service.

Affiliate means an entity that controls, is controlled by or is under common control with a party, where "control" means ownership of 50% or more of the shares, equity interest or other securities entitled to vote for election of directors or other managing authority.

Application means the software program provided by the Company downloaded by You on any electronic device, named DEX Screener

Company (referred to as either "the Company", "We", "Us" or "Our" in this Agreement) refers to DEX Screener, Inc., 123 Southeast 3rd Avenue #640, Miami, Florida 33130.

Country refers to: Delaware, United States

Device means any device that can access the Service such as a computer, a cellphone or a digital tablet.

Personal Data is any information that relates to an identified or identifiable individ


[User] How can liquidity providers ensure that the price in a Meteora pool is in sync with the general market price?

[Assistant]
Liquidity providers can ensure that the price in a Meteora pool is in sync with the general market price by following these steps:

1. **Check the Token Ratio**: Before adding liquidity to a pool, liquidity providers should verify the ratio of tokens they are adding. For example, if creating a SOL/USDC pool, they should ensure that for every 1 SOL added, they also add 100 USDC if that is the current market price.

2. **Use Jupiter's Price API**: Meteora uses Jupiter's price API as a reference for the market price of tokens. Providers should consult this API to get an estimate of the current market price before making any liquidity additions.

3. **Compare with Other Markets**: It is crucial for liquidity providers to compare the Meteora pool price with prices from other decentralized exchanges (DEXs) that have liquidity for the same tokens. This helps in understanding the broader market price and identifying any discrepancies.

4. **Monitor for Arbitrage Opportunities**: Providers should be aware that if the pool price is not aligned with the general market price, arbitrage traders may exploit this difference. This could lead to losses for the liquidity provider if they do not maintain a price in sync with the market.

By following these steps, liquidity providers can better align their pool prices with the general market price and minimize the risk of incurring losses due to arbitrage trades.

price out of sync
Dynamic pool
The ratio of tokens in the dynamic pool determines the price of the tokens in the pool.

As a liquidity provider, it is important that you check that the pool price is in sync with the general market price or your deposit will be impacted by arbitrage trades, causing you to incur a loss.

For example, as a pool creator for a SOL/USDC pool when the current market price is 1 SOL = 100 USDC, you would need to add 100 USDC for every 1 SOL you add to the pool. If you only added 50 USDC for every 1 SOL, this differs from the market price and you can lose money as arbitragers take advantage of your low SOL price by buying your SOL at a cheaper rate and selling it on another DEX at market rate, profiting from the difference.

DLMM pool
Sometimes, the initial price in the DLMM pool may not be in sync with the broader market price, especially when it was just created with a wrong initial price and has low liquidity.

As a liquidity provider, it is important that you check that the pool price is in sync with the general market price or your deposit will be impacted by arbitrage trades, causing you to incur a loss.

Important: As a reference for market price for the token, Meteora uses Jupiter's price API. However, this is just an estimate. Before adding liquidity, LPs should always check and compare the Meteora pool price with all other markets (e.g. other DEX pools) that have liquidity for the token to have a better sense of the general market price.


[User] What does the 'slot' field indicate in the response from Solana?

[Assistant]
In the response from Solana, the 'slot' field indicates the specific slot in which the transaction was processed. Each slot represents a unique point in the blockchain's history, and it helps to identify when a particular transaction was included in the ledger.

For example, in the response structure:

```json
{
  "slot": 48,
  "confirmations": null,
  "err": null,
  "status": {
    "Ok": null
  },
  ...
}
```

Here, the 'slot' value of 48 indicates that the transaction was processed in slot number 48. This information is crucial for tracking the transaction's status and understanding its place within the blockchain's timeline.

 optional

if true - a Solana node will search its ledger cache for any signatures not found in the recent status cache

Result #
An array of RpcResponse<object> consisting of either:

<null> - Unknown transaction, or
<object>
slot: <u64> - The slot the transaction was processed
confirmations: <usize|null> - Number of blocks since signature confirmation, null if rooted, as well as finalized by a supermajority of the cluster
err: <object|null> - Error if transaction failed, null if transaction succeeded. See TransactionError definitions
confirmationStatus: <string|null> - The transaction's cluster confirmation status; Either processed, confirmed, or finalized. See Commitment for more on optimistic confirmation.
DEPRECATED: status: <object> - Transaction status
"Ok": <null> - Transaction was successful
"Err": <ERR> - Transaction failed with TransactionError
Code sample #
curl https://api.devnet.solana.com -s -X POST -H "Content-Type: application/json" -d '
  {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSignatureStatuses",
    "params": [
      [
        "5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"
      ],
      {
        "searchTransactionHistory": true
      }
    ]
  }
'

Response #
{
  "jsonrpc": "2.0",
  "result": {
    "context": {
      "slot": 82
    },
    "value": [
      {
        "slot": 48,
        "confirmations": null,
        "err": null,
        "status": {
          "Ok": null
        },
        "confirma


[User] How can I obtain the latest slot number when using QuickNode's getAccountInfo RPC method?

[Assistant]
To obtain the latest slot number when using QuickNode's `getAccountInfo` RPC method, you can subscribe to root notifications. This allows you to receive updates about the latest slot number in real-time.

Here’s how you can do it using Solana Web3.js:

1. **Set up a connection to your QuickNode endpoint**.
2. **Subscribe to root changes** to get the latest slot information.

Here’s a code example demonstrating this:

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

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

  // Subscribe to root changes to get the latest slot number
  solanaConnection.onRootChange((rootInfo) => {
    console.log("Updated slot info: ", rootInfo);
  });
})();
```

In this example, the `onRootChange` method is used to listen for updates, and whenever there is a change, it logs the updated slot information to the console. This way, you can continuously monitor the latest slot number while using the `getAccountInfo` RPC method.

ccept any parameters
Returns
result
integer
The result will be an RpcResponse JSON object with id equal to the subscription id (needed to unsubscribe)
Notification Format:
The notification format is the same as seen in the getAccountInfo RPC HTTP method
slot
The latest slot number
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.onRootChange((rootInfo) =>
    console.log("Updated slot info: ", rootInfo)
  );
})();

Don't have an account yet?
Create your QuickNode endpoint in seconds and start building
Get started for free
Previous
programUnsubscribe
Next
rootUnsubscribe
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
rootUnsubscribe RPC Method
(Subscription Websocket) Unsubscribe from root notifications.
Updated on
Sep 20, 2024
Parameters
number
The account id for the subscription to cancel
Returns
result
boolean
The result will be an RpcResponse JSON object with unsubscribed success message
Request

Solana Web3.js (v1.x)
const web3 = require("@solana/web3.js");
(async () => {
  const solanaConnection = new web3.Connection


[User] How do you create a new Anchor project for Solana development?

[Assistant]
To create a new Anchor project for Solana development, follow these steps:

1. **Open the Solana Playground**: Navigate to [Solana Playground](https://beta.solpg.io) in a new browser tab.

2. **Create a New Project**:
   - Click the "Create a new project" button located on the left-side panel.
   - Enter a project name of your choice.
   - Select "Anchor" as the framework.
   - Click the "Create" button to initialize your project.

3. **Access the Program Code**: Once the project is created, you will see a new project with the program code available in the `src/lib.rs` file.

Here’s a basic example of what the `lib.rs` file might start with:

```rust
use anchor_lang::prelude::*;

// This is where you will define your program's logic.
```

This setup will allow you to begin developing your Solana program using the Anchor framework.

o inspect the transaction details and the newly created mint account on SolanaFM.

Output
Terminal
Running client...
  client.ts:

Transaction Signature: https://solana.fm/tx/3BEjFxqyGwHXWSrEBnc7vTSaXUGDJFY1Zr6L9iwLrjH8KBZdJSucoMrFUEJgWrWVRYzrFvbjX8TmxKUV88oKr86g?cluster=devnet-solana

Mint Account: https://solana.fm/address/CoZ3Nz488rmATDhy1hPk5fvwSZaipCngvf8rYBYVc4jN?cluster=devnet-solana

Create Token
Create Token

Mint Account
Mint Account

Notice how we built a transaction with multiple instructions this time. We first created a new account and then initialized its data as a mint. This is how you build more complex transactions that involve instructions from multiple programs.

Deploying Your First Solana Program
In this section, we'll build, deploy, and test a simple Solana program using the Anchor framework. By the end, you'll have deployed your first program to the Solana blockchain!

The purpose of this section is to familiarize you with the Solana Playground. We'll walk through a more detailed example in the PDA and CPI sections. For more details, refer to the Programs on Solana page.

Create Anchor Project #
First, open https://beta.solpg.io in a new browser tab.

Click the "Create a new project" button on the left-side panel.

Enter a project name, select Anchor as the framework, then click the "Create" button.

New Project
New Project

You'll see a new project created with the program code in the src/lib.rs file.

lib.rs
use anchor_lang::prelude::*;

// This i


[User] What is the rate limit for requests to the DexScreener API for getting the latest boosted tokens?

[Assistant] The rate limit for requests to the DexScreener API for getting the latest boosted tokens is 60 requests per minute.

xt",
  "links": [
    {
      "type": "text",
      "label": "text",
      "url": "https://example.com"
    }
  ]
}
Get the latest boosted tokens (rate-limit 60 requests per minute)
GEThttps://api.dexscreener.com/token-boosts/latest/v1
Response

200
Ok

Body

application/json
urlstring (uri)
chainIdstring
tokenAddressstring
amountnumber
totalAmountnumber
iconnullable string (uri)
headernullable string (uri)
descriptionnullable string
linksnullable array of object

Request

JavaScript
Copy
const response = await fetch('https://api.dexscreener.com/token-boosts/latest/v1', {
    method: 'GET',
    headers: {},
});
const data = await response.json();
Test it
Response

200
Copy
{
  "url": "https://example.com",
  "chainId": "text",
  "tokenAddress": "text",
  "amount": 0,
  "totalAmount": 0,
  "icon": "https://example.com",
  "header": "https://example.com",
  "description": "text",
  "links": [
    {
      "type": "text",
      "label": "text",
      "url": "https://example.com"
    }
  ]
}
Get the tokens with most active boosts (rate-limit 60 requests per minute)
GEThttps://api.dexscreener.com/token-boosts/top/v1
Response

200
Ok

Body

application/json
urlstring (uri)
chainIdstring
tokenAddressstring
amountnumber
totalAmountnumber
iconnullable string (uri)
headernullable string (uri)
descriptionnullable string
linksnullable array of object

Request

JavaScript
Copy
const response = await fetch('https://api.dexscreener.com/token-boosts/top/v1', {
    method: 'GET',
    headers:


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

[Assistant]
The `getTokenSupply` method in Alchemy is used to retrieve the total supply of a specific SPL Token type. This method allows users to query the amount of tokens available for a given token mint.

### Parameters:
- **Pubkey of token Mint**: This is a base-58 encoded string representing the public key of the token mint you want to query.
- **Config object (optional)**: This can include a `commitment` level which configures the level of commitment for the blocks queried. The acceptable values for commitment are:
  - `"finalized"`
  - `"confirmed"`
  - `"processed"`

### Results:
The response from the `getTokenSupply` method includes:
- **amount**: The raw balance of the token supply without decimals (as a string).
- **decimals**: The number of base 10 digits to the right of the decimal place for the token.
- **uiAmountString**: The balance represented as a string, formatted according to the mint-prescribed decimals.

### Example Request:
Here’s an example of how to use the `getTokenSupply` method with a cURL request:

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

### Example Response:
The response would look something like this:

```json
{
    "jsonrpc": "2.0",
    "result": {
        "context": {
            "slot": 137571639
        },
        "value": {
            "amount": "999999999997060679",
            "decimals": 9,
            "uiAmount": 9.999999999970608E8,
            "uiAmountString": "999999999.997060679"
        }
    },
    "id": 1
}
```

In this response:
- The total supply of the token is `999999999997060679`.
- The token has `9` decimals, meaning the supply can be represented with up to 9 digits after the decimal point.
- The user-friendly amount (`uiAmountString`) is `999999999.997060679`.

This method is essential for developers and applications that need to track the total supply of tokens on the Solana blockchain.

thod": "getTokenAccountsByOwner"
}
'

Response

200
Response body
object
id
integer
jsonrpc
string
result
object
context
object

context object
value
object

value object

getTokenSupply
post
https://{network}.g.alchemy.com/v2/{apiKey}
Returns the total supply of an SPL Token type.

Parameters
<base-58 encoded string> - Pubkey of token Mint to query
<object> - (optional) Config object:
commitment: <object> - (optional) Configures the commitment level of the blocks queried
Accepts one of the following strings: ["finalized", "confirmed", "processed"]
For more info, refer to this doc.
Results
amount: <u64 string> - the raw balance without decimals
decimals: <u8> - number of base 10 digits to the right of the decimal place
uiAmountString: <string> - the balance as a string, using mint-prescribed decimals
Example
Request
cURL

curl --location --request POST 'https://solana-mainnet.g.alchemy.com/v2/demo/' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getTokenSupply",
    "params": [
        "HfYFjMKNZygfMC8LsQ8LtpPsPxEJoXJx4M6tqi75Hajo"
    ]
}'
Response
JavaScript

{
    "jsonrpc": "2.0",
    "result": {
        "context": {
            "slot": 137571639
        },
        "value": {
            "amount": "999999999997060679",
            "decimals": 9,
            "uiAmount": 9.999999999970608E8,
            "uiAmountString": "999999999.997060679"
        }
    },
    "id": 1
}
Path Params
apiKey
string
required
Defa


[User] How many decimals are specified for the token in the provided Solana documentation snippet?

[Assistant] The specified number of decimals for the token in the provided Solana documentation snippet is 9.

m TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb
To initialize metadata inside the mint, please run `spl-token initialize-metadata BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP <YOUR_TOKEN_NAME> <YOUR_TOKEN_SYMBOL> <YOUR_TOKEN_URI>`, and sign with the mint authority.

Address:  BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP
Decimals:  9

Signature: 5iQofFeXdYhMi9uTzZghcq8stAaa6CY6saUwcdnELST13eNSifiuLbvR5DnRt311frkCTUh5oecj8YEvZSB3wfai

Once a new token is created with the metadata extension enabled, use the following command to initialize the metadata.

spl-token initialize-metadata <TOKEN_MINT_ADDRESS> <YOUR_TOKEN_NAME>
<YOUR_TOKEN_SYMBOL> <YOUR_TOKEN_URI>

The token URI is normally a link to offchain metadata you want to associate with the token. You can find an example of the JSON format here.

For example, running the following command will store the additional metadata directly on the specified mint account:

spl-token initialize-metadata BdhzpzhTD1MFqBiwNdrRy4jFo2FHFufw3n9e8sVjJczP "TokenName" "TokenSymbol" "https://raw.githubusercontent.com/solana-developers/opos-asset/main/assets/DeveloperPortal/metadata.json"

You can then look up the address of the mint account on an explorer to inspect the metadata. For example, here is a token created with the metadata extension enabled on the SolanaFm explorer.

You can learn more on the Metadata Extension Guide. For more details related to various Token Extensions, refer to the Token Extensions Getting Started Guide and the SPL doc


[User] What HTTP method is used to request historical market data from CoinGecko?

[Assistant] The HTTP method used to request historical market data from CoinGecko is `GET`.

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] What does the resolution feature in the Anchor.toml file enable for Solana projects?

[Assistant]
The resolution feature in the Anchor.toml file is specified under the `[features]` section. While the documentation snippet does not provide detailed information about what the resolution feature specifically enables, it is included as a feature that can be toggled on or off for an Anchor project.

To enable the resolution feature, you would set it to true in the Anchor.toml file like this:

```toml
[features]
resolution = true
skip-lint = false
```

If you need further details on the specific functionalities or benefits provided by the resolution feature, you may need to consult additional documentation or resources related to Anchor and Solana.

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

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

Terminal
solana-test-validator

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

Terminal
anchor test --skip-local-validator

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

Anchor.toml
[toolchain]

[features]
resolution = true
skip-lint = false

[programs.localnet]
my_program = "3ynNB373Q3VAzKp7m4x238po36hjAGFXFJB4ybN2iTyg"

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

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

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

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

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

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

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

anchor deploy

To deploy to mainnet, simply update


[User] How does the 'startAt' parameter affect the DCA creation in Jupiter?

[Assistant]
The `startAt` parameter in the DCA (Dollar-Cost Averaging) creation process in Jupiter specifies the Unix timestamp in seconds at which the DCA orders will begin executing. If this parameter is set to a specific timestamp, the DCA will not start placing orders until that time is reached.

If the `startAt` parameter is set to `null`, it implies that the DCA will start executing immediately upon creation.

Here’s a brief example to illustrate how you might set the `startAt` parameter:

```javascript
const params: CreateDCAParamsV2 = {
  payer: user.publicKey,
  user: user.publicKey,
  inAmount: BigInt(5_000_000),
  inAmountPerCycle: BigInt(1_000_000),
  cycleSecondsApart: BigInt(86400),
  inputMint: USDC,
  outputMint: BONK,
  minOutAmountPerCycle: null,
  maxOutAmountPerCycle: null,
  startAt: Math.floor(Date.now() / 1000) + 3600, // Start in 1 hour
  userInTokenAccount,
};
```

In this example, the DCA will start executing one hour after the current time.

Wdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v');
const BONK = new PublicKey('DezXAZ8z7PnrnRJjz3wXBoRgixCa6xjnB7YaB1pPB263');

async function createDCA() {
  const params: CreateDCAParamsV2 = {
    payer: user.publickey, // could have a different account pay for the tx (make sure this account is also a signer when sending the tx)
    user: user.publicKey,
    inAmount: BigInt(5_000_000), // buy a total of 5 USDC over 5 days
    inAmountPerCycle: BigInt(1_000_000), // buy using 1 USDC each day
    cycleSecondsApart: BigInt(86400), // 1 day between each order -> 60 * 60 * 24
    inputMint: USDC, // sell
    outputMint: BONK, // buy
    minOutAmountPerCycle: null,  // effectively allows for a max price. refer to Integration doc
    maxOutAmountPerCycle: null, // effectively allows for a min price. refer to Integration doc
    startAt: null, // unix timestamp in seconds
    userInTokenAccount, // optional: if the inputMint token is not in an Associated Token Account but some other token account, pass in the PublicKey of the token account, otherwise, leave it undefined
  };

  const { tx, dcaPubKey } = await dca.createDcaV2(params);
  const txid = await sendAndConfirmTransaction(connection, tx, [user]);

  console.log('Create DCA: ', { txid });

  return dcaPubKey;
}

// this is for withdrawing from program ATA
async function withdraw(dcaPubKey) {
  // it's possible to withdraw in-tokens only or out-tokens only or both in and out tokens together. See WithdrawParams for more details
  co