draft: LIP-27 - Token Bound Profiles Proposal #304

ValentineCodes · 2024-09-14T10:17:59Z

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.

Update lip-27.md

JordyDutch · 2024-09-15T22:07:05Z

👏🏼🚀🤝🏼

tantodefi · 2024-09-16T14:49:50Z

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 · 2024-09-16T21:57:37Z

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

YamenMerhi

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 ..

LIPs/lip-27.md

frozeman · 2024-09-26T08:17:59Z

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

ValentineCodes · 2024-09-26T08:33:49Z

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 · 2024-09-30T13:27:44Z

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

Co-authored-by: Yamen Merhi <[email protected]>

ValentineCodes · 2024-10-04T07:58:08Z

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 · 2024-10-04T08:08:20Z

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

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:

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.
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).

CJ42 · 2024-11-05T20:50:17Z

LIPs/lip-27.md

+
+## Simple Summary
+
+LIP-27 introduces a standard for creating Token Bound Profiles (TBP) using **LSP8 Identifiable Digital Assets** and **Universal Profiles (LSP0)**. This standard enables LSP8 tokens to be associated with a Universal Profile, facilitating token-based ownership and interaction.


Suggested change

LIP-27 introduces a standard for creating Token Bound Profiles (TBP) using **LSP8 Identifiable Digital Assets** and **Universal Profiles (LSP0)**. This standard enables LSP8 tokens to be associated with a Universal Profile, facilitating token-based ownership and interaction.

LSP-27 introduces a standard for creating Token Bound Profiles (TBP) using **LSP8 Identifiable Digital Assets** and **Universal Profiles (LSP0)**. This standard enables LSP8 tokens to be associated with a Universal Profile, facilitating token-based ownership and interaction.

CJ42 · 2024-11-05T20:52:24Z

LIPs/lip-27.md

+Key components include:
+
+- A **Registry Contract** that maps LSP8 token identifiers to their respective Universal Profiles.
+- A modified **Universal Profile** contract that restricts execution rights to the token owner.


So the owner() of a UP is the holder of the NFT? What happen if I want my UP to be owned by a KeyManager?

CJ42 · 2024-11-05T20:56:13Z

LIPs/lip-27.md

+
+As NFTs and tokenized assets proliferate, there is a need for tokens to have autonomous profiles capable of holding assets, executing contracts, and interacting with decentralized applications. **LIP-27** facilitates this functionality within the Lukso ecosystem using **LSP8 tokens** and **Universal Profiles**.
+
+This approach enhances the utility of tokens by allowing each token to have its own programmable, self-sovereign profile, while maintaining compatibility with Lukso’s standards for identity (**LSP0**) and digital assets (**LSP8**).


I think this can be done with LSP8 using the tokenIdFormat address.

A custom implementation of LSP8 (within the Solidity code, for instance via the _afterTokenTransfer(...) hook could:

deploy a new UP contract when minting a tokenId (as standalone or proxy linked to an implementation)

renounceOwnership of the UP on burning

CJ42 · 2024-11-05T20:57:38Z

LIPs/lip-27.md

+The system consists of two primary components:
+
+1. A **singleton registry** for Token Bound Profiles.
+2. A common **Universal Profile implementation** modified to support LSP8 ownership, while adhering to the `LSP0-ERC725Account` interface.


Is there a link to a repo where we can see the Solidity code of this custom implementation?

CJ42 · 2024-11-05T20:58:54Z

LIPs/lip-27.md

+        address profile,
+        address indexed implementation,
+        bytes32 salt,
+        uint256 chainId,


Why having the chainId here? This does not seem necessary. A UP exists only on a specific chain.

CJ42 · 2024-11-05T21:23:47Z

LIPs/lip-27.md

+
+- **Purpose**; This function permanently deletes the token contract and ID from storage, leaving the profile without an owner.
+
+## Rationale


I do not find this section clear. This is an important one for proposing a new standard.

It does highlight generically the potential benefits (although I find these more generic statements than specific advantages or problems being solved by the standard).

I would suggest to review this section carefully if looking to push this standard, as the rationale is what motivate the developers and projects in the ecosystem to adopt the standard, as it solves their specific needs.

CJ42 · 2024-11-05T21:29:42Z

LIPs/lip-27.md

+
+## Backwards Compatibility
+
+LIP-27 is fully compatible with existing **LSP0** and **LSP8** standards. It introduces no breaking changes to the Universal Profile or Identifiable Digital Asset contracts.


This is a very strong statement. By the look of the function section above, it seems to break partially LSP14 which is part of LSP0. Although this could be debatable to the extent.

The bigger problem is that this standard proposal breaks composability over "who can be the owner of the UP". In the sense "control the UP". Ownership and control (via the owner() function) are two very different things

CJ42 · 2024-11-05T21:30:39Z

LIPs/lip-27.md

+
+LIP-27 is fully compatible with existing **LSP0** and **LSP8** standards. It introduces no breaking changes to the Universal Profile or Identifiable Digital Asset contracts.
+
+- **LSP0 (Universal Profile)**: The modifications to the Universal Profile contract under LIP-27 are backward compatible and do not alter the existing interface. The contract logic is adapted to incorporate LSP8 token ownership without disrupting the standard functionality.


Yes that's correct from the public interface point of view. So this statement nuances my previous comment above.

However, it does disrupt the standard functionalities.

CJ42 · 2024-11-05T21:33:00Z

LIPs/lip-27.md

+
+- An LSP8 token could be transferred to its own token bound account. If this occurs, both the LSP8 token and all assets stored in the token bound account would be permanently inaccessible, as the token bound account is incapable of executing a transaction that transfers the LSP8 token.
+
+Application clients and account implementations wishing to adopt this proposal are encouraged to implement measures that limit the possibility of ownership cycles.


This must be enforced at the smart contract level. But this my not be applicable as I believe LSP14 Ownable 2 Steps mention in the specs that it cannot transfer ownership to self (to be verified)

CJ42 · 2024-11-05T21:34:25Z

LIPs/lip-27.md

+- Alice withdraws 10 LYX from the token bound account and immediately accepts Bob’s offer.
+- Bob receives token X, but account Y is empty.
+
+To mitigate fraudulent behavior by malicious account owners, decentralized marketplaces should implement protection against these sorts of scams. Here are a few mitigation strategies to consider:


Interesting section 👀

CJ42 · 2024-11-05T22:09:07Z

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 · 2024-11-18T14:23:35Z

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:

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.

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 🤝

ValentineCodes and others added 5 commits September 14, 2024 11:14

docs: LIP-27 - Token Bound Profiles Proposal Initial Draft

de11e54

refactor: change acronym

f3a3c4b

refactor: clean up

88e8cd0

Update lip-27.md

4a82d29

Merge pull request #1 from tantodefi/patch-1

5a14787

Update lip-27.md

ValentineCodes changed the title ~~draft: LIP-27 - Token Bound Profiles Proposal Initial Draft~~ draft: LIP-27 - Token Bound Profiles Proposal Sep 16, 2024

ValentineCodes added 2 commits September 16, 2024 22:42

refactor: add author

582f86c

fix: authors table

de70618

YamenMerhi reviewed Sep 26, 2024

View reviewed changes

LIPs/lip-27.md Outdated Show resolved Hide resolved

refactor: change description

96a93f2

Co-authored-by: Yamen Merhi <[email protected]>

CJ42 requested changes Nov 5, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

draft: LIP-27 - Token Bound Profiles Proposal #304

draft: LIP-27 - Token Bound Profiles Proposal #304

ValentineCodes commented Sep 14, 2024

JordyDutch commented Sep 15, 2024

tantodefi commented Sep 16, 2024

ValentineCodes commented Sep 16, 2024 •

edited

Loading

YamenMerhi left a comment

frozeman commented Sep 26, 2024

ValentineCodes commented Sep 26, 2024

frozeman commented Sep 30, 2024

ValentineCodes commented Oct 4, 2024

ValentineCodes commented Oct 4, 2024

CJ42 left a comment

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 Nov 5, 2024

CJ42 commented Nov 5, 2024

ValentineCodes commented Nov 18, 2024


		## Simple Summary

		LIP-27 introduces a standard for creating Token Bound Profiles (TBP) using LSP8 Identifiable Digital Assets and Universal Profiles (LSP0). This standard enables LSP8 tokens to be associated with a Universal Profile, facilitating token-based ownership and interaction.

	LIP-27 introduces a standard for creating Token Bound Profiles (TBP) using LSP8 Identifiable Digital Assets and Universal Profiles (LSP0). This standard enables LSP8 tokens to be associated with a Universal Profile, facilitating token-based ownership and interaction.
	LSP-27 introduces a standard for creating Token Bound Profiles (TBP) using LSP8 Identifiable Digital Assets and Universal Profiles (LSP0). This standard enables LSP8 tokens to be associated with a Universal Profile, facilitating token-based ownership and interaction.


		As NFTs and tokenized assets proliferate, there is a need for tokens to have autonomous profiles capable of holding assets, executing contracts, and interacting with decentralized applications. LIP-27 facilitates this functionality within the Lukso ecosystem using LSP8 tokens and Universal Profiles.

		This approach enhances the utility of tokens by allowing each token to have its own programmable, self-sovereign profile, while maintaining compatibility with Lukso’s standards for identity (LSP0) and digital assets (LSP8).


		- Purpose; This function permanently deletes the token contract and ID from storage, leaving the profile without an owner.

		## Rationale


		## Backwards Compatibility

		LIP-27 is fully compatible with existing LSP0 and LSP8 standards. It introduces no breaking changes to the Universal Profile or Identifiable Digital Asset contracts.


		LIP-27 is fully compatible with existing LSP0 and LSP8 standards. It introduces no breaking changes to the Universal Profile or Identifiable Digital Asset contracts.

		- LSP0 (Universal Profile): The modifications to the Universal Profile contract under LIP-27 are backward compatible and do not alter the existing interface. The contract logic is adapted to incorporate LSP8 token ownership without disrupting the standard functionality.


		- An LSP8 token could be transferred to its own token bound account. If this occurs, both the LSP8 token and all assets stored in the token bound account would be permanently inaccessible, as the token bound account is incapable of executing a transaction that transfers the LSP8 token.

		Application clients and account implementations wishing to adopt this proposal are encouraged to implement measures that limit the possibility of ownership cycles.

draft: LIP-27 - Token Bound Profiles Proposal #304

Are you sure you want to change the base?

draft: LIP-27 - Token Bound Profiles Proposal #304

Conversation

ValentineCodes commented Sep 14, 2024

JordyDutch commented Sep 15, 2024

tantodefi commented Sep 16, 2024

ValentineCodes commented Sep 16, 2024 • edited Loading

YamenMerhi left a comment

Choose a reason for hiding this comment

frozeman commented Sep 26, 2024

ValentineCodes commented Sep 26, 2024

frozeman commented Sep 30, 2024

ValentineCodes commented Oct 4, 2024

ValentineCodes commented Oct 4, 2024

CJ42 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CJ42 commented Nov 5, 2024

ValentineCodes commented Nov 18, 2024

ValentineCodes commented Sep 16, 2024 •

edited

Loading