Ensure frontend is setup to handle multiple relayers

[mds1]

Do we get a regular tx hash or a tx ID back from OZ relayers used on polygon + L2s? This block of code assumes we get a tx hash on polygon, and an ID everywhere else, but that seems incorrect? (this comment is unrelated to the diff)

Originally posted by @mds1 in #319 (comment)

With ITX (on Mainnet/Rinkeby), their API returns a custom hash and you have to subsequently query their endpoint to figure out the list of actual network transaction hashes. That is what we pass forward from Umbra API.

With Defender, we get back the hash of the first transaction submitted, and that is what we pass forward from Umbra API. Defender also gives you a separate, custom Identifier which can use to query their API, to find out if that first transaction has been replaced or cancelled. We currently don't expose this in any response from Umbra API.

In practice, since we're using this on Polygon and using fast, this virtually never happens, and so the hash we get back ends up being the hash of the transaction that is ultimately mined. This should also be the case on Optimism and Arbitrum.

If we ever started using Defender on mainnet, we might have to revisit this assumption.

Originally posted by @apbendi in #319 (comment)

[garyghayrat]

• Because all networks are now using OZ defender set to 'fast', it is relatively safe to assume the tx hash returns will be mined and to display this to the user.
• The relay withdraw window should be updated to include Etherscan link to the tx hash.

[mds1]

Since we now use OZ everywhere, I think original scope of this issue is outdated and the issue can be closed. But we don't have support for properly handling replacement txs with OZ—I'm not sure if they have an endpoint we should use to fetch the latest tx hash or some other approach, but either way it probably could be a separate issue.

umbra-protocol/frontend/src/components/AccountReceiveTable.vue

Lines 594 to 599 in 5a969f7

	// This is a regular transaction hash, though it's possible OZ Defender will replace it to ensure it gets
	// included quickly, in which case the frontend would not automatically reflect when the relay was successful.
	// Because we relay with the "fast" setting, this is unlikely to be the case.
	window.logger.info(`Relayed with transaction hash ${relayTransactionHash}`);
	const receipt = await provider.value.waitForTransaction(relayTransactionHash);
	window.logger.info('Withdraw successful. Receipt:', receipt);

The relay withdraw window should be updated to include Etherscan link to the tx hash.

What is this referring to? My guess is that the tx notification window in the top right that shows tx status does not let you click it to view the withdraw tx?

[mds1]

But we don't have support for properly handling replacement txs with OZ—I'm not sure if they have an endpoint we should use to fetch the latest tx hash or some other approach, but either way it probably could be a separate issue.

@apbendi this is probably a question for you, is this something we need to support / track in an issue?

The relay withdraw window should be updated to include Etherscan link to the tx hash.

What is this referring to? My guess is that the tx notification window in the top right that shows tx status does not let you click it to view the withdraw tx?

@garyghayrat bumping this question

[garyghayrat]

The relay withdraw window should be updated to include Etherscan link to the tx hash.

What is this referring to? My guess is that the tx notification window in the top right that shows tx status does not let you click it to view the withdraw tx?

@garyghayrat bumping this question

Seems to have been solved with #381

[garyghayrat]

Opened a new issue to track. #634