docs: Add Type ID generation and data encoding to LSP1 Notification Type IDs#1333
docs: Add Type ID generation and data encoding to LSP1 Notification Type IDs#1333
Conversation
- Add 'How Type IDs are generated' section explaining keccak256(name) - Add 'TypeID generation' row to each type ID table - Add 'Data encoding' section for each type ID showing abi.encode params - Note LSP26 uses abi.encodePacked (20 bytes) vs abi.encode (32 bytes) - Rename page title and sidebar: 'Universal Receiver Type IDs' -> 'LSP1 Notification Type IDs' Follow-up to PR #1332 based on review from @CJ42.
emmet-bot
requested review from
CJ42,
YamenMerhi,
b00ste and
skimaharvey
as code owners
Deployed with Cloudflare Pages ☁️ 🚀 🆗 |
leo-assistant-chef
left a comment
leo-assistant-chef
left a comment
There was a problem hiding this comment.
Great follow-up to #1332, Emmet. The TypeID generation rows and Data encoding sections are exactly what developers need when building URDs. I verified all 19 TypeIDs against their keccak256 hashes — 18 are correct, but one has a pre-existing error that this PR's new TypeID generation rows now make immediately verifiable.
🔴 Wrong TypeID for LSP8Tokens_OperatorNotification (pre-existing bug — fix in this PR)
The docs currently show:
LSP8Tokens_OperatorNotification → 0x468cd1581d7bc001c3b685513d2b929b55437be34700410383d58f3aa1ea0abc
But keccak256("LSP8Tokens_OperatorNotification") is:
0x8a1c15a8799f71b547e08e2bcb2e85257e81b0a07eee2ce6712549eef1f00970
The value 0x468cd... is actually keccak256("LSP9ValueReceived") — a copy-paste from the LSP9 section. The TypeID generation row you added for this entry will now show keccak256("LSP8Tokens_OperatorNotification") which produces a different result, making the collision immediately obvious to any reader. Please fix the TypeID value itself:
-| **TypeID** | `0x468cd1581d7bc001c3b685513d2b929b55437be34700410383d58f3aa1ea0abc` |
+| **TypeID** | `0x8a1c15a8799f71b547e08e2bcb2e85257e81b0a07eee2ce6712549eef1f00970` |🟡 LSP8 OperatorNotification data encoding: bool true/bool false are values, not types
Using literal boolean values inside an ABI signature reads as if they are type names, which is confusing:
// Current (confusing)
abi.encode(address tokenOwner, bytes32 tokenId, bool true, bytes operatorNotificationData)Suggested fix — use a named parameter and explain via comment:
abi.encode(address tokenOwner, bytes32 tokenId, bool authorized, bytes operatorNotificationData)
// authorized = true on authorizeOperator
// authorized = false on revokeOperator🟡 LSP7 OperatorNotification data encoding: uint256 0 is a value, not a type
Same issue in the LSP7 operator revoke case:
// Current (confusing)
abi.encode(address tokenOwner, uint256 0, bytes operatorNotificationData)Suggested fix:
abi.encode(address tokenOwner, uint256 allowance, bytes operatorNotificationData)
// allowance = 0 on revokeOperator🔵 JS example: clarify ethers version, or add viem alternative
import { keccak256, toUtf8Bytes } from 'ethers'; // ethers v6This is ethers v6 syntax (v5 used separate ethers.utils.keccak256). Most examples on docs.lukso.tech use viem. Consider either adding a // ethers v6 comment, or adding a viem variant:
import { keccak256, toHex } from 'viem';
const typeId = keccak256(toHex('LSP7Tokens_SenderNotification'));⚪️ Rename: hold for Fabian's confirmation (already noted in PR body)
"LSP1 Notification Type IDs" is a better name — more precise and consistent with the LSP numbering convention. Just needs the green light before merge.
Summary: Fix the LSP8Tokens_OperatorNotification TypeID (wrong hash), clean up the bool true/uint256 0 type-vs-value ambiguity in the data encoding blocks, and clarify the ethers version. The core additions (TypeID generation rows + data encoding sections) are solid and valuable — this is very close to merge-ready.
- Fix wrong TypeID for LSP8Tokens_OperatorNotification (was showing LSP9ValueReceived hash 0x468cd... instead of correct 0x8a1c15a8...) - Replace 'bool true'/'bool false' with named 'bool authorized' param in LSP8 operator data encoding - Replace 'uint256 0' with named 'uint256 allowance' param in LSP7 operator revokeOperator data encoding - Add ethers v6 version comment and viem alternative for keccak256 example
…amples - Add Tabs (Solidity/ethers/viem) for all code snippets matching docs pattern - Add 'Notification Type IDs list' table with anchor links to all 19 type IDs - Wrap 'How Type IDs are generated' in collapsible <details> - Rename 'Using Type IDs in JavaScript' -> 'Using Type ID' with Solidity + JS tabs - Replace data encoding sections with encoding AND decoding examples in all three languages (Solidity abi.decode, ethers AbiCoder, viem decodeAbiParameters) - LSP26: show address(bytes20(data)) pattern for abi.encodePacked decoding - Use existing CSS tab classes (tab_ethers, tab_viem) with groupId sync
docs/contracts/type-ids.md
Outdated
| | **JavaScript constant:** | `LSP1_TYPE_IDS.LSP0OwnershipTransferStarted` | | ||
|
|
||
| **Data encoding:** | ||
| **Data encoding and decoding:** |
There was a problem hiding this comment.
Please only show the dcode for decoding the notification:
How to decode notification data?
Code snippets must be hidden in a green collapsible
- Remove 'Standard' column from TOC, rename to 'Notification Type' with
brief descriptions (e.g., 'When receiving LSP7 tokens')
- Add 'TypeId value' column with word + hex in TOC, all anchor-linked
- Move note text under respective tabs (JS note under ethers/viem,
Solidity note under Solidity tab)
- Add recommendation to import from package in Solidity tab
- Remove standalone note block and 'See repository' line
- Solidity tab moved to last position in all tab groups
- Data sections now show ONLY decoding (not encoding)
- All decoding sections wrapped in green :::success collapsible
('How to decode notification data?')
- Replace bullet examples with LSP1 Delegate explanation paragraph covering use cases: auto-register assets, auto-swap, tip followers, split tokens, subscriber lists for airdrops - Add 'See also' section linking to LSP1 Delegate, LSP1 standard, and lsp-smart-contracts repo
Arrow emoji now on its own line before the bytes32 hex value using <br/> for cleaner visual separation in the Notification Type IDs table.
Replace :::info callouts with <details><summary> for the decode sections as requested.
3 participants
Summary
Follow-up to #1332 based on review feedback from @CJ42.
Changes
Type ID generation explanation
keccak256("TypeName")TypeID generationrow to every type ID table showing the keccak256 callData encoding documentation
For each type ID, added a
Data encodingsection showing the exactabi.encodeparameters from the source contracts:(previousOwner, newOwner)for ownership transfers(operator, from, to, amount, data)for sender/recipient;(tokenOwner, allowance, operatorNotificationData)for operatorbytes32 tokenIdinstead ofuint256 amount; operator includesbool authorizedflagabi.encodePacked(address)(20 bytes) — noted as different from standardabi.encodeRenamed page
All data encoding was verified against the lsp-smart-contracts source code.