3. Important! One final pre-flight check

Please check all the items on this list to make sure everything will operate safely, reliably, and effectively

Validation of transfer hash

For cross-chain validation of the transfer, a hashing method is used. This logic allows to eliminate the network of validators, which significantly speeds up the execution of the transfer.

Between networks of the same type (EVM->EVM, TVM->TVM), a simplified hashing method is used to save gas, while between networks of different types, cross-chain hashing logic is applied. The exception to this rule is the EVM and Solana pair, where simplified hashing logic is also used.

Flag _notifyTransferSendingResult

Default value: false

This flag enables notifications about the status of transfer deliveries to the destination network by sending notifications from the relay to the source network. You can learn more about the notification logic in the Source chain notifications section for further details.

IMPORTANT!

In the event of disabling notifications, the client can save on network fees (the transfer will become slightly cheaper in terms of gas). However, the client's off-chain module will not receive data about the status of the transfer delivery in the destination network. This can impact certain internal logic, such as automatically resending a transfer in case of insufficient fees to cover gas in the destination network.

It's essential to understand this if you plan to disable these notifications.

Flag _disableHashValidation

Default value: false

This flag is used to disable automatic validation of the transfer hash before executing its instructions.

It is strongly not recommended to set this flag to true, as it may result in the vulnerability of your cross-chain protocol!

However, if you do disable automatic validation, we recommend that you implement this check yourself by calling the _validTransferHash() method before executing the transfer instructions.

Address Whitelist

To make sure that the transfer was sent by a client contract in the source network, a "whitelist" of addresses has been implemented.

This is a list of pairs chainId => address (network ID => address of the client contract in this network). The client fills this list.

If the client contract of the destination network receives a transfer from an invalid address of the source network (the pair is not in the list), the transfer instructions are not executed (see error).

To add a trusted address to the client contract's owner, one of the following methods must be called:

  1. addTrustedAddress(uint64 _chainId, uint _trustedAddress) - accepts one trusted pair;

  2. addTrustedAddresses(uint64[] calldata _chainIds, uint[] calldata _trustedAddresses) - accepts a list of trusted pairs.

We strongly recommend our Clients to enter only trusted pairs into this whitelist otherwise it may lead to a vulnerability in the cross-chain logic.

Important: In the new version of the contracts, this parameter has become mandatory, so it is necessary to fill in the list of trusted addresses for all supported networks.

For information: Solana network logic uses a slightly different approach to whitelists. Instead of adding the address of the client program itself, the address of the client sender program is added to the whitelist. For more detailed information, see the demo program setup example in the Solana network.

Additional configuration of the client's server

The client's server is a critical part of the system. Please make sure that you protect it as responsibly as possible. Here are some basic tips from the Asterizm team to improve its security:

  1. Proper SSH configuration on the server:

    1. change the standard port 22 to some other port;

    2. prohibit authentication by the root user;

    3. prohibit authorization with a password (allow SSH keys only).

  2. Set up a firewall on the server and close all unnecessary ports;

  3. Close the SSH port for everyone except your work network IP, or use VPN;

  4. Limit the rights of users added to the server - it is not recommended to give out root rights unthinkingly;

  5. Do not disclose the real IP of your server (client's server).

Please remember that the security of the client's server is your responsibility!

Do not neglect pre-configuring it properly.

Validation of the transfer execution order

The system supports on-chain validation of transfer execution order. In case the previous transfer was not executed in the destination network, all subsequent transfers will not be executed either. This logic is necessary for systems that require strict transfer execution order.

You can activate this validation on a client contract by setting the useForceOrder flag to true when deploying (see the Deploying Contracts manual)

Important! Remember that in case of any kind of transfer execution errors in the destination network, the execution order validator state will not change, as a result of which all subsequent transfers will also be rejected.

Use this validation with caution and only if you are absolutely confident in the code of your contract!

Setting the Fee Coverage for the Transfer in the Destination Network

To send a transfer from the relay to the client contract in the destination network, a certain amount of gas in the destination network's native currency is required. For this purpose, the client's off-chain module makes an HTTP request to the relay's API, where the gas amount in the destination network is calculated. The calculation is based on the current prices of native currencies in both the source and destination networks, the volume of transferred data (gas limit), and the current gas price in the destination network.

After receiving the response, the client's off-chain module sends the amount of native currency along with the transaction of the encrypted payload.

Due to the possibility of a sudden increase in gas prices in the destination network (which could result in the sent fee being insufficient for the destination network), it is recommended to set a commission multiplier in the configuration file of the client's off-chain module (see parameter FeeMultiplierPercent). This multiplier will increase the received fee amount by the specified percentage.

For example, if the relay's API returns a value of 1000 and the client sets FeeMultiplierPercent: 20, then to cover the fee in the destination network, 1200 coins from the source network will be sent.

Resending the Transfer Due to Insufficient Fee Coverage Error

In the event that a transfer is declined at the relay due to insufficient fee coverage in the destination network (typically caused by a sudden surge in gas prices in the destination network), there's an option to retry sending the transfer by adding a certain amount of tokens to cover the fee.

There are 3 ways to do that:

  1. Calling the resendTransfer() method on the initiator contract in the source network, passing the transferHash as a parameter, and sending a certain amount of native coins from the source network. This method can be invoked from any address, meaning anyone can send a certain amount of coins to attempt resending the transfer.

  2. Calling the resendAsterizmTransfer() method on the client contract in the source network, passing the transferHash as a parameter, and sending a certain amount of native coins from the source network. This method can only be invoked by the contract owner.

  3. Calling the console method of the client's off-chain module, passing the following parameters: chainSymbol, transferHash, commissionAmount (THIS METHOD IS STILL UNDER DEVELOPMENT, COMING SOON).

After executing one of the methods described above, the relay will attempt to resend the transfer using a fee increased by the amount of coins sent. In this process, the initially sent fee and the fee added with the transfer resend method will be summed up.

If all checks pass, the transfer will be sent to the destination network for further processing.

PreviousDefault implementation (manual)NextExternal relays

Last updated