Skip to Content
Welcome

Reactor Developer Documentation

Reactor is a secure, low-cost, and developer-friendly messaging protocol enabling seamless communication across Web2 and Web3 systems. Built on the Internet Computer (IC), Reactor supports cross-chain messaging, Web2 integrations, automation, and randomness — all through a unified interface.

Reactor empowers developers to build cross-environment applications without the high cost and increased complexity of traditional blockchain integration tools.

Key Features

  • 100% Onchain - Messages stay onchain providing end to end security and transparency.
  • Level 5 Cross-Chain Security - Risk management provides enhanced defense-in-depth strategies.
  • Cross-Chain Messaging — Interact between blockchains with one interface.
  • Web2 ↔ Web3 Integration — Push and pull data across web and blockchain based applications.
  • Automation — Schedule or event-triggered message execution.
  • Random Number Generation — On-demand randomness for games, lotteries, etc.
  • Consistent Pricing — Zero node operator incentives allow for low per message pricing on almost all chains.
  • Scalable Infrastructure — Cloud-level performance to connect blockchains and existing systems together.

Use Cases

Cross-Chain Loyalty

Verify NFT ownership across chains to issue access passes or rewards.

Token Snapshot + Storage

Query token balances and save to AWS S3 for accounting/compliance.

Hybrid Apps

Build applications that span onchain logic and traditional infrastructure (cloud and on-prem).

Webhooks to Smart Contracts

Push events from Web2 systems (like Stripe or Twilio) to smart contracts.

Decentralized Gaming

Use Reactor’s RNG and automation to enable game logic without centralized servers.

Architecture

Reactor Core

Deployed on the Internet Computer (IC), the Core performs:

  • HTTP requests to Web2 services
  • Cross-Chain message routing
  • Scheduled tasks
  • Random number generation
  • Receives messages from the web

Reactor Gateway

Smart contracts on supported blockchains:

  • Sends messages to Core
  • Receives responses from Core
  • Forwards requested data to the specified smart contracts

Reactor Fee Manager

Smart contracts on supported blockchains:

  • Manages fee configurations for destinations
  • Maintains the set of available payment tokens on a chain
  • Calculates the fee for a message

Reactor Sentinel

Provides risk management through analysis and auditing of messages flowing through Reactor:

  • Inspects all messages to determine risk profile
  • Apply additional custom logic on messages
  • Mitigate security attacks and other adverse actions

ID

The ID is a deterministic, audit-friendly identifier that binds each Reactor message to its origin and data. By recomputing it from the recorded origin and data, you get tamper-evident cryptographic assurance that the message delivered to the destination matches what was originally produced at the source. This lets you trace messages across systems, safely handle retries and replay protection, and verify integrity onchain and offchain. Combined with Reactor’s 100% onchain execution model, messages are processed end-to-end without relying on any offchain components such as relayer networks, cross-chain bridge validator sets, or separate external oracle validator sets.

EVM-Sourced Messages

For messages originating from an EVM chain:

  • source_chain_name – canonical chain name string from the Supported Names registry
  • source_tx_hash – 32-byte transaction hash
  • source_tx_index – EVM transactionIndex (position of the tx within its block)
  • log_index – index of the emitted log within the transaction receipt

We construct id_bytes as:

id_bytes =
    source_tx_hash               // 32 bytes
 || uint64_be(source_tx_index)   // 8 bytes, big-endian
 || utf8(source_chain_name)      // variable length, no separator
 || uint64_be(log_index)         // 8 bytes, big-endian
 
 id = keccak256(id_bytes)

Web-Sourced Messages

For messages originating from a web request (via send_web_reactor_message):

  • domain_separator – identifier that distinguishes the source of the message
  • request_id – client-supplied idempotency key (e.g. UUID)
  • source_address – opaque source developer/app identifier
  • action – Reactor action name (e.g. web_message, chain_message, generate_random_numbers)
  • destination_name – canonical destination chain/service name
  • destination_address – destination contract or endpoint identifier
  • payload_hash – 32-byte Keccak-256 hash of the request payload

We construct id_bytes as:

id_bytes =
    "REACTOR_WEB_MSG_V1"               // domain separator
 || utf8(client_request_id)            // variable length, no separator
 || utf8(source_address)               // variable length, no separator
 || utf8(action)                       // variable length, no separator
 || utf8(lowercase(destination_name))  // variable length, no separator
 || utf8(destination_address)          // variable length, no separator
 || payload_hash                       // 32 bytes
 
 id = keccak256(id_bytes)
Last updated on
Sending Messages