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

Message ID

The Message 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_tx_hash – 32-byte transaction hash
  • source_tx_index – EVM transactionIndex (position of the tx within its block)
  • source_chain_id – canonical Reactor chain id string
  • log_index – index of the emitted log within the transaction receipt

Each field is encoded as:

  • uint32_be(field_length_in_bytes) followed by field_bytes

We construct message_id_bytes as:

message_id_bytes =
    uint32_be(32)
 || source_tx_hash
 || uint32_be(8)
 || uint64_be(source_tx_index)
 || uint32_be(byte_length(utf8(source_chain_id)))
 || utf8(source_chain_id)
 || uint32_be(8)
 || uint64_be(log_index)
 
 id = keccak256(message_id_bytes)

Web-Sourced Messages

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

  • domain_separator – REACTOR_WEB_MSG_V1
  • source_address – Reactor-issued account source address
  • destination_chain_id – canonical chain id resolved from lowercase(destination_name)
  • destination_address – destination contract or endpoint identifier
  • action – Reactor action name (e.g. web_message, chain_message, generate_random_numbers)
  • payload_hash – 32-byte Keccak-256 hash of the request payload bytes
  • request_id – client-supplied idempotency key (e.g. UUID)

Encoding rules:

  • The domain separator is appended as raw UTF-8 bytes with no length prefix.
  • Every subsequent field is encoded as uint32_be(field_length_in_bytes) followed by field_bytes.

We construct message_id_bytes as:

message_id_bytes =
    utf8("REACTOR_WEB_MSG_V1")
 || uint32_be(byte_length(utf8(source_address)))
 || utf8(source_address)
 || uint32_be(byte_length(utf8(destination_chain_id)))
 || utf8(destination_chain_id)
 || uint32_be(byte_length(utf8(destination_address)))
 || utf8(destination_address)
 || uint32_be(byte_length(utf8(action)))
 || utf8(action)
 || uint32_be(32)
 || payload_hash
 || uint32_be(byte_length(utf8(request_id)))
 || utf8(request_id)
 
 id = keccak256(message_id_bytes)
Last updated on
Sending Messages