Reactor: The Onchain Connectivity Layer for Web2, Web3, and Beyond

1. Executive Summary

Reactor is a 100% onchain connectivity layer for Web2↔Web3 and cross-chain workflows. It lets applications, smart contracts, and web services trigger and coordinate actions across systems without relying on offchain relayers, separate validator networks, oracle committees, or stitched-together backend glue.

Reactor runs as a Rust canister on the Internet Computer Protocol, or ICP, with smart contracts called Gateways deployed on each supported blockchain. Reactor Core handles message orchestration and execution. Sentinel provides policy and control before execution. ReactorScan provides operational visibility into every message from source to delivery.

The integration surface is intentionally small: one API for Web2 systems and one contract-level send path for smart contracts on supported blockchains. This is a deliberate design choice. Teams can add a single blockchain-connected workflow to an existing system without a platform rewrite, then expand as their needs grow.

In the current implementation, Web2 callers use Reactor Core’s send API, while EVM contracts initiate messages through the Reactor Gateway’s send function.

The R token is Reactor’s unified cross-chain usage token, designed so users do not need to obtain and manage different native gas tokens on each supported chain.

2. The Problem: Why Current Connectivity Stacks Are Hard to Explain, Debug, and Scale

2.1 How Teams Build Cross-Environment Workflows Today

Applications that span blockchains, Web2 systems, and external services are increasingly common. A product might need to:

Trigger a CRM workflow when an onchain payment settles
Send a cross-chain message when a user action fires on one chain
Call a risk model when a DeFi position changes
Generate randomness for an onchain game

Building any of these today typically requires assembling a stack of independent services:

A bridge or cross-chain messaging protocol
One or more oracle feeds
A custom HTTP gateway or server
Backend jobs for monitoring and retry
Secret management for credentials
Custom monitoring, alerting, and reconciliation tooling

Each component introduces its own trust assumptions, operational surface, and failure modes.

2.2 The Operating Model Cost

The problem is not only that the stack is complex to build. It is also complex to operate, explain, audit, and scale.

Engineering teams absorb the cost of debugging across app and chain boundaries. Security teams must reason about multiple independent validator sets, oracle committees, and relayer operators. Finance and operations teams face unpredictable pricing across multiple vendors. Product teams move slower because every new blockchain-connected workflow requires coordinating across infrastructure layers.

This is operating model pain, not just protocol inefficiency. The workflow may function, but it becomes harder to explain to stakeholders, harder to audit for compliance, and harder to extend as requirements grow.

2.3 What Is Missing

Existing cross-chain protocols address one part of the problem well, namely chain-to-chain messaging, but they were not designed to unify Web2↔Web3 workflows or reduce the broader operating model burden. They rely on:

Offchain relayer networks that must be paid on every message
External validator or oracle committees with their own trust models
Separate integrations for each capability (cross-chain, HTTP, randomness, policy)

The result is fragmented developer experience, unpredictable pricing, and systems that are harder to audit and explain than they should be.

3. Reactor’s Thesis: Moving the Connectivity Layer Onchain

Reactor’s core thesis is that the connectivity layer itself should move onchain.

When Reactor’s routing, policy evaluation, and execution coordination run onchain, backed by ICP consensus, teams get:

Fewer external moving parts
A more auditable execution path
Deterministic routing and processing
Simpler integration surfaces
A path to policy-aware and risk-aware execution without managing separate infrastructure

In practice, this makes blockchain-connected workflows easier to add, inspect, and govern. Because Reactor is designed for incremental adoption, teams do not have to choose between their existing systems and a cleaner connectivity model. They can have both.

An important nuance is that Reactor does not eliminate all trust assumptions. Reactor’s security still depends on the correctness and security of ICP and the destination chains it connects. What Reactor avoids is a separate offchain relayer network, a separate oracle committee, and a separate validator fleet dedicated solely to Reactor’s operation. This is a meaningful reduction in external moving parts, not a claim of zero external dependencies.

What Reactor is not: Reactor is not a general-purpose bridge abstraction for every trust model, a standalone compliance suite, or a full application orchestration platform that requires replacing existing systems. It is a connectivity and execution layer designed to let teams add blockchain-connected workflows with fewer external moving parts and lower operating model complexity.

4. Reactor Design Goals

Reactor is designed around the following principles:

Full-spectrum connectivity. A single platform for chain-to-chain, Web2 to Web3, Web3 to Web2, and automation workflows, rather than a collection of separate integrations.

100% onchain connectivity and orchestration. Reactor’s routing, policy evaluation, and orchestration run as canisters on ICP without separate offchain relayer fleets.

Deterministic and auditable processing. Every message is processed in a consistent, traceable manner. The execution path can be independently verified.

Control before execution. Sentinel evaluates every message before it is executed, enforcing policy, workflow controls, and access rules.

Operational visibility. ReactorScan provides a full execution trail for every message, from source to destination. Teams can see what happened, when, and why.

Small integration surface. One API for Web2. One contract call for blockchains. Teams add one workflow at a time without rewriting what already works.

Incremental adoption. Reactor fits alongside existing systems. It does not require migration or commitment to a full platform switch.

Predictable pricing. Simple, usage-based fees that can be forecast and budgeted without multi-vendor opacity.

5. Core Architecture

5.1 Why ICP

Reactor Core and Sentinel run as canisters on the Internet Computer Protocol, or ICP.

Reactor needs a compute environment that can maintain workflow state, support timer-driven background processing, perform routing and policy logic under consensus, and interact with external systems when required. ICP provides all of these capabilities as first-class features of the platform.

This is not an arbitrary choice. ICP’s specific properties make it well-suited for what Reactor needs:

Deterministic execution with strong consensus guarantees, so routing and processing decisions are predictable and auditable.
Stable storage for message state, chain configuration, pricing data, and workflow records that persist across canister upgrades.
Timer-driven background processing for polling supported chains, processing message queues, and coordinating multistep workflow execution.
Outbound HTTP capability for making calls to Web2 services and external APIs from within the onchain environment.

From the perspective of other blockchains and Web2 services, Reactor is a neutral connectivity layer, not a chain that applications must adopt or migrate to.

5.2 Reactor Gateway

The Reactor Gateway is a smart contract deployed on each supported blockchain. It is Reactor’s onchain entry and exit point on that network.

On the source side, the Gateway:

exposes the send function that smart contracts call to initiate a Reactor message
encodes the payload, destination, and action type into a canonical Reactor message format
emits a structured event that Reactor Core monitors and ingests
collects the required message fee in a supported payment token (native gas token, R token, or wrapped native) and enforces fee sufficiency before accepting the message

On the destination side, the Gateway:

receives messages forwarded by Reactor Core after source-side integrity checks, policy evaluation, and replay protection checks have completed
validates that the incoming message corresponds to an approved Reactor execution record and has not already been executed
dispatches the payload to the target contract via a standard IReactorMessageReceiver interface
maintains execution state for retry and failure tracking

Gateway security principles:

Gateway contracts are built on standard, audited access control, pausability, and reentrancy protection patterns. Retry is explicitly permissionless when correct parameters and sufficient gas are supplied. Callers do not need elevated permissions to retry a message they originated. Fee collection and configuration are managed via defined administrative roles.

Implementation details for EVM deployments, including the event schema, role definitions, fee components, and payload size defaults, are in Appendix A.

5.3 Reactor Core

Reactor Core is the main orchestration and execution layer, running as a Rust canister on ICP.

Core is where messages are ingested, validated, routed, and executed. Its responsibilities span the full lifecycle of a Reactor message:

Message intake and routing: Monitoring supported chains for Reactor events and ingesting them into the ICP environment.
Payload integrity verification: Recomputing the payload hash on ICP and rejecting any mismatch with the hash emitted at the source.
Stable storage: Persisting message records, execution state, chain configuration, and pricing data.
Chain configuration management: Maintaining per-chain routing, gas cap, and fee parameters.
Timer-driven background processing: Polling chains for new events, processing message queues, and coordinating workflow steps without manual intervention.
Coordination with Sentinel: Passing messages to Sentinel for policy evaluation before execution.
Action execution: Coordinating the appropriate action, whether a cross-chain call, HTTP request, or randomness generation, once Sentinel approves.
Result routing: Delivering execution results to the designated destination chain or Web2 endpoint.
Idempotent execution: Ensuring that repeated processing attempts do not produce duplicate successful outcomes.
Replay protection: Tracking message IDs in persistent state to prevent malicious or accidental replay.
Logs and metrics: Generating records for ReactorScan and operational auditing.

5.4 ReactorScan

ReactorScan is Reactor’s observability and traceability layer. It is not just an explorer. It gives teams the visibility they need to inspect, monitor, and operate Reactor-connected workflows in production.

One of the most practical concerns when adopting new connectivity infrastructure is simple: what happens when something goes wrong, and can I see it? ReactorScan is the answer to that question. It provides:

Message tracing from source emission to destination execution.
Status visibility: pending, processing, executed, failed.
Retry visibility: when retries occurred and their outcomes.
Failure visibility: classifiable failure states with enough context to diagnose and resolve them.
Full execution history across all workflow steps.
Operational confidence: the ability to inspect a live production system and understand its state without guessing.

This visibility matters to engineering teams debugging failures, security teams reviewing activity, operations teams monitoring production, and compliance teams who need an audit trail.

5.5 Sentinel

Sentinel is Reactor’s onchain policy and control layer, implemented as an ICP-based canister component.

Sentinel’s role is control before execution. Before Reactor Core executes any action, Sentinel evaluates the message and returns an allow or deny decision. The Sentinel shell is complete and operational. It can accept a Reactor message during Core’s processing loop and return a true or false decision that gates execution.

Current Sentinel capabilities:

Source controls: Allow or deny messages by source address or contract.
Destination controls: Allow or deny specific destinations or action types.
Caller checks: Validate the ICP principal or caller identity for web-originated messages.
Payload constraints: Enforce size limits, format requirements, or content rules.
Workflow gating: Require specific conditions to be met before a message proceeds.
Secrets provisioning: Securely supply credentials and API keys to Reactor Core for outbound Web2 calls, without exposing them to the originating caller.

Planned extensions:

Rate limiting: Throttle message flows per source, destination, or workflow.

Sentinel is a control layer integrated into message processing, not a separate compliance product or enterprise platform. Its value is practical: teams get a single, consistent, onchain place to define and enforce rules over Reactor workflows. Those rules apply to every message that passes through, are auditable after the fact, and do not require maintaining separate policy backends.

5.6 The R Token

The R token is Reactor’s unified cross-chain usage token.

Multichain applications face a practical coordination problem. Native gas tokens must be obtained, managed, and replenished on every chain they operate on. Managing this across multiple networks adds operational overhead and treasury friction.

R reduces this friction. Users who pay in R do not need to hold and manage separate native gas tokens on each supported chain. R works as a payment token across Reactor’s supported networks.

R is used for:

Platform fees: messaging, automation, randomness, and cross-chain execution across supported chains.
Ecosystem growth: team incentives, grants, marketing campaigns, community programs, and liquidity.

R does not secure ICP’s consensus or Reactor’s execution layer. ICP’s own validator set is responsible for that. R does not represent equity in Archly Reactor Inc., profit share, or governance rights. This separation is intentional: it keeps Reactor’s security model independent of token economics, and allows the token to serve a focused, practical role.

6. Integration Model

One API for Web2. One contract call for blockchains.

This is a deliberate design choice, not an accident of simplicity. Most connectivity infrastructure requires teams to learn SDKs, configure schemas, manage multiple entry points, and coordinate across several abstractions before getting a single message through. Reactor keeps the integration surface small by design.

Applications call Reactor Core’s send API. Smart contracts call the Reactor Gateway’s send function. Both paths enter the same routing, policy, and execution pipeline.

This reduces not only coding overhead but also review and adoption overhead. Engineering teams do not need to learn multiple runtime abstractions, security teams do not need to re-evaluate several distinct integration paths, and product teams can reuse the same send model as workflows expand.

The goal is simple: adding a blockchain-connected workflow to an existing system should take hours, not weeks, and should not require rebuilding what already works.

6.1 Web2 Integration via Reactor Core’s Send API

Applications, backend systems, SaaS platforms, and internal services initiate Reactor messages by calling Reactor Core’s send API. The caller specifies the destination, action type, and payload. Routing, encoding, and fee mechanics are handled by Reactor Core.

Access is controlled using ICP principals, ensuring that only authorized callers can send messages through a given Reactor integration.

In the current implementation, Web2 callers use an authenticated send interface exposed by Reactor Core.

6.2 Smart Contract Integration via the Reactor Gateway’s Send Function

Smart contracts on supported blockchains initiate Reactor messages by calling the send function on the Reactor Gateway:


gateway.send(destinationName, destinationAddress, action, payload);

The Gateway handles payload encoding, fee collection, and event emission. The calling contract does not need to manage the details of Reactor’s message format or understand the downstream routing. This interface is currently available for EVM-compatible chains.

6.3 Receiving Messages

Contracts that receive Reactor messages implement the IReactorMessageReceiver interface. The Gateway calls this interface on the destination contract after the incoming message has passed integrity checks, Sentinel approval, and replay protection checks.

6.4 Adoption Philosophy

Start with one workflow, not a platform rewrite.

Reactor is designed to be adopted one workflow at a time, alongside existing systems. Teams do not need to migrate, replace existing infrastructure, or commit to a platform switch before they get value.

The right starting point is the workflow that is currently most painful: the one that requires the most backend glue, the most operational overhead, or the most vendor coordination. Reactor addresses that workflow first. Everything else can wait until it makes sense.

7. Workflow Types

Reactor supports several distinct workflow patterns. Each is a first-class capability within the same execution environment, not a separate integration or bolt-on product.

7.1 Web2 → Web3

An application or Web2 system calls Reactor Core’s send API to trigger an onchain action on a supported chain. This might include minting a token, updating contract state, initiating a payment, or invoking another contract action.

Representative uses:

A user action in a web application triggers a token issuance on a target chain.
A payment processor event initiates an onchain settlement.
An internal business system updates cross-chain application state.

7.2 Web3 → Web2

A smart contract emits a Reactor event on a supported chain. Reactor Core routes the message to a Web2 endpoint, triggering an action in an external system.

Representative uses:

An NFT mint triggers a CRM workflow to update a customer record.
An onchain payment event fires a billing or fulfillment webhook.
A contract condition triggers a support ticket or internal alert in an operations system.

7.3 Chain → Chain

A smart contract on one chain sends a message to a contract on a different chain. Reactor handles routing, verification, and delivery across the two chains.

Representative uses:

Cross-chain token or data transfer.
Multichain application state synchronization.
Cross-chain governance or voting coordination.

7.4 Automation and Scheduled Workflows

Reactor is not only for sending individual messages. It enables blockchain-connected workflows that fire based on events or schedules, coordinating actions across Web2 systems, contracts, and chains.

Representative workflow shapes:

App event → contract action.
Contract event → backend callback.
Chain event → webhook or downstream trigger.
Multi-step flow spanning multiple systems.
Policy-gated automation that requires Sentinel approval before proceeding.

This is one of Reactor’s most immediately useful capabilities. Teams building event-driven systems that cross the Web2 and Web3 boundary feel the value here most directly: a single platform for event intake, routing, policy checks, and action execution, instead of assembling those pieces independently.

7.5 Randomness

Reactor provides onchain random number generation as a native action type, not a separate integration.

Representative uses:

Onchain games requiring verifiable randomness.
Lotteries, raffles, and prize draws.
Randomized distribution of tokens or rewards.

Randomness is generated within the Reactor runtime and delivered to the destination as a standard Reactor message result.

8. Message Routing and Processing Flow

Every Reactor message, regardless of workflow type, follows a consistent processing path. This section describes that path from end to end.

8.1 Step-by-Step Flow

Step 1 — Entry point

An application calls Reactor Core’s send API, or a smart contract on the source chain calls the Reactor Gateway’s send function. These are the two entry paths for all Reactor messages.

Step 2 — Event emission and intake

For chain-originated messages, the Gateway encodes the payload and emits a ReactorMessage event on the source chain. Reactor Core continuously monitors supported chains for these events. When detected, Core ingests the event into the ICP environment.

For application-originated messages, the send API delivers the message directly into Reactor Core, authenticated by the caller’s ICP principal.

Step 3 — Integrity verification and message ID derivation

Reactor Core recomputes the payload hash and compares it to the hash included in the source event. Any mismatch causes the message to be rejected. For EVM-sourced messages, Core derives a deterministic message ID:


keccak256(
  source_transaction_hash ||
  source_transaction_index (big endian) ||
  chain.id (string) ||
  log_index
)

This ID is the stable, audit-friendly identity for the message throughout its lifecycle.

Step 4 — Sentinel evaluation

The message is passed to Sentinel. Sentinel applies configured policy checks, including source and destination rules, caller identity checks, payload constraints, and workflow gates, then returns an allow or deny decision. Where configured, Sentinel also supplies secrets (credentials, API keys) needed for outbound Web2 calls, without exposing them to the originating caller.

If Sentinel denies the message, execution is halted and the decision is recorded. If Sentinel approves, processing continues.

Step 5 — Action execution

Reactor Core executes the requested action:

For cross-chain calls: routing the message to the destination chain’s Gateway.
For Web2 destinations: making the outbound HTTP call to the specified endpoint.
For randomness: generating the random value within the Reactor runtime.
For automation steps: executing the next step in the configured workflow.

Step 6 — Destination delivery

After integrity checks, policy evaluation, and replay protection checks complete, the destination Gateway receives the message and dispatches it to the target contract through IReactorMessageReceiver. For Web2 destinations, the result is delivered to the specified endpoint. Execution state is recorded and replay protection is enforced.

Step 7 — Observability

The full execution path, including entry, intake, integrity checks, Sentinel decisions, action execution, and delivery, is surfaced through ReactorScan. Status, timing, and outcome are visible across every step.

8.2 Workflow Variants

The same flow applies to all workflow types, with minor variations:

Web2 → Web3: entry via Reactor Core’s send API; delivery via destination Gateway.
Web3 → Web2: entry via the source Gateway’s send function; delivery via outbound HTTP call.
Chain → Chain: entry via the source Gateway’s send function; delivery via destination Gateway on a different chain.
Randomness: entry via the source Gateway’s send function; execution is the randomness computation; delivery is the result back to the originating chain or system.
Automation: may involve multiple execution steps, each following this same pattern.

9. Message Identity and Auditability

9.1 Deterministic Message IDs

For messages originating from EVM-compatible chains, Reactor derives a deterministic message ID in Core. This ID is recomputable by any party with access to the source transaction, without depending on Reactor as the sole source of truth.

The derivation formula:


keccak256(
  source_transaction_hash ||
  source_transaction_index (big endian) ||
  chain.id (string) ||
  log_index
)

This has practical consequences for every team operating Reactor-connected workflows:

Auditability: Any party can independently verify the message ID from the source transaction.
Replay protection: A message ID is tied to a specific, unique source event. It cannot be replayed without replicating the source transaction itself.
Reconciliation: Operators can match Reactor message records against source chain events for independent verification.
Safe retries: Retry logic operates on the same message ID without risk of creating duplicate successful executions.
Traceability: The message ID is stable from the moment of source emission through to destination delivery, making it the common thread across all system logs.

9.2 Web-Originated Message Identity

For messages originating from Web2 systems through Reactor Core’s send API, Reactor binds message identity to the authorized caller principal plus a unique message record accepted by Core. Replay protection is enforced against previously accepted submissions.

Depending on integration requirements, Reactor may also persist hashed message commitments for later audit and reconciliation.

ICP principal-based access control ensures that only authorized systems can send messages through a given Reactor integration.

9.3 Traceability Through ReactorScan

Every message processed by Reactor is visible in ReactorScan with its full execution trail: source, intermediate state transitions, Sentinel decision, action execution, and destination delivery.

This makes Reactor auditable at every step, for debugging, compliance reviews, operations, and incident response.

10. Execution Safety and State Handling

10.1 Deterministic Processing

Reactor Core processes messages in a consistent, auditable manner. Given the same inputs, the same routing and execution decisions are made. This predictability is foundational to operational trust and is what makes the execution trail in ReactorScan meaningful.

10.2 Idempotent Execution

Reactor tracks execution state per message ID in persistent storage. Repeated processing of the same message, whether from retry logic or external triggers, does not produce duplicate successful outcomes where idempotence is required.

10.3 Replay Protection

Message IDs are tracked in persistent state across the system. A message that has already been executed cannot be replayed successfully. This applies to both chain-originated and web-originated messages.

10.4 Retryability

Reactor supports explicit retry for messages that have failed delivery. Retry is permissionless when the correct parameters and sufficient gas are supplied. Callers do not need elevated permissions to retry a message they originated.

Failure state is tracked per message, keyed by destination, source, action, message ID, and payload hash. This gives operators enough information to understand what failed and why before retrying.

10.5 Source Truth and Destination Execution

For chain-originated messages, the source of truth is the finalized event on the source chain. Reactor Core ingests and processes these events. Destination execution is coordinated by Core, validated by the destination Gateway, and surfaced through ReactorScan.

Reactor does not claim to prove end-to-end delivery in a zero-knowledge or cryptographic sense beyond the integrity and replay protection mechanisms described here. The execution trail is auditable and verifiable by operators with access to source and destination chain data and ReactorScan records.

11. Policy and Control with Sentinel

Sentinel applies policy checks and enforces workflow controls before Reactor Core executes any action. This is control before execution, not a post-hoc audit mechanism.

The Sentinel shell is complete and operational. During Core’s processing loop, Sentinel receives the message, applies configured policy, and returns an allow or deny decision that gates execution.

Current Sentinel capabilities:

Source controls: Allow or deny messages by source address or contract.
Destination controls: Allow or deny specific destinations or action types.
Caller checks: Validate the ICP principal or caller identity for web-originated messages.
Payload constraints: Enforce size limits, format requirements, or content rules.
Workflow gating: Require specific conditions to be met before a message proceeds.
Secrets provisioning: Supply credentials or API keys to Core for outbound Web2 calls, without exposing them to the originating caller.

Planned extensions:

Rate limiting: Throttle message flows per source, destination, or workflow.

For teams running sensitive or high-value workflows, Sentinel is the mechanism that makes Reactor governable. Instead of enforcing rules in separate backend systems or relying on caller-side logic, Sentinel applies those rules consistently at the connectivity layer, onchain, in the execution path, and visibly through ReactorScan.

12. Operational Visibility with ReactorScan

ReactorScan provides operational visibility for every message in Reactor, giving teams a clear view of status, execution, retries, failures, and history.

For each message, ReactorScan exposes:

Source: where the message originated (chain and contract, or Web2 system and caller).
Status: pending, processing, approved by Sentinel, executing, executed, or failed.
Execution steps: each processing stage with timestamps and outcomes.
Retry history: when retries occurred and their results.
Failure details: classifiable failure states with enough context to diagnose the issue.
Full execution trail: the complete record from source emission to destination delivery.

This visibility serves different stakeholders differently. Engineering teams use it to debug. Security teams use it to review activity. Operations teams use it to monitor production. Compliance teams use it as an audit trail.

When teams evaluate whether to adopt new infrastructure, a common concern is simple: what happens when something goes wrong, and will I be able to see it? ReactorScan is the direct answer to that question. Visibility lowers adoption risk.

13. Pricing and Usage Model

13.1 Pricing Philosophy

Reactor is a transaction-based infrastructure business. Its pricing model reflects that: simple, usage-based, and predictable.

For most supported chains, the representative message fee is approximately $0.10 per message, including destination gas up to a defined cap. Chains with materially higher gas costs (such as Ethereum mainnet) may be priced differently and are documented separately.

Callers pay source chain gas when submitting to the Gateway, plus the Reactor message fee. Because Reactor does not depend on separate oracle networks, relayer fleets, or dedicated external operator layers, its fee structure avoids the additional per-message payments associated with those architectures.

13.2 Fee Structure

The Gateway’s fee manager computes the per-message fee from composable components:

A base send fee
A per-byte payload fee
A caller fee
An action fee
Destination-specific and action-specific adjustments
Applicable discounts across fee classes

Accepted payment tokens include the chain’s native token, the R token, and wrapped native tokens. The fee manager and fee collection address are admin-configurable.

13.3 Predictability as a Product Property

Predictable pricing is a deliberate design goal. Teams building products on top of Reactor need to forecast infrastructure costs. Pricing that varies unpredictably across chains, vendors, and conditions creates operational drag, showing up in budget variance, finance conversations, and reluctance to expand usage.

Reactor’s cost structure, based on ICP canister execution plus destination gas and without separate offchain operator payments, makes the economics more stable and easier to model than many multi-vendor alternatives.

Exact current pricing, gas caps, and any active tiers or promotions are defined in the official Reactor pricing documentation.

14. R Token as Unified Cross-Chain Usage Token

14.1 Why a Unified Token

Multichain applications face a practical coordination problem. They need native gas tokens on every chain they operate on. Managing, bridging, and replenishing multiple gas tokens adds operational overhead and creates friction for teams that want to focus on product rather than treasury logistics.

R is designed to reduce this friction. Users who pay in R do not need to hold and manage separate native gas tokens on each supported chain. R works as a single payment token across Reactor’s supported networks.

14.2 Token Utility

R is used to:

Pay message fees for cross-chain calls, Web2↔Web3 workflows, randomness, and automation.
Fund ecosystem growth: team incentives, grants, marketing campaigns, community programs, and liquidity.

14.3 What R Is Not

R does not secure ICP consensus or Reactor’s execution layer. That responsibility lies with ICP’s own validator set. R does not represent equity in Archly Reactor Inc. It does not confer profit share or governance rights.

This separation is intentional. It keeps Reactor’s security model independent of token economics and allows R to serve a focused, practical role: unified payment and ecosystem alignment.

Token supply, allocation, and vesting schedules are detailed in Appendix B.

15. Adoption Model: Start with One Workflow

Start with one workflow, not a platform rewrite.

Reactor is not a replacement for existing systems. It is designed to fit alongside them. Teams can solve the most painful workflow first and expand only after Reactor has earned trust in production.

The practical starting point for most teams is a single workflow that is currently painful: one that requires backend glue, custom retry logic, multiple vendor integrations, or cross-chain coordination that is hard to monitor. Reactor addresses that workflow first, without touching anything else.

From there, teams can expand: additional workflow types, additional chains, additional Sentinel policies. At no stage is a platform rewrite required. The integration surface stays small: one API for Web2 and one contract call for blockchains. Adding a second workflow does not mean learning a new system. It means making a second call through the same integration pattern.

This approach matters for adoption decisions. Evaluating new infrastructure carries internal cost: engineering time, security review, reliability concerns, internal alignment. Reactor is designed to minimize that cost by fitting cleanly into existing systems. The observability is high (ReactorScan), the integration surface is small, and the adoption path is explicitly incremental.

Reactor can also be deployed through ISVs, integrators, and consultants who help customers add blockchain-connected workflows without full-stack overhauls. This reduces adoption friction for buyers who want to move quickly without committing to large internal infrastructure projects.

The right frame is: use Reactor where the current stack is most painful. Leave everything else alone until Reactor has earned trust in that first workflow.

16. Differentiation vs. Existing Approaches

Reactor coexists with and is distinct from existing connectivity approaches. The most common alternatives teams encounter fall into three categories.

Many interoperability systems follow a familiar pattern. They rely on offchain relayer networks, external validator or oracle committees, or application-configured verifier sets to process messages. Protocols such as Chainlink CCIP, LayerZero, Axelar, and Hyperlane fall into this category. Each introduces its own trust layer, operator economics, and fee structure. Most focus primarily on chain-to-chain messaging and do not natively support Web2↔Web3 workflows. Policy or risk controls are typically managed offchain or left to the application.

Multi-vendor Web2↔Web3 glue stacks, which are still the default for many teams connecting blockchain events to Web2 systems, assemble bridges, oracles, HTTP gateways, backend jobs, and monitoring tooling from separate vendors. The workflow may function, but the operating model accumulates trust assumptions, pricing unpredictability, and debugging complexity across multiple systems.

Reactor’s approach differs across five dimensions:

Trust layering. Reactor’s routing, policy evaluation, and orchestration run as canisters on ICP without a separate offchain relayer fleet or oracle committee dedicated to Reactor’s operation. Trust derives from ICP’s consensus and the underlying chains, not from an additional operator layer.

Connectivity scope. Chain-to-chain, Web2 to Web3, and Web3 to Web2 are all first-class capabilities within the same execution environment. Teams do not need separate products for each workflow type.

Policy and control integration. Sentinel enforces policy on every message before any action is taken. This is built into the processing pipeline, available onchain, and auditable, not managed in a separate offchain system or left to caller-side logic.

Observability. ReactorScan provides a full, per-message execution trail from source to destination, surfacing state transitions, Sentinel decisions, retries, and failures in a single interface.

Integration surface and pricing. One API for Web2. One contract call for blockchains. Pricing is usage-based and avoids the layered per-message fees of architectures that require paying separate relayer, oracle, and executor networks.

Important caveat: Reactor’s security still depends on the security of ICP and the connected destination chains. The claim is that Reactor avoids a separate layer of offchain trust dedicated to Reactor’s operation, not that it operates with zero external dependencies.

17. Roadmap and Future Extensions

Reactor’s near-term priorities include:

Expanding the set of supported blockchains.
Extending Sentinel with declarative policy configuration, additional rule types, and enhanced secrets management.
Expanding ReactorScan with richer dashboards, audit log exports, and operational reporting.
Developing higher-level workflow templates and verticalized SDKs for common use cases (DeFi, gaming, fintech, enterprise automation).

Longer-term technical directions under active exploration include:

Finality abstractions: support for a FinalityPolicy model that derives finality from chain headers and confirmation data rather than fixed elapsed time, enabling correct finality handling across chains with different confirmation semantics, including deterministic-finality chains like Solana, Aptos, and Sui.
Richer analysis within Sentinel: longer-term exploration of anomaly detection and risk analysis over message flows, potentially incorporating pattern recognition or scoring models.
Stablecoin fee support: accepting stablecoins as an alternative payment method alongside R and native tokens.
Expanded automation: scheduled and event-driven multistep workflows with richer branching and condition logic.

18. Conclusion

Reactor is a 100% onchain connectivity layer for Web2↔Web3 and cross-chain workflows. It lets applications, smart contracts, and web services trigger and coordinate blockchain-connected workflows without relying on offchain relayers, separate validator networks, or backend glue.

The architecture is built around four primary components: Gateway contracts on supported chains, Reactor Core on ICP for orchestration and execution, Sentinel for policy and control before execution, and ReactorScan for operational visibility and auditability. Together, they provide a connectivity layer that is inspectable, governable, and operationally straightforward.

Reactor is not trying to win as a louder interoperability narrative. It is designed to win as a simpler, more auditable, more controllable, and more incrementally adoptable way to run blockchain-connected workflows across Web2 and Web3.

Start with one workflow, not a platform rewrite. One API for Web2. One contract call for blockchains.

Reactor’s goal is not just to make these workflows possible, but to make them easier to operate, inspect, and govern in production.

For up-to-date documentation, pricing, and SDKs:

Appendix A: Gateway Technical Reference

This appendix contains implementation-level details for the Reactor Gateway contracts on EVM-compatible chains.

Event Schema

The Gateway emits the following event for every outbound Reactor message:


ReactorMessage(
  address indexed sourceAddress,
  string destinationName,
  string destinationAddress,
  string action,
  bytes32 indexed payloadHash,
  bytes payload,
  bool waitForFinality
)

Security Patterns

Gateway contracts inherit from:

AccessControlDefaultAdminRules for role-based access control
Pausable for emergency stop capability
ReentrancyGuard for protection against reentrant calls

Defined roles: ADMIN_ROLE, EXECUTOR_ROLE, PAUSER_ROLE, FEE_MANAGER_ROLE.

Fee Structure

The per-message fee is computed from composable components:

A base send fee
A per-byte payload fee
A caller fee
An action fee
Destination-specific and action-specific adjustments
Applicable discounts across fee classes

Accepted payment tokens include the native chain gas token, the R token, and wrapped native token. The fee manager and fee holder addresses are admin-configurable. The default maximum payload size is 500 bytes.

Failure Tracking

Failure state is tracked per message, keyed by destination, source, action, message ID, and payload hash.

Appendix B: R Token Allocation and Vesting

Total Supply

Total R token supply: 1,000,000,000 R

Allocation

Bucket	% of Supply	Tokens (R)
Airdrops & Liquidity	7%	70,000,000
Investors	10%	100,000,000
Marketing	10%	100,000,000
Team & Advisors	18%	180,000,000
Ecosystem	25%	250,000,000
Community	30%	300,000,000
Total	100%	1,000,000,000

Within the Team & Advisors bucket, the founding team and initial advisors collectively receive 25,000,000 R (2.5% of total supply). The remainder is reserved for future team members and advisors.

Cliffs and Vesting

All vesting streams vest linearly after the applicable cliff.

Cliffs (months from token generation event):

Marketing: 3
Investors: 6
Team: 12
Advisors: 12

Vesting durations (months, post-cliff):

Investors: 12
Advisors: 12
Marketing: 18
Ecosystem: 18
Team: 20
Community: 24

The founding team and initial advisors are subject to a 12-month lockup (no vesting), followed by 12-month linear vesting.