Minor fix (#231)

docs/03-intermediate/02-message-receiving/handle_reply.md

@@ -9,7 +9,7 @@ In this lesson, you will learn how a program can efficiently handle request mess
 
 Imagine a dApp with specific functionality. To update this application, you'd upload a new version to the blockchain, which would cause the dApp's address to change. For a smooth user transition, you need to maintain a consistent address for interaction. A Proxy program lets you achieve this. The Proxy program will act as an intermediary: it will receive messages from users, forward them to the updated version of the application and relay responses back to the users. Each time you update the Target program, you’d only need to update the program address of the Target in the Proxy Program.
 
-Before analyzing program codes in detail, it will be helpful to first present a schematic overview of how Gear programs operate:
+Before analyzing program codes in detail, it will be helpful to first present a schematic overview of how programs on Vara operate:
 
 ![gif 1](../img/02/handle_reply.gif)
 
@@ -89,7 +89,7 @@ extern "C" fn handle() {
 }
 ```
 
-The Gear program utilizes the `handle_reply()` function to handle replies to messages. Let’s delve into processing the response message from the second program:
+The program on Vara utilizes the `handle_reply()` function to handle replies to messages. Let’s delve into processing the response message from the second program:
 
 1. Use the `msg::reply_to()` function to retrieve the identifier of the message for which the `handle_reply()` function was invoked.
 2. Ensure that the message identifier matches the identifier of the message sent from the `handle()` function. This step verifies that the response corresponds to the specific message sent earlier.

docs/03-intermediate/03-wait-wake-system/wait_wake.md

@@ -5,7 +5,7 @@ hide_table_of_contents: true
 
 # wait() and wake()
 
-To enhance message handling in Gear programs, the `exec::wait()` and `exec::wake()` functions are invaluable tools:
+To enhance message handling in programs on Vara, the `exec::wait()` and `exec::wake()` functions are invaluable tools:
 
 ## Wait
 

docs/03-intermediate/04-delayed-message/delayed-message.md

@@ -9,7 +9,7 @@ Conventional approaches by programs on other blockchains rely on external, centr
 
 An external transaction acts as a trigger to activate the program and start its logic. For instance, someone can initiate an auction by sending a message to the auction program. After the auction period expires, the program needs to process the auction's outcome. However, this process awaits until someone sends the correct message to the program, triggering this action.
 
-Gear Protocol achieves fully on-chain logic, eliminating reliance on external services by introducing delayed messaging functionality. Programs within Gear-powered networks can execute autonomously over an unlimited number of blocks, provided there is sufficient gas for execution. This advancement eliminates the need for centralized components in dApps, enabling them to operate entirely on-chain.
+Vara network achieves fully on-chain logic, eliminating reliance on external services by introducing delayed messaging functionality. Programs within Gear-powered networks can execute autonomously over an unlimited number of blocks, provided there is sufficient gas for execution. This advancement eliminates the need for centralized components in dApps, enabling them to operate entirely on-chain.
 
 The `msg::send_delayed` function facilitates sending a message after a specified delay, accepting the following parameters:
 - `program` - the program (or user) to which the message will be directed;