Discussion: GameFi & P2E Contract Ideas

[leovigna]

General Contract Discussion

What are some interesting features we could look to implement beyond general interactive NFT capabilities? Would these require additional smart contracts?

GameFi

GameFi refers the intersection of gaming and finance. This can be play to earn but also other decentralized finance logic such as vesting, staking or trading. Some contract ideas:

• Token Vesting
• P2E
• Staking
• Payment Streaming

Research

Consider researching existing protocols and their different tradeoffs.

[HrikB]

After working on the CrafterMint.sol contract, it became apparent to me that use of tokenIds to determine which tokens should be reserved by the contract for minting was a little overkill. Generally, when it comes to crafting in the context of gaming, uniqueness among different outputs of the same type do not need to be denoted (this is most easily shown by a quantity feature in said games, or stacking). If there is a piece of leather, there is no tangible different among two pieces of leather. While there are some unique use cases in which differentiating between the same type of outputs can be useful (perhaps, loot boxes), not differentiating seems to be the more common occurrence.

For this purpose, ERC1155 seems to be a much better fit for NFT Crafting. ERC721 crafting still could be useful and the more options our platform provides the better, but ERC1155 crafting would more aptly fit the general case of non-unique outputs. Additionally, ERC1155 would more easily allow different types of crafting outputs to be created. From the openzeppelin docs:

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";

contract GameItems is ERC1155 {
    uint256 public constant GOLD = 0;
    uint256 public constant SILVER = 1;
    uint256 public constant THORS_HAMMER = 2;
    uint256 public constant SWORD = 3;
    uint256 public constant SHIELD = 4;

    constructor() public ERC1155("https://game.example/api/item/{id}.json") {
        _mint(msg.sender, GOLD, 10**18, "");
        _mint(msg.sender, SILVER, 10**27, "");
        _mint(msg.sender, THORS_HAMMER, 1, "");
        _mint(msg.sender, SWORD, 10**9, "");
        _mint(msg.sender, SHIELD, 10**9, "");
    }
}

Different outputs can all be stored on the same contract and if limits are required, they can enforced by our contracts (leaving the option to the game developer). And on top of that, using an upgradable proxy, we can make it possible to add more types of outputs if the game developer wished it so.

[corbanvilla]

A few other thoughts for some gas optimizations:

Since an event is emitted on recipe creation with required ingredients, we could optimize an 1155 or erc20 version by not actually storing uint amount and address token for every ingredient but instead only storing a hash of all of the relevant ingredients put together.

Clients could then read the event, put together a recipe and form the transaction and the only thing the contract has to do is verify. This way we only store from one slot on recipe creation, and read from one slot for each craft (not including the external token transfers).

[corbanvilla]

Games like TF2 developed a community which frequently traded cosmetic items and trinkets. Within the NFT marketplace, it could make sense to incorporate a trading system leveraging a smart contract to escrow the transaction.

[corbanvilla]

https://polygontech.medium.com/knightlands-is-coming-to-polygon-9ed025d5709c

[HrikB]

Games like TF2 developed a community which frequently traded cosmetic items and trinkets. Within the NFT marketplace, it could make sense to incorporate a trading system leveraging a smart contract to escrow the transaction.

I like this idea. From a development standpoint we could honestly just fork the nfttrader.io contracts (dk if there's any moral implications of that). And from a business standpoint, having an escrow run as a loss leader (with no fees) would be a great way to get attention onto our marketplace.