Skip to Content
Sending Messages

Sending Messages on Reactor

For chain to chain or chain to web messages, your contract will need to call the ReactorGateway’s send function. The send function takes care of calculating the fee, the transfer of native gas or tokens to pay the fee for the message, and sending the message to the Reactor Core to be processed.

Send Function

function send(
    address _paymentToken,
    string calldata _destinationChainName,
    string calldata _destinationAddress,
    string calldata _action,
    bytes calldata _payload,
    bool _waitForFinality
) external payable;

Send message parameters

  • _paymentToken: Address of token used to pay for message.
  • _destinationChainName: Name of blockchain where message will be sent.
  • _destinationAddress: Address to send message to on the destination chain.
  • _action: Type of message to send.
  • _payload: Encoded action-specific data for the message.
  • _waitForFinality: Whether to wait for finality on the chain before processing the message.

Payment Token

The payment token is the asset used to cover fees for sending messages on Reactor. The fees can be paid using either the native gas, a supported payment token on the chain, or the R Token. The zero address value on a chain, the address(0) or 0x0000000000000000000000000000000000000000 on EVM chains, can be used to pay fees in the native gas. To get the contract address for other supported payment tokens, including the R token, look at the Payment Tokens page.

Destination Chain Name

Destination Chain Names are unique identifiers that determines the target chain of the message. With this, messages can be sent to the current chain that the message originated on or a different chain. Applications choose where they want their data to be routed to regardless of the message’s type.

Destination Address

The address of the contract on the destination chain where the message will be delivered. The contract at the destination address must implement the IExecutable interface in order to receive messages.

Action

Actions are the way that convey to Reactor the intent behind the message that is being sent. This allows Reactor to be simple and flexible to cover the workflows required today while staying open to enable the emerging use cases in the future.

The following actions are currently supported:

  • cross_chain: Send data between blockchains.
  • web_request: Get or post data on a web resource (i.e. web service or API).

Payload

On Reactor, any data that can be encoded into bytes can be sent as the payload for a message. This is the data that will be delivered to the contract at the destination address on the destination chain. While cross_chain messages can contain any byte-encoded data, messages like web_request must follow a predefined format. In the case of web_request messages, the payload must be ABI encoded with the HTTP method, URL, and body (see example below).

Message Parameters

At times, there is a need to convey additional information related to a message between Reactor and the applications. In these scenarios, like request and response headers for web_request messages, Reactor payloads can be encoded with parameters.

// Example of web request with headers
bytes memory web_request_payload = abi.encode("GET", "https://docs.reactor.network", "");
bytes memory payload = abi.encode(web_request_payload, ["header.NAME_1", "header.NAME_2"], ["VALUE_1", "VALUE_2"]);

For web_request messages, the payload delivered to the contract at the destination address on the destination chain will be encoded with parameters that include any response headers along with the HTTP response. Since any data that is delivered to the contracts will be persisted to the blockchain, it is important to handle sensitive data in a secure manner. For these cases, please contact the [Reactor Team] so that overrides can be added to remove any sensitive data before it is sent to contracts. In the future, there will be a self-service portal that will allow for the management of sensitive data like API keys, credentials, or other private information for messages coming into Reactor and going out of Reactor. This includes using this sensitive data in outgoing web_request messages.

Wait For Finality

Some applications will want to make sure that the chances of a reorg of blockchain is extremely low, especially when dealing with financial tranasaction or transferring assets between blockchains. These applications can set this flag to true and Reactor will wait until the source blockchain has been finalized before proceeding to process the message and sending the message to the destination blockchain. If the application does not require this level of finality, then simple set the flag to false and Reactor will process the message as fast as possible.

Examples

Here’s are two basic examples of calling send from a contract:

Paying fees with native gas

IReactorGateway(gatewayAddress).send{value: msg.value}(
    address(0), // Use native gas to pay fees
    "ethereum",
    "0xDestinationAddr...",
    "cross_chain",
    abi.encode("Don't Panic!"),
    true
);

Paying fees with token

IReactorGateway(gatewayAddress).send(
    0xTokenAddr..., // Use token to pay fees
    "base",
    "0xDestinationAddr...",
    "web_request",
    abi.encode("GET", "https://docs.reactor.network", ""),
    false
);
Last updated on
WelcomeReceiving Messages