- [Q1] Which of the following is/are true?
(A): NFT ownership is tracked by _ownerOf true
(B): NFT balance is tracked by _balanceOf true
(C): NFT approvals are tracked by getApproved > 他のもあるよ
(D): NFT operator can transfer all of owner’s NFTs
- [Q2] InSecureumERC721 recognizes the following role(s)
(A): Owner
(B): Spender (Approved address)
(C): Operator
(D): None of the above
- [Q3] The security concern(s) addressed explicitly in _mint include
(A): Prevent minting to zero address true
(B): Prevent reminting of NFTs true
(C): Transparency by emitting event
(D): None of the above
- [Q4] The security concerns in _burn include
(A): Anyone can arbitrarily burn NFTs true
(B): Potential integer underflow because of unchecked none
(C): Incorrect emission of event no
(D): None of the above
- [Q5] The security concern(s) addressed explicitly in _safeMint include
(A): Validating if the recipient is an EOA >>
(B): Ensuring that the recipient can only be an EOA bad nonono
(C): Validating if the recipient is an ERC721 aware contract true
(D): None of the above
- [Q6] Function approve
(A): Allows the NFT owner to approve a spender true
(B): Allows the NFT spender to approve an operator no
(C): Allows the NFT operator to approve a spender true
(D): None of the above
- [Q7] Function setApprovalForAll
(A): Approves msg.sender to manage operator’s NFTs > true
(B): Gives everyone approval to manage msg.sender’s NFTs > no
(C): Revokes everyone’s approvals to manage msg.sender’s NFTs >
(D): None of the above
- [Q8] The security concern(s) in transferFrom include
(A): Allowing the msg.sender to transfer any NFT
(B): NFTs potentially stuck in recipient contracts
(C): Potential integer underflow
(D): None of the above