From e35d14864cb6fe3727f5a93f3037786add10beb4 Mon Sep 17 00:00:00 2001
From: Aztec Bot <49558828+AztecBot@users.noreply.github.com>
Date: Mon, 16 Sep 2024 09:23:23 -0400
Subject: [PATCH] chore: redo typo PR by Olexandr88 (#8560)

Thanks Olexandr88 for
https://github.com/AztecProtocol/aztec-packages/pull/8424. Our policy is
to redo typo changes to dissuade metric farming. This is an automated
script.
---
 docs/docs/aztec/concepts/wallets/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/docs/aztec/concepts/wallets/index.md b/docs/docs/aztec/concepts/wallets/index.md
index c8550e418c0..790db2cd1f9 100644
--- a/docs/docs/aztec/concepts/wallets/index.md
+++ b/docs/docs/aztec/concepts/wallets/index.md
@@ -28,7 +28,7 @@ Note that users must be able to receive funds in Aztec before deploying their ac
 
 Every transaction in Aztec is broadcast to the network as a zero-knowledge proof of correct execution, in order to preserve privacy. This means that transaction proofs are generated on the wallet and not on a remote node. This is one of the biggest differences with regard to EVM chain wallets.
 
-A wallet is responsible for **creating** an _execution request_ out of one or more _function calls_ requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](../../../protocol-specs/transactions/local-execution.md#execution-request) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
+A wallet is responsible for **creating** an _execution request_ out of one or more _function calls_ requested by a dapp. For example, a dapp may request a wallet to "invoke the `transfer` function on the contract at `0x1234` with the following arguments", in response to a user action. The wallet [turns that into an execution request](../../../protocol-specs/transactions/local-execution.md#execution-request) with the signed instructions to execute that function call from the user's account contract. In an [ECDSA-based account](https://github.com/AztecProtocol/aztec-packages/blob/master/noir-projects/noir-contracts/contracts/ecdsa_k_account_contract/src/main.nr), for instance, this is an execution request that encodes the function call in the _entrypoint payload_, and includes its ECDSA signature with the account's signing private key.
 
 Once the _execution request_ is created, the wallet is responsible for **simulating** and **proving** the execution of its private functions. The simulation yields an execution trace, which can be used to provide the user with a list of side effects of the private execution of the transaction. During this simulation, the wallet is responsible of providing data to the virtual machine, such as private notes, encryption keys, or nullifier secrets. This execution trace is fed into the prover, which returns a zero-knowledge proof that guarantees correct execution and hides all private information. The output of this process is a [_transaction object_](../../../protocol-specs/transactions/tx-object.md).