Inverted Submission Flow

[danielbate]

Problem

When a transaction is submitted from a connector and approved in a user wallet, it takes 3 requests to submit a tx and build it's summary inside the application. Versus it only taking 1 request when submitting a tx from the SDK when we have the private key readily accessible.

The main reason for this is that as the wallet submits the tx, the application loses context of both the submission and finalised transaction, and therefore it must fetch both the raw tx and tx status to build it's summary.

This issue aims to bring parity to these 2 flows and enable single request submission and summary inside apps using connectors, as visualised below:

Solution

To enable the above flow, the app must take ownership of tx submission. With the wallet passing back the finalised tx, propagated via the connectors.

This would involve the following work:

SDK

1. Introduce a transaction preparation function to be utilised by connectors, via the connector interface. The expected signature is as follows:

  /**
   * Should perform all necessary operations (i.e estimation,
   * funding, signing) to prepare a tx so it can be submitted
   * at the app level.
   *
   * @param address - The address to sign the tx
   * @param transaction - The tx to prepare
   *
   * @returns The prepared tx request
   */
  async prepareForSend(address: string, transaction: TransactionRequestLike): Promise<TransactionRequest>;

2. Utilise the preparation method inside Account.sendTransaction so that the process is still obfuscated to consumers.

fuels-ts/packages/account/src/account.ts

Lines 653 to 659 in 01375ce

	async sendTransaction(
	transactionRequestLike: TransactionRequestLike,
	{ estimateTxDependencies = true, onBeforeSend, skipCustomFee = false }: AccountSendTxParams = {}
	): Promise<TransactionResponse> {
	if (this._connector) {
	return this.provider.getTransactionResponse(
	await this._connector.sendTransaction(this.address.toString(), transactionRequestLike, {

Non Native Wallets

For EVM and SVM wallets, all logic is inside the connector, so we need to do only the following

1. Introduce the new preparation method inside the relevant connector, identical to sendTransaction however passing back the prepared tx rather than submitting

Native Wallets

Wallets such as Fuel Wallet and Bako, more of the logic is on the wallet side so would involve the following:

1. Introduce the preparation method inside the wallet itself, with a new event to trigger the flow
2. Introduce the method inside the connector, that submits the event

[danielbate]

Implementation is now complete as part of #3689 and was proved via the EVM and SVM connectors as can be seen here.