Gas Station: how to integrate frontend transaction signing

​

Overview

​

Examples

​

Sample app overview

​

Consider obtaining the user signature pre-sponsorship

​

Build and sign on the FE, sponsor and submit on the BE

1. Frontend: Build a feePayer transaction.
2. Frontend: Obtain the sender’s signature over the transaction.
3. Frontend: Send a request to your app’s backend to sponsor and submit the transaction. This request will include serialized versions of the transaction and the sender’s AccountAuthenticator.
4. Backend: Send a gas_sponsorAndSubmitSignedTransaction request to Shinami’s Gas Station (with the de-serialized transaction and sender AccountAuthenticator).
5. Shinami: Shinami will sponsor the transaction and then submit it with the sender and feePayer signatures, returning the PendingTransactionResponse to your backend if successful.
6. Backend: Handle the response as needed.
7. Backend: Send a response to the frontend.
8. Frontend: Handle the response (this is the response to the request in Step 3). In our sample app, we poll a Movement node until it has a record of the transaction and then print the user’s message that was included in the transaction.

​

Build and sponsor on the BE, sign and submit on the FE

1. Frontend: Send a request to your app’s backend to build and sponsor a transaction. Include any data from the FE needed to build the transaction. In our case, that’s the sender’s address and the message the user submitted in the form on the page.
2. Backend: Build a feePayer transaction.
3. Backend: Make a gas_sponsorTransaction request to Shinami’s Gas Station to sponsor the transaction.
4. Backend or Frontend: Set the transaction’s feePayerAddress to the feePayer address value returned from the Gas Station sponsorship request (our TypeScript SDK sets this for you automatically and so does not explicitly return it to you). The sender can sign the transaction with either the actual feePayer address or the special 0x0 address assigned when you create a feePayer transaction. However, you must ensure the actual feePayer’s address is set on the transaction before you submit it to the Movement blockchain. If not, you’ll get an INVALID_SIGNATURE error because the feePayer’s signature was over a transaction with the feePayer address but the submitted transaction still has the 0x0 address.
5. Backend: Return the serialized transaction, feePayer AccountAuthenticator, and (optionally) feePayer’s address to the frontend.
6. Frontend: Deserialize the transaction and obtain the sender’s signature over the transaction.
7. Frontend: Submit the transaction, along with the sender and (deserialized) feePayer signatures, to a Movement node.
8. Frontend: Handle the response (a PendingTransactionResponse if successful). In our sample app, we poll a Movement node until it has a record of the transaction and then print the user’s message that was included in the transaction.

​

Other flows in our sample app

• Build and sign on the FE, sponsor on the BE, submit on the FE.
• Build and sponsor on the BE, sign on the FE, submit on the BE.
• Embedded Shinami Invisible Wallet: Build, sponsor, and sign on the BE.

​

Appendix

​

Common issues

​

INVALID_SIGNATURE error when submitting the transaction

​

Serializing and deserializing

// AccountAuthenticator
const serializedAccountAuthenticator = authenticator.bcsToHex().toString();
// AccountAddress
const serializedAccountAddress = accountAddress.bcsToHex().toString();
// SimpleTransaction
const serializedSimpleTransaction = simpleTx.bcsToHex().toString();

import {
  SimpleTransaction, Deserializer, AccountAuthenticator, Hex, AccountAddress
} from "@aptos-labs/ts-sdk";

AccountAuthenticator.deserialize(new Deserializer(
  Hex.fromHexString(serializedAccountAuthenticator).toUint8Array()));

AccountAddress.deserialize(new Deserializer(
  Hex.fromHexString(serializedAccountAddress).toUint8Array()));

SimpleTransaction.deserialize(new Deserializer(
  Hex.fromHexString(serializedSimpleTransaction).toUint8Array()));