Posted By : Tushar
For a predetermined period, NFT owners can lease their tokens to third parties via ERC 4907. This functionality allows different players or users to temporarily use the NFTs in various applications, such as virtual real estate or gaming.
The roles involved in this process include the Owner, who possesses the NFT; the User, who has the NFT in their wallet but is unable to sell or transfer it; and the 'expires' function, which automatically ends usage without any further action required.
A controller or operator role is assigned to oversee a large number of NFTs. While they can perform certain usage operations, individuals in these roles are unable to approve or transfer the NFT, unlike the owner.
As an extension of ERC-721, the ERC 4907 standard introduces the dual roles of 'owner' and 'user' at the application layer. With an automatic 'expires' mechanism that enforces the user's time-limited role, ERC 4907 simplifies NFT rentals. Thanks to this innovative feature, NFTs are automatically rentable; owners no longer need to manually revoke user privileges, saving time and avoiding additional on-chain transactions.
The main challenge arises in usage rights management, making it essential to establish a unified standard to facilitate collaboration across all applications.
It's becoming more and more common in the world of digital assets for non-fungible tokens (NFTs) to use the new Ethereum token standard, ERC 4907. In order to facilitate the temporary transfer of usage rights while maintaining ownership, it creates a new 'user role' that is distinct from the 'owner role.' This is advantageous for subscription or rental models.
In order to enable NFT rentals, Double Protocol has incorporated ERC 4907, allowing asset owners to lease without forfeiting ownership. This expands the utility of NFT and opens up new revenue streams. By including ERC 4907-based rental options, their relationship with Shardeum, a scalable smart contract platform, improves this strategy even further and fosters an NFT ecosystem that is more widely available.
These collaborations highlight the real-world applications and transformative potential of ERC 4907, leading to a more dynamic digital asset market. As these partnerships develop, they promise significant changes in the landscape of NFTs and digital ownership.
You may also like | How to Implement an On-Chain NFT Allowlist
Players can rent rare in-game items or characters temporarily, allowing for access to premium content without a full purchase.
Users can rent virtual plots of land or properties in metaverse platforms for specific events or time periods.
Artists can rent their works for exhibitions or shows, allowing more people to experience the art without ownership.
Also, Explore | NFT ETFs | A Beginner's Guide to Investing in Digital Assets
The blockchain used the actual world as a source for the concept of renting. Instead of paying money to use something that the other party has, one party wants it but cannot afford to own it or doesn't need it. People adore the thought of living off the returns from their assets, exactly like in the real world. Rentable NFTs' primary concept is that they are a passive revenue source.
ERC 4907 will enhance NFT renting and enable related derivatives across various use cases, such as gaming, art, and music. As the Metaverse and Web3 expand, more people will opt to rent NFTs instead of buying assets, increasing market liquidity over time.
ERC 4907, which establishes a single standard, will enhance collaboration and assist Ethereum's cross-platform ecosystem. This standard improves communication between all parties engaged in utility NFT leases for gaming, the metaverse, and membership cards by simplifying integration and reducing development costs.
Moreover, third-party protocols employing ERC 4907 may oversee NFT usage rights without needing permission from the initial issuer. Others can swiftly do their own tasks when a project gives users this position. A PFP NFT, for instance, may be included in a platform that permits short-term rentals and simultaneously offers 'rent-to-own' options via a mortgage platform without the original project's permission.
By introducing an extended function set, the ERC 4907 standard can achieve full ERC-721 compatibility. Furthermore, there are a lot of parallels between the new functions provided in this standard and the current ERC-721 functionalities. This makes it possible for developers to embrace the new standard swiftly and simply. Future and current NFTs produced as standard ERC-721 can be wrapped to be compatible with ERC 4907 or upgraded to ERC 4907.
Also, Read | How to Create a Compressed NFT on Solana
Owners can lease their digital assets while maintaining ownership according to ERC 4907, which permits NFTs to be rented out. For asset holders, this means additional revenue prospects.
This standard increases the functionality of NFTs and encourages their wider use across a range of industries, including gaming and virtual real estate, by allowing them to be rented.
In the NFT space, the standard fosters innovation by creating opportunities for new applications including digital art exhibitions, virtual events, and game rentals.
Also, Check | A Step-by-Step Tutorial of Building a Cross Chain NFT Bridge
1. In situations when the rental mechanism is not thoroughly monitored, users may take advantage of it. For example, they may rent an NFT for a very little time in order to swiftly transfer it without the owner's permission.
2. Legal concerns may arise from renting digital assets, particularly if the NFTs include copyrighted content or other intellectual property. Users might have to make sure local laws are followed.
Also, Discover | NFT-Based Loyalty Programs: Revamping Customer Engagement
// function setUser(uint256 tokenId, address user, uint64 expires) external
Main Purpose: Assigns a user to an NFT along with an expiration time.
Parameter:
tokenId: Unique Identifier of NFT
user: the address of new user who can Use NFT
exepires: duration until which the user can access the NFT
Access-Control : Usually callable from an authorised address or the NFT owner. This guarantees that user access can only be modified by authorised entities.
// function userOf(uint256 tokenId) external view returns (address);
Purpose: identifies the NFT's engaged user.
Parameters:
tokenId:Unique Identifier of NFT.
Returns: The user's address. It returns the zero address (address(0)) in the event that the user has expired or if no user is allocated.
// function userExpires(uint256 tokenId) external view returns (uint256);
Purpose: retrieves the NFT user's expiration timestamp.
Parameters:
tokenId:Unique Identifier of NFT.
Returns: The Unix timestamp indicating the expiration date of the user's access. There is no user when the value is 0.
// Event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires);
Purpose: Emitted whenever a user is assigned or updated for an NFT.
Parameters:
tokenId: unique identifier of the NFT.
user: Address of the new User.
expires: The new expiration timestamp.
Significance: Real-time tracking of user assignments is made possible by this event for both front-end apps and external services.
Also, Read | NFT Domains | Revolutionizing Ownership in the Digital Landscape
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// ERC721 Implementation
contract MyERC721Token {
struct Token {
address owner;
address approved;
}
// Mapping from token ID to token information
mapping(uint256 => Token) private _tokens;
// Mapping from owner to number of tokens
mapping(address => uint256) private _balances;
// Mapping from owner to operator approvals
mapping(address => mapping(address => bool)) private _operatorApprovals;
// Counter for token IDs
uint256 private _tokenIdCounter;
// Events
event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
// Mint a new NFT
function mint(address to) public {
require(to != address(0), 'Cannot mint to zero address');
uint256 tokenId = _tokenIdCounter++;
_tokens[tokenId] = Token(to, address(0));
_balances[to]++;
emit Transfer(address(0), to, tokenId);
}
// Get the balance of an owner
function balanceOf(address owner) external view returns (uint256) {
require(owner != address(0), 'Owner address cannot be zero');
return _balances[owner];
}
// Get the owner of a specific token
function ownerOf(uint256 tokenId) public view returns (address) {
address owner = _tokens[tokenId].owner;
require(owner != address(0), 'Token does not exist');
return owner;
}
// Approve another address to transfer the specified token
function approve(address to, uint256 tokenId) external {
address owner = ownerOf(tokenId);
require(msg.sender == owner, 'Not the token owner');
_tokens[tokenId].approved = to;
emit Approval(owner, to, tokenId);
}
// Get the approved address for a specific token
function getApproved(uint256 tokenId) public view returns (address) {
require(_tokens[tokenId].owner != address(0), 'Token does not exist');
return _tokens[tokenId].approved;
}
// Approve or revoke permission for an operator to manage all tokens
function setApprovalForAll(address operator, bool approved) external {
require(operator != msg.sender, 'Cannot approve oneself');
_operatorApprovals[msg.sender][operator] = approved;
emit ApprovalForAll(msg.sender, operator, approved);
}
// Check if an operator is approved to manage all tokens of the owner
function isApprovedForAll(address owner, address operator) external view returns (bool) {
return _operatorApprovals[owner][operator];
}
// Transfer ownership of a token
function transferFrom(address from, address to, uint256 tokenId) external {
require(msg.sender == from || msg.sender == getApproved(tokenId) || _operatorApprovals[from][msg.sender], 'Not authorized');
require(_tokens[tokenId].owner == from, 'Incorrect owner');
require(to != address(0), 'Cannot transfer to zero address');
// Call before transfer hook
_beforeTokenTransfer(from, to, tokenId);
// Transfer the token
_tokens[tokenId].owner = to;
_tokens[tokenId].approved = address(0);
_balances[from]--;
_balances[to]++;
emit Transfer(from, to, tokenId);
}
// Internal function to clear approval when transferring
function _clearApproval(uint256 tokenId) internal {
if (_tokens[tokenId].approved != address(0)) {
delete _tokens[tokenId].approved;
}
}
// Internal hook to be overridden
function _beforeTokenTransfer(address from, address to, uint256 tokenId) internal virtual {}
}
// Interface for ERC 4907
interface IERC4907 {
event UpdateUser(uint256 indexed tokenId, address indexed user, uint64 expires);
function setUser(uint256 tokenId, address user, uint64 expires) external;
function userOf(uint256 tokenId) external view returns (address);
function userExpires(uint256 tokenId) external view returns (uint256);
}
// ERC 4907 Implementation
contract ERC4907 is MyERC721Token, IERC4907 {
// Custom errors
error CanNotRentToZeroAddress();
error NotOwnerOrApproved();
error InvalidExpire();
struct TenantInfo {
address tenant;
uint64 expires;
}
mapping(uint256 => TenantInfo) internal _tenants;
constructor() {
// Minting initial tokens
for (uint256 i = 1; i <= 10; i++) {
mint(msg.sender); // Minting 10 NFTs
}
}
function setUser(uint256 tokenId, address tenant, uint64 expires) public override {
if (ownerOf(tokenId) != msg.sender && getApproved(tokenId) != msg.sender) {
revert NotOwnerOrApproved();
}
if (tenant == address(0)) {
revert CanNotRentToZeroAddress();
}
if (expires <= block.timestamp) {
revert InvalidExpire();
}
TenantInfo storage ref = _tenants[tokenId];
ref.tenant = tenant;
ref.expires = expires;
emit UpdateUser(tokenId, tenant, expires);
}
function userOf(uint256 tokenId) public view override returns (address) {
TenantInfo storage ref = _tenants[tokenId];
if (ref.expires >= block.timestamp) {
return ref.tenant;
} else {
return address(0);
}
}
function userExpires(uint256 tokenId) public view override returns (uint256) {
return _tenants[tokenId].expires;
}
// Override the transfer function to clear tenant info on transfer
function _beforeTokenTransfer(address from, address to, uint256 tokenId) internal override {
super._beforeTokenTransfer(from, to, tokenId);
TenantInfo storage ref = _tenants[tokenId];
if (from != to && ref.tenant != address(0)) {
delete _tenants[tokenId];
emit UpdateUser(tokenId, address(0), 0);
}
}
}
With the release of ERC 4907, which provides a flexible framework designed specifically for the growing NFT rental industry, non-fungible tokens (NFTs) have evolved tremendously. Its dual-role strategy not only makes rights allocation more clear but also lays the foundation for a range of partnerships and applications. This innovation comes at a perfect time, as it tackles the intricacy of the leasing space and keeps up with the exponential growth of digital assets.
ERC 4907 represents an evolution in the NFT space by introducing rental functionalities, and providing new opportunities for monetization and interaction with digital assets. It opens the door to innovative business models and use-cases across various industries, enhancing the utility of NFTs beyond mere ownership.
The NFT environment is about to change as ERC 4907 redefines digital asset leasing and develops popularity across several ecosystems. A future of innovation and fluidity in digital asset management is promised by the protocol, which also offers increased security, operational efficiency, and a multitude of opportunities. As a major protagonist in the story of digital innovation, ERC 4907 solidifies its position by setting new standards that not only predict future trends but also meet present needs. Need assistance with developing your NFT project, connect with our skilled blockchain and NFT developers to get started.
References:
https://github.com/tronprotocol/tips/blob/master/tip-4906.md
https://ethereum-magicians.org/t/eip-6884-delegatable-utility-tokens-derived-from-origin-nfts/13837/
https://github.com/ethereum/ERCs/blob/master/ERCS/erc-7507.md/
https://github.com/ethereum/web3.py/issues/1351
https://soliditydeveloper.com/erc-1155
https://medium.com/coinmonks/erc-721-tokens-b83d7fc3e740
https://www.kaleido.io/blockchain-blog/how-to-create-and-deploy-an-erc-721-token
https://github.com/OpenZeppelin/openzeppelin-contracts/issues/3659
https://hips.hedera.com/hip/hip-376
October 8, 2024 at 01:12 pm
Your comment is awaiting moderation.