Feature: Add support for ERC721R

[benhalverson]

Would you accept a PR for adding support for ERC721R? I can create the PR.
See https://github.com/exo-digital-labs/ERC721R

From the github repo, you would need to add these functions.

function isRefundGuaranteeActive() public view returns (bool) {
    return (block.timestamp <= refundEndTime);
}

function getRefundGuaranteeEndTime() public view returns (uint256) {
    return refundEndTime;
}

function refund(uint256[] calldata tokenIds) external {
    require(isRefundGuaranteeActive(), "Refund expired");

    for (uint256 i = 0; i < tokenIds.length; i++) {
        uint256 tokenId = tokenIds[i];
        require(msg.sender == ownerOf(tokenId), "Not token owner");
        transferFrom(msg.sender, refundAddress, tokenId);
    }

    uint256 refundAmount = tokenIds.length * mintPrice;
    Address.sendValue(payable(msg.sender), refundAmount);
}

function toggleRefundCountdown() public onlyOwner {
    refundEndTime = block.timestamp + refundPeriod;
}

function setRefundAddress(address _refundAddress) external onlyOwner {
    refundAddress = _refundAddress;
}

[liarco]

Hi @benhalverson, thank you very much for taking the time to make this proposal. I'm gonna move this to the Discussions section since it's invalid as a bug report.

I discussed about this a lot since the ERC721R standard was announced and I have many concerns with it. I feel like this solution doesn't provide with enough safety for users (rag-pullers can just wait a bit more while still being able to behave almost the same) and project owners might not be able to startup their projects properly because they lack certainty about how many funds will be there by the end of the refund period and how much the final value of the base crypto will be.

I understand the reason why the authors wanted to create this solution, but I think it's still not optimal and comes with some downsides that might lead potentially good projects to failure. That's why I don't think I would accept this PR at the moment, but would really like to hear what other people think about my concerns and this solution in general.

[benhalverson]

Where is this discussion you are having?

[liarco]

I simply converted the issue to a discussion so you are already in it 😉

[benhalverson]

I discussed about this a lot since the ERC721R standard was announced and I have many concerns with it.

I was asking about this part of what you wrote. I read this as you had a discussion about this elsewhere. I was asking where?

Can you provide more context on why you think the example doesn't provide enough safety?
What are the specific downsides you see?

The code can be modified to prevent multiple refund requests
It's also possible to set the refund expiration time and amount to refund.
Just like in a normal store it's common to pay a restock fee before returning a product. I think something similar could be implemented.

One example I was thinking of is having a blocklist just like it's common to have a whitelist.

[liarco]

I was asking about this part of what you wrote. I read this as you had a discussion about this elsewhere. I was asking where?

Oh sorry, I was referring to Twitter spaces and DMs I received about the same topic. I think your is the first public request about this.

Can you provide more context on why you think the example doesn't provide enough safety? What are the specific downsides you see?

If you are running a new business out of the funds raised with NFTs (like any "traditional" startup does with capitals from their initial investors), how can you (and your service providers) rely on funds that can be taken away at any point until a given date? That would force you to forget about most of the raised funds (at least all the ones that can be claimed as a refund) and wait before activating any service the would require those funds to be spent.

Another point is crypto volatility. It may be ok to keep some of the funds as crypto as an investment (if your business can afford that), but as soon as people get the token, the project has the responsibility to deliver what's in the roadmap... what if your reference crypto (let's say ETH) dumps by 15% during the "refund time" and then you can't run parts of your roadmap anymore?

For example, let's say you are creating a new clothing brand, you plan to raise a specific amount of ETH based on your business plan and costs estimations. You keep a 5% margin in order to account for volatility and unplanned expenses (more than that might be too much for the token to sell out). You also leave a 50% refund option for 30 days.
During the 30 days you have to deliver something, so people won't feel like they have been scammed, but running a production line for real-life products at 50% of your full spending capability might impact on costs by a huge amount. That might burn huge margins that could otherwise be redistributed straight to holders in case of success.

Unless you are buying pure art (and even in that case there might be exceptions), NFTs are investments on new businesses. Investments shouldn't come with this kind of "warranties", it's unfair and might limit the project growth by a lot.

Talking about "rug-pull" prevention, a rug-pull is a rug-pull even if they can just steal you 30% of the initial sale. I think proper education in the space would provide with much more benefits compared to a refund system for investments.

The code can be modified to prevent multiple refund requests It's also possible to set the refund expiration time and amount to refund. Just like in a normal store it's common to pay a restock fee before returning a product. I think something similar could be implemented.

In my opinion this is the major flaw: an investment on a new business can't be compared to buying a product off-shelf. With most NFT projects the "product" is not the token itself, but something that is not there and MIGHT be created and become successful thanks to the early investors.

One example I was thinking of is having a blocklist just like it's common to have a whitelist.

Keeping bad actors away from collections is almost impossible (as far as I know), because anyone can simply use a new wallet and there is no effective way to prevent this.

What do you think?