Does an ERC721 contract have to rely on an external agent to be the approved spender?

Question

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?

Answer 1

I understand that you are questioning the operator and approved workflows in the ERC-721 standard.

From your perspective you do not need to worry about those and you can keep the reference implementation behavior. You might consider that the end user is using your dApp. But in actuality the end user may be delegating their ownership of the token to an exchange or some other entity/wallet. That is why that level of indirection exists.