Preflight ERC-4626 redeem calls to prevent predictable failed transactions

[mfpatta]

Feature request

Please consider simulating ERC-4626 redemption calls before users sign and broadcast them. If maxRedeem(owner) is 0, or if a read-only simulation returns a deterministic contract error, the app could warn the user and avoid a transaction that is certain to revert and consume gas.

Example

A redemption initiated through Trust Wallet reverted on Ethereum mainnet:

https://etherscan.io/tx/0x5deba4dee751170ad0febdd4ca71cd7ff6f9e4e6d7f8d89ac1320cc19bf9f627

The vault call was redeem(907143001, receiver, owner). A read-only simulation returned:

ERC4626ExceededMaxRedeem(owner, 907143001, 0)

The wallet held the requested number of vault shares, but the vault's current maxRedeem was zero. The failure was contract-level, so switching wallets or increasing gas would not help.

I also observed multiple recent Redeem transactions from unrelated addresses reverting on the same vault.

This is not a claim that Trust Wallet controls the vault. It is a request for a preflight check and a clear warning when the signed transaction is predictably doomed to fail.