robertoschler
over 1 year ago  Karma: 50
Does an ERC721 contract have to rely on an external agent to be the approved spender?

I am creating a dApp that services a game. The "house" in the game is my game server that creates the smart contract using Web3.js. It also owns all the non-fungible assets at the start of the game, all the tokens. My current intention is to create a smart contract that inherits the Open Zeppelin ERC721 smart contract. This smart contract will handle the awarding of the non-fungible assets, aka the tokens, to the various players as during the game.

I just finished this article on the Open Zeppelin ERC721 token implementation:

https://medium.com/blockchannel/walking-through-the-erc721-full-implementation-72ad72735f3c

The article states that the ERC721 token works with external contracts that handle the spending logic, and that the address for that "agent" contract is put in the main contract's "allowed" map so the contract knows they are an "approved" spender. If I understand things correctly, the ERC721 token acts as the managing entity for token ownership record-keeping and facilitating the integrity of token transfer and allowances, while another smart contract handles the logic involved in spending/transferring tokens.

Is there any harm or risk in not using the external approved spender strategy? Instead, why not simply have a public call in my ERC721 derived smart contract that does the transfer directly when called by the contract owner, which would be the "house" in my case? I'm trying to figure out why this extra layer of complexity, that of using another smart contract acting as the "approved spender", is necessary or is recommended?

en
ERC721
solidity
robertoschler
over 1 year ago  Karma: 50
Does an ERC721 contract have to rely on an external agent to be the approved spender?

I am creating a dApp that services a game. The "house" in the game is my game server that creates the smart contract using Web3.js. It also owns all the non-fungible assets at the start of the game, all the tokens. My current intention is to create a smart contract that inherits the Open Zeppelin ERC721 smart contract. This smart contract will handle the awarding of the non-fungible assets, aka the tokens, to the various players as during the game.

I just finished this article on the Open Zeppelin ERC721 token implementation:

https://medium.com/blockchannel/walking-through-the-erc721-full-implementation-72ad72735f3c

The article states that the ERC721 token works with external contracts that handle the spending logic, and that the address for that "agent" contract is put in the main contract's "allowed" map so the contract knows they are an "approved" spender. If I understand things correctly, the ERC721 token acts as the managing entity for token ownership record-keeping and facilitating the integrity of token transfer and allowances, while another smart contract handles the logic involved in spending/transferring tokens.

Is there any harm or risk in not using the external approved spender strategy? Instead, why not simply have a public call in my ERC721 derived smart contract that does the transfer directly when called by the contract owner, which would be the "house" in my case? I'm trying to figure out why this extra layer of complexity, that of using another smart contract acting as the "approved spender", is necessary or is recommended?

en
ERC721
solidity

3 ANSWERS
vivalebastian
over 1 year ago Karma: 784

Would love to see this game when you're ready to show it off ^

Would love to see this game when you're ready to show it off ^

j0zffrazier
7 months ago Karma: 0

I was recently programming around this, and I'm researching to make sure I have considered all aspects, if anybody else has more to add regarding using external approval contracts that would be interesting to know. Just a side note, for those who are doing transfers internally from their primary contract and want to avoid the requirement of setting and using the approval process, you can programmatically do the transfer from within your solidity contract, using the openzepplin implementation, you can use the internal function _transferFrom(from, to, tokenId); which bypasses the approval process :-)

I was recently programming around this, and I'm researching to make sure I have considered all aspects, if anybody else has more to add regarding using external approval contracts that would be interesting to know. Just a side note, for those who are doing transfers internally from their primary contract and want to avoid the requirement of setting and using the approval process, you can programmatically do the transfer from within your solidity contract, using the openzepplin implementation, you can use the internal function _transferFrom(from, to, tokenId); which bypasses the approval process :-)

Earn tokens by posting and answering questions about blockchain!
Karma to eth
YOUR ANSWER