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.

https://github.com/FuelLabs/fuels-ts/blob/01375ce29bf5f18b5d8f5e97fec5d82f4fb6ae5f/packages/account/src/account.ts#L653-L659

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.

[danielbate]

In #3689 I introduced a usePrepareForSend flag to signal to Account.sendTransaction that this method should be used in the tx flow. FE did not like this approach and instead we should check for the presence of the function. I have been having trouble with making it optional on the abstract class, but let's see.

I'm going to revert #3869 so it is not included in 0.100.0 and we can agree the finalised approach with FE. As this will likely be similar to #3736, I agree with these going together anyway.

[danielbate]

Blocked until #3669 and #3737 are complete.

[danielbate]

In #3669 we changed the FuelConnector.sendTransaction signature to return both a string | TransactionResponse:

https://github.com/FuelLabs/fuels-ts/blob/e8494fa488848ba215e339e2dd12364ab5b3a1a1/packages/account/src/connectors/fuel-connector.ts#L47-L51

Although this does not encourage connectors or wallets to return a prepared request to give full flexibility to the SDK, it does enable the single request submit -> summary flow.

This may be enough for now and we can implement in the EVM/SVM connectors along with #3769.

But as preferred by @LuizAsFight, the Wallet will likely remain with the same 3 request flow for now.

I will prepare a draft PR to follow #3769 that supports this flow in docs/tests.

[arboleya]

@danielbate Two quick questions:

1. What are the three requests for the Wallet?
2. Would this make the Wallet feel slower after users confirm? IIRC today it doesn't wait for anything and just closes very fast. Ideally, we didn't want to lose this snapiness.

[danielbate]

What are the three requests for the Wallet?

3 request flow from submission -> summary generation.

• Wallet performs submitAndAwaitStatus
• SDK performs statusChange
• SDK performs getTransactionWithReceipts

Would this make the Wallet feel slower after users confirm? IIRC today it doesn't wait for anything and just closes very fast. Ideally, we didn't want to lose this snapiness.

No the wallet will remain as it is and will not lose it's snappiness. Only the App/SDK can be made snappier from this change.

[arboleya]

Resolved via:

• https://github.com/FuelLabs/fuel-connectors/issues/514