Overview

Teleport transactions in Rayls enable secure cross-chain transfers of digital assets between Rayls Privacy Node Ledgers within Private Subnets. Before a token can be teleported, it must be registered in the subnet. This guide provides a comprehensive overview of the registration and teleportation processes, including references to the specific handler documentation required for different token standards.

Pre-Requisites

Before initiating a teleport transaction, ensure the following:

Token Deployment: The token must be deployed and minted on your Rayls Privacy Node.
Token Registration: The token must be registered in the Token registry of the Private Subnet.
Token Approval: The token must be approved by the Private Subnet Operator in order to be active for cross-chain message in the subnet.
Smart Contracts Deployed: The appropriate Rayls handler (ERC-20, ERC-721, or ERC-1155) must be deployed and configured.
Connected Components: Check the logs of both the Rayls Privacy Node Ledger and Relayer to make sure they are connected and operational.

Step-by-Step

1. Sending a Teleport Transaction

Use the Appropriate Handler:

Depending on your token standard (ERC-20, ERC-721, or ERC-1155), initiate the teleport transaction using the respective handler's smart contract functions.

Refer to the Handler Documentation:

For detailed instructions on how to initiate the teleport transaction using the specific handler, refer to:

2. Teleport Execution

Once the teleport function is called:

Relayer Activation:

The Relayer component on the sender's Rayls Privacy Node detects the teleport transaction and securely relays it to the Subnet Hub.

Subnet hub Validation:

The Subnet Hub validates the transaction, ensuring it complies with the network rules before finalizing the teleport to the destination Rayls Privacy Node.

3. Receiving the Teleport Transaction

At the receiver’s Rayls Privacy Node:

Relayer Listening to the Subnet Hub:

The destination Rayls Privacy Node’s Relayer picks up the transaction from the Subnet Hub, processes it, and finalizes the teleport.

Token Release:

Tokens are minted on the destination Rayls Privacy Node Ledger, marking the completion of the teleport process.

4. Revert Transaction Flow (Error Handling)

In the event that a teleport transaction fails at any stage (e.g., due to Subnet hub issues, relayer malfunctions, or destination ledger errors), the teleport will automatically go into the revert flow:

Transaction Validation Failure:

If the Subnet Hub fails to validate the teleport, the Relayer will trigger a revert transaction to the sender’s Rayls Privacy Node. The tokens will be re-credited (re-minted) to the sender's account, this is a regular on-chain transaction and the revert reason is added as a metadata in the transaction for monitoring and auditability purposes.

Destination Rayls Privacy Node Failure:

If the issue occurs during the finalization on the receiver's Ledger (e.g., the destination ledger fails to mint the tokens), the sender Relayer’s will detect the issue via the Subnet hub and revert transaction with the revert reason added as a metadata, returning the tokens to the original ledger.

5. Monitoring your transaction

All transactions inside of a Rayls Privacy Node and Private Subnet can be monitored via the Rayls Privacy Node block explorer.

For more information check out the Monitoring Rayls Privacy Node Transactions page.

Teleport transactions offer a powerful way to move assets securely and privately between Rayls Privacy Nodes within the Rayls ecosystem. By following this guide and utilizing the appropriate handlers, you can efficiently manage cross-chain transfers while maintaining full compliance with each network rules