Closed PoolPirate closed 4 months ago
@PoolPirate Sei does not have ibc hooks implemented, so using the API directly we will never provide a route/set of txs that use the adapter to send IBC messages (the API just supports swaps that end on sei, but can not hop further).
I am assuming you did not go through the API but just executed our contracts directly and therefore did not have protection on the route the API would not allow, correct?
Oh I see, must have overlooked the missing hooks middleware. Am indeed running my own routing, you guys not using the adapter for sending from there explains why I'm the only one who got assets stuck there 😅
Will close for now as there's nothing to be done here (besides maybe documenting it)
@PoolPirate yeah, in general the contracts were made to be exclusively used by the API, so have not documented their usage for non APi cases.
In this example the contract was deployed such that if/when IBC hooks is added, we already have the contract deployed but the safer approach would've been to make the sei version of the ibc adapter contract error in case of non-API usage.
@NotJeremyLiu Am generally against limiting features on-chain that are not inherently broken. In this case it was just a combination of my short IBC timeouts plus an issue with my relayer setup causing these timeout to occur.
It appears like ibc timeouts for skip calls originating from SEI do not trigger a refund properly. The memo seems fine to me, however the timeout tx does not have any wasm call. Maybe its an underlying issue from Sei itself?
Example here: Skip Swap Sei->Osmosis https://www.mintscan.io/sei/tx/DBDE183DD6BDBC4F07905AA36E9E3BD74029FE5E1ED862C3E6F9E147EF35D74E?height=71364751§or=message
Timeout: https://www.mintscan.io/sei/tx/87FDD3CBBEFDD374EED9205A069092AF5DE3182E7F01C71866DD29554EB1E7DD?height=71365486§or=logs
The funds from that transfer remain in the ibc transfer adapter contract sei1nrsp0k5urftug9p0tscg2lek0tfve0m6ks2nps27p2rm7aapes7q9hn0pu