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

[LSP8] Discussion - truncation of bytes32 tokenId for keyTypes Mapping #259

Open
CJ42 opened this issue Nov 16, 2023 · 0 comments
Open

[LSP8] Discussion - truncation of bytes32 tokenId for keyTypes Mapping #259

CJ42 opened this issue Nov 16, 2023 · 0 comments

Comments

@CJ42
Copy link
Member

CJ42 commented Nov 16, 2023

To Be Discussed

One of the limitation of the Mapping key type is when dealing with bytes32 tokenIds, such as NFTs.

Since LSP2 defines that a key of type Mapping will truncate on the right side, this can cause collisions if the first 20 bytes of two token IDs are the same. This can be the case when the LSP8 Token ID Type is 3 (string).

Such data keys that are susceptibles to this issue can be the following:

Examples

From the actual LSP8 specs

{
  "name": "LSP8MetadataTokenURI:<address|uint256|bytes32|string>",
  "key": "0x1339e76a390b7b9ec9010000<address|uint256|bytes32|string>",
  "keyType": "Mapping",
  "valueType": "(bytes4,string)",
  "valueContent": "(Bytes4,URI)"
}

Example of a possible LSP8 data key

{
    "name": "WinningBidder:<bytes32-tokenId>",
    "key": "0x2651e040e5e018ae36310000<address>",
    "keyType": "Mapping",
    "valueType": "address",
    "valueContent": "Address"
}

Question

How can a schema be defined that avoids the truncation, and prevent this potential collision?

@CJ42 CJ42 changed the title [LSP8] truncation of bytes32 tokenId for keyTypes Mapping [LSP8] Discussion - truncation of bytes32 tokenId for keyTypes Mapping Nov 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant