You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Context and scope
One possible use of Teleporter that could prove very helpful for dApp developers is the ability to query the state of a contract on another chain. The data being queried could be the current value of an oracle, the current state of an account, a random value from a VRF contract, etc.
The query would be sent to the other chain as a Teleporter message with a specific request ID. When the message is delivered to the destination, the specified data would be looked up on chain, and then submitted in a subsequent Teleporter message sent back to the origin chain. The delivery of that second message would invoke a callback providing the value to be used by the original requesting contract.
In order to make this pattern as easy as possible, create contracts that demonstrate this flow on top of Teleporter. Ideally, the interface can be generic enough such that dApps could inherit a CrossChainRequester or CrossChainProvider contract that handles most of the logic.
Open questions
Is it possible to make the interface generic of the type of the value being queried?
What's the best pattern for registering callbacks? Could either store the callback for a given request ID on the source chain contract, or pass it through the messages.
How to set the relayer incentive fees for each message? To start, a working demo that doesn't use any relayer fees is sufficient to demonstrate the use case.
The text was updated successfully, but these errors were encountered:
I was thinking about how to tackle this best and couldn't get an approach out of my head: Javascript has the Promise API. The approach is simple. I perform an action and provide two callbacks:
Then: logic to be executed when asynchronous operation was successful
Catch: logic to be executed when async operation failed
I believe this pattern could make developing with Teleporter in some cases more straight forward. Let's say I want to perform a simple bridging operation. The users send the tokens to the bridge. The bridge attempts to bridge the token. On success nothing happens, but on failure the user receives their funds back.
In Javascript the logic for the handling the success and failure case are passed in as functions. I did not find a straight forward way to do this in solidity, so I worked with contract interfaces. You can find a very rough draft (code is not deployable or testable) of how this pattern could be implemented below.
Context and scope
One possible use of Teleporter that could prove very helpful for dApp developers is the ability to query the state of a contract on another chain. The data being queried could be the current value of an oracle, the current state of an account, a random value from a VRF contract, etc.
The query would be sent to the other chain as a Teleporter message with a specific request ID. When the message is delivered to the destination, the specified data would be looked up on chain, and then submitted in a subsequent Teleporter message sent back to the origin chain. The delivery of that second message would invoke a callback providing the value to be used by the original requesting contract.
In order to make this pattern as easy as possible, create contracts that demonstrate this flow on top of Teleporter. Ideally, the interface can be generic enough such that dApps could inherit a
CrossChainRequester
orCrossChainProvider
contract that handles most of the logic.Open questions
The text was updated successfully, but these errors were encountered: