How do I interract with someelses's public program on Solana?

There’s information of how to write and interract with my own program on Solana.

But how to do it when it’s someelse’s program? Is there any example of it?

Option #1: there may not be any documentation for that particular program. Namely, I wander on explorer.solana.com and stumble upon a program. How would I interract with it knowing about it only what is seen on the explorer?

When interacting with a Solana program you essentially just send it a set of bytes and a list of Solana account addresses marked as either read-only or read-write. So if you wanted to interact with an undocumented program you would have to have examples of what accounts you would need to send it and what kind of data to send it.

Because the data sent to the program is just raw bytes, it could be rather difficult to know exactly what bytes to send and what all of the bytes mean.

In my own little Solana demo app, I use the Web3.js API ( see the code here ) to create transactions, passing the required accounts, signers, and raw binary data to the program to do what I want it to do. If if were somebody else’s program, the process would be the same, you would just have to figure out what bytes, signers and accounts are needed by that program to do what it needs to do.

You would look for transactions already on the chain that do what you want to do with that program, and then try and imitate how it uses the accounts and binary data to do whatever it’s doing.

2 Likes
  1. “Data” sent to a programm and “accounts” sent to a program → are “data” and “accounts” synonyms here?

  2. But can’t all necessary information (data and other things) be deduced from solscan.io alone? Or at least from solcan and some additional API calls or calculations?

All in all, I want to be able to pick a certain transaction, but could be a random one too, in the future, on solscan.io, reverse engineer it and execute with slightly different parameters.

No.

For every Solana transaction there are actually three kinds of inputs:

  1. A list of accounts and their read/write status: The first input to a Solana transaction is a list of account addresses that must be in a specific order as expected by the smart contract. Additionally, each account must be marked as only read-only, or read-write. The smart contract will use these accounts during the transaction, possibly modifying the accounts that are marked as read-write.

    For instance, in the demo app I made, in order to create a new reservation on a calendar, I have to create a new account keypair. Then I have to pass this account keypair as read-write to the smart contract in the accounts list. The smart contract will then initialize the account with the reservation data.

  2. A list of raw bytes: The second input to a Solana transaction is the raw set of bytes sent to the smart contract. These bytes are usually serialized in the Borsh format. Reading or understanding the Borsh format, though, requires that you know the exact shape of the structure used by the smart contract.

    For instance, in my example above, of creating a calendar reservation, I need to pass the data about what date to create the reservation at, how long the reservation is, and the username of the user creating the reservation. These all get written to a raw bytes list. In order to understand the bytes, you must know exactly what each field means. In my case I could have the starting time in seconds as a f64, the ending time in seconds as a f64, and the username as a string, in that order. You must know which fields, what type, and what order in order to understand the byte list, or you just have to guess.

  3. Signatures: Finally, the last input to the transaction is a list of signatures. Depending on what the contract needs to do, it will require signatures from users that need to authorize the transaction. For instance, if I am creating a calendar reservation for a specific wallet, that transaction needs to be signed by that wallet, so that one user is not allowed to create reservations for another user.

In summary, you can, using only the data on Solscan, know how to send the same transaction, but if you need to make modifications to certain parameters, it requires understanding the meaning of the different accounts that are passed in, and the raw bytes that goes along with it. Because if you change the wrong bytes in the data, or you pass in the wrong accounts, or fail to get a required signature, then you will either accidentally tell the contract to do something you didn’t want it to, or, more likely, you will get an error from the contract because of invalid data or accounts.

1 Like