As far as I understand, the high level goal of this bounty is to give normal wallets the ability to interact with dapps via their respective ICA's. More concretely, we want to write a service that translates transactions meant to be signed and submitted on chain B, into transactions that are signed and submitted on chain A, ultimately affecting the state on chain B via ICA's.
As an example, if I have an EOA on Polygon (0xA) and an ICA on Arbitrum (0xB), I should be able to issue transactions on uniswap.org that change the state of my 0xB account only by signing with 0xA.
Dapps aren't built with ICA's in mind and because of this a few limitations could arise,
- Gas, dapps often require the active account to have a sufficient gas balance. In the context of an ICA where gas is paid via the home chain, they often won't have a gas balance which could lead to UX problems
- Signatures, some dapps (e.g. OpenSea, 1Inch) require users to sign ToS before being given access. When the active account session is an ICA it will be impossible to sign with this account... If ICA's supported EIP-1271, somehow registering the owner during deployment that could be a nice approach, but there'd still be UX barriers with undeployed ICAs. A new standard could be created and adopted by Ethereum tooling, whereby dapps check that the signature originated from the origin account, but that seems out of scope for this bounty.
- Transaction validation, if dapps enforce some kind of anti-tampering checks on transactions (e.g. making sure the
data,fromandtoproperties of a submitted transaction match what they gave to the wallet) it could lead to UX problems
- Dapps often enforce a balance check on the active account before prompting for transaction signatures, but it'd be cool if the Hyperlane Liquidity Layer was used so you could transfer tokens in addition to executing the desired transaction if the balance of the ICA is insufficient
A frontend (and optional service) that sits between a dapp and a wallet, enriching the WC address payload that normally just includes the EOA address with the ICA addresses. Requests to the EOA are simply forwarded to the wallet and requests to ICA's are altered so the EOA can sign them.
This would allow all wallets to access ICA functionality in dapps with WalletConnect.
Just musings, but could be useful when showcasing how an ICA wallet would be built with Hyperlane
A lightweight ICA native wallet that computes ICA addresses for all networks supported on startup. When signing transaction requests destined for the ICA's, it would use a similar service as described above in ICA'ify to transform the transactions into something the ICA can sign.