Bumblefudge

@0xteddybear hey sorry was i blocking this getting merged? the spec outlining how to profile ERC-7930 for non-EVM chains is now here: https://github.com/ChainAgnostic/CAIPs/blob/29762ef99a6ffea1e07e3f796c0d1a5a95e89b88/CAIPs/caip-350.md and the profile for evm is here:...

I think we can close this since #8392 and #8396 merged in the same ideas.

Hey, sorry I missed this last month. To me the crux of the issue lies here: > Adding smart contracts (KT1 addresses) into CAIP-10 would require defining whether they are...

Yeah, that's how I was leaning too-- let me know if you want any help adding the kt1 stuff to the tezos/caip10 ? As for operation hashes, I should mention...

> I think it is kind of interesting considering the strict use of CAIP-10 in did:pkh. I'm not sure I understand what you mean here, tho. Why not just add...

> Design Decisions SLIP-44 for native asset: Uses standard coin type 148 for XLM, following CAIP-20 Unified asset namespace: Consolidates AlphaNum4 and AlphaNum12 into single asset namespace for simplicity Hyphen...

Paging Dr. @Keith-Kowal

NB @wyc -- @csuwildcat has proposed dumping some straw men and precedents into here, with no DIF imprimatur implied or otherwise: https://github.com/decentralized-identity/schema-directory

Also, forgive me if I'm offbase here, but doesn't Vyper [generate the same ABIs](https://docs.vyperlang.org/en/latest/deploying-contracts.html#deploying-a-contract)? I think it's probably more accurate to scope this to EVM than to Solidity specifically.

> I like the idea. I don't know the process to have codes accepted here, do we require at least one implementation? See [Robin's process doc](https://github.com/multiformats/multiformats/blob/master/contributing.md#multiformats-registrations) - `Provide evidence that...