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
);