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 _destinationName, 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.
  • _destinationName: Name of destination where message will be sent.
  • _destinationAddress: Address to send message to on the destination.
  • _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 Name

One of the Supported Name which are unique identifiers that determine the destination of the message. With this, messages can be sent to the current chain that the message originated on or a different destination. 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 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:

  • chain_message: Send data between blockchains.
  • web_message: Get or post data on a web resource (i.e. web service or API).
  • generate_random_numbers: Create a set of verifiable random numbers.

Note: When an action is being executed on the destination, it must complete within the max gas limit allocated to the transaction. For EVM destinations, this limit is 2M (2000000) gas units. Each individual action can have its own independent max gas limit per destination that can be higher than the default specified. Messages that fail due to out of gas errors are treated as successfully completed messages in Reactor and will not be eligible for retries. When designing your application, be sure to take into consideration this limit when reasoning through your scenaios.

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. While chain_message messages can contain any byte-encoded data, messages like web_message and generate_random_numbers must follow a predefined format. In the case of web_message messages, the payload must be ABI encoded with the HTTP method, URL, request body, and optional request headers (see example below). For generate_random_numbers, the payload must be an ABI encoded integer represent the number of random numbers to generate.

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_message messages, Reactor payloads can be encoded with parameters.

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

For web_message messages, the payload delivered to the contract at the destination address on the destination will only include the HTTP status code and HTTP response body. No response headers will be included at this time. Since any data that is sent from and 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 any applications. 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_message 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 tranasactions 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...", "chain_message", abi.encode("Don't Panic!"), true );

Paying fees with token

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

Last updated on