Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NFT Core Standard Approved Account IDs Type [NEP] #301

Closed
BenKurrek opened this issue Dec 20, 2021 · 0 comments · Fixed by #303
Closed

NFT Core Standard Approved Account IDs Type [NEP] #301

BenKurrek opened this issue Dec 20, 2021 · 0 comments · Fixed by #303
Assignees

Comments

@BenKurrek
Copy link
Contributor

BenKurrek commented Dec 20, 2021

It was brought to my attention that the core standard implementation has a parameter approved_account_ids which is of type Option<HashMap<AccountId, u64>>. In the core standards, however, the approved_account_ids is of type null|string[].

I'm wondering if this is an error in the core standards for the following reason. If the transfer needs to be reverted and the token should be sent back to its original owner, the contract must also revert the token's approvals map. By passing in a HashMap<AccountId, u64> like the core standard implementation, you can easily revert the token's approvals list as seen both here and here.

I'm wondering how you can revert the token's approvals list if you're only passing in an array of accounts to the function. Please let me know if I'm missing something. It seems like all the contracts I've stumbled across (including the core standard implementation) uses a HashMap and not an array.

Example:
Benji owns a token with the following map:

Token {
  owner_id: Benji
  approvals: {
    marketplace A: 0
    marketplace B: 1
  }
}

Benji then calls nft_transfer_call to transfer the token to Mike. The step by step is as follows:

  1. NFT gets transferred to Mike. This means the state of the token is as follows:
Token {
  owner_id: Mike
  approvals: {}
}

With the next approval ID to be given out being 2.

  1. NFT contract does a cross contract call to Mike's contract. Let's say it returns true meaning that the token should be sent back to Benji:

  2. Resolve transfer gets called. At this point we've got two scenarios based on the conflicting standards.

A) Passing in the hash map of approved account IDs which is the following in our scenario:

approvals: {
    marketplace A: 0
    marketplace B: 1
  }
  • The contract will do its logic and refund the token's approvals (which is empty rn). It will then transfer the token back to Benji. This should, as far as my understanding goes, revert the token's approvals back to it's old state (which is what is passed into the function). This includes the approval IDs given out as well as the accounts themsevles:

This means that the state of the token will be the following after transfer:

Token {
  owner_id: Benji
  approvals: {
    marketplace A: 0
    marketplace B: 1
  }
}

This makes sense and is what a bunch of contracts are doing.

B) If you just pass in an array, you would pass in the following in our scenario:
approvals = [marketplace A, marketplace B]

  • How do you revert the token object back to it's old approvals map if you don't have their original approval IDs? You could use the incrementing approval ID and just reassign the accounts new approval IDs to put in the map but this doesn't seem right to me as it would render all marketplaces useless when it comes to this token since they wouldn't be able to transfer the token.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant