ChainAgnostic / CAIPs

Chain Agnostic Improvement Proposals
https://chainagnostic.org
Creative Commons Zero v1.0 Universal
494 stars 149 forks source link

[CAIP-19] Assets versus Actors or Entities? #259

Open bumblefudge opened 8 months ago

bumblefudge commented 8 months ago

I got a DM from someone deciding whether to use CAIP-19 in a project, who thought the SYNTAX of CAIP-19 worked fine, but didn't understand why it was semantically constrained to ASSETS. the only examples other than NFTs in the spec is SLIP-44, which is a registry of asset metadata for native tokens (also assets). they pointed out, however, that the ### Semantics section feels more capacious than just assets, and could be extended to other namespaces, including more meta-ones like "memory slots".

Using different discriminators, like abi or memory or solidity-0.8.23+, one could conceivably rely on abstractions inherent to Solidity and/or the EVM runtime (and thus to the entire eip155 namespace) to query arbitrary deployed contracts for, e.g., a specific memory slot or ABI variable, regardless of whether they're erc20- or erc721-conformant contracts.

Part of the elegance of CAIP-19 is that it helps other L1s define an asset_namespace profile for the "ERC20/721-equivalent" interfaces and define those in a namespace, as many have already done. Editing the Semantics section to explicitly allow non-asset namespaces would kinda open the door to asset_namespaces without an equivalent outside a given L1/namespace. It would also require such abstract supersets of ERC20+721 to be defined in, e.g., the eip155/caip19.md as valid values, on the understanding that other L1s might not have equivalents. Then again, this might actually be helpful, since plenty over other L1s use variations or forks of Solidity and/or Vyper, at least on some L2s...

In any case, some else is welcome to open a PR if I don't get to it, or I can do a WIP PR draft if interested parties prefer.

bumblefudge commented 7 months ago

See also: https://eips.ethereum.org/EIPS/eip-5219 (another possible resource_namespace if assets were generalized to resources...)