diff --git a/docs/fundamentals-and-concepts/interacting-with-contracts.mdx b/docs/fundamentals-and-concepts/interacting-with-contracts.mdx
index 92b57f41..9a3f4ffc 100644
--- a/docs/fundamentals-and-concepts/interacting-with-contracts.mdx
+++ b/docs/fundamentals-and-concepts/interacting-with-contracts.mdx
@@ -111,7 +111,7 @@ A footprint is a set of ledger keys, each marked as either read-only or read-wri
 
 Any Soroban transaction submitted by a user has to be accompanied by this footprint. A single footprint encompasses _all_ the data read and written by _all_ contracts transitively invoked by the transaction: not just the initial contract that the transaction calls, but also all contracts it calls, and so on.
 
-Since it can be difficult for a user to know which ledger entries a given contract call will attempt to read or write (especially those entries caused by contracts called by other contracts deep within a transaction), the host provides an auxiliary `simulateTransaction` mechanism that executes a transaction against a temporary, possibly slightly-stale _snapshot_ of the ledger. The `simulateTransaction` mechanism is _not_ constrained to only read or write the contents of a footprint; rather it _records_ a footprint describing the transaction's execution, discards the execution's effects, and then returns the recorded footprint to its caller.
+Since it can be difficult for a user to know which ledger entries a given contract call will attempt to read or write (especially entries that are caused by other contracts deep within a transaction), the host provides an auxiliary `simulateTransaction` mechanism that executes a transaction against a temporary, possibly slightly-stale _snapshot_ of the ledger. The `simulateTransaction` mechanism is _not_ constrained to only read or write the contents of a footprint; rather it _records_ a footprint describing the transaction's execution, discards the execution's effects, and then returns the recorded footprint to its caller.
 
 This simulation-provided footprint can then be used to accompany a "real" submission of the same transaction to the network for real execution. If the state of the ledger has changed too much between the time of the simulated and the real submission, the footprint may be too stale and no longer accurately identify the _keys_ the transaction needs to read and/or write, at which point the simulation must be retried to refresh the footprint.