You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
ormemory
orsolidity-0.8.23+
, one could conceivably rely on abstractions inherent to Solidity and/or the EVM runtime (and thus to the entireeip155
namespace) to query arbitrary deployed contracts for, e.g., a specific memory slot or ABI variable, regardless of whether they'reerc20
- orerc721
-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 toasset_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.
The text was updated successfully, but these errors were encountered: