From 76b97dd89be869ae4f9183b58d3502f0007bffc2 Mon Sep 17 00:00:00 2001 From: dhai Date: Tue, 24 Dec 2024 22:46:06 +0530 Subject: [PATCH] reword Co-authored-by: Daniel Bate --- apps/docs/src/guide/contracts/optimising-contract-calls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/apps/docs/src/guide/contracts/optimising-contract-calls.md b/apps/docs/src/guide/contracts/optimising-contract-calls.md index d41ddb5978..c657fc686b 100644 --- a/apps/docs/src/guide/contracts/optimising-contract-calls.md +++ b/apps/docs/src/guide/contracts/optimising-contract-calls.md @@ -12,7 +12,7 @@ The below flowchart shows this entire process: The SDK will prepare the contract call _after_ the user has submitted the transaction at the application level. This is so the transaction is funded in it's finalised state. However this makes the chain feel slower than it actually is as we are making two network requests. -This can be mitigated by preparing the contract call _before_ the user presses 'Submit Transaction'. If the transaction is prepared beforehand, the SDK only has to send the transaction to the network and wait for it to be confirmed. This reflects the actual speed of the chain to the user. +This can be mitigated by preparing the contract call _before_ the user submits the transaction. If the transaction is prepared beforehand, the SDK only has to send the transaction to the network and wait for it to be confirmed. This reflects the actual speed of the chain to the user. You can experience this yourself by trying out this [demo](https://fuel-wallet-prefetch-experiment-75ug.vercel.app/).