0

I'm attempting to use the programSubscribe method to listen for specific types of Token Program events, namely "initializeMint". Essentially, I want to know about the creation of token accounts before they mint.

In explorer, I can see that specific event associated with the Token Program, as well as the actual account creation, but when I listen to all events from the program all I see are events with type="mint" or type="account". Should I not expect to see the exact phrase "initializeMint" in the emitted event?

Clearly I'm misunderstanding something or there are assumptions that aren't clear to me yet. Are all of these events with type="account" the creation of token accounts? The documentation on Web Sockets doesn't go into much detail on the payload.

devnet txn: https://explorer.solana.com/tx/rBrU8B8FDNAan6wYWvo9N2xfNLtMwXxNQned8Bmjgm7JWHfje2jJKXTE4mWqf7mBz43G82UpDkXh6W2iJu3P9zm?cluster=devnet

And the docs I have been referring to: https://solana.com/docs/rpc/websocket/programsubscribe

I also looked at logsSubscribe but that was much more verbose and gave me the sense that there were other scenarios when InitializeMint appeared in the instructions.

Any guidance, link to robust documentation on event payloads, etc. would be greatly appreciated.

Thanks

1 Answer 1

1

The programSubscribe endpoint specifically gives account updates when one of the accounts owned by the program changes:

Subscribe to a program to receive notifications when the lamports or data for an account owned by the given program changes

This means that you'll get all of the accounts, both "mint"s and "account"s, and not the instructions that were executed, like initializeMint.

You have two options:

  • Keep using programSubscribe, and count that a mint has been created when its supply is equal to 0. Note that this approach is fallible, because it's possible for a mint to be initialized and also for tokens to be created within the same transaction, so you'll miss those creations.
  • Use logSubscribe and parse for the following two lines, as shown in your sample transaction:
  "Program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [1]",
  "Program log: Instruction: InitializeMint",

I would go with the second approach since I know it'll always work, whereas the first one is more brittle.

3
  • Thanks, Jon. This is where I was going with it. While the log event payloads can be verbose, logSubscribe also offers much more flexibility and extensibility. For example, if the boilerplate RPC code is agnostic of the data being parsed, I could simply pass, at request/subscribe time, a parser method to handle the result.
    – MolonLabe
    Commented Mar 27 at 12:43
  • Hey Jon, is it possible to elaborate a little further as to why the creation states do not get emitted through the pubsub?
    – Nicholas
    Commented May 15 at 23:55
  • Pubsub only gives the final state of an account, so you can miss mint creations. For example, if a transaction creates a mint and then mints some tokens, the pubsub will give a notification of a mint with a non-zero supply. How can you deduce that the mint was created based on that information? You also need to see the instructions that were executed in the transaction to be sure.
    – Jon C
    Commented May 16 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.