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
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:
Benji then calls nft_transfer_call to transfer the token to Mike. The step by step is as follows:
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.
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:
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:
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.
The text was updated successfully, but these errors were encountered:
It was brought to my attention that the core standard implementation has a parameter
approved_account_ids
which is of typeOption<HashMap<AccountId, u64>>
. In the core standards, however, theapproved_account_ids
is of typenull|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:
Benji then calls
nft_transfer_call
to transfer the token to Mike. The step by step is as follows:With the next approval ID to be given out being
2
.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:
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:
This means that the state of the token will be the following after transfer:
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]
The text was updated successfully, but these errors were encountered: