diff --git a/docs/education/glossary.md b/archive/education/glossary.md similarity index 99% rename from docs/education/glossary.md rename to archive/education/glossary.md index 1c8bb52..7b01f14 100644 --- a/docs/education/glossary.md +++ b/archive/education/glossary.md @@ -4,6 +4,7 @@ sidebar_position: 4 description: A comprehensive blockchain and DeFi glossary for developers, traders, and builders joining Reactive Network. Learn essential Web3, EVM, cross-chain, and Reactive Contract concepts—from Airdrops and Finality to TPS, block time, and automated DeFi execution. slug: glossary hide_title: true +unlisted: true --- ![Glossary Image](img/glossary.jpg) diff --git a/docs/education/img/glossary.jpg b/archive/education/img/glossary.jpg similarity index 100% rename from docs/education/img/glossary.jpg rename to archive/education/img/glossary.jpg diff --git a/docs/education/img/reactive-education.jpg b/archive/education/img/reactive-education.jpg similarity index 100% rename from docs/education/img/reactive-education.jpg rename to archive/education/img/reactive-education.jpg diff --git a/docs/education/introduction/_category_.json b/archive/education/introduction/_category_.json similarity index 100% rename from docs/education/introduction/_category_.json rename to archive/education/introduction/_category_.json diff --git a/docs/education/introduction/img/basic-reactive-workflow-source.jpg b/archive/education/introduction/img/basic-reactive-workflow-source.jpg similarity index 100% rename from docs/education/introduction/img/basic-reactive-workflow-source.jpg rename to archive/education/introduction/img/basic-reactive-workflow-source.jpg diff --git a/docs/education/introduction/img/basic-reactive-workflow.jpg b/archive/education/introduction/img/basic-reactive-workflow.jpg similarity index 100% rename from docs/education/introduction/img/basic-reactive-workflow.jpg rename to archive/education/introduction/img/basic-reactive-workflow.jpg diff --git a/docs/education/introduction/index.md b/archive/education/introduction/index.md similarity index 96% rename from docs/education/introduction/index.md rename to archive/education/introduction/index.md index fb25e3e..7d370db 100644 --- a/docs/education/introduction/index.md +++ b/archive/education/introduction/index.md @@ -4,6 +4,7 @@ title: Introduction description: Educational course on Reactive Contracts covering events, callbacks, subscriptions, oracles, and ReactVM. Includes lectures, GitHub code examples, and video workshops for developers building on Reactive Network. slug: /education/introduction hide_title: true +unlisted: true --- ![Reactive Network Education Image](../img/reactive-education.jpg) @@ -16,9 +17,9 @@ This course walks you through how Reactive contracts work, step by step. You'll Start with the introduction for a closer look at what Reactive contracts can do and how they operate across EVM-compatible chains, then check the prerequisites to make sure you have the right background before moving on. -[Introduction to Reactive Contracts →](./reactive-contracts.md) +[Introduction to Reactive Contracts →](reactive-contracts.md) -[Prerequisites →](./prerequisites.md) +[Prerequisites →](prerequisites.md) ## Module One diff --git a/docs/education/introduction/prerequisites.md b/archive/education/introduction/prerequisites.md similarity index 99% rename from docs/education/introduction/prerequisites.md rename to archive/education/introduction/prerequisites.md index ad6a557..a7f8257 100644 --- a/docs/education/introduction/prerequisites.md +++ b/archive/education/introduction/prerequisites.md @@ -3,6 +3,7 @@ title: Technical and Knowledge Prerequisites for Mastering Reactive Contracts sidebar_position: 2 description: What you need to know before starting the Reactive Contracts course. Covers required background in Solidity, EVM, Git, and command line tools, plus wallet setup for Ethereum Sepolia testnet deployment. slug: prerequisites +unlisted: true --- # Technical and Knowledge Prerequisites for Mastering Reactive Contracts diff --git a/docs/education/introduction/reactive-contracts.md b/archive/education/introduction/reactive-contracts.md similarity index 97% rename from docs/education/introduction/reactive-contracts.md rename to archive/education/introduction/reactive-contracts.md index 7aef6b7..1616054 100644 --- a/docs/education/introduction/reactive-contracts.md +++ b/archive/education/introduction/reactive-contracts.md @@ -3,6 +3,7 @@ title: "What Are Reactive Contracts and Why Do They Matter" sidebar_position: 1 description: Reactive Contracts are smart contracts that autonomously monitor and respond to events across EVM-compatible blockchains. Explains what they are, how they differ from traditional smart contracts, and why cross-chain automation matters. slug: reactive-contracts +unlisted: true --- # What Are Reactive Contracts and Why Do They Matter @@ -13,7 +14,7 @@ Regular smart contracts sit idle until someone sends them a transaction. They ca Reactive contracts work differently. They monitor events across EVM-compatible chains and respond to them automatically, executing logic and triggering on-chain actions without anyone having to intervene. No manual transactions, no centralized bots, no private key management on your end. -![Basic Reactive Workflow](./img/basic-reactive-workflow.jpg) +![Basic Reactive Workflow](img/basic-reactive-workflow.jpg) ## Why This Matters diff --git a/docs/education/module-1/_category_.json b/archive/education/module-1/_category_.json similarity index 100% rename from docs/education/module-1/_category_.json rename to archive/education/module-1/_category_.json diff --git a/docs/education/module-1/how-events-work.md b/archive/education/module-1/how-events-work.md similarity index 99% rename from docs/education/module-1/how-events-work.md rename to archive/education/module-1/how-events-work.md index 60b9022..90dc218 100644 --- a/docs/education/module-1/how-events-work.md +++ b/archive/education/module-1/how-events-work.md @@ -3,6 +3,7 @@ title: "Lesson 2: How Events and Callbacks Work" sidebar_position: 2 description: Learn how EVM events and callbacks work in Reactive Contracts. Covers event creation and emission, the IReactive interface and react() method, and how callbacks trigger cross-chain transactions on destination chains. slug: how-events-work +unlisted: true --- # Lesson 2: How Events and Callbacks Work diff --git a/docs/education/module-1/how-oracles-work.md b/archive/education/module-1/how-oracles-work.md similarity index 99% rename from docs/education/module-1/how-oracles-work.md rename to archive/education/module-1/how-oracles-work.md index 4f6ed4d..b8fca82 100644 --- a/docs/education/module-1/how-oracles-work.md +++ b/archive/education/module-1/how-oracles-work.md @@ -3,6 +3,7 @@ title: "Lesson 5: How Oracles Work" sidebar_position: 5 description: How oracles bring off-chain data onto the blockchain and why they matter for Reactive Contracts. Covers the oracle problem, multisig security, Chainlink integration, and how Reactive Contracts can respond to oracle events in real time. slug: how-oracles-work +unlisted: true --- # Lesson 5: How Oracles Work diff --git a/docs/education/module-1/img/inversion-of-control.jpg b/archive/education/module-1/img/inversion-of-control.jpg similarity index 100% rename from docs/education/module-1/img/inversion-of-control.jpg rename to archive/education/module-1/img/inversion-of-control.jpg diff --git a/docs/education/module-1/img/reactvm.jpg b/archive/education/module-1/img/reactvm.jpg similarity index 100% rename from docs/education/module-1/img/reactvm.jpg rename to archive/education/module-1/img/reactvm.jpg diff --git a/docs/education/module-1/index.md b/archive/education/module-1/index.md similarity index 67% rename from docs/education/module-1/index.md rename to archive/education/module-1/index.md index 254c076..3be1087 100644 --- a/docs/education/module-1/index.md +++ b/archive/education/module-1/index.md @@ -1,9 +1,16 @@ ---- -title: "Module 1: Beginner — Foundations of Reactive Contracts" -sidebar_position: 1 -description: Introduction to Reactive Contracts covering how they respond to on-chain events, EVM event handling and callbacks, the ReactVM dual-state environment, subscriptions, and how oracles connect blockchain with off-chain data. -slug: /education/module-1 ---- +[//]: # (---) + +[//]: # (title: "Module 1: Beginner — Foundations of Reactive Contracts") + +[//]: # (sidebar_position: 1) + +[//]: # (description: Introduction to Reactive Contracts covering how they respond to on-chain events, EVM event handling and callbacks, the ReactVM dual-state environment, subscriptions, and how oracles connect blockchain with off-chain data.) + +[//]: # (slug: /education/module-1) + +[//]: # (unlisted: true) + +[//]: # (---) # Module 1: Beginner — Foundations of Reactive Contracts @@ -11,22 +18,22 @@ slug: /education/module-1 Module 1 covers the core concepts behind Reactive contracts: how they work, what makes them different from regular smart contracts, and the infrastructure that supports them. By the end of this module, you'll understand how Reactive contracts detect events, execute responses, and interact with off-chain data. -[Lesson 1: Reactive Contracts](./reactive-contracts.md) +[Lesson 1: Reactive Contracts](reactive-contracts.md) How Reactive contracts work in practice, focusing on their reactive nature. Walks through real use cases like data collection with oracles and executing stop orders on decentralized exchanges. -[Lesson 2: How Events and Callbacks Work](./how-events-work.md) +[Lesson 2: How Events and Callbacks Work](how-events-work.md) How EVM events and callbacks enable communication between smart contracts and external systems. Includes a practical example using Chainlink's price oracle integration. -[Lesson 3: ReactVM and Reactive Network As a Dual-State Environment](./react-vm.md) +[Lesson 3: ReactVM and Reactive Network As a Dual-State Environment](react-vm.md) Reactive Network runs on a dual-state environment: ReactVM for Reactive logic and Reactive Network (RNK) for on-chain execution. This lesson explains how state management and transactions work across both. -[Lesson 4: How Subscriptions Work](./subscriptions.md) +[Lesson 4: How Subscriptions Work](subscriptions.md) Subscriptions are how Reactive contracts listen for specific on-chain events. This lesson covers setting them up, managing them, and using them to automate contract execution. -[Lesson 5: How Oracles Work](./how-oracles-work.md) +[Lesson 5: How Oracles Work](how-oracles-work.md) Oracles bridge the gap between blockchain and real-world data. This lesson explains how they work, covers multisig protocols for securing oracle data, and walks through applications in DeFi, insurance, and prediction markets. \ No newline at end of file diff --git a/docs/education/module-1/react-vm.md b/archive/education/module-1/react-vm.md similarity index 99% rename from docs/education/module-1/react-vm.md rename to archive/education/module-1/react-vm.md index 1fe4e70..c123681 100644 --- a/docs/education/module-1/react-vm.md +++ b/archive/education/module-1/react-vm.md @@ -3,6 +3,7 @@ title: "Lesson 3: ReactVM and the Dual-State Environment" sidebar_position: 3 description: Learn how Reactive contracts operate across two separate states — one on Reactive Network and one in a private ReactVM instance. Covers execution context detection, managing dual variable sets, and how transactions flow in each environment. slug: react-vm +unlisted: true --- # Lesson 3: ReactVM and the Dual-State Environment @@ -24,7 +25,7 @@ By the end of this lesson, you'll understand: Every deployed Reactive contract has two instances: one on Reactive Network and one in a dedicated ReactVM. Both instances are physically stored and executed on each network node. This separation is an architectural decision made to ensure high performance even with large volumes of events. -![Reactive Network | ReactVM](./img/reactvm.jpg) +![Reactive Network | ReactVM](img/reactvm.jpg) **Reactive Network** operates as a standard EVM blockchain with additional system contracts that handle subscribing and unsubscribing to events on origin chains like Ethereum, BNB, Polygon, or Optimism. Each deployer address has its own dedicated ReactVM. diff --git a/docs/education/module-1/reactive-contracts.md b/archive/education/module-1/reactive-contracts.md similarity index 99% rename from docs/education/module-1/reactive-contracts.md rename to archive/education/module-1/reactive-contracts.md index 168e91f..32cde14 100644 --- a/docs/education/module-1/reactive-contracts.md +++ b/archive/education/module-1/reactive-contracts.md @@ -3,6 +3,7 @@ title: "Lesson 1: Reactive Contracts" sidebar_position: 1 description: Learn how Reactive Contracts differ from traditional smart contracts and practical use cases including oracle data aggregation, Uniswap stop orders, DEX arbitrage, and cross-chain pool rebalancing. slug: reactive-contracts +unlisted: true --- # Lesson 1: Reactive Contracts @@ -25,7 +26,7 @@ With traditional smart contracts, control flows from the outside in. An external Reactive contracts invert that. The contract itself defines which events it cares about and what to do when they happen. Execution is triggered by on-chain events, not by someone signing a transaction. -![Inversion of Control](./img/inversion-of-control.jpg) +![Inversion of Control](img/inversion-of-control.jpg) To see why this matters, consider the alternative. Without a Reactive contract, you'd need to set up a separate service (typically a bot) to monitor blockchains using centralized data providers. That bot holds private keys for the funds it manages and submits transactions from its own EOA address. It works, but it introduces a centralized point of control that can fail, be compromised, or go offline. diff --git a/docs/education/module-1/subscriptions.md b/archive/education/module-1/subscriptions.md similarity index 99% rename from docs/education/module-1/subscriptions.md rename to archive/education/module-1/subscriptions.md index ed3a6f6..1a2f45d 100644 --- a/docs/education/module-1/subscriptions.md +++ b/archive/education/module-1/subscriptions.md @@ -3,6 +3,7 @@ title: "Lesson 4: How Subscriptions Work" sidebar_position: 4 description: Learn how to set up and manage event subscriptions in Reactive Contracts. Covers static subscriptions in the constructor, subscription criteria and wildcards, prohibited patterns, and dynamic subscription management through callbacks. slug: how-subscriptions-work +unlisted: true --- # Lesson 4: How Subscriptions Work diff --git a/docs/education/module-2/_category_.json b/archive/education/module-2/_category_.json similarity index 100% rename from docs/education/module-2/_category_.json rename to archive/education/module-2/_category_.json diff --git a/docs/education/module-2/basic-reactive-functions.md b/archive/education/module-2/basic-reactive-functions.md similarity index 99% rename from docs/education/module-2/basic-reactive-functions.md rename to archive/education/module-2/basic-reactive-functions.md index c43f159..090f0fe 100644 --- a/docs/education/module-2/basic-reactive-functions.md +++ b/archive/education/module-2/basic-reactive-functions.md @@ -3,6 +3,7 @@ title: "Lesson 7: Basic Reactive Functions" sidebar_position: 2 description: Walkthrough of a Reactive Contract that implements a Uniswap V2 stop order. Covers the contract structure, event subscriptions, the react() function, threshold logic, and the full execution flow from initialization to trade completion. slug: basic-reactive-functions +unlisted: true --- # Lesson 7: Basic Reactive Functions diff --git a/docs/education/module-2/how-uniswap-works.md b/archive/education/module-2/how-uniswap-works.md similarity index 99% rename from docs/education/module-2/how-uniswap-works.md rename to archive/education/module-2/how-uniswap-works.md index 9891832..16f740f 100644 --- a/docs/education/module-2/how-uniswap-works.md +++ b/archive/education/module-2/how-uniswap-works.md @@ -3,6 +3,7 @@ title: "Lesson 6: How Uniswap V2 Works" sidebar_position: 1 description: Discover how Uniswap V2 pools and smart contracts work, including the constant product formula and key events like Swap and Sync. Learn about token swaps, liquidity provisioning, and see a smart contract example. slug: how-uniswap-works +unlisted: true --- # Lesson 6: How Uniswap V2 Works diff --git a/docs/education/module-2/index.md b/archive/education/module-2/index.md similarity index 65% rename from docs/education/module-2/index.md rename to archive/education/module-2/index.md index a78f73b..f808fe1 100644 --- a/docs/education/module-2/index.md +++ b/archive/education/module-2/index.md @@ -1,9 +1,16 @@ ---- -title: "Module 2: Intermediate - Building Blocks for Reactivity" -sidebar_position: 1 -description: Practical introduction to DeFi and Reactive Contracts. Covers how Uniswap V2 liquidity pools and smart contracts work, then shows how Reactive Contracts can autonomously execute trades based on real-time on-chain conditions. -slug: /education/module-2 ---- +[//]: # (---) + +[//]: # (title: "Module 2: Intermediate - Building Blocks for Reactivity") + +[//]: # (sidebar_position: 1) + +[//]: # (description: Practical introduction to DeFi and Reactive Contracts. Covers how Uniswap V2 liquidity pools and smart contracts work, then shows how Reactive Contracts can autonomously execute trades based on real-time on-chain conditions.) + +[//]: # (slug: /education/module-2) + +[//]: # (unlisted: true) + +[//]: # (---) # Module 2: Intermediate - Building Blocks for Reactivity @@ -13,10 +20,10 @@ Module 1 covered the core concepts: how Reactive contracts work, how they proces You'll start by learning how Uniswap V2 works under the hood: its liquidity pools, smart contracts, and trading mechanics. Then you'll see how a Reactive contract can plug into that system and autonomously execute trades when specific conditions are met. This is where the theory from Module 1 starts turning into practical applications. -[Lesson 6: How Uniswap V2 Works](./how-uniswap-works.md) +[Lesson 6: How Uniswap V2 Works](how-uniswap-works.md) How Uniswap V2's liquidity pools and smart contracts enable decentralized trading. Covers the constant product formula, how swaps work, and what events Uniswap emits, which is what a Reactive contract will subscribe to in the next lesson. -[Lesson 7: Basic Reactive Functions](./basic-reactive-functions.md) +[Lesson 7: Basic Reactive Functions](basic-reactive-functions.md) How Reactive contracts operate in a DeFi context. Walks through how a Reactive contract can monitor Uniswap events and autonomously execute trades when on-chain conditions match predefined criteria. \ No newline at end of file diff --git a/docs/education/use-cases/_category_.json b/archive/education/use-cases/_category_.json similarity index 100% rename from docs/education/use-cases/_category_.json rename to archive/education/use-cases/_category_.json diff --git a/docs/education/use-cases/img/1.png b/archive/education/use-cases/img/1.png similarity index 100% rename from docs/education/use-cases/img/1.png rename to archive/education/use-cases/img/1.png diff --git a/docs/education/use-cases/img/11.png b/archive/education/use-cases/img/11.png similarity index 100% rename from docs/education/use-cases/img/11.png rename to archive/education/use-cases/img/11.png diff --git a/docs/education/use-cases/img/2.png b/archive/education/use-cases/img/2.png similarity index 100% rename from docs/education/use-cases/img/2.png rename to archive/education/use-cases/img/2.png diff --git a/docs/education/use-cases/img/22.png b/archive/education/use-cases/img/22.png similarity index 100% rename from docs/education/use-cases/img/22.png rename to archive/education/use-cases/img/22.png diff --git a/docs/education/use-cases/img/3.png b/archive/education/use-cases/img/3.png similarity index 100% rename from docs/education/use-cases/img/3.png rename to archive/education/use-cases/img/3.png diff --git a/docs/education/use-cases/img/33.png b/archive/education/use-cases/img/33.png similarity index 100% rename from docs/education/use-cases/img/33.png rename to archive/education/use-cases/img/33.png diff --git a/docs/education/use-cases/img/magic-exchange.png b/archive/education/use-cases/img/magic-exchange.png similarity index 100% rename from docs/education/use-cases/img/magic-exchange.png rename to archive/education/use-cases/img/magic-exchange.png diff --git a/docs/education/use-cases/img/magic-swap.png b/archive/education/use-cases/img/magic-swap.png similarity index 100% rename from docs/education/use-cases/img/magic-swap.png rename to archive/education/use-cases/img/magic-swap.png diff --git a/docs/education/use-cases/img/uniswap-stop-order.jpg b/archive/education/use-cases/img/uniswap-stop-order.jpg similarity index 100% rename from docs/education/use-cases/img/uniswap-stop-order.jpg rename to archive/education/use-cases/img/uniswap-stop-order.jpg diff --git a/docs/education/use-cases/img/use-case-1.png b/archive/education/use-cases/img/use-case-1.png similarity index 100% rename from docs/education/use-cases/img/use-case-1.png rename to archive/education/use-cases/img/use-case-1.png diff --git a/archive/education/use-cases/index.md b/archive/education/use-cases/index.md new file mode 100644 index 0000000..e307e88 --- /dev/null +++ b/archive/education/use-cases/index.md @@ -0,0 +1,33 @@ +[//]: # (---) + +[//]: # (title: "Use Cases") + +[//]: # (sidebar_position: 1) + +[//]: # (description: Discover practical uses of Reactive Contracts with demos on low-latency log monitoring and Uniswap V2 stop orders. Deploy and test these examples to boost your expertise.) + +[//]: # (slug: /education/use-cases) + +[//]: # (unlisted: true) + +[//]: # (---) + +# Use Cases + +## Overview + +The Use Cases section primarily focuses on analyzing scenarios where Reactive Contracts might be a game changer. + +The [Basic Demo](use-case-1.md) is a basic use case of the Reactive Network enabling low-latency event monitoring, capturing logs from origin chain contracts, processing them, and triggering callbacks on the destination chain. + +The [Deploying Reactive Contracts with Remix](remix-ide-demo.mdx) article is a guide for deploying a Reactive Contract using the Remix Development Environment. + +The [Uniswap V2 Stop Order Demo](use-case-3.md) is a demo of a simple Reactive contract that implements a stop order upon a Uniswap V2 liquidity pool. Study its setup and try deploying and testing it yourself. + +The [Approval Magic Demo](use-case-2.md) extends reactive and subscription-based concepts to implement an approval-based token exchange across multiple chains. + +If you have an idea for another use case, feel free to submit and turn it into a bounty, using our [Unicornization](https://reactive.network/unicornization) program. + +## GitHub Repository + +Visit the [Reactive Contract Demos](https://github.com/Reactive-Network/reactive-smart-contract-demos) repository on GitHub to clone the project and start exploring! diff --git a/docs/education/use-cases/remix-ide-demo.mdx b/archive/education/use-cases/remix-ide-demo.mdx similarity index 97% rename from docs/education/use-cases/remix-ide-demo.mdx rename to archive/education/use-cases/remix-ide-demo.mdx index 46bf300..0d21e5b 100644 --- a/docs/education/use-cases/remix-ide-demo.mdx +++ b/archive/education/use-cases/remix-ide-demo.mdx @@ -3,11 +3,9 @@ title: "Deploying Reactive Contracts with Remix" sidebar_position: 2 description: Learn how to deploy a basic reactive contract using Remix IDE. Ideal for mastering Reactive Network fundamentals. slug: remix-ide-demo +unlisted: true --- -import LasnaButton from "../../../src/components/lasna-button"; -import DownloadButton from "../../../src/components/download-zip"; - # Deploying Reactive Contracts with Remix ## Overview @@ -24,7 +22,7 @@ Before getting started, ensure you have a basic understanding of the following: You'll also need three smart contracts, along with their abstract contracts and interfaces, to run the demo. All contracts should remain in the same folder. Download all the necessary files using the button below: - +[//]: # ()
@@ -40,7 +38,7 @@ The exchange rate is **1/100**, meaning you'll receive **100 REACT** for **1 Sep Do not send more than 5 SepETH per request, as doing so will cause you to lose the excess amount without receiving any additional REACT. The maximum that should be sent in a single transaction is 5 SepETH, which will yield 500 REACT. ::: - +[//]: # ()
diff --git a/docs/education/use-cases/use-case-1.md b/archive/education/use-cases/use-case-1.md similarity index 98% rename from docs/education/use-cases/use-case-1.md rename to archive/education/use-cases/use-case-1.md index 8602e0d..8e389b8 100644 --- a/docs/education/use-cases/use-case-1.md +++ b/archive/education/use-cases/use-case-1.md @@ -3,6 +3,7 @@ title: "Use Case: Reactive Network Demo" sidebar_position: 1 description: Learn to build and deploy a Basic Reactive Contract. Understand low-latency log monitoring and cross-chain calls using Ethereum testnets. Ideal for mastering Reactive Network fundamentals. slug: use-case-1 +unlisted: true --- # Use Case: Reactive Network Demo @@ -14,7 +15,7 @@ This article focuses on building and deploying a reactive contract, using the ba * Low-latency monitoring of logs emitted by contracts on the origin chain. * Executing calls from the Reactive Network to contracts on the destination chain. -![Basic Demo](./img/use-case-1.png) +![Basic Demo](img/use-case-1.png) ## Contracts diff --git a/docs/education/use-cases/use-case-2.md b/archive/education/use-cases/use-case-2.md similarity index 98% rename from docs/education/use-cases/use-case-2.md rename to archive/education/use-cases/use-case-2.md index aa2d075..083fef6 100644 --- a/docs/education/use-cases/use-case-2.md +++ b/archive/education/use-cases/use-case-2.md @@ -3,6 +3,7 @@ title: "Use Case: Approval Magic Demo" sidebar_position: 4 description: Explore how the reactive network automates token approvals and transfers across multiple chains. Learn about the ApprovalService, ApprovalListener, and client contracts like ApprovalEthExch and ApprovalMagicSwap, and how they optimize gas costs while ensuring secure, real-time token interactions. Gain practical insights into its setup, functionality, and deployment. slug: use-case-2 +unlisted: true --- # Use Case: Approval Magic Demo @@ -13,7 +14,7 @@ This article focuses on the [Approval Magic Demo](https://github.com/Reactive-Ne ## Magic Exchange Flow -![Exchange](./img/magic-exchange.png) +![Exchange](img/magic-exchange.png) 1. Validator calls `callback()` on `CallbackProxy`. 2. `CallbackProxy` calls `onApproval()` on `ApprovalService`. @@ -25,7 +26,7 @@ This article focuses on the [Approval Magic Demo](https://github.com/Reactive-Ne ## Magic Swap Flow -![Swap](./img/magic-swap.png) +![Swap](img/magic-swap.png) 1. Validator calls `callback()` on `CallbackProxy`. 2. `CallbackProxy` calls `onApproval()` on `ApprovalService`. diff --git a/docs/education/use-cases/use-case-3.md b/archive/education/use-cases/use-case-3.md similarity index 96% rename from docs/education/use-cases/use-case-3.md rename to archive/education/use-cases/use-case-3.md index ce619e8..7170416 100644 --- a/docs/education/use-cases/use-case-3.md +++ b/archive/education/use-cases/use-case-3.md @@ -3,15 +3,16 @@ title: "Use Case: Uniswap V2 Stop Order Demo" sidebar_position: 3 description: Discover how a Reactive Contract executes stop orders on Uniswap V2 pools, automating trade actions based on predefined conditions. Gain practical insights into its setup, functionality, and deployment. slug: use-case-3 +unlisted: true --- # Use Case: Uniswap V2 Stop Order Demo ## Overview -This article focuses on the [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) where a reactive contract listens for `Sync` events in a Uniswap V2 pool and triggers asset sales when the exchange rate hits a specified threshold. This demo extends the principles introduced in the [Reactive Network Demo](./use-case-1.md), which provides an introduction to building Reactive Contracts that respond to real-time events. +This article focuses on the [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) where a reactive contract listens for `Sync` events in a Uniswap V2 pool and triggers asset sales when the exchange rate hits a specified threshold. This demo extends the principles introduced in the [Reactive Network Demo](use-case-1.md), which provides an introduction to building Reactive Contracts that respond to real-time events. -![Uniswap V2 Stop Order](./img/uniswap-stop-order.jpg) +![Uniswap V2 Stop Order](img/uniswap-stop-order.jpg) ## Contracts diff --git a/docs/docs/debugging.md b/docs/docs/debugging.md index 08ae987..868e3b5 100644 --- a/docs/docs/debugging.md +++ b/docs/docs/debugging.md @@ -4,6 +4,7 @@ sidebar_position: 15 description: The page dedicated to debugging of most frequent errors and issues on Reactive Network. slug: /debugging hide_title: true +unlisted: true --- ![Debugging Image](./img/debugging.jpg) @@ -61,7 +62,7 @@ You can verify a contract’s balance anytime on Reactscan or via Foundry cast c cast balance $CONTRACT_ADDR --rpc-url $RPC_URL ``` -To check the outstanding debt, query the relevant proxy contract (`0x0000000000000000000000000000000000fffFfF` on Reactive): +To check the outstanding debt, query the relevant proxy contract (`0x8888888888888888888888888888888888888888` on Reactive): ```bash cast call $PROXY_ADDR "debts(address)" $CONTRACT_ADDR --rpc-url $RPC_URL | cast to-dec diff --git a/docs/docs/demos.md b/docs/docs/demos.md index 0efde66..dd393cc 100644 --- a/docs/docs/demos.md +++ b/docs/docs/demos.md @@ -4,9 +4,10 @@ sidebar_position: 12 description: Practical Reactive Network demos covering event subscriptions, log monitoring, dynamic callbacks, and real-world automation examples including Uniswap V2 stop orders. slug: /demos hide_title: true +unlisted: true --- -![Demos Image](./img/demos.jpg) +![Demos Image](./img/reactive-demos.jpg) ## Overview @@ -14,35 +15,35 @@ This section contains practical demos of how Reactive Network enables event-driv ## Reactive Network Basic Demo -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. +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. +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. +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. +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. +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. +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. +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. +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 @@ -50,4 +51,4 @@ The [Hyperlane Demo](https://github.com/Reactive-Network/reactive-smart-contract ## 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. \ No newline at end of file +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, a 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. \ No newline at end of file diff --git a/docs/docs/economy.md b/docs/docs/economy.md index 2dbd557..ca824fd 100644 --- a/docs/docs/economy.md +++ b/docs/docs/economy.md @@ -1,26 +1,21 @@ --- title: Economy sidebar_position: 6 -description: Learn how Reactive Contracts pay for execution and cross-chain callbacks, including REACT funding, transaction fees, and callback pricing. +description: Learn how reactive contracts pay for execution and cross-chain callbacks, including REACT funding, transaction fees, and callback pricing. slug: /economy hide_title: true +unlisted: true --- ![Economy](./img/economy.jpg) ## Overview -This section explains how Reactive Contracts pay for execution and cross-chain callbacks, including REACT funding, transaction fees, and callback pricing. RVM transactions and callbacks are executed first and accounted for later. Contracts must maintain sufficient balances to remain active. +This section explains how reactive contracts pay for execution and cross-chain callbacks, including REACT funding, transaction fees, and callback pricing. Contracts must maintain sufficient balances to remain active. -## RVM Transactions +## Reactive Transactions -RVM transactions do not include a gas price at execution time. Fees are calculated and charged later using the base fee of a subsequent block (typically the next block). Because accounting is aggregated at the block level, Reactscan can't associate fees with individual RVM transactions. - -:::info[Max Gas Limit] -The maximum gas limit for RVM transactions is 900,000 units. -::: - -The Reactive transaction fee is calculated as: +Reactive transaction fees are charged synchronously when the system contract executes the `react()` call. The fee is calculated as: $$ fee = BaseFee ⋅ GasUsed @@ -28,16 +23,16 @@ $$ Where: -- `BaseFee` — base fee per gas unit in the accounting block +- `BaseFee` — base fee per gas unit in the current block - `GasUsed` — gas consumed during execution -:::info[Reactive Network Transactions] -RNK transactions follow the standard EVM gas model. +:::info[Max Gas Limit] +The maximum gas limit for reactive transactions is 900,000 units. ::: ### Direct Transfers -Reactive Contracts must be funded in REACT before executing RVM transactions. +Reactive contracts must be funded in REACT before executing reactive transactions. Fund a contract: @@ -77,10 +72,6 @@ cast send \ --value 0.1ether ``` -:::info[System Contract] -On Reactive Network, the system contract and callback proxy share the same address: `0x0000000000000000000000000000000000fffFfF`. -::: - ## Callback Pricing Callback costs depend on the destination network and current base fees. The callback price $$p_{callback}$$ is calculated as: @@ -98,7 +89,7 @@ Where: ## Callback Payment -Callbacks use the same payment model as RVM transactions. Contracts without sufficient funds are blocklisted and can't execute transactions or callbacks. +Callbacks use the same payment model as reactive transactions. Contracts without sufficient funds are blocklisted and can't execute transactions or callbacks. :::warning[Callback Gas Limit] Reactive Network enforces a minimum callback gas limit of 100,000 gas. Callback requests below this threshold are ignored, as this minimum ensures sufficient gas for internal audits and computations required to process the callback. @@ -171,7 +162,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 index 2da90da..3b2f044 100644 --- a/docs/docs/events-and-callbacks.md +++ b/docs/docs/events-and-callbacks.md @@ -1,7 +1,7 @@ --- title: Events & Callbacks sidebar_position: 9 -description: Learn how Reactive Contracts process events and trigger cross-chain callback transactions. +description: Learn how reactive contracts process events and trigger cross-chain callback transactions. slug: /events-&-callbacks hide_title: true --- @@ -10,100 +10,69 @@ hide_title: true ## Overview -Reactive Contracts process on-chain events and trigger transactions on destination chains through callbacks. Contracts run inside isolated environments called [ReactVMs](./reactvm.md), where incoming events are processed and callback transactions are generated when conditions are met. +Reactive contracts process on-chain events and trigger transactions on destination chains through callbacks. The system contract delivers event logs to the contract's `react()` function, and callback transactions are generated when conditions are met. ## 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-omni/blob/main/src/interfaces/IReactive.sol) interface: ```solidity -// SPDX-License-Identifier: UNLICENSED - -pragma solidity >=0.8.0; - -import './IPayer.sol'; - -interface IReactive is IPayer { - struct LogRecord { - uint256 chain_id; - address _contract; - uint256 topic_0; - uint256 topic_1; - uint256 topic_2; - uint256 topic_3; - bytes data; - uint256 block_number; - uint256 op_code; - uint256 block_hash; - uint256 tx_hash; - uint256 log_index; - } - ... +struct LogRecord { + uint256 chainId; + address contractAddress; + uint256 topic0; + uint256 topic1; + uint256 topic2; + uint256 topic3; + bytes data; + uint256 blockNumber; + uint256 opCode; + uint256 blockHash; + uint256 txHash; + uint256 logIndex; } + +function react(LogRecord calldata log_) external; ``` -Reactive Network calls `react()` whenever a subscribed event is detected. The `LogRecord` structure contains the event metadata, including chain ID, contract address, topics, and event data. +The system contract calls `react()` whenever a subscribed event is detected. The `LogRecord` structure contains the event metadata, including chain ID, contract address, topics, and event data. + +Since `react()` is always called by the system contract, contracts should use the `onlySystem` modifier provided by `AbstractReactive` to restrict access. -Reactive Contracts execute inside a private ReactVM associated with the deployer's address. Contracts inside one ReactVM **can't** interact directly with contracts deployed by other users. +## Callbacks to Destination Chains -Below is an example `react()` function from the [Basic Reactive Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/basic/BasicDemoReactiveContract.sol): +Reactive contracts initiate transactions on destination chains by calling `requestCallback()` or `requestCallbackV_1_0()` on the system contract: ```solidity -function react(LogRecord calldata log) external vmOnly { - - if (log.topic_3 >= 0.001 ether) { - bytes memory payload = abi.encodeWithSignature("callback(address)", address(0)); - emit Callback(destinationChainId, callback, GAS_LIMIT, payload); - } -} -``` +function requestCallback(CallbackVersion version_, bytes memory config_) external; -[More on Events →](../education/module-1/how-events-work) +function requestCallbackV_1_0(CallbackConfiguration_V_1_0 memory config_) external; +``` -## Callbacks to Destination Chains +When either method is called during `react()` execution, Reactive Network submits a transaction to the specified destination chain. -Reactive Contracts initiate transactions on destination chains by emitting `Callback` events, which are also part of the [IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) interface: +The `V_1_0` callback configuration uses the following struct: ```solidity -event Callback( - uint256 indexed chain_id, - address indexed _contract, - uint64 indexed gas_limit, - bytes payload -); +struct CallbackConfiguration_V_1_0 { + uint256 chainId; + address recipient; + uint64 gasLimit; + bytes payload; +} ``` -When this event appears in the transaction trace, Reactive Network submits a transaction to the specified destination chain. +Where: -- **chain_id** — destination network -- **_contract** — target contract -- **gas_limit** — execution gas limit -- **payload** — encoded function call +* `chainId` -- destination network +* `recipient` -- target contract on the destination chain +* `gasLimit` -- execution gas limit +* `payload` -- ABI-encoded function call + +The `requestCallbackV_1_0()` method is a typed convenience wrapper that avoids manual ABI encoding. Both methods produce the same result. :::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 replaces the first 160 bits of the callback payload with the address of the reactive contract that initiated the callback. The first callback argument is therefore always an `address`, regardless of how it is named in Solidity. On the destination side, contracts extending `AbstractCallback` can use the `onlyCallbackSender` modifier to verify this address matches the expected reactive contract. ::: -### Example: Uniswap Stop Order Demo - -Example callback payload construction from the [Uniswap Stop Order Reactive Contract](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/uniswap-v2-stop-order/UniswapDemoStopOrderReactive.sol): - -```solidity -bytes memory payload = abi.encodeWithSignature( - "stop(address,address,address,bool,uint256,uint256)", - address(0), - pair, - client, - token0, - coefficient, - threshold -); -triggered = true; -emit Callback(log.chain_id, stop_order, CALLBACK_GAS_LIMIT, payload); -``` - -The payload encodes the function call and parameters that will be executed on the destination chain. - -[More on Callback Payment →](./economy#callback-payment) - -[More on Callbacks →](../education/module-1/how-events-work#callbacks-to-destination-chains) \ No newline at end of file +[More on callback payment →](./economy#callback-payment) diff --git a/docs/docs/hyperlane.mdx b/docs/docs/hyperlane.mdx index 61557a4..bcbeb2d 100644 --- a/docs/docs/hyperlane.mdx +++ b/docs/docs/hyperlane.mdx @@ -1,7 +1,7 @@ --- title: Hyperlane sidebar_position: 3 -description: Learn how to use Hyperlane Mailboxes as an alternative transport for cross-chain callbacks in Reactive Contracts. +description: Learn how to use Hyperlane Mailboxes as alternative transport for cross-chain callbacks in Reactive Contracts. slug: /hyperlane hide_title: true --- @@ -12,13 +12,9 @@ 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 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 callback proxies. 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 -- You need additional routing flexibility -- You want to integrate Reactive Contracts with existing Hyperlane-based systems +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 specific chain doesn't yet have its callback proxy deployed. ## Hyperlane Mailboxes diff --git a/docs/docs/index.md b/docs/docs/index.md index 9ee1a97..9e19736 100644 --- a/docs/docs/index.md +++ b/docs/docs/index.md @@ -1,7 +1,7 @@ --- sidebar_position: 1 title: Getting Started -description: Explore Reactive Network — an automation layer for EVM chains. Build Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation. +description: Explore Reactive Network, an EVM automation layer with CometBFT consensus and instant finality. Build reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. slug: / hide_title: true --- @@ -10,55 +10,51 @@ hide_title: true ## Overview -Reactive Network is an EVM-compatible chain built around Reactive Contracts (RCs) — event-driven smart contracts for cross-chain, on-chain automation. +Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. It runs on CometBFT consensus, providing instant finality and roughly 1-second block times while maintaining full EVM compatibility. -Reactive Contracts monitor event logs across EVM chains and execute Solidity logic automatically when conditions are met. Instead of waiting for users or bots to trigger transactions, RCs run continuously and decide when to send cross-chain callback transactions, essentially providing on-chain if-this-then-that automation for smart contracts. +Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur. Instead of relying on users or off-chain bots to trigger transactions, they decide autonomously when to send cross-chain callback transactions, providing on-chain if-this-then-that automation for smart contracts. -This makes it possible to build conditional cross-chain workflows such as: - -* Automated stop-loss and take-profit orders -* Liquidation protection -* Automated portfolio rebalancing -* Yield optimization -* Cross-chain workflows +This makes it possible to build workflows such as automated stop-loss and take-profit orders, liquidation protection, portfolio rebalancing, and yield optimization across chains. ## Step 1 — Reactive Basics -[Origins & Destinations →](./origins-and-destinations.mdx) Understand origin and destination chains and their Callback Proxy addresses. +[//]: # ([Origins & Destinations →](./origins-and-destinations.mdx) Understand origin and destination chains and their callback proxy addresses.) [Hyperlane →](./hyperlane.mdx) Learn how cross-chain callbacks are transported using Hyperlane. -[Reactive Contracts →](./reactive-contracts.md) Learn how Reactive Contracts subscribe to events and trigger actions. - -[ReactVM →](./reactvm.md) Understand ReactVM and how Reactive execution works. +[Reactive Contracts →](./reactive-contracts.md) Learn how reactive contracts subscribe to events and trigger actions. -[Economy →](./economy) Understand callback payments and Reactive's economy. +[//]: # ([Economy →](./economy) Understand callback payments and Reactive's economy.) ## Step 2 — Reactive Essentials [Reactive Mainnet & Lasna Testnet →](./reactive-mainnet.mdx) Connect to Reactive Mainnet or Lasna Testnet. -[Reactive Library →](./reactive-lib.mdx) Use Reactive abstract contracts and interfaces. +[Reactive Library →](./reactive-lib.mdx) Use Reactive's abstract contracts and interfaces. [Events & Callbacks →](./events-and-callbacks.md) Learn how event subscriptions trigger cross-chain callbacks. [Subscriptions →](./subscriptions.md) Configure event subscriptions. -[RNK RPC Methods →](./rnk-rpc-methods.md) Reference RPC methods for Reactive nodes. - -## Step 3 — Reactive Building +[RNK RPC Methods →](./rnk-rpc-methods.md) Reference RPC methods for Reactive's nodes. -[Reactive Demos →](./demos.md) Explore working examples. +[//]: # (## Step 3 — Reactive Building) -[Reactive Demos on GitHub →](https://github.com/Reactive-Network/reactive-smart-contract-demos) Clone demo projects and start building. +[//]: # () +[//]: # ([Reactive Demos →](./demos.md) Explore working examples. ) -## Extra +[//]: # () +[//]: # ([Reactive Demos on GitHub →](https://github.com/Reactive-Network/reactive-smart-contract-demos) Clone demo projects and start building.) -[Reactscan →](./reactscan.md) Explore Reactive transactions and contracts. +[//]: # () +[//]: # (## Extra) -[Reactive Education →](../education/introduction/index.md) Take the Reactive technical course. +[//]: # () +[//]: # ([Reactscan →](./reactscan.md) Explore reactive transactions and contracts.) -[Debugging →](debugging.md) Troubleshoot common issues. +[//]: # () +[//]: # ([Debugging →](./debugging.md) Troubleshoot common issues.) -[Contacts →](../contacts/index.md) Get support and connect with the community. +[//]: # () +[//]: # ([Contacts →](../contacts/index.md) Get support and connect with the community.) diff --git a/docs/docs/origins-and-destinations.mdx b/docs/docs/origins-and-destinations.mdx index de5445c..4ceee4a 100644 --- a/docs/docs/origins-and-destinations.mdx +++ b/docs/docs/origins-and-destinations.mdx @@ -1,9 +1,10 @@ --- title: Origins & Destinations sidebar_position: 2 -description: Learn how Reactive Contracts subscribe to event logs on origin chains and send callback transactions to destination chains. +description: Learn how reactive contracts subscribe to event logs on origin chains and send callback transactions to destination chains. slug: /origins-and-destinations hide_title: true +unlisted: true --- import MainnetChainTable from "../../src/components/origins-destinations"; @@ -13,25 +14,18 @@ import TestnetChainTable from "../../src/components/origins-destinations-testnet ## Overview -Reactive Contracts (RCs) can **listen to event logs on one chain** and **trigger actions on another**. To describe that flow, we use two roles: +Reactive contracts can listen to event logs on one chain and trigger actions on another. To describe that flow, we use two roles: -- **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). +- **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 occur). -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 -Callbacks are delivered to destination chains via a **Callback Proxy** contract. Its job is to make callback transactions verifiable and safe for destination-side contracts. +Callbacks are delivered by Reactive Signer, which posts transactions to destination chains. These transactions pass through a callback proxy contract, which makes them verifiable and safe for destination-side contracts. -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). - -:::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. -::: +A destination contract can validate a callback by checking that `msg.sender` is the relevant callback proxy and the original sender from Reactive Network is Reactive Signer. ## Mainnet Chains diff --git a/docs/docs/reactive-contracts.md b/docs/docs/reactive-contracts.md index b054090..c9e7dc9 100644 --- a/docs/docs/reactive-contracts.md +++ b/docs/docs/reactive-contracts.md @@ -1,36 +1,20 @@ --- title: Reactive Contracts sidebar_position: 4 -description: Learn about Reactive Contracts (RCs) — event-driven smart contracts for cross-chain, on-chain automation that monitor event logs and trigger callback transactions. +description: Learn about reactive contracts, event-driven smart contracts for cross-chain, on-chain automation that subscribe to event logs and trigger callback transactions. slug: /reactive-contracts hide_title: true --- -![Reactive Contracts Image](./img/reactive-contracts.jpg) +![Reactive Contracts Image](img/reactive-contracts.jpg) ## Overview -Reactive Contracts (RCs) are event-driven smart contracts for cross-chain, on-chain automation. They monitor event logs across EVM chains, execute Solidity logic when subscribed events occur, and can trigger cross-chain callback transactions. - -RCs define which chains, contracts, and events to monitor and operate autonomously based on on-chain events rather than user transactions or bots. +Reactive contracts are event-driven smart contracts for cross-chain, on-chain automation. They subscribe to event logs across EVM chains, execute Solidity logic when matching events occur, and trigger cross-chain callback transactions. ## Deployment -Reactive Contracts deploy in two environments: - -- **Reactive Network (RNK)** — the public chain where EOAs interact with the contract and subscriptions are managed - -- **ReactVM (RVM)** — a private execution environment where event processing takes place - -Both copies use identical bytecode but operate independently. - -## State Separation - -The two deployments do not share state. Constructor flags or runtime checks can be used to distinguish environments. A contract can detect execution inside ReactVM by calling the system contract — calls revert outside ReactVM. See our [demos](./demos.md) for details. - -## ReactVM Limitations - -Inside [ReactVM](./reactvm.md), Reactive Contracts can't access external systems directly. They receive event logs from Reactive Network and can send callback transactions to destination chains, but can't interact with external RPC endpoints or off-chain services. +Reactive contracts are deployed to Reactive Network like any standard smart contract. Once deployed, the system contract delivers event logs to the contract's `react()` function and processes callback requests. ## Verifying Reactive Contracts @@ -94,32 +78,3 @@ If you encounter the error below, your Foundry version doesn't expect the `--bro error: unexpected argument '--broadcast' found ``` ::: - -## Verified Contracts on Reactscan - -After verification: - -1. Open Reactscan ([Reactive Mainnet](https://reactscan.net/), [Lasna Testnet](https://lasna.reactscan.net/)) -2. Navigate to your RVM -3. Open Contracts - - -![Image a](./img/verify-a.png) - -4. Select the contract address - -![Image b](./img/verify-b.png) - -Successful verification shows: - -```json -Contract Address: 0xc3e185561D2a8b04F0Fcd104A562f460D6cC503c -Status: VERIFIED (EXACT MATCH) -Compiler: 0.8.28 -``` - -![Image c](./img/verify-c.png) - -Verified contracts expose full source code with syntax highlighting and file structure. - -[More on Reactive Contracts →](../education/module-1/reactive-contracts) diff --git a/docs/docs/reactive-lib.mdx b/docs/docs/reactive-lib.mdx index bc58295..e84bb65 100644 --- a/docs/docs/reactive-lib.mdx +++ b/docs/docs/reactive-lib.mdx @@ -1,7 +1,7 @@ --- title: Reactive Library sidebar_position: 8 -description: Reference for the Reactive Library — abstract contracts and interfaces for building Reactive Contracts. +description: Reference for Reactive library, abstract contracts and interfaces for building reactive contracts. slug: /reactive-library hide_title: true --- @@ -12,161 +12,102 @@ import CronTable from "../../src/components/cron-table"; ## Overview -[Reactive Library](https://github.com/Reactive-Network/reactive-lib) provides abstract contracts and interfaces for building Reactive Contracts. The library includes components for subscriptions, callbacks, payments, and system contract interaction. +[Reactive library](https://github.com/Reactive-Network/reactive-lib-omni) provides abstract contracts and interfaces for building reactive contracts. The library includes components for subscriptions, callbacks, payments, and system contract interaction. Install the library in your Foundry project: ```bash -forge install Reactive-Network/reactive-lib +forge install Reactive-Network/reactive-lib-omni ``` ## Abstract Contracts ### AbstractCallback -[AbstractCallback](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractCallback.sol) extends `AbstractPayer.sol` and provides callback authorization for Reactive Contracts. +[AbstractCallback](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/abstract-base/AbstractCallback.sol) provides callback authorization for destination-side contracts. The contract initializes `_CALLBACK_SENDER`, which is the reactive contract authorized to send callbacks. -The contract initializes: - -- `rvm_id` — authorized ReactVM identifier -- `vendor` — callback proxy address - -The `rvmIdOnly` modifier restricts functions to the authorized ReactVM. +The `onlyCallbackSender` modifier restricts callback functions to the authorized sender. ```solidity -modifier rvmIdOnly(address _rvm_id) { - require(rvm_id == address(0) || rvm_id == _rvm_id, 'Authorized RVM ID only'); +modifier onlyCallbackSender(address callbackSender_) { + _onlyCallbackSender(callbackSender_); _; } ``` -The constructor sets the deploying ReactVM as the authorized `rvm_id` and registers the callback proxy as an authorized payment sender. +The implementation reverts with `CallbackNotAuthorized` if the sender doesn't match. ```solidity -constructor(address _callback_sender) { - rvm_id = msg.sender; - vendor = IPayable(payable(_callback_sender)); - addAuthorizedSender(_callback_sender); +function _onlyCallbackSender(address callbackSender_) internal view { + if (callbackSender_ != _CALLBACK_SENDER) { + revert CallbackNotAuthorized(callbackSender_, _CALLBACK_SENDER); + } } ``` -### AbstractPausableReactive +The constructor takes the callback proxy address (as the service provider for payments) and the authorized reactive contract address. -[AbstractPausableReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractPausableReactive.sol) extends `AbstractReactive.sol` and provides pausable event subscriptions. - -Subscriptions are defined using the `Subscription` struct, which specifies chain ID, contract address, and event topics. - -The contract provides: +```solidity +constructor(IPayable callbackProxy_, address callbackSender_) AbstractPayer(callbackProxy_) { + _CALLBACK_SENDER = callbackSender_; +} +``` -- `pause()` — unsubscribes all pausable subscriptions -- `resume()` — restores subscriptions +### AbstractPayer -Access is restricted to the contract owner. +[AbstractPayer](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/abstract-base/AbstractPayer.sol) provides payment and debt-settlement functionality for reactive contracts. The contract defines: `_SERVICE_PROVIDER`, which is the system contract or callback proxy authorized to request payments. -The constructor sets the deployer as the owner. +The `onlyServiceProvider` modifier restricts payment requests to the authorized provider. ```solidity -constructor() { - owner = msg.sender; +modifier onlyServiceProvider() { + _onlyServiceProvider(); + _; } -``` -The `pause()` function unsubscribes all subscriptions returned by `getPausableSubscriptions()`: - -```solidity -function pause() external rnOnly onlyOwner { - require(!paused, 'Already paused'); - Subscription[] memory subscriptions = getPausableSubscriptions(); - for (uint256 ix = 0; ix != subscriptions.length; ++ix) { - service.unsubscribe( - subscriptions[ix].chain_id, - subscriptions[ix]._contract, - subscriptions[ix].topic_0, - subscriptions[ix].topic_1, - subscriptions[ix].topic_2, - subscriptions[ix].topic_3 - ); +function _onlyServiceProvider() internal view { + if (msg.sender != address(_SERVICE_PROVIDER)) { + revert NotAuthorized(msg.sender, address(_SERVICE_PROVIDER)); } - paused = true; } ``` -The `resume()` function restores the same subscriptions: +The `pay()` function handles payment requests from the service provider. ```solidity -function resume() external rnOnly onlyOwner { - require(paused, 'Not paused'); - Subscription[] memory subscriptions = getPausableSubscriptions(); - for (uint256 ix = 0; ix != subscriptions.length; ++ix) { - service.subscribe( - subscriptions[ix].chain_id, - subscriptions[ix]._contract, - subscriptions[ix].topic_0, - subscriptions[ix].topic_1, - subscriptions[ix].topic_2, - subscriptions[ix].topic_3 - ); - } - paused = false; +function pay(uint256 amount_) external onlyServiceProvider { + _pay(payable(msg.sender), amount_); } ``` -### AbstractPayer - -[AbstractPayer](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractPayer.sol) provides payment and debt-settlement functionality for Reactive Contracts. - -Features include: - -- Authorized payment senders -- Vendor debt settlement -- Direct contract funding - -The `authorizedSenderOnly` modifier restricts payment initiation to authorized senders. +The `_coverDebt()` function settles any outstanding debt with the service provider. ```solidity -modifier authorizedSenderOnly() { - require(senders[msg.sender], 'Authorized sender only'); - _; +function _coverDebt() internal { + uint256 amount = _SERVICE_PROVIDER.debt(address(this)); + _pay(payable(_SERVICE_PROVIDER), amount); } ``` -The contract provides: - -- `pay()` — transfers funds to the authorized sender -- `coverDebt()` — settles outstanding vendor debt +The internal `_pay()` function handles the actual transfer with proper error handling. ```solidity -function pay(uint256 amount) external authorizedSenderOnly { - _pay(payable(msg.sender), amount); -} - -function coverDebt() external { - uint256 amount = vendor.debt(address(this)); - _pay(payable(vendor), amount); -} - -function _pay(address payable recipient, uint256 amount) internal { - require(address(this).balance >= amount, 'Insufficient funds'); - if (amount > 0) { - (bool success,) = payable(recipient).call{value: amount}(new bytes(0)); - require(success, 'Transfer failed'); +function _pay(address payable recipient_, uint256 amount_) internal { + if (address(this).balance < amount_) { + revert InsufficientFunds(amount_, address(this).balance); } -} -``` -Authorized senders are managed with: + if (amount_ > 0) { + (bool success,) = payable(recipient_).call{ value: amount_ }(new bytes(0)); -```solidity -function addAuthorizedSender(address sender) internal { - senders[sender] = true; -} - -function removeAuthorizedSender(address sender) internal { - senders[sender] = false; + if (!success) { + revert TransferFailed(); + } + } } ``` -The contract accepts direct transfers: +The contract accepts direct transfers for funding. ```solidity receive() virtual external payable { @@ -175,33 +116,26 @@ receive() virtual external payable { ### AbstractReactive -[AbstractReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractReactive.sol) is the base contract for Reactive Contracts. It extends `AbstractPayer.sol` and implements `IReactive.sol`, providing access to the Reactive Network system contract and subscription service. +[AbstractReactive](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/abstract-base/AbstractReactive.sol) is the base contract for reactive contracts. It provides access to the Reactive's system contract and subscription service. -The contract defines two execution modes: +The contract defines: -- `vmOnly` — ReactVM execution -- `rnOnly` — Reactive Network execution +- `SYSTEM`: the system contract address (`0x8888888888888888888888888888888888888888`) +- `REACTIVE_IGNORE`: wildcard topic value for event subscriptions -These modes ensure functions run in the appropriate environment. - -The constructor initializes the system contract as both the payment vendor and subscription service, and authorizes it for payment operations. +The `onlySystem` modifier restricts functions like `react()` to calls from the system contract. ```solidity -constructor() { - vendor = service = SERVICE_ADDR; - addAuthorizedSender(address(SERVICE_ADDR)); - detectVm(); +modifier onlySystem() { + _onlyServiceProvider(); + _; } ``` -Execution mode is determined automatically using `detectVm()`, which checks whether the system contract is deployed. +The constructor initializes the system contract as the service provider for payment operations. ```solidity -function detectVm() internal { - uint256 size; - // solhint-disable-next-line no-inline-assembly - assembly { size := extcodesize(0x0000000000000000000000000000000000fffFfF) } - vm = size == 0; +constructor() AbstractPayer(SYSTEM) { } ``` @@ -209,29 +143,23 @@ function detectVm() internal { ### IPayable -[IPayable](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IPayable.sol) defines payment and debt-query functionality for Reactive Contracts. - -- `receive()` — accepts direct payments -- `debt()` — returns the outstanding debt of a contract +[IPayable](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/interfaces/IPayable.sol) defines payment and debt-query functionality for reactive contracts. It is the common interface for both the system contract and the callback proxy. ```solidity interface IPayable { receive() external payable; - function debt(address _contract) external view returns (uint256); + function debt(address contract_) external view returns (uint256 debt_); } ``` ### IPayer -[IPayer](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IPayer.sol) defines a minimal interface for initiating payments and receiving funds. - -- `pay()` — initiates a payment -- `receive()` — accepts direct transfers +[IPayer](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/interfaces/IPayer.sol) defines the interface for contracts that need to pay for system contract or proxy services. ```solidity interface IPayer { - function pay(uint256 amount) external; + function pay(uint256 amount_) external; receive() external payable; } @@ -239,58 +167,59 @@ interface IPayer { ### IReactive -[IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) defines the core interface for Reactive Contracts. It extends `IPayer.sol` and provides event notifications and the execution entry point. +[IReactive](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/interfaces/IReactive.sol) defines the main interface for reactive contracts. It provides event notifications and the execution entry point. The `LogRecord` struct contains event data delivered to the contract. ```solidity struct LogRecord { - uint256 chain_id; - address _contract; - uint256 topic_0; - uint256 topic_1; - uint256 topic_2; - uint256 topic_3; - bytes data; - uint256 block_number; - uint256 op_code; - uint256 block_hash; - uint256 tx_hash; - uint256 log_index; + uint256 chainId; + address contractAddress; + uint256 topic0; + uint256 topic1; + uint256 topic2; + uint256 topic3; + bytes data; + uint256 blockNumber; + uint256 opCode; + uint256 blockHash; + uint256 txHash; + uint256 logIndex; } ``` -The `Callback` event is emitted when a Reactive contract triggers a callback transaction. +The `Callback` event is deprecated. New contracts should use the system contract's `requestCallback()` or `requestCallbackV_1_0()` methods instead. ```solidity +/// @dev Deprecated. Use the system contract's requestCallback() and requestCallback_V_*_*() methods. event Callback( - uint256 indexed chain_id, - address indexed _contract, - uint64 indexed gas_limit, - bytes payload + uint256 indexed chainId_, + address indexed contract_, + uint64 indexed gasLimit_, + bytes payload_ ); ``` -The `react()` function processes event notifications. +The `react()` function processes event notifications. It is called by the system contract. ```solidity -function react(LogRecord calldata log) external; +function react(LogRecord calldata log_) external; ``` ### ISubscriptionService -[ISubscriptionService](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/ISubscriptionService.sol) defines functions for managing event subscriptions. It extends `IPayable.sol` and allows Reactive Contracts to subscribe to or unsubscribe from event logs. +[ISubscriptionService](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/interfaces/ISubscriptionService.sol) defines functions for managing event subscriptions. Reactive contracts use it to subscribe to or unsubscribe from event logs. The `subscribe()` function registers a subscription with the specified event criteria. ```solidity function subscribe( - uint256 chain_id, - address _contract, - uint256 topic_0, - uint256 topic_1, - uint256 topic_2, - uint256 topic_3 + uint256 chainId_, + address contract_, + uint256 topic0_, + uint256 topic1_, + uint256 topic2_, + uint256 topic3_ ) external; ``` @@ -298,59 +227,46 @@ The `unsubscribe()` function removes a subscription matching the specified crite ```solidity function unsubscribe( - uint256 chain_id, - address _contract, - uint256 topic_0, - uint256 topic_1, - uint256 topic_2, - uint256 topic_3 + uint256 chainId_, + address contract_, + uint256 topic0_, + uint256 topic1_, + uint256 topic2_, + uint256 topic3_ ) external; ``` ### ISystemContract -[ISystemContract](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/ISystemContract.sol) combines the functionality of `IPayable.sol` and `ISubscriptionService.sol`. It represents the Reactive Network system contract interface used for payments and subscription management. +[ISystemContract](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/interfaces/ISystemContract.sol) combines the functionality of `IPayable` and `ISubscriptionService`, and provides callback request methods. It represents the Reactive's system contract interface. + +The `CallbackVersion` enum and `CallbackConfiguration_V_1_0` struct define the callback configuration format. ```solidity -import './IPayable.sol'; -import './ISubscriptionService.sol'; +enum CallbackVersion { V_1_0 } -interface ISystemContract is IPayable, ISubscriptionService { +struct CallbackConfiguration_V_1_0 { + uint256 chainId; + address recipient; + uint64 gasLimit; + bytes payload; } ``` -## System Contract - -Reactive Network operations are handled by three core contracts: - -[System Contract](https://github.com/Reactive-Network/system-smart-contracts/blob/main/src/SystemContract.sol): - -- Handles payments for Reactive Contracts -- Manages contract access control (whitelist/blacklist) -- Emits cron events for periodic triggers +The `requestCallback()` method accepts a version and ABI-encoded configuration. The `requestCallbackV_1_0()` method provides a typed convenience wrapper for V1.0 callbacks. -[Callback Proxy](https://github.com/Reactive-Network/system-smart-contracts/blob/main/src/CallbackProxy.sol): - -- Delivers callback transactions to destination contracts -- Manages deposits, reserves, and debts -- Restricts callbacks to authorized Reactive Contracts -- Calculates callback gas costs and kickbacks - -[AbstractSubscriptionService](https://github.com/Reactive-Network/system-smart-contracts/blob/main/src/AbstractSubscriptionService.sol): +```solidity +function requestCallback(CallbackVersion version_, bytes memory config_) external; -- Manages event subscriptions -- Supports filtering by chain, contract, and topics -- Supports wildcard matching via `REACTIVE_IGNORE` -- Emits subscription update events +function requestCallbackV_1_0(CallbackConfiguration_V_1_0 memory config_) external; +``` ### CRON Functionality -The `SystemContract` provides a cron mechanism for time-based automation by emitting events at fixed block intervals. Reactive Contracts can subscribe to these events to implement scheduled execution without polling or external automation. +The legacy system contract `0x0000000000000000000000000000000000fffFfF` provides a cron mechanism for time-based automation by emitting events at fixed block intervals. reactive contracts can subscribe to these events to implement scheduled execution without polling or external automation. Only authorized validator root addresses can call `cron()`. Each call to `cron()` emits one or more `Cron` events depending on the divisibility of the current block number. Larger intervals produce less frequent events. -Each `Cron` event contains a single parameter: - -- `number` — the current block number +Each `Cron` event contains a single parameter `number`, which is the current block number. diff --git a/docs/docs/reactive-mainnet.mdx b/docs/docs/reactive-mainnet.mdx index 0e5972a..c21d5a1 100644 --- a/docs/docs/reactive-mainnet.mdx +++ b/docs/docs/reactive-mainnet.mdx @@ -6,39 +6,52 @@ slug: /reactive-mainnet hide_title: true --- -import MainnetButton from "../../src/components/mainnet-button"; +[//]: # (import MainnetButton from "../../src/components/mainnet-button";) + import LasnaButton from "../../src/components/lasna-button"; ![Mainnet Testnet Image](./img/mainnet-testnet.jpg) ## Overview -Reactive Mainnet is the production network for Reactive Contracts. Lasna Testnet provides a testing environment for development and experimentation before mainnet deployment. +Reactive Mainnet is the production network for reactive contracts. Lasna Testnet provides a testing environment for development and experimentation before mainnet deployment. -:::info[System Contract] -Reactive Mainnet and Lasna Testnet share the same system contract address: -`0x0000000000000000000000000000000000fffFfF` -::: +[//]: # (:::info[System Contract]) -## Reactive Mainnet +[//]: # (Reactive Mainnet and Lasna Testnet share the same system contract address:) -Network parameters: +[//]: # (`0x8888888888888888888888888888888888888888`) + +[//]: # (:::) + +[//]: # () +[//]: # (## Reactive Mainnet) + +[//]: # () +[//]: # (Network parameters:) + +[//]: # () +[//]: # (* **Network Name:** Reactive Mainnet) -* **Network Name:** Reactive Mainnet -* **RPC URL:** https://mainnet-rpc.rnk.dev/ -* **Chain ID:** 1597 -* **Currency Symbol:** REACT -* **Block Explorer:** https://reactscan.net/ +[//]: # (* **RPC URL:** https://mainnet-rpc.rnk.dev/) - +[//]: # (* **Chain ID:** 1597) -
+[//]: # (* **Currency Symbol:** REACT) + +[//]: # (* **Block Explorer:** https://reactscan.net/) + +[//]: # () +[//]: # () + +[//]: # () +[//]: # (
) ## Get Testnet REACT ### Reactive Faucet -To obtain **testnet REACT (lREACT)**, send **ETH** to one of the faucet contracts: +To obtain testnet REACT (lREACT), send ETH to one of the faucet contracts: ```json Ethereum Sepolia: `0x9b9BB25f1A81078C544C829c5EB7822d747Cf434` @@ -51,21 +64,25 @@ Exchange rate: **1 ETH → 100 lREACT**. Transfers can be made using MetaMask or any Ethereum-compatible wallet. :::info[Important] -Do **not** send more than **5 ETH** per transaction. +Don't send more than 5 ETH per transaction. -- Maximum sent: **5 ETH** -- Maximum received: **500 lREACT** +- Maximum sent: 5 ETH +- Maximum received: 500 lREACT -Amounts above 5 ETH are **lost** and will not generate additional lREACT. +Amounts above 5 ETH are lost and will not generate additional lREACT. ::: -### ReacDEFI Swap +[//]: # (### ReacDEFI Swap) -You can swap ETH for lREACT using [ReacDEFI](https://reacdefi.app/markets#testnet-faucet): +[//]: # () +[//]: # (You can swap ETH for lREACT using [ReacDEFI](https://reacdefi.app/markets#testnet-faucet):) -1. Choose the amount of **lREACT** -2. Connect a Sepolia or Base Sepolia wallet -3. Confirm the transaction +[//]: # () +[//]: # (1. Choose the amount of lREACT) + +[//]: # (2. Connect an Ethereum Sepolia or Base Sepolia wallet) + +[//]: # (3. Confirm the transaction) ### Terminal Request @@ -84,10 +101,9 @@ cast send 0x2afaFD298b23b62760711756088F75B7409f5967 --rpc-url $BASE_SEPOLIA_RPC Network parameters: * **Network Name:** Reactive Lasna -* **RPC URL:** https://lasna-rpc.rnk.dev/ +* **RPC URL:** https://lasna-omni-rpc.rnk.dev/ * **Chain ID:** 5318007 * **Currency Symbol:** lREACT -* **Block Explorer:** https://lasna.reactscan.net +* **Block Explorer:** https://lasna-omni.reactscan.net/ - diff --git a/docs/docs/reactscan.md b/docs/docs/reactscan.md index 81dbcde..ca91ce2 100644 --- a/docs/docs/reactscan.md +++ b/docs/docs/reactscan.md @@ -4,6 +4,7 @@ sidebar_position: 13 description: Learn how to find information on Reactscan with relevant links and pictures. slug: /reactscan hide_title: true +unlisted: true --- ![Economy](./img/reactscan.jpg) diff --git a/docs/docs/reactvm.md b/docs/docs/reactvm.md index 5766322..0e6f975 100644 --- a/docs/docs/reactvm.md +++ b/docs/docs/reactvm.md @@ -1,70 +1,18 @@ --- -title: ReactVM +title: Reactive Authentication sidebar_position: 5 -description: Learn about ReactVM, the execution environment where Reactive Contracts process event logs and execute event-driven automation across chains. +description: Reactive Authentication slug: /reactvm hide_title: true +unlisted: true --- -![ReactVM Image](./img/rvm.jpg) - ## 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. - -## 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. - -### 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 +### Reactive Authentication -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. +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: - -- **ReactVM State** — updated automatically when subscribed events occur -- **Reactive Network State** — updated when EOAs call contract functions - -Both instances share the same bytecode but operate independently. - -For example, in a governance contract: - -- Vote counts may be maintained in ReactVM state -- Administrative actions such as `pause()` may exist in the Reactive Network state - -Most automation logic runs inside ReactVM. - -## Reactive Network Processing Flow - -The diagram below shows how events from an origin chain are processed by Reactive Network and ReactVM, and how resulting actions are delivered to destination chains. - -![Reactive Network Lifecycle](./img/global-processing-flow.png) - -[More on ReactVM →](../education/module-1/react-vm.md) diff --git a/docs/docs/rnk-rpc-methods.md b/docs/docs/rnk-rpc-methods.md index a30fc1d..f3a7da6 100644 --- a/docs/docs/rnk-rpc-methods.md +++ b/docs/docs/rnk-rpc-methods.md @@ -1,7 +1,7 @@ --- title: RNK RPC Methods sidebar_position: 11 -description: Learn about Reactive Network's Geth version RPC methods used for interaction with Reactive nodes and ReactVMs. +description: Learn about Reactive Network's custom JSON-RPC methods for querying filters, subscriptions, and block sequences. slug: /rnk-rpc-methods hide_title: true --- @@ -10,33 +10,25 @@ hide_title: true ## Overview -This page documents **Reactive-specific JSON-RPC methods** available in Reactive Network’s (RNK) Geth version. Use them to inspect **ReactVM activity** (transactions, logs, code, storage), and to query network metadata like subscribers, filters, and origin-chain stats. +This page documents **Reactive-specific JSON-RPC methods** available in Reactive Network's Geth version. Use them to query active event filters, individual filter details, and block-level reactive transaction sequences. -:::tip[Ethereum RPC Methods] -Reactive Network supports standard [Geth RPC methods](https://geth.ethereum.org/docs/interacting-with-geth/rpc). This page lists RNK extensions only. -::: - -## rnk_getTransactionByHash +## rnk_getFilters -Returns a ReactVM transaction by RVM ID and transaction hash. +Returns all active event filters currently registered on Reactive Network, along with the current filter version. #### Parameters -1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID associated with the transaction. -2. **txHash**: `DATA`, 32 Bytes — The hash of the transaction to retrieve. +This method does not require any input parameters. #### cURL ```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ +curl --location 'https://lasna-omni-rpc.rnk.dev/' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", - "method": "rnk_getTransactionByHash", - "params": [ - "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044" - ], + "method": "rnk_getFilters", + "params": [], "id": 1 }' | jq ``` @@ -45,70 +37,65 @@ curl --location 'https://lasna-rpc.rnk.dev/' \ Returns an object with the following fields: -- **hash** (`string`): The transaction hash. -- **number** (`string`): The transaction number (hex-encoded). -- **time** (`uint64`): The timestamp of when the transaction occurred. -- **root** (`string`): The Merkle root associated with the transaction. -- **limit** (`uint32`): The maximum gas limit set for the transaction. -- **used** (`uint32`): The gas used by the transaction. -- **type** (`uint8`): The transaction type (0 for `Legacy`, 1 for `AccessList`, 2 for `DynamicFee`, 3 for `Blob`, 4 for `SetCode`). -- **status** (`uint8`): The status of the transaction (1 for `Success`, 0 for `Failure`). -- **from** (`string`): The transaction initiator. -- **to** (`string`): The recipient address. -- **createContract** (`bool`): Indicates whether a contract was created during this transaction. -- **sessionId** (`uint64`): The block number where the transaction is located (hex-encoded). -- **refChainId** (`uint32`): The origin chain ID. -- **refTx** (`string`): The hash of the origin chain transaction that triggered this one. -- **refEventIndex** (`uint32`): The origin chain event opcode (0 for `LOG0`, 1 for `LOG1`, 2 for `LOG2`, 3 for `LOG3`, 4 for `LOG4`). -- **data** (`string`): The encoded transaction data in hexadecimal format. -- **rData** (`string`): Additional response data in hexadecimal format (if any). +- **version** (`uint32`): The current version of the filter set. Incremented whenever filters are added or removed. +- **topicFilters** (`array[object]`): A list of active topic filters. Each filter object contains: + - **Uid** (`string`): The unique identifier of the filter, generated by the contract. + - **ChainId** (`uint64`): The origin chain ID. `0` matches any chain. + - **Contract** (`string | null`): The address of the origin contract being monitored. Null address matches any contract. + - **Topics** (`array[string | null]`): An array of up to 4 log topics (`topic_0` through `topic_3`) used for event filtering. Null entries match any topic. + - **Configs** (`array[object]`): An array of subscription configurations. Each config contains: + - **Contract** (`string`): The Reactive contract address subscribed to this filter. + - **RvmId** (`string`): The address of the associated RVM instance. + - **Active** (`bool`): Whether the subscription is currently active. ```json { "jsonrpc": "2.0", "id": 1, "result": { - "hash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", - "number": "0x9", - "time": 1753427529, - "root": "0x8df166bb5c9843696457dbdc5ab20ca1ab9acdd8703b6f1fd1f51766f34fad7d", - "limit": 900000, - "used": 47429, - "type": 2, - "status": 1, - "from": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "to": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", - "createContract": false, - "sessionId": 109252, - "refChainId": 11155111, - "refTx": "0x52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f5", - "refEventIndex": 328, - "data": "0x0d152c2c00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000aa36a7000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a00000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000086da6000000000000000000000000000000000000000000000000000000000000000034570ac2a3bbfa2809982e69218a745aa83e1bff79b54e2a2ce10e5d6d4c5c00a52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f50000000000000000000000000000000000000000000000000000000000000148000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000003e8", - "rData": "0x" + "version": 42, + "topicFilters": [ + { + "Uid": "0x6a13fb25641a7b730b319ae22f42876a", + "ChainId": 5318007, + "Contract": "0x70585aba609bf77a67b91b68298f34237fde1b90", + "Topics": [ + "0xca6e822df923f741dfe968d15d80a18abd25bd1e748bcb9ad81fea5bbb7386af", + null, + null, + null + ], + "Configs": [ + { + "Contract": "0x70585aba609bf77a67b91b68298f34237fde1b90", + "RvmId": "0x0000000000000000000000000000000000000000", + "Active": true + } + ] + } + ] } } ``` -## rnk_getTransactionByNumber +## rnk_getFilterById -Returns a ReactVM transaction by RVM ID and transaction number. +Returns details of a specific event filter by its unique identifier. #### Parameters -1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID associated with the transaction. -2. **txNumber**: `HEX` — The sequence number of the transaction to retrieve. +1. **filterId**: `string` — The unique identifier of the filter to retrieve. #### cURL ```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ +curl --location 'https://lasna-omni-rpc.rnk.dev/' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", - "method": "rnk_getTransactionByNumber", + "method": "rnk_getFilterById", "params": [ - "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "0x9" + "0xbce1695aafe72c3929c5dacf2a4c1f8d" ], "id": 1 }' | jq @@ -116,242 +103,60 @@ curl --location 'https://lasna-rpc.rnk.dev/' \ #### Response -Returns an object with the following fields: +Returns a filter object with the following fields: -- **hash** (`string`): The transaction hash. -- **number** (`string`): The transaction number (hex-encoded). -- **time** (`uint64`): The timestamp of when the transaction occurred. -- **root** (`string`): The Merkle root associated with the transaction. -- **limit** (`uint32`): The maximum gas limit set for the transaction. -- **used** (`uint32`): The gas used by the transaction. -- **type** (`uint8`): The transaction type (0 for `Legacy`, 1 for `AccessList`, 2 for `DynamicFee`, 3 for `Blob`, 4 for `SetCode`). -- **status** (`uint8`): The status of the transaction (1 for `Success`, 0 for `Failure`). -- **from** (`string`): The transaction initiator. -- **to** (`string`): The recipient address. -- **createContract** (`bool`): Indicates whether a contract was created during this transaction. -- **sessionId** (`uint64`): The block number where the transaction is located (hex-encoded). -- **refChainId** (`uint32`): The origin chain ID. -- **refTx** (`string`): The hash of the origin chain transaction that triggered this one. -- **refEventIndex** (`uint32`): The origin chain event opcode (0 for `LOG0`, 1 for `LOG1`, 2 for `LOG2`, 3 for `LOG3`, 4 for `LOG4`). -- **data** (`string`): The encoded transaction data in hexadecimal format. -- **rData** (`string`): Additional response data in hexadecimal format (if any). +- **Uid** (`string`): The unique identifier of the filter, generated by the contract. +- **ChainId** (`uint64`): The origin chain ID. `0` matches any chain. +- **Contract** (`string | null`): The address of the origin contract being monitored. Null address matches any contract. +- **Topics** (`array[string | null]`): An array of up to 4 log topics (`topic_0` through `topic_3`) used for event filtering. Null entries match any topic. +- **Configs** (`array[object]`): An array of subscription configurations. Each config contains: + - **Contract** (`string`): The Reactive contract address subscribed to this filter. + - **RvmId** (`string`): The address of the associated RVM instance. + - **Active** (`bool`): Whether the subscription is currently active. ```json { "jsonrpc": "2.0", "id": 1, "result": { - "hash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", - "number": "0x9", - "time": 1753427529, - "root": "0x8df166bb5c9843696457dbdc5ab20ca1ab9acdd8703b6f1fd1f51766f34fad7d", - "limit": 900000, - "used": 47429, - "type": 2, - "status": 1, - "from": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "to": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", - "createContract": false, - "sessionId": 109252, - "refChainId": 11155111, - "refTx": "0x52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f5", - "refEventIndex": 328, - "data": "0x0d152c2c00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000aa36a7000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a00000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000086da6000000000000000000000000000000000000000000000000000000000000000034570ac2a3bbfa2809982e69218a745aa83e1bff79b54e2a2ce10e5d6d4c5c00a52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f50000000000000000000000000000000000000000000000000000000000000148000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000003e8", - "rData": "0x" + "Uid": "0xbce1695aafe72c3929c5dacf2a4c1f8d", + "ChainId": 11155111, + "Contract": "0x3feb01b66bd77e8105e2c97e7f4eebb44ad8b83f", + "Topics": [ + "0x552b2dd798eedf0c450199b5a7c35ff9f2955c113876b1afbe87060335b31653", + null, + null, + null + ], + "Configs": [ + { + "Contract": "0xff18d4a21c9f5780f753432aa45f0c43b9c1b462", + "RvmId": "0x941b727ad8acf020558ce58cd7cb65b48b958db1", + "Active": false + } + ] } } ``` -## rnk_getTransactionLogs - -Returns the logs emitted by a ReactVM transaction number. - -#### Parameters - -1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID for which transaction logs are being queried. -2. **txNumber**: `HEX` — The transaction number for which logs are requested. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getTransactionLogs", - "params": [ - "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", - "0x9" - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns an array of objects with the following fields: - -- **txHash** (`string`): The transaction hash. -- **address** (`string`): The contract address that generated the transaction. -- **topics** (`string[]`): An array of indexed event topics. - - **topics[0]**: The event signature hash. - - **topics[1]**: The first indexed parameter (if applicable). - - **topics[2]**: The second indexed parameter (if applicable). - - **topics[3]**: The third indexed parameter (if applicable). -- **data** (`string`): The non-indexed event data in hexadecimal format. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": [ - { - "txHash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", - "address": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", - "topics": [ - "0x8dd725fa9d6cd150017ab9e60318d40616439424e2fade9c1c58854950917dfc", - "0x0000000000000000000000000000000000000000000000000000000000aa36a7", - "0x000000000000000000000000fc2236a0d3421473676c4c422046fbc4f1afdffe", - "0x00000000000000000000000000000000000000000000000000000000000f4240" - ], - "data": "0x000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000a42f90252d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce00000000000000000000000000000000000000000000000000000000000003e800000000000000000000000000000000000000000000000000000000" - } - ] -} -``` - -## rnk_getHeadNumber - -Returns the latest transaction number for a given ReactVM. - -#### Parameters - -1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID for which the latest transaction number is requested. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getHeadNumber", - "params": [ - "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a" - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns an object with the following field: - -- **result** (`string`): the latest transaction number (hex-encoded). - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": "0x9" -} -``` - -## rnk_getTransactions - -Returns a range of transactions from a given starting number. - -#### Parameters - -1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID for which transactions are being retrieved. -2. **from**: `HEX` — The starting transaction number. -3. **limit**: `HEX` — The maximum number of transactions to retrieve. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getTransactions", - "params": [ - "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", - "0x9", - "0x1" - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns an object with the following fields: - -- **hash** (`string`): The transaction hash. -- **number** (`string`): The transaction number (hex-encoded). -- **time** (`uint64`): The timestamp of when the transaction occurred. -- **root** (`string`): The Merkle root associated with the transaction. -- **limit** (`uint32`): The maximum gas limit set for the transaction. -- **used** (`uint32`): The gas used by the transaction. -- **type** (`uint8`): The transaction type (0 for `Legacy`, 1 for `AccessList`, 2 for `DynamicFee`, 3 for `Blob`, 4 for `SetCode`). -- **status** (`uint8`): The status of the transaction (1 for `Success`, 0 for `Failure`). -- **from** (`string`): The transaction initiator. -- **to** (`string`): The recipient address. -- **createContract** (`bool`): Indicates whether a contract was created during this transaction. -- **sessionId** (`uint64`): The block number where the transaction is located (hex-encoded). -- **refChainId** (`uint32`): The origin chain ID. -- **refTx** (`string`): The hash of the origin chain transaction that triggered this one. -- **refEventIndex** (`uint32`): The origin chain event opcode (0 for `LOG0`, 1 for `LOG1`, 2 for `LOG2`, 3 for `LOG3`, 4 for `LOG4`). -- **data** (`string`): The encoded transaction data in hexadecimal format. -- **rData** (`string`): Additional response data in hexadecimal format (if any). - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": [ - { - "hash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", - "number": "0x9", - "time": 1753427529, - "root": "0x8df166bb5c9843696457dbdc5ab20ca1ab9acdd8703b6f1fd1f51766f34fad7d", - "limit": 900000, - "used": 47429, - "type": 2, - "status": 1, - "from": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "to": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", - "createContract": false, - "sessionId": 109252, - "refChainId": 11155111, - "refTx": "0x52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f5", - "refEventIndex": 328, - "data": "0x0d152c2c00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000aa36a7000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a00000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000086da6000000000000000000000000000000000000000000000000000000000000000034570ac2a3bbfa2809982e69218a745aa83e1bff79b54e2a2ce10e5d6d4c5c00a52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f50000000000000000000000000000000000000000000000000000000000000148000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000003e8", - "rData": "0x" - } - ] -} -``` - -## rnk_getRnkAddressMapping +## rnk_getBlockSequences -Returns the ReactVM ID associated with a Reactive Network contract address. +Returns the reactive transaction sequences processed in a given Reactive Network block. Each sequence represents a batch of reactive transactions triggered by origin-chain events. #### Parameters -1. **reactNetworkContrAddr**: `DATA`, 20 Bytes — The address of the Reactive Network contract for which the RVM ID is being requested. +1. **blockNumber**: `string` — The hex-encoded block number for which to retrieve reactive transaction sequences. #### cURL ```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ +curl --location 'https://lasna-omni-rpc.rnk.dev/' \ --header 'Content-Type: application/json' \ --data '{ "jsonrpc": "2.0", - "method": "rnk_getRnkAddressMapping", + "method": "rnk_getBlockSequences", "params": [ - "0xc3e185561D2a8b04F0Fcd104A562f460D6cC503c" + "0x331E09" ], "id": 1 }' | jq @@ -359,543 +164,28 @@ curl --location 'https://lasna-rpc.rnk.dev/' \ #### Response -Returns an object with the following field: - -- **rvmId** (`string`): The unique identifier of the RVM associated with the given contract. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a" - } -} -``` - -## rnk_getStat - -Returns aggregated statistics per origin chain. - -#### Parameters - -This method does not require any input parameters. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getStat", - "params": [], - "id": 1 -}' | jq -``` - -#### Response - -Returns an object with the following fields: - -- **chainId** (`object`): The statistics for a specific origin chain. - - **txCount** (`uint64`): The total number of transactions processed from this origin chain. - - **eventCount** (`uint64`): The total number of events emitted from this origin chain. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "origin": { - "11155111": { - "txCount": 20807136, - "eventCount": 60122691 - }, - "43113": { - "txCount": 1244787, - "eventCount": 4929280 - }, - "5318007": { - "txCount": 160035, - "eventCount": 169908 - }, - "80002": { - "txCount": 450072, - "eventCount": 1786648 - }, - "84532": { - "txCount": 14266438, - "eventCount": 122218657 - }, - "97": { - "txCount": 3787433, - "eventCount": 9384761 - } - } - } -} -``` - -## rnk_getVms - -Returns information about all known ReactVMs. - -#### Parameters - -This method does not require any input parameters. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getVms", - "params": [], - "id": 1 -}' | jq -``` - -#### Response - -Returns a list of active RVMs with the following fields: - -- **rvmId** (`string`): The unique identifier of the RVM. -- **lastTxNumber** (`string`): The last transaction number executed by this RVM (hex-encoded). -- **contracts** (`uint32`): The number of contracts associated with this RVM. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": [ - { - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "lastTxNumber": "0x9", - "contracts": 4 - }, - { - "rvmId": "0xfe5a45db052489cbc16d882404bcfa4f6223a55e", - "lastTxNumber": "0x2", - "contracts": 1 - }, - { - "rvmId": "0x49abe186a9b24f73e34ccae3d179299440c352ac", - "lastTxNumber": "0x2d6", - "contracts": 1 - }, - { - "rvmId": "0x941b727ad8acf020558ce58cd7cb65b48b958db1", - "lastTxNumber": "0x7", - "contracts": 3 - }, - { - "rvmId": "0xc1d48a9173212567bd358e40c50bfe131a9fabf1", - "lastTxNumber": "0x3c", - "contracts": 28 - } - ] -} -``` - -## rnk_getVm - -Returns information about a specific ReactVM. - -#### Parameters - -1. **rvmId**: `DATA`, 20 Bytes — The unique identifier of the RVM for which information is requested. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getVm", - "params": ["0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a"], - "id": 1 -}' | jq -``` - -#### Response - Returns an object with the following fields: -- **rvmId** (`string`): The unique identifier of the RVM. -- **lastTxNumber** (`string`): The last transaction number executed by this RVM (hex-encoded). -- **contracts** (`uint32`): The number of contracts created by this RVM. +- **StateRoot** (`string`): The Merkle state root after processing the sequences. +- **FromSeq** (`uint64`): The starting sequence number in this block. +- **ToSeq** (`uint64`): The ending sequence number in this block. +- **FiltersVersion** (`uint32`): The filter set version used when processing this block. +- **GasUsed** (`uint32`): The total gas consumed by reactive transactions in this block. +- **ReactiveTxCount** (`uint16`): The number of reactive transactions executed in this block. +- **Sequences** (`array`): The RLP-encoded reactive transaction sequences. ```json { "jsonrpc": "2.0", "id": 1, "result": { - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "lastTxNumber": "0x9", - "contracts": 4 + "StateRoot": "0xae228178ffd763ea8f19a796a938ba51ebe32f913ff0c59ce253cb830069d0c1", + "FromSeq": 100473548, + "ToSeq": 100473550, + "FiltersVersion": 716, + "GasUsed": 22715, + "ReactiveTxCount": 0, + "Sequences": [] } } -``` - -## rnk_getSubscribers - -Returns subscriptions associated with a given ReactVM. - -#### Parameters - -1. **rvmId**: `DATA`, 20 Bytes — The unique identifier of the RVM for which subscriber information is requested. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getSubscribers", - "params": ["0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a"], - "id": 1 -}' | jq -``` - -#### Response - -Returns a list of RVM-related contract events with the following fields: - -- **uid** (`string`): The unique identifier of the subscription. -- **chainId** (`uint32`): The blockchain ID of the subscribed contract. -- **contract** (`string`): The address of the subscribed contract on the origin chain. -- **topics** (`array`): An array of event topics (some may be `null` if not indexed). -- **rvmId** (`string`): The unique identifier of the RVM. -- **rvmContract** (`string`): The address of the RVM contract handling this subscription. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": [ - { - "uid": "7d45d863e45da3a7e60d2cc5bdd7088f", - "chainId": 11155111, - "contract": "0xe1bac3039ea58fee2abce7a8cbcc4b0c8ad030c5", - "topics": [ - "0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1", - null, - null, - null - ], - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "rvmContract": "0xc3e185561d2a8b04f0fcd104a562f460d6cc503c" - }, - { - "uid": "d979ded638e32915f59ae9bfb3b70e6c", - "chainId": 11155111, - "contract": "0x7acbd40c79da73b671d47618135486eef39ec6e3", - "topics": [ - "0x9996f0dd09556ca972123b22cf9f75c3765bc699a1336a85286c7cb8b9889c6b", - null, - null, - null - ], - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "rvmContract": "0xc3e185561d2a8b04f0fcd104a562f460d6cc503c" - }, - { - "uid": "62968b91e4122e0c03a08f38b31a1ae4", - "chainId": 11155111, - "contract": "0x16102fe2caa2610a99beaa5f4fb6e230825b1096", - "topics": [ - "0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1", - null, - null, - null - ], - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "rvmContract": "0x2afafd298b23b62760711756088f75b7409f5967" - } - ] -} -``` - -## rnk_getCode - -Retrieves the deployed contract bytecode for a given ReactVM at a specific state. - -#### Parameters - -1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. -2. **contract** `DATA`, 20 bytes — The Reactive contract address. -3. **txNumberOrHash** `HEX | TAG` — Specifies the state at which the contract code is retrieved. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getCode", - "params": [ - "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", - "0xA79933a054c8Ad29ae55bEe769Cd9d8228F03520", - "0x22" - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns the bytecode of a contract: - -- **bytecode** (`string`) — The contract bytecode in hexadecimal format. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": "0x60806040526004361061007e575f3560e01c80638456cb591161004d5780638456cb591461010757806396f90b451461011d578063995e4b9814610147578063c290d6911461017157610085565b806303ac52b314610089578063046f7da2146100b3578063...efb147864736f6c634300081c0033", - -} -``` - -## rnk_getStorageAt - -Returns the value stored at a given 32-byte storage key for a contract inside a specific ReactVM, evaluated at a chosen state. - -#### Parameters - -1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. -2. **address**: `DATA`, 20 bytes — The address of the contract from which to retrieve the storage value. -3. **hexKey**: `DATA`, 32 bytes — The hexadecimal key for which the storage value is being queried. -4. **txNumberOrHash**: `HEX | TAG` — Specifies the block number or hash at which the storage value is queried. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getStorageAt", - "params": [ - "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", - "0xA79933a054c8Ad29ae55bEe769Cd9d8228F03520", - "0x0000000000000000000000000000000000000000000000000000000000000002", - "0xb707d1ddcea3fce0a966fde10f412b4c9cdedf99c67a470a7bbcb2407e1c8bcc" - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns the storage value: - -**result** (`string`): A hexadecimal string representing the storage data. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": "0x000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a" -} -``` - -## rnk_call - -Runs a read-only EVM call against a contract inside a ReactVM at a chosen state (no transaction is created). - -#### Parameters - -1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. -2. **args**: `OBJECT` — The transaction arguments, including the contract method and parameters. Should include: - - `to`: `DATA`, 20 bytes — The address of the contract. - - `data`: `DATA` — The call data, representing the method and parameters. - - `from`: `DATA`, 20 bytes, (optional) — The address from which the call is simulated. If omitted, the simulation assumes the call is made from an empty address (0x000...). - - `gas`: `HEX`, (optional) — The maximum amount of gas allowed for the simulation. If omitted, a default value is used. - - `gasPrice`: `HEX`, (optional) — The price of gas (in RVM-specific units) for the simulation. - - `value`: `HEX`, (optional) — The amount of tokens (e.g., Ether) to send along with the call. For non-payable functions, this should be 0. -3. **txNumberOrHash**: `HEX | TAG` — Specifies the block number or hash to use for simulating the call. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_call", - "params": [ - "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", - { - "to": "0xA79933a054c8Ad29ae55bEe769Cd9d8228F03520", - "data": "0x96f90b45" - }, - "latest" - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns the result of the simulated call: - -**result** (`string`): The simulated result of the contract call, returned as a hexadecimal string. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": "0x0000000000000000000000000000000000000000000000000000000000027a94" -} -``` - -## rnk_getBlockRvms - -Returns the ReactVMs that produced at least one ReactVM transaction in a given Reactive Network block, plus per-RVM counters. - -#### Parameters - -1. **blockN**: `uint64` – The block number for which to retrieve the RVM history. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getBlockRvms", - "params": [ - 109252 - ], - "id": 1 -}' | jq -``` - -#### Response - -Returns an array of objects representing RVMs that were active in the given block. Each object contains: - -- **rvmId** (`string`): The unique identifier of each RVM. -- **headTxNumber** (`string`): The transaction with the greatest number in the session (hex-encoded). -- **prevRnkBlockId** (`uint64`): The previous block number in which the RVM session was active. -- **txCount** (`uint32`): The total number of transactions in the current RVM session. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": [ - { - "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", - "headTxNumber": "0x9", - "prevRnkBlockId": 109244, - "txCount": 1 - } - ] -} -``` - -## rnk_getFilters - -Lists all active log filters (subscriptions) currently registered on Reactive Network. - -#### Parameters - -This method does not require any input parameters. - -#### cURL - -```bash -curl --location 'https://lasna-rpc.rnk.dev/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc": "2.0", - "method": "rnk_getFilters", - "params": [], - "id": 1 -}' | jq -``` - -#### Response - -Returns an array of filter objects. Each filter object contains the following fields: - -- **uid** (`string`): The unique identifier for the filter. -- **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. -- **active** (`bool`): Indicates whether the subscription/filter is active. - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": [ - { - "Uid": "4603da7efc5d1b77f7fa5b0bfd949d6c", - "ChainId": 11155111, - "Contract": "0x1e8db093a0cc38302f5822a451809bfd692ff695", - "Topics": [ - "0x8cabf31d2b1b11ba52dbb302817a3c9c83e4b2a5194d35121ab1354d69f6a4cb", - null, - null, - null - ], - "Configs": [ - { - "Contract": "0xac9163487ca9c5189766706595cbef9b75c1c8e9", - "RvmId": "0xc1d48a9173212567bd358e40c50bfe131a9fabf1", - "Active": true - } - ] - }, - { - "Uid": "b91cf2f05464d578896164d4e6c0c854", - "ChainId": 11155111, - "Contract": "0x5e3eeda090eea783af9ee8d81147d9417bb97b38", - "Topics": [ - "0x8cabf31d2b1b11ba52dbb302817a3c9c83e4b2a5194d35121ab1354d69f6a4cb", - null, - null, - null - ], - "Configs": [ - { - "Contract": "0xe3cf3d848557974d3abf8e7c15c3a534187f1c6f", - "RvmId": "0xc1d48a9173212567bd358e40c50bfe131a9fabf1", - "Active": true - } - ] - }, - { - "Uid": "0fce746e0305e2fc2e425735ea71a52f", - "ChainId": 11155111, - "Contract": "0x0102e0a1792b8805f16b6ec27978f6898b865475", - "Topics": [ - "0x9bffe4738606691ddfa5e5d28208b6ef74537676b39ddb9854b7854a62df0692", - null, - null, - null - ], - "Configs": [ - { - "Contract": "0xe4d4b0c2f8502a98e68c6f0ef2483214c106fd82", - "RvmId": "0x941b727ad8acf020558ce58cd7cb65b48b958db1", - "Active": true - } - ] - } - ] -} ``` \ No newline at end of file diff --git a/docs/docs/subscriptions.md b/docs/docs/subscriptions.md index 20042d0..07c3ea1 100644 --- a/docs/docs/subscriptions.md +++ b/docs/docs/subscriptions.md @@ -1,7 +1,7 @@ --- title: Subscriptions sidebar_position: 10 -description: Learn how Reactive Contracts subscribe to events and configure event-driven automation. +description: Learn how reactive contracts subscribe to events and configure event-driven automation. slug: /subscriptions hide_title: true --- @@ -10,56 +10,43 @@ hide_title: true ## Overview -Subscriptions define which events Reactive Contracts (RCs) listens to. RCs subscribe to events through the system contract by specifying: +Subscriptions define which events reactive contracts listen to. They subscribe to events through the system contract by specifying: - Origin chain ID - Contract address - Event topics -When a matching event is detected, the contract's `react()` function is triggered. +When a matching event is detected, the system contract calls the contract's `react()` function. Subscriptions can be configured: - During deployment (constructor) -- Dynamically via callbacks +- Dynamically at any point during execution ## Subscription Basics -Subscriptions are created by calling `subscribe()` on the system contract. This is typically done inside the contract constructor. Since contracts deploy both on Reactive Network (RNK) and inside a ReactVM (where the system contract doesn't exist), the constructor must avoid calling `subscribe()` inside ReactVM. +Subscriptions are created by calling `SYSTEM.subscribe()`. This is typically done inside the constructor. Reactive contracts extend [AbstractReactive](https://github.com/Reactive-Network/reactive-lib-omni/blob/main/src/abstract-base/AbstractReactive.sol), which provides access to the `SYSTEM` constant and the `REACTIVE_IGNORE` wildcard. -[IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol), [AbstractReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractReactive.sol), and [ISystemContract](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/ISystemContract.sol) should be implemented. Here's a subscription example in the constructor from the [Basic Demo Reactive Contract](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/basic/BasicDemoReactiveContract.sol): +Here's a subscription example from a [demo contract](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/omni/src/micro-demos/PingPong.sol): ```solidity -uint256 public originChainId; -uint256 public destinationChainId; -uint64 private constant GAS_LIMIT = 1000000; - -address private callback; - -constructor( - address _service, - uint256 _originChainId, - uint256 _destinationChainId, - address _contract, - uint256 _topic_0, - address _callback -) payable { - service = ISystemContract(payable(_service)); - - originChainId = _originChainId; - destinationChainId = _destinationChainId; - callback = _callback; - - if (!vm) { - service.subscribe( - originChainId, - _contract, - _topic_0, +contract PingPong is AbstractReactive { + uint256 public constant PING_TOPIC_0 = 0xca6e822df923f741dfe968d15d80a18abd25bd1e748bcb9ad81fea5bbb7386af; + + constructor() payable { + SYSTEM.subscribe( + block.chainid, + address(this), + PING_TOPIC_0, REACTIVE_IGNORE, REACTIVE_IGNORE, REACTIVE_IGNORE ); } + + function react(LogRecord memory log_) external onlySystem { + // Handle the event + } } ``` @@ -67,19 +54,19 @@ Subscriptions filter events using: - Chain ID - Contract address -- Topics 0–3 +- Topics 0-3 :::info[Filtering Criteria] Reactive Network provides filtering criteria based on the origin contract's chain ID, address, and all four topics. ::: -## Wildcards & Matching +## Wildcards and Matching ### REACTIVE_IGNORE `REACTIVE_IGNORE` is a predefined wildcard value that matches any topic value: -```json +``` 0xa65f96fc951c35ead38878e0f0b7a3c744a6f5ccc1476b313353ce31712313ad ``` @@ -87,17 +74,17 @@ Reactive Network provides filtering criteria based on the origin contract's chai Wildcards can also be specified with: -- `uint256(0)` → any chain ID -- `address(0)` → any contract +- `uint256(0)` for any chain ID +- `address(0)` for any contract -**At least one parameter must be specific.** +At least one parameter must be specific. ### Subscription Examples #### All Events From One Contract ```solidity -service.subscribe( +SYSTEM.subscribe( CHAIN_ID, 0x7E0987E5b3a30e3f2828572Bb659A548460a3003, REACTIVE_IGNORE, @@ -109,10 +96,10 @@ service.subscribe( #### Specific Event Type -Example: Uniswap V2 Sync events +Example: Uniswap V2 Sync events across all contracts. ```solidity -service.subscribe( +SYSTEM.subscribe( CHAIN_ID, address(0), 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1, @@ -125,7 +112,7 @@ service.subscribe( #### Specific Contract and Event ```solidity -service.subscribe( +SYSTEM.subscribe( CHAIN_ID, 0x7E0987E5b3a30e3f2828572Bb659A548460a3003, 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1, @@ -140,222 +127,121 @@ service.subscribe( Call `subscribe()` multiple times: ```solidity -if (!vm) { - - service.subscribe( - originChainId, - _contract1, - _topic0, - REACTIVE_IGNORE, - REACTIVE_IGNORE, - REACTIVE_IGNORE - ); - - service.subscribe( - originChainId, - _contract2, - REACTIVE_IGNORE, - _topic1, - REACTIVE_IGNORE, - REACTIVE_IGNORE - ); -} +SYSTEM.subscribe( + originChainId, + _contract1, + _topic0, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE +); + +SYSTEM.subscribe( + originChainId, + _contract2, + REACTIVE_IGNORE, + _topic1, + REACTIVE_IGNORE, + REACTIVE_IGNORE +); ``` ### Unsubscribing -Subscriptions can be removed through the system contract. - -Export the wildcard constant: +Subscriptions can be removed by calling `SYSTEM.unsubscribe()` with the same parameters used to create the subscription. This is called from the reactive contract itself. -```bash -export REACTIVE_IGNORE=0xa65f96fc951c35ead38878e0f0b7a3c744a6f5ccc1476b313353ce31712313ad -``` - -Example: - -```bash -cast send \ - --rpc-url $REACTIVE_RPC \ - --private-key $REACTIVE_PRIVATE_KEY \ - $SYSTEM_CONTRACT_ADDR \ - "unsubscribeContract(address,uint256,address,uint256,uint256,uint256,uint256)" \ - $REACTIVE_CONTRACT_ADDR \ - $ORIGIN_CHAIN_ID \ - $ORIGIN_CONTRACT \ - $TOPIC_0 \ - $REACTIVE_IGNORE \ - $REACTIVE_IGNORE \ - $REACTIVE_IGNORE +```solidity +SYSTEM.unsubscribe( + CHAIN_ID, + contractAddress, + topic0, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE +); ``` ### Subscription Limitations #### Equality Matching Only -Subscriptions support exact matches only. - -Not supported: - -- `<` or `>` -- Ranges -- Bitwise filters +Subscriptions support exact matches only. Range comparisons (`<`, `>`), ranges, and bitwise filters are not supported. #### Complex Criteria Sets -Each subscription defines **one set of matching criteria**. - -Not supported: - -- Disjunctions (OR conditions) -- Multiple criteria sets within one subscription - -Workaround: - -- Use multiple `subscribe()` calls -- May lead to a **large number of subscriptions** +Each subscription defines one set of matching criteria. Disjunctions (OR conditions) and multiple criteria sets within one subscription are not supported. Use multiple `subscribe()` calls as a workaround. #### No Global Subscriptions -Not allowed: - -- All chains -- All contracts -- All events on a chain +Subscribing to all chains, all contracts, or all events on a chain is not allowed. #### Duplicate Subscriptions -Duplicate subscriptions are allowed but behave as one subscription. - -Each `subscribe()` transaction still costs gas. +Duplicate subscriptions are allowed but behave as one subscription. Each `subscribe()` call still costs gas. ## Dynamic Subscriptions -Subscriptions can be created or removed dynamically based on incoming events. +Subscriptions can be created or removed dynamically at any point during execution. Since the contract lives directly on Reactive Network, it can call `SYSTEM.subscribe()` and `SYSTEM.unsubscribe()` from any function. -Subscription management is performed through the system contract, which is accessible only from Reactive Network (RNK). The ReactVM instance of a contract can't call the system contract directly, so dynamic subscription changes must be performed through callback transactions. +The following example from a [demo contract](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/omni/src/micro-demos/Xfers.sol) subscribes to Sepolia ERC-20 Transfer events and automatically unsubscribes after a configurable number of events: -The typical flow is: +```solidity +contract Xfers is AbstractReactive { + uint256 private constant SEPOLIA_CHAIN_ID = 11155111; + uint256 private constant ERC20_TRANSFER_TOPIC_0 = 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef; -1. An event is received in the ReactVM. -2. The contract decides whether to subscribe or unsubscribe. -3. A `Callback` event is emitted. -4. Reactive Network (RNK) executes the subscription change. + uint256 public _limit; -### Subscribing & Unsubscribing + constructor(uint256 limit_) payable { + _limit = limit_; + _sub(); + } -These functions run on the Reactive Network contract instance and modify subscriptions through the system contract. The example below is based on the [ApprovalListener.sol](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/approval-magic/ApprovalListener.sol) contract from the [Approval Magic demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/approval-magic). + function react(LogRecord memory log_) external onlySystem { + if (log_.opCode == 3) { + // Process the transfer event... -```solidity -// Methods specific to Reactive Network contract instance - -function subscribe(address rvm_id, address subscriber) - external - rnOnly - callbackOnly(rvm_id) - { - service.subscribe( + if (--_limit == 0) { + _unsub(); + } + } + } + + function _sub() internal { + SYSTEM.subscribe( SEPOLIA_CHAIN_ID, address(0), - APPROVAL_TOPIC_0, + ERC20_TRANSFER_TOPIC_0, + REACTIVE_IGNORE, REACTIVE_IGNORE, - uint256(uint160(subscriber)), REACTIVE_IGNORE ); } -function unsubscribe(address rvm_id, address subscriber) - external - rnOnly - callbackOnly(rvm_id) - { - service.unsubscribe( + function _unsub() internal { + SYSTEM.unsubscribe( SEPOLIA_CHAIN_ID, address(0), - APPROVAL_TOPIC_0, + ERC20_TRANSFER_TOPIC_0, + REACTIVE_IGNORE, REACTIVE_IGNORE, - uint256(uint160(subscriber)), REACTIVE_IGNORE ); } +} ``` -Parameters: - -- **rvm_id** — ReactVM identifier (injected automatically) -- **subscriber** — address to subscribe or unsubscribe - -Operations: - -- **subscribe** — registers a subscriber for `APPROVAL_TOPIC_0` -- **unsubscribe** — removes a subscriber from `APPROVAL_TOPIC_0` - -### react() Logic - -The `react()` function processes incoming events and emits callbacks when subscription changes are required. +The contract also supports resubscribing by calling `_coverDebt()` to settle any outstanding balance before reactivating the subscription: ```solidity -// Methods specific to ReactVM contract instance -function react(LogRecord calldata log) external vmOnly { - - if (log.topic_0 == SUBSCRIBE_TOPIC_0) { - - bytes memory payload = abi.encodeWithSignature( - "subscribe(address,address)", - address(0), - address(uint160(log.topic_1)) - ); - - emit Callback( - REACTIVE_CHAIN_ID, - address(this), - CALLBACK_GAS_LIMIT, - payload - ); - - } else if (log.topic_0 == UNSUBSCRIBE_TOPIC_0) { - - bytes memory payload = abi.encodeWithSignature( - "unsubscribe(address,address)", - address(0), - address(uint160(log.topic_1)) - ); - - emit Callback( - REACTIVE_CHAIN_ID, - address(this), - CALLBACK_GAS_LIMIT, - payload); - +function updateLimit(uint256 limit_) external payable { + _limit = limit_; + + if (limit_ == 0) { + _unsub(); } else { - - (uint256 amount) = abi.decode(log.data, (uint256)); - - bytes memory payload = abi.encodeWithSignature( - "onApproval(address,address,address,address,uint256)", - address(0), - address(uint160(log.topic_2)), - address(uint160(log.topic_1)), - log._contract, - amount - ); - - emit Callback( - SEPOLIA_CHAIN_ID, - address(approval_service), - CALLBACK_GAS_LIMIT, - payload - ); + _coverDebt(); + _sub(); } } ``` - -Event handling: - -- **Subscribe event** → emits a callback that creates a subscription -- **Unsubscribe event** → emits a callback that removes a subscription -- **Other events** → emit callbacks that trigger application logic - -Callbacks are executed by Reactive Network after the event is processed. - -[More on Subscriptions →](../education/module-1/subscriptions.md) \ No newline at end of file diff --git a/docs/docs/testing.md b/docs/docs/testing.md index 4cc9ae8..bfb6d15 100644 --- a/docs/docs/testing.md +++ b/docs/docs/testing.md @@ -4,6 +4,7 @@ sidebar_position: 14 description: Test Reactive Contracts locally with Foundry using reactive-test-lib. Simulate event-driven, cross-chain smart contract execution with forge test without using a testnet. slug: /testing hide_title: true +unlisted: true --- ![Testing Image](./img/testing.jpg) @@ -17,7 +18,7 @@ Supported features: - Event subscriptions (including wildcards) - Full `react()` pipeline - Cross-chain and same-chain callbacks -- Same-chain callbacks via `SERVICE_ADDR` (`0x0000000000000000000000000000000000fffFfF`) +- Same-chain callbacks via `SERVICE_ADDR` (`0x8888888888888888888888888888888888888888`) - Cron-based triggers - Multi-step workflows (bridges, confirmations) - Automatic chain ID resolution @@ -66,7 +67,7 @@ contract MyReactiveTest is ReactiveTest { `super.setUp()` performs the following setup: -1. Deploys `MockSystemContract` and writes its code to `SERVICE_ADDR` (`0x0000000000000000000000000000000000fffFfF`) +1. Deploys `MockSystemContract` and writes its code to `SERVICE_ADDR` (`0x8888888888888888888888888888888888888888`) 2. Deploys `MockCallbackProxy` for cross-chain callback execution 3. Sets `rvmId` to `address(this)` 4. Sets `reactiveChainId` to `REACTIVE_CHAIN_ID` (`0x512512`) diff --git a/docs/education/use-cases/index.md b/docs/education/use-cases/index.md deleted file mode 100644 index 9fbeb6f..0000000 --- a/docs/education/use-cases/index.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "Use Cases" -sidebar_position: 1 -description: Discover practical uses of Reactive Contracts with demos on low-latency log monitoring and Uniswap V2 stop orders. Deploy and test these examples to boost your expertise. -slug: /education/use-cases ---- - -# Use Cases - -## Overview - -The Use Cases section primarily focuses on analyzing scenarios where Reactive Contracts might be a game changer. - -The [Basic Demo](use-case-1.md) is a basic use case of the Reactive Network enabling low-latency event monitoring, capturing logs from origin chain contracts, processing them, and triggering callbacks on the destination chain. - -The [Deploying Reactive Contracts with Remix](./remix-ide-demo.mdx) article is a guide for deploying a Reactive Contract using the Remix Development Environment. - -The [Uniswap V2 Stop Order Demo](./use-case-3.md) is a demo of a simple Reactive contract that implements a stop order upon a Uniswap V2 liquidity pool. Study its setup and try deploying and testing it yourself. - -The [Approval Magic Demo](./use-case-2.md) extends reactive and subscription-based concepts to implement an approval-based token exchange across multiple chains. - -If you have an idea for another use case, feel free to submit and turn it into a bounty, using our [Unicornization](https://reactive.network/unicornization) program. - -## GitHub Repository - -Visit the [Reactive Contract Demos](https://github.com/Reactive-Network/reactive-smart-contract-demos) repository on GitHub to clone the project and start exploring! diff --git a/docs/legacy/debugging.md b/docs/legacy/debugging.md new file mode 100644 index 0000000..6413380 --- /dev/null +++ b/docs/legacy/debugging.md @@ -0,0 +1,151 @@ +--- +title: Debugging +sidebar_position: 13 +description: The page dedicated to debugging of most frequent errors and issues on Reactive Network. +slug: /legacy/debugging +hide_title: true +--- + +![Debugging Image](img/debugging.jpg) + +## Overview + +The debugging page is dedicated to key operational and troubleshooting details for Reactive Network and beyond. Use it as a quick reference when setting up or troubleshooting your deployments. + +## Callback Structure + +Callbacks **must include at least one argument** — the first slot **must always be left for an RVM address**. Omitting it will cause the call to fail. Reactive automatically overwrites the first 160 bits of the payload with the relevant **RVM ID** (the deployer’s address). + +Callback payload example: + +```solidity +bytes memory payload = abi.encodeWithSignature( + "stop(address,address,address,bool,uint256,uint256)", + address(0), + pair, + client, + token0, + coefficient, + threshold +); +emit Callback(chain_id, stop_order, CALLBACK_GAS_LIMIT, payload); +``` + +[More on Callbacks →](events-and-callbacks.md#callbacks-to-destination-chains) + +## 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. + +![Debugging Image](img/contract-inactive.png) + +You can either fund the relevant contract on deployment: + +```bash +forge create --broadcast --rpc-url $RPC_URL --private-key $PRIVATE_KEY $CONTRACT_PATH --value $VALUE --constructor-args $ARG1 $ARG2 ... +``` + +Or transfer funds manually after deployment, calling `coverDebt()` afterward: + +```bash +cast send $CONTRACT_ADDR --rpc-url $RPC_URL --private-key $PRIVATE_KEY --value $VALUE +``` + +```bash +cast send --rpc-url $RPC_URL --private-key $PRIVATE_KEY $CONTRACT_ADDR "coverDebt()" +``` + +You can verify a contract’s balance anytime on Reactscan or via Foundry cast command: + +```bash +cast balance $CONTRACT_ADDR --rpc-url $RPC_URL +``` + +To check the outstanding debt, query the relevant proxy contract (`0x0000000000000000000000000000000000fffFfF` on Reactive): + +```bash +cast call $PROXY_ADDR "debts(address)" $CONTRACT_ADDR --rpc-url $RPC_URL | cast to-dec +``` + +[More on Reactive Economy →](economy.md) + +## Getting Testnet lREACT + +### Reactive Faucet + +To obtain testnet **lREACT**, send **ETH** to one of the Reactive faucet contracts: + +```json +Ethereum Sepolia: 0x9b9BB25f1A81078C544C829c5EB7822d747Cf434 + +Base Sepolia: 0x2afaFD298b23b62760711756088F75B7409f5967 +``` + +The exchange rate is **1:100** — for each **ETH** sent, you receive **100 lREACT**. You can make the transfer using **MetaMask** or any Ethereum-compatible wallet. + +:::info[Important] +**Do not** send more than **5 ETH** in a single transaction. Any excess will be **lost**. Maximum per request: **5 ETH → 500 lREACT**. +::: + +### ReacDEFI Swap + +You can also swap ETH for lREACT directly using [ReacDEFI](https://reacdefi.app/markets#testnet-faucet). Select the desired lREACT amount, and the app will calculate the required ETH. An Ethereum/Base Sepolia wallet (MetaMask or Coinbase) must be connected. + +### Terminal Request + +You can also request lREACT by calling `request()` on one of the faucet contracts: + +```bash +cast send 0x9b9BB25f1A81078C544C829c5EB7822d747Cf434 \ + --rpc-url $ETHEREUM_SEPOLIA_RPC \ + --private-key $ETHEREUM_SEPOLIA_PRIVATE_KEY \ + "request(address)" $CONTRACT_ADDR \ + --value 0.1ether +``` + +```bash +cast send 0x2afaFD298b23b62760711756088F75B7409f5967 \ + --rpc-url $BASE_SEPOLIA_RPC \ + --private-key $BASE_SEPOLIA_PRIVATE_KEY \ + "request(address)" $CONTRACT_ADDR \ + --value 0.1ether +``` + +[More on Reactive Faucet →](reactive-mainnet.mdx#get-testnet-react) + +## Reactive Faucet Issue + +If you’ve sent **ETH** to the Reactive Faucet at `0x9b9BB25f1A81078C544C829c5EB7822d747Cf434` (Ethereum Sepolia) or `0x2afaFD298b23b62760711756088F75B7409f5967` (Base Sepolia) but haven’t received **lREACT** within a few minutes, the faucet might be experiencing a temporary issue. Report it in our [General Telegram channel](https://t.me/reactivedevs/1). You will receive your test lREACT once the issue is resolved. + +## Nonce & Gas Price Issue + +When encountering the `Replacement transaction underpriced` error, it means a new transaction is trying to replace a pending one with an equal or lower gas price. To fix this, first check your current **nonce**: + +```bash +cast nonce --rpc-url $REACTIVE_RPC $CONTRACT_ADDR +``` + +Then resend the transaction with the same nonce, but specify higher gas prices using the `--priority-gas-price` and `--gas-price` flags: + +```bash +cast send --rpc-url $REACTIVE_RPC --private-key $PRIVATE_KEY --priority-gas-price $VALUE --gas-price $VALUE --nonce $VALUE $CONTRACT_ADDR … +``` + +## MetaMask Smart Transactions Issue + +When trying to perform a transaction on Reactive Network, a bridge transfer or faucet claim, MetaMask may show a message like `Smart Transaction interrupted — this transaction was going to fail` or the transaction may never appear on-chain. + +MetaMask has a feature called **Smart Transactions**, which routes transactions through a special **“smart address”** instead of your regular wallet address. +These smart contracts are not deployed on the **Reactive Network**, so any operations relying on direct wallet transactions (like our bridge or faucet) will fail. + +You will need to disable Smart Transactions in MetaMask: + +1. Open MetaMask. +2. Tap the **menu icon** (☰) in the top-right corner. +3. Go to **Settings → Advanced.** +4. Find **Smart Transactions.** +5. Toggle it **OFF.** + +After this, your transactions will go through the regular route and should work correctly. + +[More on MetaMask's Smart Transactions →](https://support.metamask.io/manage-crypto/transactions/smart-transactions/) \ No newline at end of file diff --git a/docs/legacy/demos.md b/docs/legacy/demos.md new file mode 100644 index 0000000..7e373a9 --- /dev/null +++ b/docs/legacy/demos.md @@ -0,0 +1,53 @@ +--- +title: Demos +sidebar_position: 11 +description: Practical Reactive Network demos covering event subscriptions, log monitoring, dynamic callbacks, and real-world automation examples including Uniswap V2 stop orders. +slug: /legacy/demos +hide_title: true +--- + +![Demos Image](img/demos.jpg) + +## Overview + +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 Basic Demo + +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. + +## 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. + +## 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. + +## 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. + +## 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 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. \ No newline at end of file diff --git a/docs/legacy/economy.md b/docs/legacy/economy.md new file mode 100644 index 0000000..5f16f79 --- /dev/null +++ b/docs/legacy/economy.md @@ -0,0 +1,194 @@ +--- +title: Economy +sidebar_position: 5 +description: Learn how Reactive Contracts pay for execution and cross-chain callbacks, including REACT funding, transaction fees, and callback pricing. +slug: /legacy/economy +hide_title: true +--- + +![Economy](img/economy.jpg) + +## Overview + +This section explains how Reactive Contracts pay for execution and cross-chain callbacks, including REACT funding, transaction fees, and callback pricing. RVM transactions and callbacks are executed first and accounted for later. Contracts must maintain sufficient balances to remain active. + +## RVM Transactions + +RVM transactions do not include a gas price at execution time. Fees are calculated and charged later using the base fee of a subsequent block (typically the next block). Because accounting is aggregated at the block level, Reactscan can't associate fees with individual RVM transactions. + +:::info[Max Gas Limit] +The maximum gas limit for RVM transactions is 900,000 units. +::: + +The Reactive transaction fee is calculated as: + +$$ +fee = BaseFee ⋅ GasUsed +$$ + +Where: + +- `BaseFee` — base fee per gas unit in the accounting block +- `GasUsed` — gas consumed during execution + +:::info[Reactive Network Transactions] +RNK transactions follow the standard EVM gas model. +::: + +### Direct Transfers + +Reactive Contracts must be funded in REACT before executing RVM transactions. + +Fund a contract: + +```bash +cast send $CONTRACT_ADDR \ + --rpc-url $REACTIVE_RPC \ + --private-key $REACTIVE_PRIVATE_KEY \ + --value 0.1ether +``` + +Then settle outstanding debt: + +```bash +cast send \ + --rpc-url $REACTIVE_RPC \ + --private-key $REACTIVE_PRIVATE_KEY \ + $CONTRACT_ADDR "coverDebt()" +``` + +:::info[Contract Status] +Contract status is available on [Reactscan](https://reactscan.net/). + +- `active` — contract executes normally +- `inactive` — outstanding debt must be settled +::: + +### System Contract Deposits + +Contracts can be funded through the system contract using `depositTo()`. The sender pays the transaction fee, and any outstanding debt is settled automatically. + +```bash +cast send \ + --rpc-url $REACTIVE_RPC \ + --private-key $REACTIVE_PRIVATE_KEY \ + $SYSTEM_CONTRACT_ADDR "depositTo(address)" \ + $CONTRACT_ADDR \ + --value 0.1ether +``` + +:::info[System Contract] +On Reactive Network, the system contract and callback proxy share the same address: `0x0000000000000000000000000000000000fffFfF`. +::: + +## Callback Pricing + +Callback costs depend on the destination network and current base fees. The callback price $$p_{callback}$$ is calculated as: + +$$ +p_{callback} = p_{base} ⋅ C ⋅ (g_{callback} + K) +$$ + +Where: + +- $$p_{base}$$ — base gas price (`tx.gasprice` or `block.basefee`) +- $$C$$ — destination-network pricing coefficient +- $$g_{callback}$$ — callback gas usage +- $$K$$ — fixed gas surcharge + +## Callback Payment + +Callbacks use the same payment model as RVM transactions. Contracts without sufficient funds are blocklisted and can't execute transactions or callbacks. + +:::warning[Callback Gas Limit] +Reactive Network enforces a minimum callback gas limit of 100,000 gas. Callback requests below this threshold are ignored, as this minimum ensures sufficient gas for internal audits and computations required to process the callback. +::: + +### Direct Transfers + +Fund a callback contract: + +```bash +cast send $CALLBACK_ADDR \ + --rpc-url $DESTINATION_RPC \ + --private-key $DESTINATION_PRIVATE_KEY \ + --value 0.1ether +``` + +Then settle outstanding debt: + +```bash +cast send \ + --rpc-url $DESTINATION_RPC \ + --private-key $DESTINATION_PRIVATE_KEY \ + $CALLBACK_ADDR "coverDebt()" +``` + +### Callback Proxy Deposits + +Callback contracts can be funded through the callback proxy using `depositTo()`. Debt is settled automatically. + +```bash +cast send \ + --rpc-url $DESTINATION_RPC \ + --private-key $DESTINATION_PRIVATE_KEY \ + $CALLBACK_PROXY_ADDR "depositTo(address)" \ + $CALLBACK_ADDR \ + --value 0.1ether +``` + +:::tip[On-The-Spot Payment] +Implementing `pay()` or inheriting from `AbstractPayer` enables automatic settlement. The callback proxy calls `pay()` when a callback creates debt. The standard implementation verifies the caller, checks balances, and settles the debt. +::: + +## Callback Contract Balance + +### Balance + +Retrieve the balance of a callback contract: + +```bash +cast balance $CONTRACT_ADDR --rpc-url $DESTINATION_RPC +``` + +### Debt + +Query the debt recorded by the callback proxy: + +```bash +cast call $CALLBACK_PROXY_ADDR "debts(address)" $CONTRACT_ADDR --rpc-url $DESTINATION_RPC | cast to-dec +``` + +### Reserves + +Retrieve reserves held by the callback proxy: + +```bash +cast call $CALLBACK_PROXY_ADDR "reserves(address)" $CONTRACT_ADDR --rpc-url $DESTINATION_RPC | cast to-dec +``` + +## Reactive Contract Balance + +### Balance + +Retrieve the REACT balance of a Reactive contract: + +```bash +cast balance $CONTRACT_ADDR --rpc-url $REACTIVE_RPC +``` + +### Debt + +Query the debt recorded by the system contract: + +```bash +cast call $SYSTEM_CONTRACT_ADDR "debts(address)" $CONTRACT_ADDR --rpc-url $REACTIVE_RPC | cast to-dec +``` + +### Reserves + +Retrieve reserves held by the system contract: + +```bash +cast call $SYSTEM_CONTRACT_ADDR "reserves(address)" $CONTRACT_ADDR --rpc-url $REACTIVE_RPC | cast to-dec +``` \ No newline at end of file diff --git a/docs/legacy/events-and-callbacks.md b/docs/legacy/events-and-callbacks.md new file mode 100644 index 0000000..fb8f937 --- /dev/null +++ b/docs/legacy/events-and-callbacks.md @@ -0,0 +1,105 @@ +--- +title: Events & Callbacks +sidebar_position: 8 +description: Learn how Reactive Contracts process events and trigger cross-chain callback transactions. +slug: /legacy/events-&-callbacks +hide_title: true +--- + +![Events and Callbacks Image](img/events-and-callbacks.jpg) + +## Overview + +Reactive Contracts process on-chain events and trigger transactions on destination chains through callbacks. Contracts run inside isolated environments called [ReactVMs](reactvm.md), where incoming events are processed and callback transactions are generated when conditions are met. + +## 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: + +```solidity +// SPDX-License-Identifier: UNLICENSED + +pragma solidity >=0.8.0; + +import './IPayer.sol'; + +interface IReactive is IPayer { + struct LogRecord { + uint256 chain_id; + address _contract; + uint256 topic_0; + uint256 topic_1; + uint256 topic_2; + uint256 topic_3; + bytes data; + uint256 block_number; + uint256 op_code; + uint256 block_hash; + uint256 tx_hash; + uint256 log_index; + } + ... +} +``` + +Reactive Network calls `react()` whenever a subscribed event is detected. The `LogRecord` structure contains the event metadata, including chain ID, contract address, topics, and event data. + +Reactive Contracts execute inside a private ReactVM associated with the deployer's address. Contracts inside one ReactVM **can't** interact directly with contracts deployed by other users. + +Below is an example `react()` function from the [Basic Reactive Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/basic/BasicDemoReactiveContract.sol): + +```solidity +function react(LogRecord calldata log) external vmOnly { + + if (log.topic_3 >= 0.001 ether) { + bytes memory payload = abi.encodeWithSignature("callback(address)", address(0)); + emit Callback(destinationChainId, callback, GAS_LIMIT, payload); + } +} +``` + +## Callbacks to Destination Chains + +Reactive Contracts initiate transactions on destination chains by emitting `Callback` events, which are also part of the [IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) interface: + +```solidity +event Callback( + uint256 indexed chain_id, + address indexed _contract, + uint64 indexed gas_limit, + bytes payload +); +``` + +When this event appears in the transaction trace, Reactive Network submits a transaction to the specified destination chain. + +- **chain_id** — destination network +- **_contract** — target contract +- **gas_limit** — execution gas limit +- **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. +::: + +### Example: Uniswap Stop Order Demo + +Example callback payload construction from the [Uniswap Stop Order Reactive Contract](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/uniswap-v2-stop-order/UniswapDemoStopOrderReactive.sol): + +```solidity +bytes memory payload = abi.encodeWithSignature( + "stop(address,address,address,bool,uint256,uint256)", + address(0), + pair, + client, + token0, + coefficient, + threshold +); +triggered = true; +emit Callback(log.chain_id, stop_order, CALLBACK_GAS_LIMIT, payload); +``` + +The payload encodes the function call and parameters that will be executed on the destination chain. + +[More on Callback Payment →](./economy#callback-payment) \ No newline at end of file diff --git a/docs/legacy/img/contract-inactive.png b/docs/legacy/img/contract-inactive.png new file mode 100644 index 0000000..6e5d5c8 Binary files /dev/null and b/docs/legacy/img/contract-inactive.png differ diff --git a/docs/legacy/img/debugging.jpg b/docs/legacy/img/debugging.jpg new file mode 100644 index 0000000..60248cf Binary files /dev/null and b/docs/legacy/img/debugging.jpg differ diff --git a/docs/docs/img/demos.jpg b/docs/legacy/img/demos.jpg similarity index 100% rename from docs/docs/img/demos.jpg rename to docs/legacy/img/demos.jpg diff --git a/docs/legacy/img/economy.jpg b/docs/legacy/img/economy.jpg new file mode 100644 index 0000000..83607a0 Binary files /dev/null and b/docs/legacy/img/economy.jpg differ diff --git a/docs/legacy/img/events-and-callbacks.jpg b/docs/legacy/img/events-and-callbacks.jpg new file mode 100644 index 0000000..4af2a3b Binary files /dev/null and b/docs/legacy/img/events-and-callbacks.jpg differ diff --git a/docs/docs/img/global-processing-flow.png b/docs/legacy/img/global-processing-flow.png similarity index 100% rename from docs/docs/img/global-processing-flow.png rename to docs/legacy/img/global-processing-flow.png diff --git a/docs/legacy/img/mainnet-testnet.jpg b/docs/legacy/img/mainnet-testnet.jpg new file mode 100644 index 0000000..e278786 Binary files /dev/null and b/docs/legacy/img/mainnet-testnet.jpg differ diff --git a/docs/legacy/img/origins-and-destinations.jpg b/docs/legacy/img/origins-and-destinations.jpg new file mode 100644 index 0000000..5bd1449 Binary files /dev/null and b/docs/legacy/img/origins-and-destinations.jpg differ diff --git a/docs/legacy/img/reactive-contracts.jpg b/docs/legacy/img/reactive-contracts.jpg new file mode 100644 index 0000000..324e82f Binary files /dev/null and b/docs/legacy/img/reactive-contracts.jpg differ diff --git a/docs/legacy/img/reactive-demos.jpg b/docs/legacy/img/reactive-demos.jpg new file mode 100644 index 0000000..95771b7 Binary files /dev/null and b/docs/legacy/img/reactive-demos.jpg differ diff --git a/docs/legacy/img/reactive-docs.jpg b/docs/legacy/img/reactive-docs.jpg new file mode 100644 index 0000000..c32d527 Binary files /dev/null and b/docs/legacy/img/reactive-docs.jpg differ diff --git a/docs/legacy/img/reactive-lib.jpg b/docs/legacy/img/reactive-lib.jpg new file mode 100644 index 0000000..719e4ec Binary files /dev/null and b/docs/legacy/img/reactive-lib.jpg differ diff --git a/docs/docs/img/reactive-rvm.jpg b/docs/legacy/img/reactive-rvm.jpg similarity index 100% rename from docs/docs/img/reactive-rvm.jpg rename to docs/legacy/img/reactive-rvm.jpg diff --git a/docs/legacy/img/rnk-rpc-methods.jpg b/docs/legacy/img/rnk-rpc-methods.jpg new file mode 100644 index 0000000..0cb2b31 Binary files /dev/null and b/docs/legacy/img/rnk-rpc-methods.jpg differ diff --git a/docs/legacy/img/rvm.jpg b/docs/legacy/img/rvm.jpg new file mode 100644 index 0000000..073a0f2 Binary files /dev/null and b/docs/legacy/img/rvm.jpg differ diff --git a/docs/legacy/img/subscriptions.jpg b/docs/legacy/img/subscriptions.jpg new file mode 100644 index 0000000..cd014e8 Binary files /dev/null and b/docs/legacy/img/subscriptions.jpg differ diff --git a/docs/legacy/img/testing.jpg b/docs/legacy/img/testing.jpg new file mode 100644 index 0000000..6c90167 Binary files /dev/null and b/docs/legacy/img/testing.jpg differ diff --git a/docs/docs/img/verify-a.png b/docs/legacy/img/verify-a.png similarity index 100% rename from docs/docs/img/verify-a.png rename to docs/legacy/img/verify-a.png diff --git a/docs/docs/img/verify-b.png b/docs/legacy/img/verify-b.png similarity index 100% rename from docs/docs/img/verify-b.png rename to docs/legacy/img/verify-b.png diff --git a/docs/docs/img/verify-c.png b/docs/legacy/img/verify-c.png similarity index 100% rename from docs/docs/img/verify-c.png rename to docs/legacy/img/verify-c.png diff --git a/docs/legacy/index.md b/docs/legacy/index.md new file mode 100644 index 0000000..fd45c14 --- /dev/null +++ b/docs/legacy/index.md @@ -0,0 +1,58 @@ +--- +sidebar_position: 1 +title: Getting Started +description: Explore Reactive Network — an automation layer for EVM chains. Build Reactive Contracts — event-driven smart contracts for cross-chain, on-chain automation. +slug: /legacy/ +hide_title: true +--- + +![Reactive Docs Image](img/reactive-docs.jpg) + +## Overview + +Reactive Network is an EVM-compatible chain built around Reactive Contracts (RCs) — event-driven smart contracts for cross-chain, on-chain automation. + +Reactive Contracts monitor event logs across EVM chains and execute Solidity logic automatically when conditions are met. Instead of waiting for users or bots to trigger transactions, RCs run continuously and decide when to send cross-chain callback transactions, essentially providing on-chain if-this-then-that automation for smart contracts. + +This makes it possible to build conditional cross-chain workflows such as: + +* Automated stop-loss and take-profit orders +* Liquidation protection +* Automated portfolio rebalancing +* Yield optimization +* Cross-chain workflows + +## Step 1 — Reactive Basics + +[Origins & Destinations →](./origins-and-destinations.mdx) Understand origin and destination chains and their Callback Proxy addresses. + +[Reactive Contracts →](./reactive-contracts.md) Learn how Reactive Contracts subscribe to events and trigger actions. + +[ReactVM →](./reactvm.md) Understand ReactVM and how Reactive execution works. + +[Economy →](./economy) Understand callback payments and Reactive's economy. + +## Step 2 — Reactive Essentials + +[Reactive Mainnet & Lasna Testnet →](./reactive-mainnet.mdx) Connect to Reactive Mainnet or Lasna Testnet. + +[Reactive Library →](./reactive-lib.mdx) Use Reactive abstract contracts and interfaces. + +[Events & Callbacks →](./events-and-callbacks.md) Learn how event subscriptions trigger cross-chain callbacks. + +[Subscriptions →](./subscriptions.md) Configure event subscriptions. + +[RNK RPC Methods →](./rnk-rpc-methods.md) Reference RPC methods for Reactive nodes. + +## Step 3 — Reactive Building + +[Reactive Demos →](./demos.md) Explore working examples. + +[Reactive Demos on GitHub →](https://github.com/Reactive-Network/reactive-smart-contract-demos) Clone demo projects and start building. + +## Extra + +[Debugging →](./debugging.md) Troubleshoot common issues. + +[Contacts →](../contacts/index.md) Get support and connect with the community. + diff --git a/docs/legacy/origins-and-destinations.mdx b/docs/legacy/origins-and-destinations.mdx new file mode 100644 index 0000000..0730c0d --- /dev/null +++ b/docs/legacy/origins-and-destinations.mdx @@ -0,0 +1,54 @@ +--- +title: Origins & Destinations +sidebar_position: 2 +description: Learn how Reactive Contracts subscribe to event logs on origin chains and send callback transactions to destination chains. +slug: /legacy/origins-and-destinations +hide_title: true +--- + +import MainnetChainTable from "../../src/components/origins-destinations"; +import TestnetChainTable from "../../src/components/origins-destinations-testnet"; + +![Origins & Destinations Image](./img/origins-and-destinations.jpg) + +## Overview + +Reactive Contracts (RCs) can **listen to event logs on one chain** and **trigger actions on another**. To describe that flow, we use two roles: + +- **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. + +## Callback Proxy Address + +Callbacks are delivered to destination chains via a **Callback Proxy** contract. Its job is to make callback transactions verifiable and safe for destination-side contracts. + +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). + +## Mainnet Chains + +:::info[Origin/Destination] +Origin is the chain where events originate (and are read from). Destination is the chain where callbacks are delivered in response to those events. Mainnets and testnets must not be mixed: if the origin is a mainnet, the destination must also be a mainnet. +::: + + + +## Testnet Chains + +:::info[Origin/Destination] +Origin is the chain where events originate (and are read from). Destination is the chain where callbacks are delivered in response to those events. Mainnets and testnets must not be mixed: if the origin is a testnet, the destination must also be a testnet. +::: + + + +[//]: # (emojis for status ✅ ➖ ⌛) + +[//]: # (:::info[Callbacks]) + +[//]: # (Not all origin chains are compatible as destination chains. Please refer to the table below before implementing callbacks.) + +[//]: # (:::) \ No newline at end of file diff --git a/docs/legacy/reactive-contracts.md b/docs/legacy/reactive-contracts.md new file mode 100644 index 0000000..062a5b7 --- /dev/null +++ b/docs/legacy/reactive-contracts.md @@ -0,0 +1,123 @@ +--- +title: Reactive Contracts +sidebar_position: 3 +description: Learn about Reactive Contracts (RCs) — event-driven smart contracts for cross-chain, on-chain automation that monitor event logs and trigger callback transactions. +slug: /legacy/reactive-contracts +hide_title: true +--- + +![Reactive Contracts Image](img/reactive-contracts.jpg) + +## Overview + +Reactive Contracts (RCs) are event-driven smart contracts for cross-chain, on-chain automation. They monitor event logs across EVM chains, execute Solidity logic when subscribed events occur, and can trigger cross-chain callback transactions. + +RCs define which chains, contracts, and events to monitor and operate autonomously based on on-chain events rather than user transactions or bots. + +## Deployment + +Reactive Contracts deploy in two environments: + +- **Reactive Network (RNK)** — the public chain where EOAs interact with the contract and subscriptions are managed + +- **ReactVM (RVM)** — a private execution environment where event processing takes place + +Both copies use identical bytecode but operate independently. + +## State Separation + +The two deployments do not share state. Constructor flags or runtime checks can be used to distinguish environments. A contract can detect execution inside ReactVM by calling the system contract — calls revert outside ReactVM. See our [demos](demos.md) for details. + +## ReactVM Limitations + +Inside [ReactVM](reactvm.md), Reactive Contracts can't access external systems directly. They receive event logs from Reactive Network and can send callback transactions to destination chains, but can't interact with external RPC endpoints or off-chain services. + +## Verifying Reactive Contracts + +Contracts can be verified during or after deployment using the Sourcify endpoint. Sourcify is a decentralized verification service that matches deployed bytecode with source code, making contracts auditable and transparent. + +## Verify After Deployment + +```bash +forge verify-contract \ +--verifier sourcify \ +--chain-id $CHAIN_ID \ +$CONTRACT_ADDR $CONTRACT_NAME +``` + +Replace: + +- `$CHAIN_ID` → `1597` (Reactive Mainnet) or `5318007` (Lasna Testnet) +- `$CONTRACT_ADDR` → deployed contract address +- `$CONTRACT_NAME` → contract name (e.g. `MyContract`) + +## Verify on Deployment + +```bash +forge create \ +--verifier sourcify \ +--verify \ +--chain-id $CHAIN_ID \ +--private-key $PRIVATE_KEY \ +$PATH +``` + +Replace: + +- `$CHAIN_ID` → `1597` (Reactive Mainnet) or `5318007` (Lasna Testnet) +- `$PATH` → e.g. `src/MyContract.sol:MyContract` +- `$PRIVATE_KEY` → deployer key + +Example: + +```bash +forge create \ + --broadcast \ + --rpc-url $REACTIVE_RPC_URL \ + --private-key $REACTIVE_PRIVATE_KEY \ + --chain-id $REACTIVE_CHAIN_ID \ + --value 0.01ether \ + --verify \ + --verifier sourcify \ + src/.../MyContract.sol:MyContract \ + --constructor-args \ + $ARGUMENT_1 \ + $ARGUMENT_2 \ + $ARGUMENT_3 \ + # ...add more as needed +``` + +:::warning[Broadcast Error] +If you encounter the error below, your Foundry version doesn't expect the `--broadcast` flag for `forge create`. Remove `--broadcast` and retry. + +```go +error: unexpected argument '--broadcast' found +``` +::: + +## Verified Contracts on Reactscan + +After verification: + +1. Open Reactscan ([Reactive Mainnet](https://reactscan.net/), [Lasna Testnet](https://lasna.reactscan.net/)) +2. Navigate to your RVM +3. Open Contracts + + +![Image a](img/verify-a.png) + +4. Select the contract address + +![Image b](img/verify-b.png) + +Successful verification shows: + +```json +Contract Address: 0xc3e185561D2a8b04F0Fcd104A562f460D6cC503c +Status: VERIFIED (EXACT MATCH) +Compiler: 0.8.28 +``` + +![Image c](img/verify-c.png) + +Verified contracts expose full source code with syntax highlighting and file structure. diff --git a/docs/legacy/reactive-lib.mdx b/docs/legacy/reactive-lib.mdx new file mode 100644 index 0000000..10b60e0 --- /dev/null +++ b/docs/legacy/reactive-lib.mdx @@ -0,0 +1,356 @@ +--- +title: Reactive Library +sidebar_position: 7 +description: Reference for the Reactive Library — abstract contracts and interfaces for building Reactive Contracts. +slug: /legacy/reactive-library +hide_title: true +--- + +import CronTable from "../../src/components/cron-table"; + +![Reactive Library](./img/reactive-lib.jpg) + +## Overview + +[Reactive Library](https://github.com/Reactive-Network/reactive-lib) provides abstract contracts and interfaces for building Reactive Contracts. The library includes components for subscriptions, callbacks, payments, and system contract interaction. + +Install the library in your Foundry project: + +```bash +forge install Reactive-Network/reactive-lib +``` + +## Abstract Contracts + +### AbstractCallback + +[AbstractCallback](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractCallback.sol) extends `AbstractPayer.sol` and provides callback authorization for Reactive Contracts. + +The contract initializes: + +- `rvm_id` — authorized ReactVM identifier +- `vendor` — callback proxy address + +The `rvmIdOnly` modifier restricts functions to the authorized ReactVM. + +```solidity +modifier rvmIdOnly(address _rvm_id) { + require(rvm_id == address(0) || rvm_id == _rvm_id, 'Authorized RVM ID only'); + _; +} +``` + +The constructor sets the deploying ReactVM as the authorized `rvm_id` and registers the callback proxy as an authorized payment sender. + +```solidity +constructor(address _callback_sender) { + rvm_id = msg.sender; + vendor = IPayable(payable(_callback_sender)); + addAuthorizedSender(_callback_sender); +} +``` + +### AbstractPausableReactive + +[AbstractPausableReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractPausableReactive.sol) extends `AbstractReactive.sol` and provides pausable event subscriptions. + +Subscriptions are defined using the `Subscription` struct, which specifies chain ID, contract address, and event topics. + +The contract provides: + +- `pause()` — unsubscribes all pausable subscriptions +- `resume()` — restores subscriptions + +Access is restricted to the contract owner. + +The constructor sets the deployer as the owner. + +```solidity +constructor() { + owner = msg.sender; +} +``` + +The `pause()` function unsubscribes all subscriptions returned by `getPausableSubscriptions()`: + +```solidity +function pause() external rnOnly onlyOwner { + require(!paused, 'Already paused'); + Subscription[] memory subscriptions = getPausableSubscriptions(); + for (uint256 ix = 0; ix != subscriptions.length; ++ix) { + service.unsubscribe( + subscriptions[ix].chain_id, + subscriptions[ix]._contract, + subscriptions[ix].topic_0, + subscriptions[ix].topic_1, + subscriptions[ix].topic_2, + subscriptions[ix].topic_3 + ); + } + paused = true; +} +``` + +The `resume()` function restores the same subscriptions: + +```solidity +function resume() external rnOnly onlyOwner { + require(paused, 'Not paused'); + Subscription[] memory subscriptions = getPausableSubscriptions(); + for (uint256 ix = 0; ix != subscriptions.length; ++ix) { + service.subscribe( + subscriptions[ix].chain_id, + subscriptions[ix]._contract, + subscriptions[ix].topic_0, + subscriptions[ix].topic_1, + subscriptions[ix].topic_2, + subscriptions[ix].topic_3 + ); + } + paused = false; +} +``` + +### AbstractPayer + +[AbstractPayer](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractPayer.sol) provides payment and debt-settlement functionality for Reactive Contracts. + +Features include: + +- Authorized payment senders +- Vendor debt settlement +- Direct contract funding + +The `authorizedSenderOnly` modifier restricts payment initiation to authorized senders. + +```solidity +modifier authorizedSenderOnly() { + require(senders[msg.sender], 'Authorized sender only'); + _; +} +``` + +The contract provides: + +- `pay()` — transfers funds to the authorized sender +- `coverDebt()` — settles outstanding vendor debt + +```solidity +function pay(uint256 amount) external authorizedSenderOnly { + _pay(payable(msg.sender), amount); +} + +function coverDebt() external { + uint256 amount = vendor.debt(address(this)); + _pay(payable(vendor), amount); +} + +function _pay(address payable recipient, uint256 amount) internal { + require(address(this).balance >= amount, 'Insufficient funds'); + if (amount > 0) { + (bool success,) = payable(recipient).call{value: amount}(new bytes(0)); + require(success, 'Transfer failed'); + } +} +``` + +Authorized senders are managed with: + +```solidity +function addAuthorizedSender(address sender) internal { + senders[sender] = true; +} + +function removeAuthorizedSender(address sender) internal { + senders[sender] = false; +} +``` + +The contract accepts direct transfers: + +```solidity +receive() virtual external payable { +} +``` + +### AbstractReactive + +[AbstractReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractReactive.sol) is the base contract for Reactive Contracts. It extends `AbstractPayer.sol` and implements `IReactive.sol`, providing access to the Reactive Network system contract and subscription service. + +The contract defines two execution modes: + +- `vmOnly` — ReactVM execution +- `rnOnly` — Reactive Network execution + +These modes ensure functions run in the appropriate environment. + +The constructor initializes the system contract as both the payment vendor and subscription service, and authorizes it for payment operations. + +```solidity +constructor() { + vendor = service = SERVICE_ADDR; + addAuthorizedSender(address(SERVICE_ADDR)); + detectVm(); +} +``` + +Execution mode is determined automatically using `detectVm()`, which checks whether the system contract is deployed. + +```solidity +function detectVm() internal { + uint256 size; + // solhint-disable-next-line no-inline-assembly + assembly { size := extcodesize(0x0000000000000000000000000000000000fffFfF) } + vm = size == 0; +} +``` + +## Interfaces + +### IPayable + +[IPayable](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IPayable.sol) defines payment and debt-query functionality for Reactive Contracts. + +- `receive()` — accepts direct payments +- `debt()` — returns the outstanding debt of a contract + +```solidity +interface IPayable { + receive() external payable; + + function debt(address _contract) external view returns (uint256); +} +``` + +### IPayer + +[IPayer](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IPayer.sol) defines a minimal interface for initiating payments and receiving funds. + +- `pay()` — initiates a payment +- `receive()` — accepts direct transfers + +```solidity +interface IPayer { + function pay(uint256 amount) external; + + receive() external payable; +} +``` + +### IReactive + +[IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol) defines the core interface for Reactive Contracts. It extends `IPayer.sol` and provides event notifications and the execution entry point. + +The `LogRecord` struct contains event data delivered to the contract. + +```solidity +struct LogRecord { + uint256 chain_id; + address _contract; + uint256 topic_0; + uint256 topic_1; + uint256 topic_2; + uint256 topic_3; + bytes data; + uint256 block_number; + uint256 op_code; + uint256 block_hash; + uint256 tx_hash; + uint256 log_index; +} +``` + +The `Callback` event is emitted when a Reactive contract triggers a callback transaction. + +```solidity +event Callback( + uint256 indexed chain_id, + address indexed _contract, + uint64 indexed gas_limit, + bytes payload +); +``` + +The `react()` function processes event notifications. + +```solidity +function react(LogRecord calldata log) external; +``` + +### ISubscriptionService + +[ISubscriptionService](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/ISubscriptionService.sol) defines functions for managing event subscriptions. It extends `IPayable.sol` and allows Reactive Contracts to subscribe to or unsubscribe from event logs. + +The `subscribe()` function registers a subscription with the specified event criteria. + +```solidity +function subscribe( + uint256 chain_id, + address _contract, + uint256 topic_0, + uint256 topic_1, + uint256 topic_2, + uint256 topic_3 +) external; +``` + +The `unsubscribe()` function removes a subscription matching the specified criteria. + +```solidity +function unsubscribe( + uint256 chain_id, + address _contract, + uint256 topic_0, + uint256 topic_1, + uint256 topic_2, + uint256 topic_3 +) external; +``` + +### ISystemContract + +[ISystemContract](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/ISystemContract.sol) combines the functionality of `IPayable.sol` and `ISubscriptionService.sol`. It represents the Reactive Network system contract interface used for payments and subscription management. + +```solidity +import './IPayable.sol'; +import './ISubscriptionService.sol'; + +interface ISystemContract is IPayable, ISubscriptionService { +} +``` + +## System Contract + +Reactive Network operations are handled by three core contracts: + +[System Contract](https://github.com/Reactive-Network/system-smart-contracts/blob/main/src/SystemContract.sol): + +- Handles payments for Reactive Contracts +- Manages contract access control (whitelist/blacklist) +- Emits cron events for periodic triggers + +[Callback Proxy](https://github.com/Reactive-Network/system-smart-contracts/blob/main/src/CallbackProxy.sol): + +- Delivers callback transactions to destination contracts +- Manages deposits, reserves, and debts +- Restricts callbacks to authorized Reactive Contracts +- Calculates callback gas costs and kickbacks + +[AbstractSubscriptionService](https://github.com/Reactive-Network/system-smart-contracts/blob/main/src/AbstractSubscriptionService.sol): + +- Manages event subscriptions +- Supports filtering by chain, contract, and topics +- Supports wildcard matching via `REACTIVE_IGNORE` +- Emits subscription update events + +### CRON Functionality + +The `SystemContract` provides a cron mechanism for time-based automation by emitting events at fixed block intervals. Reactive Contracts can subscribe to these events to implement scheduled execution without polling or external automation. + +Only authorized validator root addresses can call `cron()`. Each call to `cron()` emits one or more `Cron` events depending on the divisibility of the current block number. Larger intervals produce less frequent events. + +Each `Cron` event contains a single parameter: + +- `number` — the current block number + + diff --git a/docs/legacy/reactive-mainnet.mdx b/docs/legacy/reactive-mainnet.mdx new file mode 100644 index 0000000..da2b6ac --- /dev/null +++ b/docs/legacy/reactive-mainnet.mdx @@ -0,0 +1,93 @@ +--- +title: Reactive Mainnet / Lasna Testnet +sidebar_position: 6 +description: RPC endpoints, chain IDs, and faucet instructions for Reactive Mainnet and Lasna Testnet. +slug: /legacy/reactive-mainnet +hide_title: true +--- + +import MainnetButton from "../../src/components/mainnet-button"; +import LasnaButton from "../../src/components/lasna-button"; + +![Mainnet Testnet Image](./img/mainnet-testnet.jpg) + +## Overview + +Reactive Mainnet is the production network for Reactive Contracts. Lasna Testnet provides a testing environment for development and experimentation before mainnet deployment. + +:::info[System Contract] +Reactive Mainnet and Lasna Testnet share the same system contract address: +`0x0000000000000000000000000000000000fffFfF` +::: + +## Reactive Mainnet + +Network parameters: + +* **Network Name:** Reactive Mainnet +* **RPC URL:** https://mainnet-rpc.rnk.dev/ +* **Chain ID:** 1597 +* **Currency Symbol:** REACT +* **Block Explorer:** https://reactscan.net/ + + + +
+ +## Get Testnet REACT + +### Reactive Faucet + +To obtain **testnet REACT (lREACT)**, send **ETH** to one of the faucet contracts: + +```json +Ethereum Sepolia: `0x9b9BB25f1A81078C544C829c5EB7822d747Cf434` + +Base Sepolia: `0x2afaFD298b23b62760711756088F75B7409f5967` +``` + +Exchange rate: **1 ETH → 100 lREACT**. + +Transfers can be made using MetaMask or any Ethereum-compatible wallet. + +:::info[Important] +Do **not** send more than **5 ETH** per transaction. + +- Maximum sent: **5 ETH** +- Maximum received: **500 lREACT** + +Amounts above 5 ETH are **lost** and will not generate additional lREACT. +::: + +### ReacDEFI Swap + +You can swap ETH for lREACT using [ReacDEFI](https://reacdefi.app/markets#testnet-faucet): + +1. Choose the amount of **lREACT** +2. Connect a Sepolia or Base Sepolia wallet +3. Confirm the transaction + +### Terminal Request + +You can request lREACT by calling `request(address)` on a faucet contract: + +```bash +cast send 0x9b9BB25f1A81078C544C829c5EB7822d747Cf434 --rpc-url $ETHEREUM_SEPOLIA_RPC --private-key $ETHEREUM_SEPOLIA_PRIVATE_KEY "request(address)" $CONTRACT_ADDR --value 0.1ether +``` + +```bash +cast send 0x2afaFD298b23b62760711756088F75B7409f5967 --rpc-url $BASE_SEPOLIA_RPC --private-key $BASE_SEPOLIA_PRIVATE_KEY "request(address)" $CONTRACT_ADDR --value 0.1ether +``` + +## Lasna Testnet + +Network parameters: + +* **Network Name:** Reactive Lasna +* **RPC URL:** https://lasna-rpc.rnk.dev/ +* **Chain ID:** 5318007 +* **Currency Symbol:** lREACT +* **Block Explorer:** https://lasna.reactscan.net + + + diff --git a/docs/legacy/reactvm.md b/docs/legacy/reactvm.md new file mode 100644 index 0000000..9b610f0 --- /dev/null +++ b/docs/legacy/reactvm.md @@ -0,0 +1,62 @@ +--- +title: ReactVM +sidebar_position: 4 +description: Learn about ReactVM, the execution environment where Reactive Contracts process event logs and execute event-driven automation across chains. +slug: /legacy/reactvm +hide_title: true +--- + +![ReactVM Image](img/rvm.jpg) + +## 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. + +## 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. + +### 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: + +- **ReactVM State** — updated automatically when subscribed events occur +- **Reactive Network State** — updated when EOAs call contract functions + +Both instances share the same bytecode but operate independently. + +For example, in a governance contract: + +- Vote counts may be maintained in ReactVM state +- Administrative actions such as `pause()` may exist in the Reactive Network state + +Most automation logic runs inside ReactVM. diff --git a/docs/legacy/rnk-rpc-methods.md b/docs/legacy/rnk-rpc-methods.md new file mode 100644 index 0000000..48a9310 --- /dev/null +++ b/docs/legacy/rnk-rpc-methods.md @@ -0,0 +1,901 @@ +--- +title: RNK RPC Methods +sidebar_position: 10 +description: Learn about Reactive Network's Geth version RPC methods used for interaction with Reactive nodes and ReactVMs. +slug: /legacy/rnk-rpc-methods +hide_title: true +--- + +![RNK RPC Methods](img/rnk-rpc-methods.jpg) + +## Overview + +This page documents **Reactive-specific JSON-RPC methods** available in Reactive Network’s (RNK) Geth version. Use them to inspect **ReactVM activity** (transactions, logs, code, storage), and to query network metadata like subscribers, filters, and origin-chain stats. + +:::tip[Ethereum RPC Methods] +Reactive Network supports standard [Geth RPC methods](https://geth.ethereum.org/docs/interacting-with-geth/rpc). This page lists RNK extensions only. +::: + +## rnk_getTransactionByHash + +Returns a ReactVM transaction by RVM ID and transaction hash. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID associated with the transaction. +2. **txHash**: `DATA`, 32 Bytes — The hash of the transaction to retrieve. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getTransactionByHash", + "params": [ + "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following fields: + +- **hash** (`string`): The transaction hash. +- **number** (`string`): The transaction number (hex-encoded). +- **time** (`uint64`): The timestamp of when the transaction occurred. +- **root** (`string`): The Merkle root associated with the transaction. +- **limit** (`uint32`): The maximum gas limit set for the transaction. +- **used** (`uint32`): The gas used by the transaction. +- **type** (`uint8`): The transaction type (0 for `Legacy`, 1 for `AccessList`, 2 for `DynamicFee`, 3 for `Blob`, 4 for `SetCode`). +- **status** (`uint8`): The status of the transaction (1 for `Success`, 0 for `Failure`). +- **from** (`string`): The transaction initiator. +- **to** (`string`): The recipient address. +- **createContract** (`bool`): Indicates whether a contract was created during this transaction. +- **sessionId** (`uint64`): The block number where the transaction is located (hex-encoded). +- **refChainId** (`uint32`): The origin chain ID. +- **refTx** (`string`): The hash of the origin chain transaction that triggered this one. +- **refEventIndex** (`uint32`): The origin chain event opcode (0 for `LOG0`, 1 for `LOG1`, 2 for `LOG2`, 3 for `LOG3`, 4 for `LOG4`). +- **data** (`string`): The encoded transaction data in hexadecimal format. +- **rData** (`string`): Additional response data in hexadecimal format (if any). + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "hash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", + "number": "0x9", + "time": 1753427529, + "root": "0x8df166bb5c9843696457dbdc5ab20ca1ab9acdd8703b6f1fd1f51766f34fad7d", + "limit": 900000, + "used": 47429, + "type": 2, + "status": 1, + "from": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "to": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", + "createContract": false, + "sessionId": 109252, + "refChainId": 11155111, + "refTx": "0x52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f5", + "refEventIndex": 328, + "data": "0x0d152c2c00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000aa36a7000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a00000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000086da6000000000000000000000000000000000000000000000000000000000000000034570ac2a3bbfa2809982e69218a745aa83e1bff79b54e2a2ce10e5d6d4c5c00a52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f50000000000000000000000000000000000000000000000000000000000000148000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000003e8", + "rData": "0x" + } +} +``` + +## rnk_getTransactionByNumber + +Returns a ReactVM transaction by RVM ID and transaction number. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID associated with the transaction. +2. **txNumber**: `HEX` — The sequence number of the transaction to retrieve. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getTransactionByNumber", + "params": [ + "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "0x9" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following fields: + +- **hash** (`string`): The transaction hash. +- **number** (`string`): The transaction number (hex-encoded). +- **time** (`uint64`): The timestamp of when the transaction occurred. +- **root** (`string`): The Merkle root associated with the transaction. +- **limit** (`uint32`): The maximum gas limit set for the transaction. +- **used** (`uint32`): The gas used by the transaction. +- **type** (`uint8`): The transaction type (0 for `Legacy`, 1 for `AccessList`, 2 for `DynamicFee`, 3 for `Blob`, 4 for `SetCode`). +- **status** (`uint8`): The status of the transaction (1 for `Success`, 0 for `Failure`). +- **from** (`string`): The transaction initiator. +- **to** (`string`): The recipient address. +- **createContract** (`bool`): Indicates whether a contract was created during this transaction. +- **sessionId** (`uint64`): The block number where the transaction is located (hex-encoded). +- **refChainId** (`uint32`): The origin chain ID. +- **refTx** (`string`): The hash of the origin chain transaction that triggered this one. +- **refEventIndex** (`uint32`): The origin chain event opcode (0 for `LOG0`, 1 for `LOG1`, 2 for `LOG2`, 3 for `LOG3`, 4 for `LOG4`). +- **data** (`string`): The encoded transaction data in hexadecimal format. +- **rData** (`string`): Additional response data in hexadecimal format (if any). + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "hash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", + "number": "0x9", + "time": 1753427529, + "root": "0x8df166bb5c9843696457dbdc5ab20ca1ab9acdd8703b6f1fd1f51766f34fad7d", + "limit": 900000, + "used": 47429, + "type": 2, + "status": 1, + "from": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "to": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", + "createContract": false, + "sessionId": 109252, + "refChainId": 11155111, + "refTx": "0x52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f5", + "refEventIndex": 328, + "data": "0x0d152c2c00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000aa36a7000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a00000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000086da6000000000000000000000000000000000000000000000000000000000000000034570ac2a3bbfa2809982e69218a745aa83e1bff79b54e2a2ce10e5d6d4c5c00a52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f50000000000000000000000000000000000000000000000000000000000000148000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000003e8", + "rData": "0x" + } +} +``` + +## rnk_getTransactionLogs + +Returns the logs emitted by a ReactVM transaction number. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID for which transaction logs are being queried. +2. **txNumber**: `HEX` — The transaction number for which logs are requested. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getTransactionLogs", + "params": [ + "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", + "0x9" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an array of objects with the following fields: + +- **txHash** (`string`): The transaction hash. +- **address** (`string`): The contract address that generated the transaction. +- **topics** (`string[]`): An array of indexed event topics. + - **topics[0]**: The event signature hash. + - **topics[1]**: The first indexed parameter (if applicable). + - **topics[2]**: The second indexed parameter (if applicable). + - **topics[3]**: The third indexed parameter (if applicable). +- **data** (`string`): The non-indexed event data in hexadecimal format. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": [ + { + "txHash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", + "address": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", + "topics": [ + "0x8dd725fa9d6cd150017ab9e60318d40616439424e2fade9c1c58854950917dfc", + "0x0000000000000000000000000000000000000000000000000000000000aa36a7", + "0x000000000000000000000000fc2236a0d3421473676c4c422046fbc4f1afdffe", + "0x00000000000000000000000000000000000000000000000000000000000f4240" + ], + "data": "0x000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000a42f90252d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce00000000000000000000000000000000000000000000000000000000000003e800000000000000000000000000000000000000000000000000000000" + } + ] +} +``` + +## rnk_getHeadNumber + +Returns the latest transaction number for a given ReactVM. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID for which the latest transaction number is requested. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getHeadNumber", + "params": [ + "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following field: + +- **result** (`string`): the latest transaction number (hex-encoded). + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": "0x9" +} +``` + +## rnk_getTransactions + +Returns a range of transactions from a given starting number. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The ReactVM ID for which transactions are being retrieved. +2. **from**: `HEX` — The starting transaction number. +3. **limit**: `HEX` — The maximum number of transactions to retrieve. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getTransactions", + "params": [ + "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", + "0x9", + "0x1" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following fields: + +- **hash** (`string`): The transaction hash. +- **number** (`string`): The transaction number (hex-encoded). +- **time** (`uint64`): The timestamp of when the transaction occurred. +- **root** (`string`): The Merkle root associated with the transaction. +- **limit** (`uint32`): The maximum gas limit set for the transaction. +- **used** (`uint32`): The gas used by the transaction. +- **type** (`uint8`): The transaction type (0 for `Legacy`, 1 for `AccessList`, 2 for `DynamicFee`, 3 for `Blob`, 4 for `SetCode`). +- **status** (`uint8`): The status of the transaction (1 for `Success`, 0 for `Failure`). +- **from** (`string`): The transaction initiator. +- **to** (`string`): The recipient address. +- **createContract** (`bool`): Indicates whether a contract was created during this transaction. +- **sessionId** (`uint64`): The block number where the transaction is located (hex-encoded). +- **refChainId** (`uint32`): The origin chain ID. +- **refTx** (`string`): The hash of the origin chain transaction that triggered this one. +- **refEventIndex** (`uint32`): The origin chain event opcode (0 for `LOG0`, 1 for `LOG1`, 2 for `LOG2`, 3 for `LOG3`, 4 for `LOG4`). +- **data** (`string`): The encoded transaction data in hexadecimal format. +- **rData** (`string`): Additional response data in hexadecimal format (if any). + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": [ + { + "hash": "0xe32b9f60321f7a83ef9dda5daf8cf5b2f5cd523156ee484f417d62d84d1e3044", + "number": "0x9", + "time": 1753427529, + "root": "0x8df166bb5c9843696457dbdc5ab20ca1ab9acdd8703b6f1fd1f51766f34fad7d", + "limit": 900000, + "used": 47429, + "type": 2, + "status": 1, + "from": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "to": "0x6ba34385d9018cfa3341db62b68b5a55839fe71f", + "createContract": false, + "sessionId": 109252, + "refChainId": 11155111, + "refTx": "0x52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f5", + "refEventIndex": 328, + "data": "0x0d152c2c00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000aa36a7000000000000000000000000c156ad2846d093e0ce4d31cf6d780357e9675dce8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a00000000000000000000000065a9b8b03a2ef50356104cb594ba2c91223973de00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000180000000000000000000000000000000000000000000000000000000000086da6000000000000000000000000000000000000000000000000000000000000000034570ac2a3bbfa2809982e69218a745aa83e1bff79b54e2a2ce10e5d6d4c5c00a52daf0ff44c50da56024f02530ba70fcf653ad11dadb1788b24b20fc824520f50000000000000000000000000000000000000000000000000000000000000148000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000003e8", + "rData": "0x" + } + ] +} +``` + +## rnk_getRnkAddressMapping + +Returns the ReactVM ID associated with a Reactive Network contract address. + +#### Parameters + +1. **reactNetworkContrAddr**: `DATA`, 20 Bytes — The address of the Reactive Network contract for which the RVM ID is being requested. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getRnkAddressMapping", + "params": [ + "0xc3e185561D2a8b04F0Fcd104A562f460D6cC503c" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following field: + +- **rvmId** (`string`): The unique identifier of the RVM associated with the given contract. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a" + } +} +``` + +## rnk_getStat + +Returns aggregated statistics per origin chain. + +#### Parameters + +This method does not require any input parameters. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getStat", + "params": [], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following fields: + +- **chainId** (`object`): The statistics for a specific origin chain. + - **txCount** (`uint64`): The total number of transactions processed from this origin chain. + - **eventCount** (`uint64`): The total number of events emitted from this origin chain. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "origin": { + "11155111": { + "txCount": 20807136, + "eventCount": 60122691 + }, + "43113": { + "txCount": 1244787, + "eventCount": 4929280 + }, + "5318007": { + "txCount": 160035, + "eventCount": 169908 + }, + "80002": { + "txCount": 450072, + "eventCount": 1786648 + }, + "84532": { + "txCount": 14266438, + "eventCount": 122218657 + }, + "97": { + "txCount": 3787433, + "eventCount": 9384761 + } + } + } +} +``` + +## rnk_getVms + +Returns information about all known ReactVMs. + +#### Parameters + +This method does not require any input parameters. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getVms", + "params": [], + "id": 1 +}' | jq +``` + +#### Response + +Returns a list of active RVMs with the following fields: + +- **rvmId** (`string`): The unique identifier of the RVM. +- **lastTxNumber** (`string`): The last transaction number executed by this RVM (hex-encoded). +- **contracts** (`uint32`): The number of contracts associated with this RVM. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": [ + { + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "lastTxNumber": "0x9", + "contracts": 4 + }, + { + "rvmId": "0xfe5a45db052489cbc16d882404bcfa4f6223a55e", + "lastTxNumber": "0x2", + "contracts": 1 + }, + { + "rvmId": "0x49abe186a9b24f73e34ccae3d179299440c352ac", + "lastTxNumber": "0x2d6", + "contracts": 1 + }, + { + "rvmId": "0x941b727ad8acf020558ce58cd7cb65b48b958db1", + "lastTxNumber": "0x7", + "contracts": 3 + }, + { + "rvmId": "0xc1d48a9173212567bd358e40c50bfe131a9fabf1", + "lastTxNumber": "0x3c", + "contracts": 28 + } + ] +} +``` + +## rnk_getVm + +Returns information about a specific ReactVM. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The unique identifier of the RVM for which information is requested. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getVm", + "params": ["0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a"], + "id": 1 +}' | jq +``` + +#### Response + +Returns an object with the following fields: + +- **rvmId** (`string`): The unique identifier of the RVM. +- **lastTxNumber** (`string`): The last transaction number executed by this RVM (hex-encoded). +- **contracts** (`uint32`): The number of contracts created by this RVM. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "lastTxNumber": "0x9", + "contracts": 4 + } +} +``` + +## rnk_getSubscribers + +Returns subscriptions associated with a given ReactVM. + +#### Parameters + +1. **rvmId**: `DATA`, 20 Bytes — The unique identifier of the RVM for which subscriber information is requested. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getSubscribers", + "params": ["0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a"], + "id": 1 +}' | jq +``` + +#### Response + +Returns a list of RVM-related contract events with the following fields: + +- **uid** (`string`): The unique identifier of the subscription. +- **chainId** (`uint32`): The blockchain ID of the subscribed contract. +- **contract** (`string`): The address of the subscribed contract on the origin chain. +- **topics** (`array`): An array of event topics (some may be `null` if not indexed). +- **rvmId** (`string`): The unique identifier of the RVM. +- **rvmContract** (`string`): The address of the RVM contract handling this subscription. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": [ + { + "uid": "7d45d863e45da3a7e60d2cc5bdd7088f", + "chainId": 11155111, + "contract": "0xe1bac3039ea58fee2abce7a8cbcc4b0c8ad030c5", + "topics": [ + "0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1", + null, + null, + null + ], + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "rvmContract": "0xc3e185561d2a8b04f0fcd104a562f460d6cc503c" + }, + { + "uid": "d979ded638e32915f59ae9bfb3b70e6c", + "chainId": 11155111, + "contract": "0x7acbd40c79da73b671d47618135486eef39ec6e3", + "topics": [ + "0x9996f0dd09556ca972123b22cf9f75c3765bc699a1336a85286c7cb8b9889c6b", + null, + null, + null + ], + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "rvmContract": "0xc3e185561d2a8b04f0fcd104a562f460d6cc503c" + }, + { + "uid": "62968b91e4122e0c03a08f38b31a1ae4", + "chainId": 11155111, + "contract": "0x16102fe2caa2610a99beaa5f4fb6e230825b1096", + "topics": [ + "0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1", + null, + null, + null + ], + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "rvmContract": "0x2afafd298b23b62760711756088f75b7409f5967" + } + ] +} +``` + +## rnk_getCode + +Retrieves the deployed contract bytecode for a given ReactVM at a specific state. + +#### Parameters + +1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. +2. **contract** `DATA`, 20 bytes — The Reactive contract address. +3. **txNumberOrHash** `HEX | TAG` — Specifies the state at which the contract code is retrieved. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getCode", + "params": [ + "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", + "0xA79933a054c8Ad29ae55bEe769Cd9d8228F03520", + "0x22" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns the bytecode of a contract: + +- **bytecode** (`string`) — The contract bytecode in hexadecimal format. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": "0x60806040526004361061007e575f3560e01c80638456cb591161004d5780638456cb591461010757806396f90b451461011d578063995e4b9814610147578063c290d6911461017157610085565b806303ac52b314610089578063046f7da2146100b3578063...efb147864736f6c634300081c0033", + +} +``` + +## rnk_getStorageAt + +Returns the value stored at a given 32-byte storage key for a contract inside a specific ReactVM, evaluated at a chosen state. + +#### Parameters + +1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. +2. **address**: `DATA`, 20 bytes — The address of the contract from which to retrieve the storage value. +3. **hexKey**: `DATA`, 32 bytes — The hexadecimal key for which the storage value is being queried. +4. **txNumberOrHash**: `HEX | TAG` — Specifies the block number or hash at which the storage value is queried. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getStorageAt", + "params": [ + "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", + "0xA79933a054c8Ad29ae55bEe769Cd9d8228F03520", + "0x0000000000000000000000000000000000000000000000000000000000000002", + "0xb707d1ddcea3fce0a966fde10f412b4c9cdedf99c67a470a7bbcb2407e1c8bcc" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns the storage value: + +**result** (`string`): A hexadecimal string representing the storage data. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": "0x000000000000000000000000a7d9aa89cbcd216900a04cdc13eb5789d643176a" +} +``` + +## rnk_call + +Runs a read-only EVM call against a contract inside a ReactVM at a chosen state (no transaction is created). + +#### Parameters + +1. **rvmId**: `DATA`, 20 bytes — The unique identifier of the RVM. +2. **args**: `OBJECT` — The transaction arguments, including the contract method and parameters. Should include: + - `to`: `DATA`, 20 bytes — The address of the contract. + - `data`: `DATA` — The call data, representing the method and parameters. + - `from`: `DATA`, 20 bytes, (optional) — The address from which the call is simulated. If omitted, the simulation assumes the call is made from an empty address (0x000...). + - `gas`: `HEX`, (optional) — The maximum amount of gas allowed for the simulation. If omitted, a default value is used. + - `gasPrice`: `HEX`, (optional) — The price of gas (in RVM-specific units) for the simulation. + - `value`: `HEX`, (optional) — The amount of tokens (e.g., Ether) to send along with the call. For non-payable functions, this should be 0. +3. **txNumberOrHash**: `HEX | TAG` — Specifies the block number or hash to use for simulating the call. Accepts either a block number (`HEX`) or a tag (`"latest"`, `"earliest"`, `"pending"`). + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_call", + "params": [ + "0xA7D9AA89cbcd216900a04Cdc13eB5789D643176a", + { + "to": "0xA79933a054c8Ad29ae55bEe769Cd9d8228F03520", + "data": "0x96f90b45" + }, + "latest" + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns the result of the simulated call: + +**result** (`string`): The simulated result of the contract call, returned as a hexadecimal string. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": "0x0000000000000000000000000000000000000000000000000000000000027a94" +} +``` + +## rnk_getBlockRvms + +Returns the ReactVMs that produced at least one ReactVM transaction in a given Reactive Network block, plus per-RVM counters. + +#### Parameters + +1. **blockN**: `uint64` – The block number for which to retrieve the RVM history. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getBlockRvms", + "params": [ + 109252 + ], + "id": 1 +}' | jq +``` + +#### Response + +Returns an array of objects representing RVMs that were active in the given block. Each object contains: + +- **rvmId** (`string`): The unique identifier of each RVM. +- **headTxNumber** (`string`): The transaction with the greatest number in the session (hex-encoded). +- **prevRnkBlockId** (`uint64`): The previous block number in which the RVM session was active. +- **txCount** (`uint32`): The total number of transactions in the current RVM session. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": [ + { + "rvmId": "0xa7d9aa89cbcd216900a04cdc13eb5789d643176a", + "headTxNumber": "0x9", + "prevRnkBlockId": 109244, + "txCount": 1 + } + ] +} +``` + +## rnk_getFilters + +Lists all active log filters (subscriptions) currently registered on Reactive Network. + +#### Parameters + +This method does not require any input parameters. + +#### cURL + +```bash +curl --location 'https://lasna-rpc.rnk.dev/' \ +--header 'Content-Type: application/json' \ +--data '{ + "jsonrpc": "2.0", + "method": "rnk_getFilters", + "params": [], + "id": 1 +}' | jq +``` + +#### Response + +Returns an array of filter objects. Each filter object contains the following fields: + +- **uid** (`string`): The unique identifier for the filter. +- **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. +- **active** (`bool`): Indicates whether the subscription/filter is active. + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": [ + { + "Uid": "4603da7efc5d1b77f7fa5b0bfd949d6c", + "ChainId": 11155111, + "Contract": "0x1e8db093a0cc38302f5822a451809bfd692ff695", + "Topics": [ + "0x8cabf31d2b1b11ba52dbb302817a3c9c83e4b2a5194d35121ab1354d69f6a4cb", + null, + null, + null + ], + "Configs": [ + { + "Contract": "0xac9163487ca9c5189766706595cbef9b75c1c8e9", + "RvmId": "0xc1d48a9173212567bd358e40c50bfe131a9fabf1", + "Active": true + } + ] + }, + { + "Uid": "b91cf2f05464d578896164d4e6c0c854", + "ChainId": 11155111, + "Contract": "0x5e3eeda090eea783af9ee8d81147d9417bb97b38", + "Topics": [ + "0x8cabf31d2b1b11ba52dbb302817a3c9c83e4b2a5194d35121ab1354d69f6a4cb", + null, + null, + null + ], + "Configs": [ + { + "Contract": "0xe3cf3d848557974d3abf8e7c15c3a534187f1c6f", + "RvmId": "0xc1d48a9173212567bd358e40c50bfe131a9fabf1", + "Active": true + } + ] + }, + { + "Uid": "0fce746e0305e2fc2e425735ea71a52f", + "ChainId": 11155111, + "Contract": "0x0102e0a1792b8805f16b6ec27978f6898b865475", + "Topics": [ + "0x9bffe4738606691ddfa5e5d28208b6ef74537676b39ddb9854b7854a62df0692", + null, + null, + null + ], + "Configs": [ + { + "Contract": "0xe4d4b0c2f8502a98e68c6f0ef2483214c106fd82", + "RvmId": "0x941b727ad8acf020558ce58cd7cb65b48b958db1", + "Active": true + } + ] + } + ] +} +``` \ No newline at end of file diff --git a/docs/legacy/subscriptions.md b/docs/legacy/subscriptions.md new file mode 100644 index 0000000..111c000 --- /dev/null +++ b/docs/legacy/subscriptions.md @@ -0,0 +1,359 @@ +--- +title: Subscriptions +sidebar_position: 9 +description: Learn how Reactive Contracts subscribe to events and configure event-driven automation. +slug: /legacy/subscriptions +hide_title: true +--- + +![Subscriptions Image](img/subscriptions.jpg) + +## Overview + +Subscriptions define which events Reactive Contracts (RCs) listens to. RCs subscribe to events through the system contract by specifying: + +- Origin chain ID +- Contract address +- Event topics + +When a matching event is detected, the contract's `react()` function is triggered. + +Subscriptions can be configured: + +- During deployment (constructor) +- Dynamically via callbacks + +## Subscription Basics + +Subscriptions are created by calling `subscribe()` on the system contract. This is typically done inside the contract constructor. Since contracts deploy both on Reactive Network (RNK) and inside a ReactVM (where the system contract doesn't exist), the constructor must avoid calling `subscribe()` inside ReactVM. + +[IReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/IReactive.sol), [AbstractReactive](https://github.com/Reactive-Network/reactive-lib/blob/main/src/abstract-base/AbstractReactive.sol), and [ISystemContract](https://github.com/Reactive-Network/reactive-lib/blob/main/src/interfaces/ISystemContract.sol) should be implemented. Here's a subscription example in the constructor from the [Basic Demo Reactive Contract](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/basic/BasicDemoReactiveContract.sol): + +```solidity +uint256 public originChainId; +uint256 public destinationChainId; +uint64 private constant GAS_LIMIT = 1000000; + +address private callback; + +constructor( + address _service, + uint256 _originChainId, + uint256 _destinationChainId, + address _contract, + uint256 _topic_0, + address _callback +) payable { + service = ISystemContract(payable(_service)); + + originChainId = _originChainId; + destinationChainId = _destinationChainId; + callback = _callback; + + if (!vm) { + service.subscribe( + originChainId, + _contract, + _topic_0, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE + ); + } +} +``` + +Subscriptions filter events using: + +- Chain ID +- Contract address +- Topics 0–3 + +:::info[Filtering Criteria] +Reactive Network provides filtering criteria based on the origin contract's chain ID, address, and all four topics. +::: + +## Wildcards & Matching + +### REACTIVE_IGNORE + +`REACTIVE_IGNORE` is a predefined wildcard value that matches any topic value: + +```json +0xa65f96fc951c35ead38878e0f0b7a3c744a6f5ccc1476b313353ce31712313ad +``` + +### Zero Values + +Wildcards can also be specified with: + +- `uint256(0)` → any chain ID +- `address(0)` → any contract + +**At least one parameter must be specific.** + +### Subscription Examples + +#### All Events From One Contract + +```solidity +service.subscribe( + CHAIN_ID, + 0x7E0987E5b3a30e3f2828572Bb659A548460a3003, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE +); +``` + +#### Specific Event Type + +Example: Uniswap V2 Sync events + +```solidity +service.subscribe( + CHAIN_ID, + address(0), + 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE +); +``` + +#### Specific Contract and Event + +```solidity +service.subscribe( + CHAIN_ID, + 0x7E0987E5b3a30e3f2828572Bb659A548460a3003, + 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE +); +``` + +#### Multiple Subscriptions + +Call `subscribe()` multiple times: + +```solidity +if (!vm) { + + service.subscribe( + originChainId, + _contract1, + _topic0, + REACTIVE_IGNORE, + REACTIVE_IGNORE, + REACTIVE_IGNORE + ); + + service.subscribe( + originChainId, + _contract2, + REACTIVE_IGNORE, + _topic1, + REACTIVE_IGNORE, + REACTIVE_IGNORE + ); +} +``` + +### Unsubscribing + +Subscriptions can be removed through the system contract. + +Export the wildcard constant: + +```bash +export REACTIVE_IGNORE=0xa65f96fc951c35ead38878e0f0b7a3c744a6f5ccc1476b313353ce31712313ad +``` + +Example: + +```bash +cast send \ + --rpc-url $REACTIVE_RPC \ + --private-key $REACTIVE_PRIVATE_KEY \ + $SYSTEM_CONTRACT_ADDR \ + "unsubscribeContract(address,uint256,address,uint256,uint256,uint256,uint256)" \ + $REACTIVE_CONTRACT_ADDR \ + $ORIGIN_CHAIN_ID \ + $ORIGIN_CONTRACT \ + $TOPIC_0 \ + $REACTIVE_IGNORE \ + $REACTIVE_IGNORE \ + $REACTIVE_IGNORE +``` + +### Subscription Limitations + +#### Equality Matching Only + +Subscriptions support exact matches only. + +Not supported: + +- `<` or `>` +- Ranges +- Bitwise filters + +#### Complex Criteria Sets + +Each subscription defines **one set of matching criteria**. + +Not supported: + +- Disjunctions (OR conditions) +- Multiple criteria sets within one subscription + +Workaround: + +- Use multiple `subscribe()` calls +- May lead to a **large number of subscriptions** + +#### No Global Subscriptions + +Not allowed: + +- All chains +- All contracts +- All events on a chain + +#### Duplicate Subscriptions + +Duplicate subscriptions are allowed but behave as one subscription. + +Each `subscribe()` transaction still costs gas. + +## Dynamic Subscriptions + +Subscriptions can be created or removed dynamically based on incoming events. + +Subscription management is performed through the system contract, which is accessible only from Reactive Network (RNK). The ReactVM instance of a contract can't call the system contract directly, so dynamic subscription changes must be performed through callback transactions. + +The typical flow is: + +1. An event is received in the ReactVM. +2. The contract decides whether to subscribe or unsubscribe. +3. A `Callback` event is emitted. +4. Reactive Network (RNK) executes the subscription change. + +### Subscribing & Unsubscribing + +These functions run on the Reactive Network contract instance and modify subscriptions through the system contract. The example below is based on the [ApprovalListener.sol](https://github.com/Reactive-Network/reactive-smart-contract-demos/blob/main/src/demos/approval-magic/ApprovalListener.sol) contract from the [Approval Magic demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/approval-magic). + +```solidity +// Methods specific to Reactive Network contract instance + +function subscribe(address rvm_id, address subscriber) + external + rnOnly + callbackOnly(rvm_id) + { + service.subscribe( + SEPOLIA_CHAIN_ID, + address(0), + APPROVAL_TOPIC_0, + REACTIVE_IGNORE, + uint256(uint160(subscriber)), + REACTIVE_IGNORE + ); + } + +function unsubscribe(address rvm_id, address subscriber) + external + rnOnly + callbackOnly(rvm_id) + { + service.unsubscribe( + SEPOLIA_CHAIN_ID, + address(0), + APPROVAL_TOPIC_0, + REACTIVE_IGNORE, + uint256(uint160(subscriber)), + REACTIVE_IGNORE + ); + } +``` + +Parameters: + +- **rvm_id** — ReactVM identifier (injected automatically) +- **subscriber** — address to subscribe or unsubscribe + +Operations: + +- **subscribe** — registers a subscriber for `APPROVAL_TOPIC_0` +- **unsubscribe** — removes a subscriber from `APPROVAL_TOPIC_0` + +### react() Logic + +The `react()` function processes incoming events and emits callbacks when subscription changes are required. + +```solidity +// Methods specific to ReactVM contract instance +function react(LogRecord calldata log) external vmOnly { + + if (log.topic_0 == SUBSCRIBE_TOPIC_0) { + + bytes memory payload = abi.encodeWithSignature( + "subscribe(address,address)", + address(0), + address(uint160(log.topic_1)) + ); + + emit Callback( + REACTIVE_CHAIN_ID, + address(this), + CALLBACK_GAS_LIMIT, + payload + ); + + } else if (log.topic_0 == UNSUBSCRIBE_TOPIC_0) { + + bytes memory payload = abi.encodeWithSignature( + "unsubscribe(address,address)", + address(0), + address(uint160(log.topic_1)) + ); + + emit Callback( + REACTIVE_CHAIN_ID, + address(this), + CALLBACK_GAS_LIMIT, + payload); + + } else { + + (uint256 amount) = abi.decode(log.data, (uint256)); + + bytes memory payload = abi.encodeWithSignature( + "onApproval(address,address,address,address,uint256)", + address(0), + address(uint160(log.topic_2)), + address(uint160(log.topic_1)), + log._contract, + amount + ); + + emit Callback( + SEPOLIA_CHAIN_ID, + address(approval_service), + CALLBACK_GAS_LIMIT, + payload + ); + } +} +``` + +Event handling: + +- **Subscribe event** → emits a callback that creates a subscription +- **Unsubscribe event** → emits a callback that removes a subscription +- **Other events** → emit callbacks that trigger application logic + +Callbacks are executed by Reactive Network after the event is processed. diff --git a/docs/legacy/testing.md b/docs/legacy/testing.md new file mode 100644 index 0000000..3ebff0b --- /dev/null +++ b/docs/legacy/testing.md @@ -0,0 +1,456 @@ +--- +title: Testing with Foundry +sidebar_position: 12 +description: Test Reactive Contracts locally with Foundry using reactive-test-lib. Simulate event-driven, cross-chain smart contract execution with forge test without using a testnet. +slug: /legacy/testing +hide_title: true +--- + +![Testing Image](img/testing.jpg) + +## Overview + +[Reactive Test Lib](https://github.com/Reactive-Network/reactive-test-lib) allows to simulate the full Reactive Network's lifecycle from triggering events to callback execution. You can test Reactive contracts locally with Foundry. The library replaces the system contract, ReactVM, and callback proxies with mock implementations that run entirely within `forge test`. + +Supported features: + +- Event subscriptions (including wildcards) +- Full `react()` pipeline +- Cross-chain and same-chain callbacks +- Same-chain callbacks via `SERVICE_ADDR` (`0x0000000000000000000000000000000000fffFfF`) +- Cron-based triggers +- Multi-step workflows (bridges, confirmations) +- Automatic chain ID resolution + +Install: + +```bash +forge install Reactive-Network/reactive-test-lib +``` + +Add to `remappings.txt`: + +```json +reactive-test-lib/=lib/reactive-test-lib/src/ +``` + +## Mocked Components + +The library replaces three Reactive components with local mocks: + +| Real Component | Mock | Purpose | +|-----------------|----------------------|------------------------------------------------------| +| System Contract | `MockSystemContract` | Subscription registry with wildcard matching | +| ReactVM | `ReactiveSimulator` | Event delivery and `react()` invocation | +| Callback Proxy | `MockCallbackProxy` | Cross-chain callback execution with RVM ID injection | + +Chain IDs are purely logical. All execution takes place on a single EVM instance. + +## Getting Started + +### Base Test Contract + +Inherit from `ReactiveTest`: + +```solidity +import "reactive-test-lib/base/ReactiveTest.sol"; +import {CallbackResult} from "reactive-test-lib/interfaces/IReactiveInterfaces.sol"; + +contract MyReactiveTest is ReactiveTest { + function setUp() public override { + super.setUp(); + // deploy contracts here + } +} +``` + +`super.setUp()` performs the following setup: + +1. Deploys `MockSystemContract` and writes its code to `SERVICE_ADDR` (`0x0000000000000000000000000000000000fffFfF`) +2. Deploys `MockCallbackProxy` for cross-chain callback execution +3. Sets `rvmId` to `address(this)` +4. Sets `reactiveChainId` to `REACTIVE_CHAIN_ID` (`0x512512`) + +Any contract that calls `subscribe()` on `SERVICE_ADDR` in its constructor (including contracts extending `AbstractReactive`) will register subscriptions automatically. + +### Deploying Contracts + +Set up your Origin, Reactive, and Callback contracts in `setUp()`. Pass `address(proxy)` to anything that extends `AbstractCallback`: + +```solidity +// Origin contract (L1) — emits events that trigger reactions +origin = new BasicDemoL1Contract(); + +// Callback contract — pass proxy as the authorized callback sender +cb = new BasicDemoL1Callback(address(proxy)); + +// Reactive contract — constructor calls subscribe() on MockSystemContract +rc = new BasicDemoReactiveContract( +address(sys), // system contract +SEPOLIA_CHAIN_ID, // origin chain +SEPOLIA_CHAIN_ID, // destination chain +address(origin), // contract to watch +uint256(keccak256("Received(address,address,uint256)")), // topic_0 +address(cb) // callback target +); +``` + +### Running a Reactive Cycle + +`triggerAndReact()` executes a full cycle in a single call: emit event, match subscription, invoke react(), and execute callbacks. + +```solidity +function testCallbackFires() public { + CallbackResult[] memory results = triggerAndReact( + address(origin), + abi.encodeWithSignature("receive()"), + SEPOLIA_CHAIN_ID + ); + + assertCallbackCount(results, 1); + assertCallbackSuccess(results, 0); + assertCallbackEmitted(results, address(cb)); +} +``` + +Use `triggerAndReactWithValue()` to send ETH with the triggering call: + +```solidity +CallbackResult[] memory results = triggerAndReactWithValue( + address(origin), + abi.encodeWithSignature("receive()"), + 0.01 ether, + SEPOLIA_CHAIN_ID +); +``` + +## Basic Demo + +The [Basic Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/basic) shows the simplest Reactive contract pattern. An origin contract emits an event when receiving ETH. The Reactive contract subscribes to that event and, if the value exceeds a threshold, emits a callback to the destination contract. + +```solidity +contract BasicDemoTest is ReactiveTest { + BasicDemoL1Contract origin; + BasicDemoReactiveContract rc; + BasicDemoL1Callback cb; + + uint256 constant SEPOLIA = 11155111; + + function setUp() public override { + super.setUp(); + + origin = new BasicDemoL1Contract(); + cb = new BasicDemoL1Callback(address(proxy)); + rc = new BasicDemoReactiveContract( + address(sys), + SEPOLIA, + SEPOLIA, + address(origin), + uint256(keccak256("Received(address,address,uint256)")), + address(cb) + ); + } + + function testCallbackAboveThreshold() public { + // 0.01 ETH > 0.001 threshold — callback fires + CallbackResult[] memory results = triggerAndReactWithValue( + address(origin), + "", + 0.01 ether, + SEPOLIA + ); + + assertCallbackCount(results, 1); + assertCallbackSuccess(results, 0); + } + + function testNoCallbackBelowThreshold() public { + // 0.0005 ETH < 0.001 threshold — no callback + CallbackResult[] memory results = triggerAndReactWithValue( + address(origin), + "", + 0.0005 ether, + SEPOLIA + ); + + assertNoCallbacks(results); + } +} +``` + +## Uniswap Stop Orders + +The [Uniswap V2 Stop Order Demo](https://github.com/Reactive-Network/reactive-smart-contract-demos/tree/main/src/demos/uniswap-v2-stop-order) monitors a pair's reserves and triggers a swap when the price crosses a threshold. The Reactive contract subscribes to `Sync` events. + +Testing requires a mock pair contract that emits the event: + +```solidity +contract StopOrderTest is ReactiveTest { + MockUniswapPair pair; + UniswapDemoStopOrderReactive rc; + UniswapDemoStopOrderCallback stopOrder; + + uint256 constant SEPOLIA = 11155111; + uint256 constant SYNC_TOPIC = 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1; + + function setUp() public override { + super.setUp(); + + pair = new MockUniswapPair(); + stopOrder = new UniswapDemoStopOrderCallback(address(proxy)); + rc = new UniswapDemoStopOrderReactive( + address(pair), + address(stopOrder), + client, + true, // token0 + 1e18, // coefficient + 500 // threshold + ); + enableVmMode(address(rc)); + } + + function testStopOrderTriggeredBelowThreshold() public { + // Simulate a sync event with reserves that push price below threshold + CallbackResult[] memory results = triggerAndReact( + address(pair), + abi.encodeWithSignature("emitSync(uint112,uint112)", 1000, 100), + SEPOLIA + ); + + assertCallbackCount(results, 1); + assertCallbackEmitted(results, address(stopOrder)); + } +} +``` + +:::info[vmOnly Modifier] +If the Reactive contract uses `vmOnly` on `react()`, call `enableVmMode(address(rc))` after deployment. This sets the internal `vm` flag to `true`. Without this call, `react()` reverts with `"VM only"`. +::: + +## Self-Callbacks + +Some Reactive contracts emit callbacks targeting themselves on Reactive Network rather than an external chain. The REACT Bridge follows this pattern where `ReactiveBridge` emits: + +```solidity +emit Callback(reactive_chain_id, address(this), GAS_LIMIT, payload); +``` + +In production, `SERVICE_ADDR` delivers these callbacks. The bridge authorizes it in its constructor: + +```solidity +constructor(...) AbstractCallback(address(SERVICE_ADDR)) { ... } +``` + +The simulator handles this automatically. When a `Callback` event's `chain_id` matches `reactiveChainId`, the callback is delivered via `vm.prank(SERVICE_ADDR)` instead of the proxy. The `authorizedSenderOnly` modifier passes correctly. + +```solidity +contract SelfCallbackTest is ReactiveTest { + ReactiveBridge rb; + + function setUp() public override { + super.setUp(); + rb = new ReactiveBridge( + reactiveChainId, + SEPOLIA, + address(bridge), + ... + ); + enableVmMode(address(rb)); + } + + function testSelfCallbackDelivered() public { + // The reactive bridge's deliver() and returnMessage() are self-callbacks. + // They are delivered via SERVICE_ADDR, not the proxy. + CallbackResult[] memory results = triggerFullCycleWithValue( + address(rb), + abi.encodeWithSignature("bridge(uint256,address)", 123, recipient), + 1 ether, + reactiveChainId, + 20 + ); + + // Self-callbacks succeed because msg.sender == SERVICE_ADDR + for (uint256 i = 0; i < results.length; i++) { + assertCallbackSuccess(results, i); + } + } +} +``` + +## Multi-Step Protocols + +Complex protocols such as [REACT Bridge](https://github.com/Reactive-Network/react-bridge) chain multiple Reactive cycles from a single user action: + +``` +1. ReactiveBridge.bridge() → emits SendMessage +2. react(SendMessage) → Callback to Bridge.initialMessage() +3. Bridge emits ConfirmationRequest +4. react(ConfirmationRequest) → Callback to Bridge.requestConfirmation() +5. Bridge emits Confirmation → react() → Callback to Bridge.confirm() +6. Bridge emits DeliveryConfirmation → react() → ... +``` + +`triggerAndReact()` executes only one cycle. For multi-step chains, use `triggerFullCycle()`: + +```solidity +CallbackResult[] memory results = triggerFullCycleWithValue( + address(reactiveBridge), + abi.encodeWithSignature("bridge(uint256,address)", uniqueish, recipient), + 1 ether, + reactiveChainId, + 20 // max iterations — safety limit +); +``` + +The simulator loops through the following steps: + +1. Executes the call and captures events +2. Matches events, calls `react()`, and collects callback specs +3. Executes each callback and records any new events +4. Tags new events with the callback's `chain_id` (events from a Sepolia callback become Sepolia events) +5. Feeds new events back into step 2 +6. Stops when no more callbacks are produced or `maxIterations` is reached + +All `CallbackResult` entries from every iteration are returned in a single array. + +## Chain Registry + +When contracts span multiple logical chains, each trigger requires the correct `originChainId`. The chain registry maps addresses to chain IDs, removing the need to pass chain IDs manually: + +```solidity +function setUp() public override { + super.setUp(); + + bridge = new Bridge(address(proxy), ...); + reactiveBridge = new ReactiveBridge(reactiveChainId, SEPOLIA, address(bridge), ...); + + // Register contracts with their logical chains + registerChain(address(bridge), SEPOLIA); + registerChain(address(reactiveBridge), reactiveChainId); +} +``` + +With registrations in place, the `originChainId` argument can be omitted: + +```solidity +// These resolve the chain ID from the registry automatically +CallbackResult[] memory results = triggerAndReact( + address(bridge), + abi.encodeWithSignature("bridge(uint256,address,uint256)", id, recipient, amount) +); + +CallbackResult[] memory results = triggerFullCycle( + address(reactiveBridge), + abi.encodeWithSignature("bridge(uint256,address)", id, recipient), + 20 +); +``` + +In full-cycle mode, events from callbacks are automatically tagged with destination chain IDs. The registry is primarily relevant for the initial trigger. + +## Cron Contracts + +Reactive contracts can subscribe to system cron events for periodic execution. The simulator provides `triggerCron()` to deliver synthetic cron events: + +```solidity +import {CronType} from "reactive-test-lib/interfaces/IReactiveInterfaces.sol"; +import {ReactiveConstants} from "reactive-test-lib/constants/ReactiveConstants.sol"; + +contract CronTest is ReactiveTest { + BasicCronContract rc; + + function setUp() public override { + super.setUp(); + rc = new BasicCronContract(address(sys), ReactiveConstants.CRON_TOPIC_1); + } + + function testCronTriggersCallback() public { + CallbackResult[] memory results = triggerCron(CronType.Cron1); + assertCallbackCount(results, 1); + } + + function testAdvanceBlocksAndTrigger() public { + uint256 startBlock = block.number; + CallbackResult[] memory results = advanceAndTriggerCron(100, CronType.Cron1); + + assertCallbackCount(results, 1); + assertEq(block.number, startBlock + 100); + } +} +``` + +Cron types: `Cron1` (every block), `Cron10`, `Cron100`, `Cron1000`, `Cron10000`. + +## Assertions + +`ReactiveTest` provides assertion helpers for common callback checks: + +```solidity +// Exact callback count +assertCallbackCount(results, 3); + +// Zero callbacks +assertNoCallbacks(results); + +// A specific target received a callback +assertCallbackEmitted(results, address(myCallback)); + +// Callback at index succeeded / failed +assertCallbackSuccess(results, 0); +assertCallbackFailure(results, 1); +``` + +Each `CallbackResult` contains the following fields: + +| Field | Description | +|--------------|------------------------------------------------| +| `chainId` | Destination chain ID from the `Callback` event | +| `target` | Address the callback executed on | +| `gasLimit` | Gas limit from `react()` | +| `payload` | ABI-encoded call (RVM ID already injected) | +| `success` | Whether the call succeeded | +| `returnData` | Return or revert data | + +## Mock Environment Details + +### Subscription Matching + +`MockSystemContract` supports the same wildcard rules as the production system contract: + +| Field | Wildcard | Meaning | +|--------------|-------------------|--------------| +| `chain_id` | `0` | Any chain | +| `_contract` | `address(0)` | Any contract | +| `topic_0..3` | `REACTIVE_IGNORE` | Any topic | + +### RVM ID Injection + +The production network overwrites the first 160 bits of the first callback argument with the deployer's address. Both `MockCallbackProxy` (cross-chain) and the simulator's direct delivery (same-chain) replicate this behavior. The `rvmIdOnly` modifier works correctly in tests. + +To simulate a different deployer: + +```solidity +rvmId = makeAddr("customDeployer"); +``` + +### Callback Routing + +Routing is determined by the `Callback` event's `chain_id`: + +- **Cross-chain** (`chain_id != reactiveChainId`) — delivered through `MockCallbackProxy` +- **Same-chain** (`chain_id == reactiveChainId`) — delivered via `vm.prank(SERVICE_ADDR)` + +### vmOnly and rnOnly + +`MockSystemContract` is deployed to `SERVICE_ADDR`, so `detectVm()` sets `vm = false` (it detects code at that address). As a result: + +- `rnOnly` functions work in constructors, `subscribe()` calls execute normally +- `vmOnly` functions need `enableVmMode(address(rc))` after deployment + +## Additional Notes + +- **Single EVM**: All execution takes place on a single EVM instance. Chain IDs are logical identifiers only. +- **No reactive-lib dependency**: The test lib reimplements ABI-compatible interfaces. Contracts continue importing `reactive-lib` as usual. +- **Requirements**: Solidity ≥ 0.8.20, Foundry with `vm.recordLogs()`, `reactive-lib` v0.2.0+. + +[Reactive Test Lib on GitHub →](https://github.com/Reactive-Network/reactive-test-lib) diff --git a/docusaurus.config.js b/docusaurus.config.js index f82eaff..9c54b07 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -114,9 +114,9 @@ const config = { }, { type: "docSidebar", - sidebarId: "education", + sidebarId: "legacy", position: "left", - label: "Education", + label: "Legacy", }, { type: "docSidebar", @@ -189,11 +189,11 @@ const config = { redirects: [ { from: "/education/getting-started/", - to: "/education/introduction/" + to: "/" }, { from: "/education/getting-started/reactive-smart-contracts", - to: "/education/introduction/reactive-contracts" + to: "/" }, { from: "/docs/data-origins-and-destinations", @@ -201,7 +201,7 @@ const config = { }, { from: "/category/getting-started", - to: "/education/introduction/" + to: "/" }, { from: "/system-contract", @@ -233,11 +233,11 @@ const config = { }, { from: "/education/introduction/reactive-smart-contracts", - to: "/education/introduction/reactive-contracts" + to: "/" }, { from: "/education/module-1/reactive-smart-contracts", - to: "/education/module-1/reactive-contracts" + to: "/" }, { from: "/architecture/reactive-smart-contracts", @@ -259,6 +259,78 @@ const config = { from: "/docs/kopli-testnet", to: "/reactive-mainnet" }, + { + from: "/education/introduction", + to: "/" + }, + { + from: "/education/introduction/reactive-contracts", + to: "/" + }, + { + from: "/education/introduction/prerequisites", + to: "/" + }, + { + from: "/education/module-1", + to: "/" + }, + { + from: "/education/module-1/reactive-contracts", + to: "/" + }, + { + from: "/education/module-1/how-events-work", + to: "/" + }, + { + from: "/education/module-1/react-vm", + to: "/" + }, + { + from: "/education/module-1/how-subscriptions-work", + to: "/" + }, + { + from: "/education/module-1/how-oracles-work", + to: "/" + }, + { + from: "/education/module-2", + to: "/" + }, + { + from: "/education/module-2/how-uniswap-works", + to: "/" + }, + { + from: "/education/module-2/basic-reactive-functions", + to: "/" + }, + { + from: "/education/use-cases", + to: "/" + }, + { + from: "/education/use-cases/use-case-1", + to: "/" + }, + { + from: "/education/use-cases/remix-ide-demo", + to: "/" + }, + { + from: "/education/use-cases/use-case-3", + to: "/" + }, + { + from: "/education/use-cases/use-case-2", + to: "/" + }, + { + from: "/education/glossary", + to: "/" + } ] } ] diff --git a/sidebars.js b/sidebars.js index a066ede..ad739f7 100644 --- a/sidebars.js +++ b/sidebars.js @@ -19,10 +19,10 @@ const sidebars = { dirName: "docs" } ], - education: [ + legacy: [ { type: "autogenerated", - dirName: "education", + dirName: "legacy", }, ], contacts: [ diff --git a/src/components/lasna-button.js b/src/components/lasna-button.js index 464f8dc..eb601be 100644 --- a/src/components/lasna-button.js +++ b/src/components/lasna-button.js @@ -34,14 +34,14 @@ export const AddToWeb3Provider = async () => { method: 'wallet_addEthereumChain', params: [{ chainId: CHAIN_ID, - rpcUrls: ['https://lasna-rpc.rnk.dev/'], + rpcUrls: ['https://lasna-omni-rpc.rnk.dev/'], chainName: 'Reactive Lasna', nativeCurrency: { name: 'REACT', symbol: 'REACT', decimals: 18, }, - blockExplorerUrls: ['https://lasna.reactscan.net/'], + blockExplorerUrls: ['https://lasna-omni.reactscan.net/'], }], }); } catch (e) { diff --git a/src/components/origins-destinations-testnet.js b/src/components/origins-destinations-testnet.js index 996dc1b..d647854 100644 --- a/src/components/origins-destinations-testnet.js +++ b/src/components/origins-destinations-testnet.js @@ -42,7 +42,7 @@ const TestnetChainTable = () => { chain: 'Reactive Lasna', chainId: 5318007, explorer: 'https://lasna.reactscan.net', - callbackAddress: '0x0000000000000000000000000000000000fffFfF', + callbackAddress: '0x8888888888888888888888888888888888888888', rpcUrl: 'https://lasna-rpc.rnk.dev/', origin: true, destination: true diff --git a/src/components/origins-destinations.js b/src/components/origins-destinations.js index a66fc56..b33951f 100644 --- a/src/components/origins-destinations.js +++ b/src/components/origins-destinations.js @@ -87,7 +87,7 @@ const MainnetChainTable = () => { chain: 'Reactive', chainId: 1597, explorer: 'https://reactscan.net', - callbackAddress: '0x0000000000000000000000000000000000fffFfF', + callbackAddress: '0x8888888888888888888888888888888888888888', rpcUrl: 'https://mainnet-rpc.rnk.dev/', origin: true, destination: true