Possible way to distinguish between implicit and originated accounts for safety check about smart-contracts HOT 2 CLOSED

I think one of the safe guards intended in the original ERC-1155 is against the operator submitting "wrong" originated address for the transaction.
Proposed approach might work, but it does not safeguard from the operator mistake. The operator still can submit originated contract as destination, by providing its hash.

from smart-contracts.

I'm not sure I understand. A user-agent should not allow a KT1 contract address to be provided as a key_hash, under normal circumstances.

Are you suggesting that a user might know how to base58check-reencode KT1 addresses as tz1/2/3, yet might not realize that this is a completely unconventional thing to do?

IMO we can expect that the meaning of the key_hash type is understood (either by users or by user-agents.) Note that one can already send tez to a bogus key_hash! Of course, for tez, there is no other way it could be, while for tokens you could decide to only support contracts as receivers.

I do think the position that a safety check should always be performed is interesting, and possibly viable. The downside, of course, is that everyone must deploy (or at least interact with) a receiver contract.

from smart-contracts.