ERC-4610 is an extension of ERC-721 and it aims to provide standardized token rental and loanable protocol for ecological applications such as blockchain games.
Returns the delegator of ERC721.
Delegator is only an attribute of ERC721 for identification, and does not have any direct permissions like {approve} {setApprovalForAll} {transferFrom} {safeTransferFrom}.
function delegatorOf(uint256 tokenId) external view returns (address);Set _delegator as the delegator of the ERC721 with tokenId as _tokenId.
Emits an {SetDelegator} event.
The delegator attribute can be set to address(0), which means the ERC721 has no delegator.
function setDelegator(address _delegator, uint256 _tokenId) external returns (bool);Safely transfers tokenId token from from to to and delegator won't be cleared if reserved is true.
function safeTransferFrom(address from, address to, uint256 tokenId, bool reserved) external;see contracts/ERC4610.sol
Application running on the blockchain, such as blockchain game, can be defined as a state machine. Most blockchain games are based on ERC-721, that is, only the owner has the permission to send a valid transaction that can cause state transition, and it's inconvenience in scenarios such as lending.
ERC-4610 aims to provide standardized token rental and loanable protocol for ecological applications such as blockchain games. ERC-4610 is an extension of ERC-721. In ERC-721, we use owner to determine who has the unique ownership of NFTs. And in ERC-4610, we added a role called delegator.
delegator has no permission to transefer or approve the token, it's a tag of ERC-721. What the delegaotr can do depends on the design and development of the application or game. In general, without affecting the security of assets, the delegator should have the same permissions as the owner. In this way, the delegator can also send a valid transaction and change the state machine.
Note that delegator is only an operator of owner , therefore, the transaction sent by delegator should eventually change the state of owner, not delegator. When it comes to the transfer of assets, the sender should be the owner (not delegator) or other (depending on your app logic), and when the assets are to be transferred out, the recipient should be the owner or other.
The figure above shows how game or applications that are based on ERC-4610 will achieve the goal of NFTs lending and borrowing in a decentralized way.
In the contracts/showcase, you will see an example of how to develop your application or game based on ERC-4610.
In the example, gold is the revenue token, and Digimon is the NFT token. There are a total of five methods involing asset flow, and these five methods will be called by the delegator.
User can claim gold rewards from the Game.
User can levelup his NFT level, and it will consume some gold tokens.
User breeds a Digimon, and will get a new Digimon NFT
User's Digimon goes on an adventure, the NFT will transfer to game contract from owner.
User withdraws his or her Digimon NFT.
- The developers of ERC-4610 should strictly distinguish between
owneranddelegatorfrommsg.sender.require(_onlyOwnerOrDelegator(tokenId))can be used instead ofrequire(_onlyOwner(tokenId))for identity verification ofmsg.sender. - The delegator has the permission to send a valid transaction, but does not hold or handle any related assets. When it comes to the transfer of assets, the
sendershould be theowner(not delegator) or other (depending on your app logic), and when the assets are to be transferred out, therecipientshould be theowneror other. delegatorshould generally have no permission for functions that may cause the loss ofownerassets, such as burning NFTs.- In some cases, the loan contract may not support the transfer of NFTs to the game contract or application contract. Please pay attention to this.