Smart Contract

[annguyen125]

Hi ProngsDev,

I recently reviewed your GameToken smart contract, and I must say it’s a well-structured implementation with great features for minting and managing avatars.
I have a few questions and suggestions to discuss:
-The Avatar struct doesn’t store the owner’s address directly, and instead, a separate avatarToOwner mapping is used. Was this a design choice for gas optimization, or are there other considerations?
-When transferring an avatar, the _tokenIdToAvatar struct doesn’t seem to update directly. Could this cause inconsistency if the avatar’s owner details in the struct are queried?

[ProngsDev]

Hi Pegasus Prongs,

Thank you for your kind words and for taking the time to review the contract! I’m glad you find the implementation interesting. Let me address your questions:
Great observation! The choice to use a separate avatarToOwner mapping instead of embedding the owner’s address directly in the Avatar struct was primarily for flexibility and readability rather than gas optimization. By decoupling the ownership details from the struct, it becomes easier to implement certain functionality, such as transfers and batch processing, without constantly updating the entire Avatar object.

That said, embedding the owner’s address in the struct could simplify ownership queries and reduce the reliance on multiple mappings. I’ll revisit this for optimization in future iterations!

“When transferring an avatar, the _tokenIdToAvatar struct doesn’t seem to update directly. Could this cause inconsistency if the avatar’s owner details in the struct are queried?”

You’re absolutely correct that this could lead to inconsistency if someone relies on the _tokenIdToAvatar data alone to determine ownership. The current implementation assumes ownership checks will primarily use the avatarToOwner mapping or the ERC721’s ownerOf method. However, to ensure the Avatar struct reflects accurate data, we could update its fields (e.g., adding owner) during transfers.