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
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:
How can a schema be defined that avoids the truncation, and prevent this potential collision?
The text was updated successfully, but these errors were encountered:
CJ42
changed the title
[LSP8] truncation of bytes32 tokenId for keyTypes Mapping
[LSP8] Discussion - truncation of bytes32 tokenId for keyTypes Mapping
Nov 16, 2023
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
Example of a possible LSP8 data key
Question
How can a schema be defined that avoids the truncation, and prevent this potential collision?
The text was updated successfully, but these errors were encountered: