Gas estimation via Remix + MetaMask fails consistently / “missing revert data”

[ottovlotto]

Developer feedback from Polkadot Developer Support telegram channel (see Matrix (bridged) message here)

Most Ethereum builders (myself included) are not using Foundry/Hardhat or manual RPC calls when trying Polkadot Hub for the first time. We use the default Ethereum stack: Remix + MetaMask (Injected Provider), click deploy, and expect it to “just work” like on Soneium L2, Arbitrum, Optimism, etc.

From that real-world builder path, two UX issues are very visible:

Gas estimation via Remix + MetaMask fails consistently
“missing revert data”
Flat very high estimates
Forces manual gas overrides (15–20M) even for simple contracts
This is extremely scary for non-expert devs and feels broken, even if the tx eventually succeeds.

Dual account derivation is very confusing in practice
One ECDSA private key → two different AccountId32s
Assets can land in the padded EE fallback account that no Substrate wallet shows or controls
To a builder, this looks exactly like “funds disappeared”
Even if this is technically correct by design, the current docs + wallet UX do not make this clear enough.
I want to be very clear: I’m not in a position right now to prepare gists, repos, or technical repros. I’m a founder actively trying to deploy a DEX and liquidity, and I need the happy path UX to be simple and safe.

What would really help is:

• Someone from the team testing exactly: Remix + MetaMask, Injected Provider, on Asset Hub mainnet, no Foundry, no scripts.
• Prioritizing fixes or mitigations for gas estimation UX.
• Improving docs and warnings around ECDSA → dual account behavior, so builders don’t get confused or scared.

Revive is genuinely impressive, and I want to be one of the first DEXes live on Hub. But this friction is real and is currently blocking builders like me. Thanks again — hoping we can smooth this last mile for Ethereum-native devs.

[ottovlotto]

Also more detail in issue reported to the documentation team here

[ottovlotto]

Response from @athei (on Element) here:

So my theory what is going wrong (just by reading this):
Substrate wallets do allow importing of secp keys as substrate key. But they don’t use the new signature type I introduced. This will lead to a wrong address indeed. And for that one we don’t have a recovery. Wallets need to support this: paritytech/polkadot-sdk#8757

But it seems unlikely that this is the case.AFAIK substrate wallets dont allow secp keys for substrate txs. But might be wrong.

Recovery is also not needed in this case. You can just use a ethereum tx to move the funds.
or use then new signature type
there is essentially no way to lose funds except manually deriving a wrong address

FYI @albertov19 and @nhussein11 in case this explainer helps with the docs clarification

[albertov19]

We were not able to replicate this, and the user confirmed it was working. I don't think this is relevant now IMO.