NFT as an account (NFTAA) #2396
Conversation
github-actions
bot
added
the
admin-review
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
|
I have read and hereby sign the Contributor License Agreement. |
fix table, delete eth addr
Add 0 requirements to milestones 2 and 3
|
@Noc2 thank you for your feedback. Our application has been modified and default deliverables 0a-0d have been added to milestones 2 and 3. The point about the article in milestone 3 has been modified from 3a to 0e to make it consistent with the templates. We believe that our application now complies with all the necessary formalities. |
There was a problem hiding this comment.
Thank you for the application and the long wait, @Roman-24.
This looks like an interesting idea. However, I'm a bit wary of another NFT pallet. We have supported several NFT implementations, each with their own twist, but few have actually been integrated into parachains or seen much adoption. Can you elaborate what your intention is here? From the looks of it, this is more of an "applied research" exercise than anything.
|
@semuelle Thank you for your feedback. Our goal is to expand the boundaries of how web3 uses NFTs today. It's an extension of how current NFTs are used, adding a whole new set of capabilities. Another feature addresses the problem of current account illiquidity. If you want to change the owner of an account (or, for example, a locked staking), there is no secure way to do it (except by sharing private keys (unsecure thing)). In our proposal, we are primarily focusing on the use case within staking, but there are several other use cases, which we have addressed in the "Business Overview" subsection. The implementation of this idea makes sense and is supported by the fact that there is a similar proposal for Ethereum, which we have discussed in the "Differences and Distinctions (NFTAA vs. EIP-6551)" paragraph. As mentioned in the proposal, we have already conducted research on this topic, along with some prototypes. Therefore, we now want to move towards a real implementation that will provide value to real users. |
There was a problem hiding this comment.
we now want to move towards a real implementation that will provide value to real users.
Thanks for the clarification, @Roman-24. My question was more geared towards understanding whether you are planning to deploy this yourself or if you have parachain teams interested in it. But either way, it looks like an interesting project to me, so I'm giving my approval and will share it with the rest of the committee.
In the meantime, could you fill out the KYB form (assuming you are applying as a company, otherwise please use this form)?
semuelle
added
ready for review
|
We have completed the KYB and therefore verification is in process. We are glad you like our idea and thank you for your support @semuelle. We will definitely communicate with the parachains, we believe we have a good network for that. |
| The second approach involves using smart contracts. For this proposal, we prefer the pallet approach due to its | ||
| integration capabilities and performance benefits. |
There was a problem hiding this comment.
According to my understanding you are forced to set up this solution on a pallet level to integrate this solution with other pallets. This wouldn't work this smart contracts. Especially not now while Kusama and Polkadot don't support smart contracts yet. So sounds like the right decision.
There was a problem hiding this comment.
We are glad that you agree with our decision of tech details.
According to our information there are some possibilities to do smart contracts, but we think it's only possible on some parachains (https://wiki.polkadot.network/docs/build-smart-contracts).
Anyway, if there will be NFTAA pallet in the future it will be possible to add chain extensions and bring this functionality to smart contract layer.
There was a problem hiding this comment.
I don't see anything about chain-extensions mentioned in the doc and I think this is a deprecated feature. Would be great if you can check on this. Also I think if you were to realize this on the smart-contract level then you can only have this logic be applied on the smart contract level. You wouldn't be able to influence the chain level. Please correct me if I'm wrong.
There was a problem hiding this comment.
It looks like you are correct, anyway what is stated in the proposition remains valid because to integrate this solution to other pallets, our preferred way is through the pallet approach. But definitely, we will need to freshen up our state of the art in our minds based on our chain extension not knowledge :))))
| Attributes are crucial for enterprise use cases, allowing NFTAAs to be marked as entities such as companies or departments | ||
| within a corporate structure. |
There was a problem hiding this comment.
From our point of view, this is an opportunity to differentiate between already existing unique NFTs inside one company. To better manage and govern the orgs represented by NFTAAs or to add additional information to the NFT that is needed to implement the usecase we are writing about.
There was a problem hiding this comment.
We already have the identity pallet which is able to represent additional information linked to an account. Given that this is the established way of linking information to an account I suggest to re-evaluate this strategy. This NFT attribute approach would introduce unnecessary overhead to existing projects that aggregate data linked to accounts. e.g. Polkassembly.
There was a problem hiding this comment.
Thanks for this comment and I'm sure it can be used since NFTAA will be like an account so it shouldn't be a problem to join. However, in our case we were thinking more of the technical attributes but thus the detail will only be clear when implemented. We just wanted to have the "corridor" more open so we don't promise something which could be potentially improved.
| Regarding security, there are at least two differences between NFTAA and TBA. The first is the possibility of generating the address of TBA sooner without having the deployed contract (as the create2 function for creating contracts is deterministic, i.e., you can calculate the future contract address). | ||
| In this case, if the upcoming smart contract is badly developed (does not contain an execute function for byte calls to other contracts) or is not upgradeable, it can happen that assets or liquidity sent to the TBA will not be withdrawable and become locked forever (even the NFT bounded in TBA can be sent by a mistake (if not safeguarded) to the address of TBA. Therefore you lock yourself from it). | ||
| The problem is that TBA uses only the address of any contract you want in the registry contract and does not look for any details on how the contract looks or if it is already deployed. In our case, the account form is pre-defined in the factory pallet, and even after deployment, we guarantee upgradeability as it is a proxy account. | ||
| The second security issue is potential fraud, which is [described in the EIP 6551 specification](https://eips.ethereum.org/EIPS/eip-6551\#fraud-prevention) that you withdraw assets from the TBA and at the same time sell the NFT to someone who thought that they would also have the assets in the TBA. In our case, we provide the security measures for not withdrawing the assets from the NFTAA while also selling the NFT, which is bound to the NFTAA. |
There was a problem hiding this comment.
Will these security measures be included in your currently developed pallet? I don't see it in the milestones.
There was a problem hiding this comment.
We will try to address this problem within existing features, but at this point we cannot exclude the possibility that this mechanism may need to be improved later.
There was a problem hiding this comment.
for example, one possibility is: If NFTAA is listed you will not be able to sell assets owned by NFTAA
| | Number | Deliverable | Specification | | ||
| |-------:|-------------------------|------------------------------------------------------------------------------------------------------------------------------------| | ||
| | **0a.** | License | MIT | | ||
| | **0b.** | Documentation | Inline documentation of code, as well as startup configuration with all necessary commands, included in repository | | ||
| | **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | ||
| | **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | ||
| | 2a. | nftaa_check | We will add functionalities to read and check if NFTAA exists for a given account | | ||
| | 2b. | nftaa_collections | We will add functionalities to read existing collections and manage NFTAAs if they are in a collection. | | ||
| | 2c. | nftaa_stake/unstake | The functionality needed to do stake/unstake operations on behalf of NFTAA, its like deposit/withdrawal functions | | ||
| | 2d. | nftaa_increase/decrease | Functions needed to increase or decrease stake by NFTAA, this is needed for full compatibility with traditional methods of staking | |
There was a problem hiding this comment.
I'm confused by this milestone. Previously you described your project as a solution to use the NFTAAs as virtual keyless accounts which are able to do anything a regular account can. Yet this milestone sounds like you are putting in a lot of work to make your solution compatible with the existing pallets for staking. If this is indeed necessary I think you should try to find a more generic solution which doesn't create this overhead for every pallet you want to support with NFTAAs.
There was a problem hiding this comment.
We don't want to do this for every pallet and we certainly want our solution to be generic, but the case of staking is special and therefore we want to have these functionalities explicitly ready. But it still applies NFTAAs are virtual keyless accounts which are able to do anything a regular account can.
There was a problem hiding this comment.
We believe staking is an ideal use case to showcase how NFTAA operates because it's a concept that many users are already familiar with, making it easier to grasp the potential of NFTAA. Additionally, staking plays a crucial role in maintaining network security, making it a fitting example to demonstrate the robustness and functionality of NFTAA in a practical environment.
There was a problem hiding this comment.
I know what staking ist. I just don't understand your answer. If you are planning to make your solution generic as in "this NFTAA can be used just like a regular account", then why do you need to put in any work to make your solution compatible with the staking pallet. I hope you understand where my issue is here. Staking is already supported for regular accounts. With you adding just another layer on top of accounts with this form of account abstraction I don't understand why you would need to modify anything below this account level. E.g. How individual pallets work with accounts.
There was a problem hiding this comment.
Maybe we don't fully understand your concerns. In our eyes, as mentioned, staking is a use case to show NFTAA in some scenario. The NFTAA will be generic, but without showcasing its potential, noone will use it, or know about it. We invest focus into development to help users as much as we can to use NFTAA in any kind of use case they think is a good fit. And as staking is a well-known word to everyone, therefore we decided to put as a showcase in the proposal staking. That was the only reason, the proposal is meant for "non-fungible tokens as accounts" not "non-fungible tokens as accounts for staking".
We prefer to have staking explicitly mentioned in the proposal, but do you prefer to remove these explicitly mentioned functionalities?
|
@PieWol thank you so much for your effort to review our proposal. We've tried to answer your questions as best we can. If there is still something that is not clear we will be happy to continue the discussion. |
keeganquigley
removed
the
admin-review
github-actions
bot
added
the
admin-review
keeganquigley
removed
the
admin-review
|
Would there be anything we can do to help move things forward? Please feel free to let me know if there’s anything needed from our side. Thank you |
|
Hey @Roman-24 , |
There was a problem hiding this comment.
Thanks for your comments. I answered or marked the conversations as resolved. Looking forward to your answers to all unresolved comments. I appreciate the time and effort you are putting into this to explain your project and that you are incorporating our feedback 🙏
|
Thank you for reviewing and resolving the conversations. We appreciate your feedback and have addressed all unresolved comments. Your insights were valuable in refining the project, and we’re grateful for your collaboration. |
Project Abstract
NFT as an Account (NFTAA) is an innovative project aimed at revolutionizing the use of NFTs within the blockchain ecosystem, particularly in the Substrate based networks like Polkadot and Kusama. The project seeks to leverage the unique properties of NFTs to function as proxy accounts, enhancing interoperability, security, and flexibility across various blockchain networks. By enabling NFTs to hold assets, stake, and interact with other blockchain components similarly to standard accounts, NFTAA introduces a novel approach to blockchain interactions.
Grant level
Application Checklist
project_name.md).@_______:matrix.org(change the homeserver if you use a different one)