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
LUKSO is an EVM compatible network, so it can be integrated like other networks. However, they've developed separate token standards called LSP7 (their ERC20) and LSP8 (their ERC721).
The LSP7 token standard doesn't really solve any of the problems associated with token approvals, although the LSP8 standard does improve some of the security issues with ERC721 token approvals.
Despite this, these tokens standards do change all of the interfaces / names compared to their Ethereum counterparts for some reason (e.g. OperatorAuthorizationChanged instead of Approval events are emitted and authorizedAmountFor is called instead of allowance to get the current token approval value).
This makes integrating existing Ethereum applications (including Revoke.cash) with these tokens a huge pain (again, without a lot of gain). It should be possible to create an special case for LUKSO's token standards in the future, but for now I don't see this being worth the effort.
The text was updated successfully, but these errors were encountered:
LUKSO is an EVM compatible network, so it can be integrated like other networks. However, they've developed separate token standards called LSP7 (their ERC20) and LSP8 (their ERC721).
The LSP7 token standard doesn't really solve any of the problems associated with token approvals, although the LSP8 standard does improve some of the security issues with ERC721 token approvals.
Despite this, these tokens standards do change all of the interfaces / names compared to their Ethereum counterparts for some reason (e.g.
OperatorAuthorizationChanged
instead ofApproval
events are emitted andauthorizedAmountFor
is called instead ofallowance
to get the current token approval value).This makes integrating existing Ethereum applications (including Revoke.cash) with these tokens a huge pain (again, without a lot of gain). It should be possible to create an special case for LUKSO's token standards in the future, but for now I don't see this being worth the effort.
The text was updated successfully, but these errors were encountered: