Skip to main content

Lesson 7: Implementing Basic Reactive Functions

Overview​

In this lesson, we’ll go through the Reactive Smart Contract (RSC) specifically designed for the Uniswap V2 platform, aimed at executing stop orders based on predefined conditions. By the end of this lesson, you’ll know:

  • That RSCs are pretty similar to Ethereum smart contracts and thus easy to understand.
  • What each part of the stop-order reactive smart contract means.
  • How this reactive smart contract is executed and what it does.

Contract​

The contract UniswapDemoStopOrderReactive.sol is set up to monitor liquidity pool events on Uniswap V2, namely tracking the Sync events to determine when the conditions for a stop order are met. When these conditions are triggered, it executes a callback transaction on the Ethereum blockchain to perform the stop order.

Key Components​

Event Declarations​

Event Declarations: Events like Callback, Subscribed, AboveThreshold, CallbackSent, and Done are used for logging and tracking the contract's operations on the blockchain.

// SPDX-License-Identifier: GPL-2.0-or-later

pragma solidity >=0.8.0;

import '../../IReactive.sol';
import '../../SubscriptionService.sol';

struct Reserves {
uint112 reserve0;
uint112 reserve1;
}

// Reactive: 0x0c189A26E0AD06f8E12179280d9e8fB0EE1648C2

contract UniswapDemoStopOrderReactive {
event Callback(
uint256 indexed chain_id,
address indexed _contract,
uint64 indexed gas_limit,
bytes payload
);

    event Subscribed(
        address indexed service_address,
        address indexed _contract,
        uint256 indexed topic_0
    );

    event VM();

    event AboveThreshold(
        uint112 indexed reserve0,
        uint112 indexed reserve1,
        uint256 coefficient,
        uint256 threshold
    );

    event CallbackSent();

    event Done();

Contract Variables​

UNISWAP_V2_SYNC_TOPIC_0 and STOP_ORDER_STOP_TOPIC_0 are constants representing the topics for Uniswap's Sync events and the contract's Stop events, respectively. CALLBACK_GAS_LIMIT is the gas limit set for the callback transaction. Variables like triggered, done, pair, stop_order, client, token0, coefficient, and threshold store the state and configuration of the stop order.

    uint256 private constant UNISWAP_V2_SYNC_TOPIC_0 = 0x1c411e9a96e071241c2f21f7726b17ae89e3cab4c78be50e062b03a9fffbbad1;
    uint256 private constant STOP_ORDER_STOP_TOPIC_0 = 0x9996f0dd09556ca972123b22cf9f75c3765bc699a1336a85286c7cb8b9889c6b;

    uint64 private constant CALLBACK_GAS_LIMIT = 1000000;

    /**
     * Indicates whether this is the instance of the contract deployed to ReactVM.
     */
    bool private vm;

    // State specific to ReactVM instance of the contract.

    bool private triggered;
    bool private done;
    address private pair;
    address private stop_order;
    address private client;
    bool private token0;
    uint256 private coefficient;
    uint256 private threshold;

Contract Logic​

Constructor​

The constructor sets up the initial state of the contract and subscribes to the necessary events from the Uniswap V2 pair _pair and the stop-order contract _stop_order using the SubscriptionService.sol.

    constructor(
        address service_address,
        address _pair,
        address _stop_order,
        address _client,
        bool _token0,
        uint256 _coefficient,
        uint256 _threshold
    ) {
        triggered = false;
        done = false;
        SubscriptionService service = SubscriptionService(service_address);
        pair = _pair;
        bytes memory payload = abi.encodeWithSignature("subscribe(address,uint256)", pair, UNISWAP_V2_SYNC_TOPIC_0);
        (bool subscription_result,) = address(service).call(payload);
        if (!subscription_result) {
            vm = true;
            emit VM();
        } else {
            emit Subscribed(service_address, pair, UNISWAP_V2_SYNC_TOPIC_0);
        }
        stop_order = _stop_order;
        bytes memory payload_2 = abi.encodeWithSignature("subscribe(address,uint256)", stop_order, STOP_ORDER_STOP_TOPIC_0);
        (bool subscription_result_2,) = address(service).call(payload_2);
        if (!subscription_result_2) {
            vm = true;
            emit VM();
        } else {
            emit Subscribed(service_address, stop_order, STOP_ORDER_STOP_TOPIC_0);
        }
        client = _client;
        token0 = _token0;
        coefficient = _coefficient;
        threshold = _threshold;
    }

react() Function​

The react() function is the core of the contract's logic. It is triggered by events on the Ethereum smart contract it is subscribed to. The function processes these events to check if the conditions for executing the stop order are met. If the event is from the stop-order contract and matches the predefined topics and addresses, the contract concludes its operation (done = true). If the event is a Sync event from the Uniswap pair, the contract checks if the current reserves meet the stop-order condition (below_threshold function). If so, it triggers the callback transaction on Ethereum to execute the stop order.

    // Methods specific to ReactVM instance of the contract.

    function react(
        uint256 chain_id,
        address _contract,
        uint256 topic_0,
        uint256 topic_1,
        uint256 topic_2,
        uint256 /* topic_3 */,
        bytes calldata data
    ) external {
        // TODO: Support for multiple dynamic orders? Not viable until we have dynamic subscriptions.
        // TODO: fix the assertions after debugging.
        //require(vm, 'ReactVM only');
        assert(!done);
        if (_contract == stop_order) {
            // TODO: Practically speaking, it's broken, because we also need to check the transfer direction.
            //       For the purposes of the demo, I'm just going to ignore that complication.
            if (
                triggered &&
                topic_0 == STOP_ORDER_STOP_TOPIC_0 &&
                topic_1 == uint256(uint160(pair)) &&
                topic_2 == uint256(uint160(client))
            ) {
                done = true;
                emit Done();
            }
        } else {
            Reserves memory sync = abi.decode(data, ( Reserves ));
            if (below_threshold(sync) && !triggered) {
                emit CallbackSent();
                bytes memory payload = abi.encodeWithSignature(
                    "stop(address,address,bool,uint256,uint256)",
                    pair,
                    client,
                    token0,
                    coefficient,
                    threshold
                );
                triggered = true;
                emit Callback(chain_id, stop_order, CALLBACK_GAS_LIMIT, payload);
            }
        }
    }

below_threshold() Function​

The below_threshold() function determines whether the current token reserves in the Uniswap pool meet the threshold conditions for executing the stop order.

    function below_threshold(Reserves memory sync) internal view returns (bool) {
        if (token0) {
            return (sync.reserve1 * coefficient) / sync.reserve0 <= threshold;
        } else {
            return (sync.reserve0 * coefficient) / sync.reserve1 <= threshold;
        }
    }

Execution Flow​

  • Initialization: Upon deployment, the contract subscribes to the necessary events from the Uniswap V2 pair and the stop order callback contract.

  • Event Monitoring: The contract listens for Sync events from the Uniswap pair to monitor the pool's reserve changes andStop events from the stop-order contract to track the execution of orders.

  • Stop Order Activation: When the Sync event indicates that the pool's price hits the threshold, the contract initiates the stop order through the callback function, executing a trade on Uniswap V2.

  • Completion: After the stop order is executed, the contract captures the Stop event from the stop-order contract, marking the process as complete.

In essence, this Reactive Smart Contract leverages the event-driven capabilities of the ReactVM to autonomously monitor and respond to on-chain conditions, executing predefined trading strategies on Uniswap V2 efficiently and in a decentralized manner.

Conclusion​

In this article, we’ve examined the implementation of a Reactive Smart Contract (RSC) for managing stop orders on the Uniswap V2 platform. Key takeaways include:

  • Similarity to Ethereum Smart Contracts: RSCs are conceptually similar to Ethereum smart contracts, making them accessible for those familiar with Ethereum's architecture.

  • Contract Components: We reviewed the key elements of the stop-order reactive smart contract, including event declarations, contract variables, and the logic behind the react() and below_threshold() functions.

  • Execution Flow: The contract’s lifecycle involves subscribing to relevant events, monitoring Uniswap V2 pool reserves, triggering stop orders when conditions are met, and capturing completion events to finalize the process.

For a deeper look into practical applications, explore the Uniswap Stop Order use case and consider experimenting with these concepts in your own projects. Join our Telegram group to engage with the community.