Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bumblefudge opened this issue Jan 18, 2024 · 1 comment
Open

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

bumblefudge opened this issue Jan 18, 2024 · 1 comment

Comments

@bumblefudge
Copy link
Collaborator

bumblefudge commented Jan 18, 2024

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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant