diff --git a/docs/home/300-react-to-events/2-primitive-catalogue/1-introduction.md b/docs/home/300-react-to-events/2-primitive-catalogue/1-introduction.md
index d3b3444c..39ad4d93 100644
--- a/docs/home/300-react-to-events/2-primitive-catalogue/1-introduction.md
+++ b/docs/home/300-react-to-events/2-primitive-catalogue/1-introduction.md
@@ -54,6 +54,8 @@ The data collected and functions used to access it are specific to each type of
 
 Scheduled inputs are triggered by events specific to each extension type, with the circumstances and the format of the scheduled input described in their respective sections. The inputs are always scheduled either for the current blockheight (which enables them to be processed immediately, as scheduled inputs are processed before the state transition function is called), or, if they are triggered before the overall `START_BLOCKHEIGHT` of the game node (specified in the `.env` file), in the so-called _pre-sync_ phase, they are scheduled for `START_BLOCKHEIGHT + 1` (which is the first blockheight for which the state transition function is called). The scheduled inputs will always start with the prefix specified in the config as `scheduledPrefix`.
 
+The [state transition function](../../200-read-write-L2-state/10-read-data.md#stf-function) call triggered by a scheduled input originating from a Primitive can access the original transaction hash using `inputData.scheduledTxHash`.
+
 To learn by example, please consult the NFT LvlUp game template – `./paima-engine-linux init template nft-lvlup` to learn more.
 
 ## Relation to funnels