[Ethereum] List ERC721 tokens owned by a user on a web page

dappserc-721

Let's say that I have an ERC721 (NFT) contract that represents a set of playing cards.

Is there sample code out there that shows listing all of the tokens of that ERC721 contract that a user owns on a web page so that the user could select one?

Best Answer

You could add a function to your smart contract that mimics what the CryptoKitties contract does in function tokensOfOwner, which

Returns a list of all Kitty IDs assigned to an address

/// @title The facet of the CryptoKitties core contract that manages ownership, ERC-721 (draft) compliant.
/// @author Axiom Zen (https://www.axiomzen.co)
/// @dev Ref: https://github.com/ethereum/EIPs/issues/721
///  See the KittyCore contract documentation to understand how the various contract facets are arranged.
contract KittyOwnership is KittyBase, ERC721 {

[...]

/// @notice Returns a list of all Kitty IDs assigned to an address.
    /// @param _owner The owner whose Kitties we are interested in.
    /// @dev This method MUST NEVER be called by smart contract code. First, it's fairly
    ///  expensive (it walks the entire Kitty array looking for cats belonging to owner),
    ///  but it also returns a dynamic array, which is only supported for web3 calls, and
    ///  not contract-to-contract calls.
    function tokensOfOwner(address _owner) external view returns(uint256[] ownerTokens) {
        uint256 tokenCount = balanceOf(_owner);

        if (tokenCount == 0) {
            // Return an empty array
            return new uint256[](0);
        } else {
            uint256[] memory result = new uint256[](tokenCount);
            uint256 totalCats = totalSupply();
            uint256 resultIndex = 0;

            // We count on the fact that all cats have IDs starting at 1 and increasing
            // sequentially up to the totalCat count.
            uint256 catId;

            for (catId = 1; catId <= totalCats; catId++) {
                if (kittyIndexToOwner[catId] == _owner) {
                    result[resultIndex] = catId;
                    resultIndex++;
                }
            }

            return result;
        }
    }

TL;DR

Adding an additional function in an ERC-1155 contract that handles the issuance of the ERC-721 tokens it contains. This function would have logic to check the amount of ether being sent to a method. If it's not enough, mint fails. If it's just enough, mint goes through. If it's too much, mint occurs and sends the extra back (minus tx fees) to the owner.

Details

You will have to create an ERC-1155 collection responsible for minting the ERC-721 tokens and define custom logic for price. Any time mint, transfer, or transferTo is called on the NFT, it must call the collection which owns it to determine if the price is enough, right, or too much.

Use Cases

Your logic could be rigid, and place a hard cap on price, or dynamic to allow events like discounts to take place. Since your question is vague, I'll indulge both slightly.

A collection contains many ERC-721 NFTs which may have slightly different properties; a ticket would have metadata like _section, _seat, _gameId and _tokenId.

This is a novel area of development and ripe for improvisation and unique solutions. I would encourage you to think outside the box while working on this project.

Flexible

Unlike traditional markets, you don't need a counterparty to determine the price using this model. The price you get for an asset is determined by a formula. If I'm looking at a single source of ETH:DAI liquidity, and I want to buy all of the ETH, I could not, as each ETH purchased exponentially increases the price with zero as a limit, if either x or y reach zero, the equation doesn't work, our k value goes to zero, making the asset unbuyable.

Static Price

If you want a price set in stone with no change at all, collection need only to limit the maximum number of ETH that can be sent to call the mint function on an NFT within it, with remainder being returned to the purchasing account.

But right now, prices are not always set in stone. There are early bird specials, discounts for purchasing many tickets (e.g. company gatherings), and even discounts after an underwhelming sale to fill seats are all commonplace.

You could loosely define the value of something (arbitrarily) as:

Value = Utility + Ownership History + Future Value + Liquidity

A ticket's has high utility, low/no ownership history impact, no future value, and liquidity varies (depending on number of sold out tickets, hype surrounding the event, number of seats). Compared to a piece of art that's sold 100 times which has low utility, high ownership history, potential future value, and liquidity without an ending time.

Since ownership history and future value are not important for tickets, we have liquidity (availability) and demand.

Value = Availability / Demand

Where demand is dependent on availability. Your 1155 contract would set the initial demand value, and the availability is determined by the number of tokens not claimed by an address in the collection leading up to the event.

A fixed price requires less code, as you simply need to set it's value in the purchasing token. availability is not part of any equation and serves only to see the remaining number of tickets.

In the case of a fluctuating price, demand could be represented as a floating point variable between 0-1. When tickets first go on sale, demand starts at 1 as zero tickets have been minted. We can approach zero, but can never reach it even if there is no demand for tickets as it creates a mathematical impossibility. It is likely that demand will remain constant: people who want to go to something want to go to something regardless. If they can afford it, they'll go. The only thing this does is reduce the price proportionally depending on the number of requests for tickets, which is not unlike tickets to events today where promoters will give discounts just to fill the seats.

Setting the equation up like this also prevents the price from going above the sale price as you cap demand at 1 in the controlling contract. However, you could alter this and allow for some resale within a reasonable range. If it's last minute, sometimes ticket prices do go up (scalpers or not). Perhaps setting demand to a floating point value slightly above one would make more sense.

Note

If the NFT is controlled by an 1155 collection with custom logic, you can define any type of price issuance from fixed price to a bonding curve, or even lower the cost automatically if N number of tickets are still unsold X days prior to the event in order to sell out.

Solidity – Best Method to List All Tokens of a User

This can be achieved by the following:

Declare storage variables at the contract level

mapping(address => uint256[]) public userOwnedTokens;
mapping(uint256 => int256) public tokenIsAtIndex;

mint(tokenId) {
    // Prior minting logic from OpenZeppelin
    userOwnedTokens[msg.sender].push(tokenId);
    uint256 arrayLength = userOwnedTokens[msg.sender].length;
    tokenIsAtIndex[tokenId] = arrayLength;
}

To get all user tokens without loop, all you have to do is, this is possible as the access specifier for userOwnedTokens is public

contractInstance.methods.userOwnedTokens.call(address) // THIS WILL RETURN AN ARRAY OF TOKEN IDs

In case of transfer of tokens, change tokenIsAtIndex[tokenId] to -1

transfer(from, to, tokenId) {
    // Transfer logic
    uint256 tokenIndex = tokenIsAtIndex[tokenId];
    userOwnedTokens[from][tokenIndex] = 000; // TO DENOTE THAT THE TOKEN HAS BEEN TRANSFERRED, YOU CAN USE ANY OTHER NUMBER
 }

Next time when userOwnedTokens is called you can keep a check wherever the tokenId is 000, those tokens have already been transferred and you can decide not to show it to the user on the frontend.

I hope it helps!!!!!