Multiple txs in actions/blinks

sRFC
1

Multiple txs in actions/blinks

Summary

Currently Action POST response only allows for the returning of a single transaction (tx) as a string.

/**
 * Response body payload returned from the Action POST Request
 */
export interface ActionPostResponse<T extends ActionType = ActionType> {
  /** base64 encoded serialized transaction */
  transaction: string;
  /** describes the nature of the transaction */
  message?: string;
  links?: {
    /**
     * The next action in a successive chain of actions to be obtained after
     * the previous was successful.
     */
    next: NextActionLink;
  };
}

There are many cases where more complex on-chain actions with programs need to be taken due to the limitation of Solana account and tx sizes. In such cases forcing the user to separately sign multiple txs when wallets already support the signing of multiple txs at once (ie. phantom with signAndSendAllTransactions) simply results in worse UX. Oftentimes this means making a decision between relaying/proxying txs for better UX or creating long more transparent action chains with worse UX.

Implementation:

Expanding the transaction field to an array of txs would solve this problem and allow for users to still have great UX while retaining the transparency of executing more complex on-chain actions with multiple txs directly. For example something like:

/**
 * Response body payload returned from the Action POST Request
 */
export interface ActionPostResponse<T extends ActionType = ActionType> {
  /** array of base64 encoded serialized transaction(s) */
  transactions: [];
  /** describes the nature of the transaction */
  message?: string;
  links?: {
    /**
     * The next action in a successive chain of actions to be obtained after
     * the previous was successful.
     */
    next: NextActionLink;
  };
}
1 Like
2

I think for most cases it makes sense to batch multiple instructions into one transaction and return it instead of returning an array of multiple transactions.

It’s possible I’m wrong, however as far as I know the only benefit of signing and sending multiple transactions as once is to go around the max size limit and account read/write limit of a single transaction on Solana. On the other hand, multiple transactions mean the user pays more in fees and the transactions are not atomic, meaning that some could fail and others may succeed, which are all cases that would cause harm to the UX instead of improving it.

For these reasons I see that specifically for Actions and Blinks transaction batching makes more sense instead of returning multiple transactions to be signed and sent.

3

Yes the tx size limit is the primary issue. Most complex on-chain actions cannot be done all in one tx bc you cannot pack all of the required ixs into one tx.

Currently for most non blink use cases standard practice for failed txs is to simply retry them. I would imagine something similar could be implemented in blinks use cases.

Am curious what you mean by “Actions and Blinks transaction batching”? Do you mean action chaining?

4

This would be very beneficial for us at Access Protocol as well as we could implement a blink for reward claiming.

We are batching as many operations into a single transaction as possible but even with this approach there are multiple transactions to be signed due to the transaction size limit.

I think that this is a good idea as the most prominent wallets have an implementation of signTransactions method

5

@nickfrosty @tsmbl @aliquotchris @0xaryan would love your feedback on this