Support for "sendAndCall" extension

[michaelkaplan13]

The ERC20Source/Destination and NativeToken/SourceDestination contracts makes it easy to bridge native tokens and ERC20 between Subnets, with each Subnet getting to define its own representation of the bridged asset with in own chain. One use case that I could image being very common for these bridged assets is to use them to pay for fees to use services on other chains.

Teleporter enables this model of chains in one Subnet leveraging services offered on chains in other Subnets. For instance, this repo has example contracts for how to leverage Chainlink VRF services on the C-Chain from within a Subnet. However, there are complexities not yet addressed when it comes to paying fees to use the service on the other chain. Those services may require payment in an ERC20, native token, or other asset type on their respective chains, but users interacting with the service on a Subnet via Teleporter may not have tokens on the service chain, and further shouldn't have to have any interaction on the service chain to use the service on a Subnet.

The example contracts to use Chainlink VRF via Teleporter side step this complexity by having a subscription set up on the service chain (i.e the C-Chain) that is funded with LINK to be able to cover VRF fees. The obvious limitation to this is that all requests from the Subnet dApp have access to use this subscription. Ideally, users on the Subnet would be able to interact and pay fees for the services directly on the Subnet contract itself, and those fee amounts would be transferred to the service chain along with the request itself.

One way to enable this is to use bridged assets on the Subnet to pay for fees by transferring them directly to the service chain along with submitting the request. In order to do so, there needs to be support for bridging tokens and using them in a call on the destination chain all in one Teleporter message. The high level idea would be a "sendAndCall" or "bridgeAndCall" mechanism that allows for bridging tokens and calling arbitrary contracts. This would be an extension to the ERC20 and native token source and destination contracts. In psuedo-code, it would something like:

contract ERC20Source {
        ...

	function sendAndCall(
	    SendTokensInput calldata tokenTransferInput, 
	    uint256 amount, 
	    bytes calldata payload, 
	    uint256 requiredGas) 
	{
	    // Lock/burn token amount
	    _deposit(amount);

	    // Handle Teleporter message fees/accounting
	    ...

	    // Encode and send the Teleporter message
	    bytes memory message = _encodeSendAndCall(...);
	    _sendTeleporterMessage(message, ...);
	}

	function _receiveTeleporterMessage(...) 
	{
	    // Normal authorization/validity checks.
	    ...

	    if (sendAndCallMessage) {
	        // If multihop, handle fees and pass message along to destination.

            // Instead of withdrawing the tokens to the recipient, approve the recipient to spend the tokens.
            erc20.approve(recipient, amount);

            // Call the recipient with the given input data.
            recipient.call{gas: requiredGas}(payload);


	    } else {
	        // Normal basic bridging logic
	    }

	}

        ...
}

In the Chainlink VRF example, the VRFProvider contract would then change from being a TeleporterReceiver to implementing a submitVRFRequest interface that would be called in the recipient.call line above. It would use transferFrom to deposit the intended service fee amount (that was just approved by the bridge contract), submit the request to the Chainlink VRF coordinator, and handle the logic of the required callback by submitting a Teleporter message back to the Subnet with the result.

This would allow the bridged asset to be used to pay for multiple arbitrary services on the C-Chain, and be specific to a single service such as VRF. For instance, if a NativeTokenSource contract on the C-Chain supports "sendAndCall", it could be used to allow users to pay fees for services on the C-Chain using AVAX completely on a Subnet dApp, with no need for additional interactions on the C-Chain.

There are still lots of questions left to be answered, but having a generic approach for enabling paying service fees on another chain would be a potentially powerful enabler.

[cam-schultz]

Token transfers within a single chain can be done as side effects of an arbitrary function call, so it makes sense to support that feature for cross-chain token transfers as well.

Handling reverts may be tricky. In the single chain case, no tokens are transferred on revert, but in the Teleporter world, tokens are burned on the TeleporterTokenDestination chain before the revert occurs on the TeleporterTokenSource chain. If we revert, I can think of a couple options:

1. Hold the bridged tokens in escrow. We'd have to provide an approved address to redeem in the Teleporter payload
2. Modify the TeleporterTokenBridge to not irrevocably burn until an ack is received. We can perhaps do something similar to the TeleporterMessenger receipts, and hold the tokens in TeleporterTokenDestination until we receive the corresponding receipt as the ack. The receipt would include whether or not the call on the TeleporterTokenSource chain was successful; TeleporterTokenDestination burns the tokens if it was, and releases them back to the caller if it isn't.

[michaelkaplan13]

Great point on handling reverts on the destination. That will definitely be tricky to make it as least error prone as possible.

Theoretically, I'm not sure it's any different than a more basic Teleporter message reverting on the destination (i.e. if _receiveTeleporterMessage reverts in the current implementations when calling transferFrom). Practically though, it is more error prone because there are more ways the calldata could be invalid/incorrect.

For the route of trying to also revert the effect on the source chain if the message reverts on the destination, I think the _receiveTeleporterMessage implementation would need to make sure it keep sufficient gas for after the .call() to send a Teleporter message back to the source chain in the case that the call() fails. I'm worried about the potentially for a "turtles all the way down" problem though, because there is no guarantee that the message sent back to the source will not revert itself 😅.

I like the idea of essentially falling back to a basic "send" if the call in the "sendAndCall" fails. We would still need to limit the amount of gas provided to the call to ensure there is enough to handle the fail case after it if needed, but it more or less could reduce the likelihood/complexity of a revert to what already exists in the current implementation.

Alternatively, the most basic approach that could be worth considering is providing the full available gas to the call, and reverting from _receiveTeleporterMessage in the event of a failure. This would make it such that the message can be retried with a higher gas limit in the future at the Teleporter level, so all of the same properties would apply which makes it easy to reason about.

[meeshhhh]

How does this "sendAndCall" model differ from a "paymaster" model where you have a contract with a pool of tokens for paying for fees?

• In the "sendAndCall" model, you don't have to actively maintain the pool for fees, it automatically routes the tokens
• In both models, the user needs to have some tokens available on the Subnet / Chain they are on. However, this doesn't necessarily need to be the token required for the service. For example, the VRF service requires LINK, but the user could send USDC, and this could be swapped on the service chain for LINK. This would be a better UX.

Is this accurate? Anything else to add to the comparison?

[michaelkaplan13]

That's all accurate, but also important to call out that paying service fees is just one possible use case of sendAndCall being supported by bridge contracts. Any UX considerations like the one you mentioned are really on the applications, but sendAndCall is generic to any application that wants to transfer funds to another chain and use them there to call other contracts.