draft: LIP-27 - Token Bound Profiles Proposal

[ValentineCodes]

LIP-27 introduces a standard for creating Token Bound Profiles (TBP) using LSP8 Identifiable Digital Assets and Universal Profiles (LSP0) on the Lukso blockchain. This proposal allows each LSP8 token to be associated with a Universal Profile, enabling token-based ownership and interactions.

[JordyDutch]

👏🏼🚀🤝🏼

[tantodefi]

For consideration with 'Ownership Cycles'

We could potentially prevent the LSP8 being sent to the associated UP of the Token Bound Profile - by adding a check/override in the transfer function - although I'm not sure if this is desirable as we should try to keep the interfaces of the Profiles as close to the same as possible.

[ValentineCodes]

For consideration with 'Ownership Cycles'

We could potentially prevent the LSP8 being sent to the associated UP of the Token Bound Profile - by adding a check/override in the transfer function - although I'm not sure if this is desirable as we should try to keep the interfaces of the Profiles as close to the same as possible.

This seems like a step in the right direction, but it may not work well with existing NFTs.

A way around this would be to modify the Universal Receiver to revert if it receives the token

[frozeman]

What is the purpose of the chain ID in the profile creation function?

[ValentineCodes]

What is the purpose of the chain ID in the profile creation function?

Ensures that the profile is uniquely tied to a specific network. However, as the LSPs are only for Lukso Blockchain, do you think this is unnecessary?

[frozeman]

Ensures that the profile is uniquely tied to a specific network. However, as the LSPs are only for Lukso Blockchain, do you think this is unnecessary?

LSPs work on any chain, but in order that this LSP8 can set the owner of a profile, both the smart contract of the profile, as well as this LSP8 need to be on the same chain. Hence why i am not sure what the chain ID is doing here.

Do i understand this right, that this is a simple LSP8 that deploys profiles, which then use the owner of the LSP8 token ID as owner of itself?

If thats the case, here are a few points:

• If the owner is changed by the transfer of the LSP8, then no keymanager can control this profile, meaning it looses all the special powers of LSP6 (permissions etc)
• The tokenId should be an address, which is the address of the profile

[ValentineCodes]

Initial thoughts:

• Achieve almost the same functionalities of ERC6551
• Bounding Account to tokenId is possible using this method, also with having accounts as direct bytes32 tokenId, but that is more for advanced usecases or a start of an NFT with account. The LSP-27 can be helpful for normal tokenId representing as numbers, hex, etc .. to be later associated with an account.
• Any Implementation ? The implementation needs to be reviewed carefully especially on the part of overriding ownership to be accessible by the token owner.
• Better to allow full profile creation with bytecode, and probably initialization calldata ?
• Wording should be independent from LUKSO Blockchain, better to use "LSPs" to refer to the ecosystem of LSPs.
• More clarity about the registry: where is it deployed, how, etc ..

Thank you for reviewing this. I’ll update the documentation based on your suggestions.

[ValentineCodes]

Ensures that the profile is uniquely tied to a specific network. However, as the LSPs are only for Lukso Blockchain, do you think this is unnecessary?

LSPs work on any chain, but in order that this LSP8 can set the owner of a profile, both the smart contract of the profile, as well as this LSP8 need to be on the same chain. Hence why i am not sure what the chain ID is doing here.

Do i understand this right, that this is a simple LSP8 that deploys profiles, which then use the owner of the LSP8 token ID as owner of itself?

If thats the case, here are a few points:

• If the owner is changed by the transfer of the LSP8, then no keymanager can control this profile, meaning it looses all the special powers of LSP6 (permissions etc)
• The tokenId should be an address, which is the address of the profile

You make a good point. Using the tokenId as the address of the profile would be a great idea for newly created NFTs. However, how would this approach work for existing NFTs?

[CJ42]

Ensures that the profile is uniquely tied to a specific network. However, as the LSPs are only for Lukso Blockchain, do you think this is unnecessary?

LSPs work on any chain, but in order that this LSP8 can set the owner of a profile, both the smart contract of the profile, as well as this LSP8 need to be on the same chain. Hence why i am not sure what the chain ID is doing here.

Do i understand this right, that this is a simple LSP8 that deploys profiles, which then use the owner of the LSP8 token ID as owner of itself?

If thats the case, here are a few points:

• If the owner is changed by the transfer of the LSP8, then no keymanager can control this profile, meaning it looses all the special powers of LSP6 (permissions etc)

• The tokenId should be an address, which is the address of the profile

You make a good point. Using the tokenId as the address of the profile would be a great idea for newly created NFTs. However, how would this approach work for existing NFTs?

This is a good point. I think some basic examples in docs.lukso.tech of how LSP8 with Token Id Format Address could be used and the address being a UP (already deployed, or deployed at the time of minting) would be very valuable examples of use cases and code examples.

[ValentineCodes]

Thanks for submitting this LSP proposal @ValentineCodes

I have added my review comments.

I am not agreeing on this standard and I think it should not be merged and accepted for two big reasons:

1) this is a very custom implementation linking LSP8 to a UP (or LSP0 more generically). We should go away of proposing standards for custom implementations logic. The aim of a standard is to be generic purpose for a wide range of use cases. Here the custom logic around the ownership management make it very tightly coupled to LSP8 functionalities. Meaning its "defining a custom logic as something standard". The logic should define the MUST and MUST not for standard behaviour (to describe what the function MUST and MUST NOT do), but the standard shouldn't define HOW it does it (here it is the case, it defines "it should call the tokenOwner(bytes32) function to retrieve the owner(). Therefore it is too enforcing.

2) this standard breaks composability of a Universal Profile when it comes to ownership management. With this standard, a token bound profile:

• could not be owned by a Key Manager anymore. Therefore users of a token bound profile would not be able to set permissions in their UP + would not have access to gas less transactions anymore. This would be a huge problem in this ecosystem as user would then need to pay for gas for their own transaction and this goes against one of the main ideas around LUKSO and user friendly experience.

In the meantime for 2), no other type of owner contract would be able to own a UP (eg: a Multisig, a Governor contract, etc...). Or if not fully, would be limited.

My suggestion would be to use the existing LSP8 standard with LSP8TokenIdFormat as Address and override the transfer functionality internally as explained in my comment: deploying a UP on minting, and renouncing ownership of the UP on burn (burning is more challenging tho).

Finally this standard is very restrictive in the sense that the holder of the NFT (= token bound profile) is also the owner of the UP (= the one who controls the profile and can setData, execute, etc...). What about if an organisation want to create token bound profiles and be the owner of the tokenIds (= part of their assets portfolio), but want to allow their users to use these UP (by renting these UP to users via a subscription model) so their address are the owner().

These are my reasons why I would not upvote this standard to get it merged into the repo and pushed forward to the ecosystem. However, you can always use this standard and your own implementation regardless if it has been merged, accepted or not (examples are @lykhonis and @jakeprins who proposed the LSP18 standard and used it already on universal.page even before the standard was finally accepted and merged).

Thanks a lot for taking the time to respond. These are great inputs and you're right. Not every concept should be a standard. We'll review our approach with this in mind 🤝