I had not seen that, and does sound like it would solve some of the problems at play here.
So:
- Latest metadata would be downloaded on the fly, and sent to the ledger device.
- Ledger device would hash the metadata, as well as use it.
- User can then sign the message, and submit it to the chain, with the metadata hash included in the signed payload.
- The chain can reject the payload if the metadata hash signed does not match what it on chain.
The flow makes sense to me. Questions would be:
- Can we rely on always being able to download the latest metadata? I guess we already assume we are always online?
- Can the ledger device handle this large payload, and hashing it?
- Is using the metadata better than using XCM?
XCM in my mind would still unify all the experiences across chains, contracts, and anything in-between. For example, transferring a contract token and a native token would look the same, just with a different asset id. Chains using different pallets, for example balances pallet, assets pallet, multi-balances pallet, etc… would all have the same XCM instructions. A browser extension, which is usually the starting point for a ledger transaction, would be able to interface with all chains automatically if they supported XCM, whereas extensions would need to individually program how to handle operations for each parachain, depending on where they have customized pallets.
The problem is that Metadata only expresses the contents on the chain, not necessarily functionality and intention. XCM relays intention of the user, and allows the XCVM to interpret that into the appropriate on-chain operations.