Reactive-Network · konstantinkoniukov · Apr 28, 2026 · Apr 24, 2026 · Apr 24, 2026 · Apr 24, 2026
diff --git a/docs/docs/debugging.md b/docs/docs/debugging.md
@@ -35,7 +35,7 @@ emit Callback(chain_id, stop_order, CALLBACK_GAS_LIMIT, payload);
 
 ## Contract Inactive
 
-If you see `Contract Status: Inactive` on Reactscan, it means the contract doesn’t have enough funds to cover gas for reactive transactions. Both **destination** and **reactive contracts** must hold sufficient balance to stay active.
+If you see `Contract Status: Inactive` on Reactscan, it means the contract doesn’t have enough funds to cover gas for Reactive transactions. Both destination and Reactive contracts must hold sufficient balance to stay active.
 
 ![Debugging Image](../docs/img/contract-inactive.png)
 

diff --git a/docs/docs/demos.md b/docs/docs/demos.md
@@ -12,30 +12,42 @@ hide_title: true
 
 This section contains practical demos of how Reactive Network enables event-driven, cross-chain smart contract automation. Each demo highlights a specific pattern from basic event callbacks to advanced DeFi protection mechanisms.
 
-## Reactive Network Demo
+## Reactive Network Basic Demo
 
-The [Reactive Network Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/basic) is the starting point. It demonstrates the lifecycle of a Reactive Contract: an event emitted on an origin chain is detected by a Reactive Contract, which then triggers a callback on a destination chain. If you’re new to Reactive Network, begin here.
+The [Reactive Network Basic Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/basic) is the starting point. It demonstrates the lifecycle of a Reactive contract: an event emitted on an origin chain is detected by a Reactive contract, which then triggers a callback on a destination chain. If you’re new to Reactive Network, begin here.
 
 ## Uniswap V2 Stop Order Demo
 
-The [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) implements automated stop orders on Uniswap V2 liquidity pools. A Reactive Contract subscribes to `Sync` events from a Uniswap pair. When the exchange rate crosses a user-defined threshold, it triggers a callback that executes the swap on the destination chain. This demo shows how price-based automation can run without off-chain bots.
+The [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) implements automated stop orders on Uniswap V2 liquidity pools. A Reactive contract subscribes to `Sync` events from a Uniswap pair. When the exchange rate crosses a user-defined threshold, it triggers a callback that executes the swap on the destination chain.
 
 ## Uniswap V2 Stop-Loss & Take-Profit Orders Demo
 
-The [Uniswap V2 Stop-Loss & Take-Profit Orders Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-take-profit-order) expands on stop orders by supporting both stop-loss and take-profit strategies within a personal deployment. A user-owned Reactive Contract monitors pair reserve updates and triggers execution when thresholds are crossed. Each user deploys their own callback and Reactive Contracts, ensuring isolated order management and full control. This example demonstrates structured, event-driven trade automation directly tied to on-chain liquidity changes.
+The [Uniswap V2 Stop-Loss & Take-Profit Orders Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-take-profit-order) expands on stop orders by supporting both stop-loss and take-profit strategies within a personal deployment. A user-owned Reactive contract monitors pair reserve updates and triggers execution when thresholds are crossed.
 
 ## Aave Liquidation Protection Demo
 
-The [Aave Liquidation Protection Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/aave-liquidation-protection) shows how to automate position protection on Aave. A Reactive Contract subscribes to periodic CRON events and triggers health checks for a user’s lending position. If the health factor drops below a defined threshold, the callback contract executes protection actions — depositing collateral, repaying debt, or both. This demo illustrates time-based automation for DeFi risk management.
+The [Aave Liquidation Protection Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/aave-liquidation-protection) shows how to automate position protection on Aave. A Reactive Contract subscribes to periodic CRON events and triggers health checks for a user’s lending position. If the health factor drops below a defined threshold, the callback contract executes protection actions: depositing collateral, repaying debt, or both.
+
+## Leverage Loop Demo
+
+The [Leverage Loop Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/leverage-loop) automates leveraged looping on Aave V3. The user deposits collateral into a personal smart account, and a Reactive contract detects the deposit and runs the loop automatically until the target health factor is reached or the maximum iteration count is hit.
+
+## Automated Prediction Market Demo
+
+The [Automated Prediction Market Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/automated-prediction-market) implements a prediction market with automated payouts. Users create questions, participants buy shares in outcomes, and a multisig resolves the result. Once the `PredictionResolved` event is emitted, a Reactive contract detects it and triggers batch distribution of winnings.
+
+## Gasless Cross-Chain Atomic Swap Demo
+
+The [Gasless Cross-Chain Atomic Swap Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/gasless-cross-chain-atomic-swap) enables trustless token exchanges across two blockchains without bridges or custodians. Two users initiate and acknowledge a swap on their respective chains, deposit tokens, and a Reactive contract orchestrates the rest — syncing state, confirming deposits, and completing the swap on both sides automatically. Users only pay gas on their own chain.
 
 ## Approval Magic Demo
 
-The [Approval Magic Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/approval-magic) shows subscription-based automation triggered by ERC-20 approval events. A Reactive Contract monitors approval logs, while a service contract manages user registrations. When an approval is detected, the system can automatically initiate follow-up actions such as swaps or exchanges. This demo highlights how event-centric logic can simplify multi-step token workflows.
+The [Approval Magic Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/approval-magic) shows subscription-based automation triggered by ERC-20 approval events. A Reactive contract monitors approval logs, while a service contract manages user registrations. When an approval is detected, the system can automatically initiate follow-up actions such as swaps or exchanges.
 
 ## Hyperlane Demo
 
-The [Hyperlane Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/hyperlane) shows cross-chain communication using Hyperlane alongside Reactive Network. This example shows how Reactive Network can integrate with external messaging protocols for two-way cross-chain interaction.
+The [Hyperlane Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/hyperlane) shows cross-chain communication using Hyperlane alongside Reactive Network. This example shows how Reactive can integrate with external messaging protocols for two-way cross-chain interaction.
 
 ## CRON Demo
 
-The [Cron Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/cron) shows time-based automation using Reactive Network’s built-in CRON events. Instead of waiting for external transactions, the Reactive Contract subscribes to periodic system-emitted events and executes logic on a fixed schedule. This pattern is useful for recurring tasks such as scheduled updates, reward distributions, or regular DeFi position checks.
+The [Cron Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/cron) shows time-based automation using Reactive Network’s built-in CRON events. Instead of waiting for external transactions, the Reactive contract subscribes to periodic system-emitted events and executes logic on a fixed schedule. This pattern is useful for recurring tasks such as scheduled updates, reward distributions, or regular DeFi position checks.
diff --git a/docs/docs/economy.md b/docs/docs/economy.md
@@ -171,7 +171,7 @@ cast call $CALLBACK_PROXY_ADDR "reserves(address)" $CONTRACT_ADDR --rpc-url $DES
 
 ### Balance
 
-Retrieve the REACT balance of a reactive contract:
+Retrieve the REACT balance of a Reactive contract:
 
 ```bash
 cast balance $CONTRACT_ADDR --rpc-url $REACTIVE_RPC

diff --git a/docs/docs/events-and-callbacks.md b/docs/docs/events-and-callbacks.md
@@ -14,7 +14,7 @@ Reactive Contracts process on-chain events and trigger transactions on destinati
 
 ## Event Processing
 
-To process events, a Reactive Contract must implement the `react()` function defined in the [IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) interface:
+To process events, a Reactive contract must implement the `react()` function defined in the [IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) interface:
 
 ```solidity
 // SPDX-License-Identifier: UNLICENSED
@@ -81,7 +81,7 @@ When this event appears in the transaction trace, Reactive Network submits a tra
 - **payload** — encoded function call
 
 :::info[Callback Authorization]
-Reactive Network automatically replaces the first 160 bits of the callback payload with the ReactVM ID (the deployer's address). As a result, the first callback argument is always the ReactVM address (`address` type), regardless of how it is named in Solidity. This ensures that callbacks are tied to the correct Reactive Contract.
+Reactive Network automatically replaces the first 160 bits of the callback payload with the ReactVM ID (the deployer's address). As a result, the first callback argument is always the ReactVM address (`address` type), regardless of how it is named in Solidity. This ensures that callbacks are tied to the correct Reactive contract.
 :::
 
 ### Example: Uniswap Stop Order Demo

diff --git a/docs/docs/hyperlane.mdx b/docs/docs/hyperlane.mdx
@@ -12,11 +12,11 @@ import MailboxAddressTable from "../../src/components/hyperlane-mailbox-table";
 
 ## Overview
 
-Reactive Contracts send **cross-chain callback transactions** to destination chains. By default, callbacks are delivered through the Reactive **Callback Proxy**. Hyperlane Mailboxes provide an alternative transport for these callbacks. The Mailbox contract on each supported chain acts as the entry and exit point for cross-chain messages.
+Reactive Contracts send **cross-chain callback transactions** to destination chains. By default, callbacks are delivered through the Reactive callback proxy. Hyperlane Mailboxes provide alternative transport for these callbacks. The Mailbox contract on each supported chain acts as the entry and exit point for cross-chain messages.
 
 Reactive Contracts still listen to event logs and trigger actions in the same way, only the callback transport changes. Hyperlane transport is useful when:
 
-- A chain does not yet support the Callback Proxy
+- A chain does not yet support the callback proxy
 - You need additional routing flexibility
 - You want to integrate Reactive Contracts with existing Hyperlane-based systems
 

diff --git a/docs/docs/official-addresses.md b/docs/docs/official-addresses.md
@@ -8,13 +8,11 @@ unlisted: true
 
 # Addresses
 
-This page contains all blockchain addresses related to the Reactive Network.
+This page contains all blockchain addresses related to Reactive Network.
 
-| Chain            | Address                                      | Description                       |
-|------------------|----------------------------------------------|-----------------------------------|
-| Ethereum Mainnet | `0x6fBb0C7A0ec62007013748e47823C239Dd48BfEf` | Bridge PRQ\<\>REACT               |
-| Ethereum Mainnet | `0x42458259d5c85fB2bf117f197f1Fef8C3b7dCBfe` | Bridge WREACT\<\>REACT            |
-| BNB Smart Chain  | `0x577432505892F7B18a26166247a7456B814E2f68` | Bridge PRQ BNB>REACT              |
-| Reactive Mainnet | `0x4F55172b66bab5e58DB20bd4d25e9301A22f2979` | Reactive part of PRQ\<\>REACT     |
-| Reactive Mainnet | `0x1aa8615D92e0F5b65Bf02939C116db3AA654D38A` | Reactive part of  WREACT\<\>REACT |
-| Reactive Mainnet | `0x1176172108b1611f7A1d2F7b0A6f889650F99EAB` | Reactive part of  PRQ BNB>REACT   |
+| Chain            | Address                                      | Description                 |
+|------------------|----------------------------------------------|-----------------------------|
+| Ethereum Mainnet | `0x42458259d5c85fB2bf117f197f1Fef8C3b7dCBfe` | Bridge WREACT\<\>REACT      |
+| Base Mainnet     | `0xe68eAD313A33A78E0B00e25aE22800D4455cd5C8` | Bridge WREACT\<\>REACT      |
+| Reactive Mainnet | `0x1aa8615D92e0F5b65Bf02939C116db3AA654D38A` | REACT\<\>WREACT to Ethereum |
+| Reactive Mainnet | `0xCAe30c6Ca71E830bE6370d110758e76fB9e44D9B` | REACT\<\>WREACT to Base     |
diff --git a/docs/docs/origins-and-destinations.mdx b/docs/docs/origins-and-destinations.mdx
@@ -18,7 +18,7 @@ Reactive Contracts (RCs) can **listen to event logs on one chain** and **trigger
 - **Origin** — the chain where events happen and event logs are read from (the event source).
 - **Destination** — the chain where Reactive Network delivers a callback transaction (the chain where state changes happen).
 
-Origins and destinations don’t have to be the same. A single Reactive Contract can subscribe to events from multiple origin chains, and it can send callbacks to one or more destination chains. Your Solidity logic can also choose the destination conditionally.
+Origins and destinations don’t have to be the same. A single Reactive contract can subscribe to events from multiple origin chains, and it can send callbacks to one or more destination chains. Your Solidity logic can also choose the destination conditionally.
 
 ## Callback Proxy Address
 
@@ -27,7 +27,7 @@ Callbacks are delivered to destination chains via a **Callback Proxy** contract.
 A destination contract can validate a callback by checking:
 
 1. **The sender is the Callback Proxy** (so the call is coming through the expected entry point).
-2. **The embedded RVM ID matches the intended Reactive Contract** (so the callback is tied to the correct RC).
+2. **The embedded RVM ID matches the intended Reactive contract** (so the callback is tied to the correct RC).
 
 :::info[Hyperlane]
 Some networks can’t act as destination chains yet because the Callback Proxy contract hasn’t been deployed there. In that case, use [Hyperlane](./hyperlane) as the transport for cross-chain callbacks.

diff --git a/docs/docs/reactive-lib.mdx b/docs/docs/reactive-lib.mdx
@@ -260,7 +260,7 @@ struct LogRecord {
 }
 ```
 
-The `Callback` event is emitted when a Reactive Contract triggers a callback transaction.
+The `Callback` event is emitted when a Reactive contract triggers a callback transaction.
 
 ```solidity
 event Callback(

diff --git a/docs/docs/reactvm.md b/docs/docs/reactvm.md
@@ -10,23 +10,44 @@ hide_title: true
 
 ## Overview
 
-ReactVM is a private execution environment within Reactive Network where [Reactive Contracts](./reactive-contracts) process events and execute logic. Each Reactive Contract runs inside a dedicated ReactVM that activates when subscribed events occur. Event logs are delivered to the ReactVM, where the contract executes Solidity logic and determines whether callback transactions should be sent to destination chains. ReactVMs run independently and can execute in parallel, allowing Reactive Contracts to process events while maintaining deterministic execution within each ReactVM.
+ReactVM is a private execution environment within Reactive Network where [Reactive Contracts](./reactive-contracts) process events and execute logic. Each Reactive contract runs inside a dedicated ReactVM that activates when subscribed events occur. Event logs are delivered to the ReactVM, where the contract executes Solidity logic and determines whether callback transactions should be sent to destination chains. ReactVMs run independently and can execute in parallel, allowing Reactive contracts to process events while maintaining deterministic execution within each ReactVM.
 
 ## My ReactVM
 
-Each deployed Reactive Contract is assigned to a ReactVM derived from the deployer’s address. Contracts deployed from the same EOA share the same ReactVM and can interact through shared state. Although multiple Reactive Contracts can be deployed within one ReactVM, separating contracts across ReactVMs is generally recommended.
+Each deployed Reactive contract is assigned to a ReactVM derived from the deployer's address. Contracts deployed from the same EOA share the same ReactVM and can interact through shared state. Although multiple Reactive Contracts can be deployed within one ReactVM, separating contracts across ReactVMs is generally recommended.
 
 ### Calling subscribe()
 
 Calling `subscribe()` or `unsubscribe()` inside ReactVM has no effect. Subscriptions must be managed through the Reactive Network instance of the contract. ReactVM contracts should communicate through callback transactions instead of direct subscription calls.
 
+### Callback Identity
+
+When a Reactive contract constructs a callback payload, the first argument must be reserved for the RVM ID. Developers pass `address(0)` as a placeholder in this slot, and Reactive Network automatically overwrites the first 160 bits with the deployer's address before the callback reaches the destination chain. This means callbacks always carry an authenticated origin that can't be forged by the contract itself.
+
+The callback must include at least one argument, omitting the first slot entirely will cause the call to fail, since the system has no location to inject the RVM ID. Destination contracts can rely on this first argument to identify which ReactVM originated the callback.
+
+Example from [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/f1f85ab2a0a8f917b9b37a57c00be2ffc8ad5ad4/src/demos/uniswap-v2-stop-order/UniswapDemoStopOrderReactive.sol#L107):
+
+```solidity
+bytes memory payload = abi.encodeWithSignature(
+    "stop(address,address,address,bool,uint256,uint256)",
+    address(0), // Overwritten with the deployer's RVM ID
+    pair,
+    client,
+    token0,
+    coefficient,
+    threshold
+);
+emit Callback(chain_id, stop_order, CALLBACK_GAS_LIMIT, payload);
+```
+
 ## State
 
 Each ReactVM maintains its own state based on processed events. ReactVM blocks include references to origin-chain block numbers and hashes, allowing Reactive Network to track and handle chain reorganizations. ReactVM states operate independently, and the overall Reactive Network state is the combination of all ReactVM states.
 
 ### Dual-State Environment
 
-Each Reactive Contract exists in two environments with separate state:
+Each Reactive contract exists in two environments with separate state:
 
 - **ReactVM State** — updated automatically when subscribed events occur
 - **Reactive Network State** — updated when EOAs call contract functions

diff --git a/docs/docs/rnk-rpc-methods.md b/docs/docs/rnk-rpc-methods.md
@@ -832,9 +832,9 @@ Returns an array of filter objects. Each filter object contains the following fi
 - **chainId** (`uint32`): The chain ID on which the filter is active.
 - **contract** (`string`): The address of the contract the filter is listening to.
 - **topics** (`array[string | null]`): An array of up to 4 log topics (from `topic_0` to `topic_3`) used for event filtering. Unused topics are null.
-- **configs** (`array[object]`): An array of configuration objects for reactive contracts and their associated ReactVMs.
-- **contract** (`string`): The reactive contract address.
-- **rvmId** (`string`): The ReactVM ID where the reactive contract resides.
+- **configs** (`array[object]`): An array of configuration objects for Reactive contracts and their associated ReactVMs.
+- **contract** (`string`): The Reactive contract address.
+- **rvmId** (`string`): The ReactVM ID where the Reactive contract resides.
 - **active** (`bool`): Indicates whether the subscription/filter is active.
 
 ```json