[API-3529] Implement GoFastHandler contract #15
Conversation
thal0x
changed the title
The reason I didn't do this is because over the weekend I'm planning on removing all of that nesting and putting all contracts in a single project |
| } | ||
|
|
||
| function _swap(address tokenIn, uint256 amountIn, bytes memory swapCalldata) internal returns (uint256 amountOut) { | ||
| address tokenOut = fastTransferGateway.token(); |
There was a problem hiding this comment.
Its a little strange that the caller needs to match their swapCallData to swap into a token whose address is stored in the gateway. This is probably fine in practice since we are generating the swap payload, but if we mess up, can we run into situations where funds are stuck if the swap output token in the swapCallData does not match the gateway token?
AxelarHandler/src/GoFastHandler.sol
Outdated
| uint64 timeoutTimestamp, | ||
| bytes calldata destinationCalldata | ||
| ) public payable returns (bytes32) { | ||
| require(executionFeeAmount != 0, "execution fee cannot be zero"); |
There was a problem hiding this comment.
Not sure this a safe assumption to make. @NotJeremyLiu
There was a problem hiding this comment.
If this is the source + dest gas fee, then I think there could be cases where it is 0
There was a problem hiding this comment.
@thal0x if we remove this check i think we have a potential fund loss bug if the swapCallData ouput denom does not match the fast transfer gateway asset as the check in line 54 can pass on a zero swapAmountOut. can we rewrite things to avoid that possibility here?
it also seems like we should just make the contract upgradeable - seems like cheap insurance against stuck funds in general. wdyt?
Implements the
GoFastHandlercontract which supports swapping and then submitting a fast transfer order