vectorized / dn404 Goto Github PK

This tripped us up as it causes incorrect method calls to succeed silently rather than revert:

Incorrect call: https://sepolia.etherscan.io/tx/0x1383a9632316ab2b8f8d505422aeead15ba15d041534de53765b2e4739d8cf29
Correct call: https://sepolia.etherscan.io/tx/0x6933ad54b8c372f6b003a09cf02be6c3cee40b7b7fe3bfca2d6fa6723bbddc06

My proposed solution:
guminc/contracts@72dd9c3

ETA: 10 May 2024.

Don't use _mintNext with an active burned pool for now (until the fixes are out).

Default settings are safe.

The best and safest way to deploy a DN404 is to mint out the entire supply in the initializer and distribute the ERC20s via a LP. Use a separate minting contract if needed.

If you have deployed a DN404, and it is searchable on codeslaw, and we haven't contacted you, you should be safe.

All PRs are closed until audit fixes are out.

In our project, we need the batch mint function so that we can perform a certain amount of multiple mints in advance for Airdrops.
I prepared an ownerMint function before, but this causes NFTs to be minted with more than one transaction. I need a feature where I can mint multiple NFTs with a single transaction, like in ERC721A. I would be very happy if you could help me.
Since I am not very experienced in this field, I may make mistakes.

I have only 5 images like Pandora. These images were distributed randomly in the original Pandora contract, but in this contract, I have not yet understood how to add my metadata file. I'm not exactly a developer so please excuse my ignorance. I don't know what kind of metadata file I should add to the setBaseURI section. Is it possible for you to add a sample metadata file, please? Also, if I do everything right, will the 5 images I have be distributed randomly?

how to quick start? i need deploy sample404 and setdatauri with metadata?
i deploy
forge create --rpc-url
--constructor-args "arodnaP" "ARODNAP" "100000000000000000000000" "0x4EE84e71803773EcBF0f312d9FE9752097B2190A"
--private-key
--etherscan-api-key
--verify
src/example/SimpleDN404.sol:SimpleDN404
https://sepolia.etherscan.io/address/0x56a3F935Eb1485A25082CadAd7db5Cfb7693DE5d
pls check

and where whitelist func? when i create pool i need add wl pool address?

Is there a method we know of that locks token and NFT transfer during the Mint transaction? It would be nice if there was a way we could turn the transfer on and off.

Would be great if we have one, since DN404 emits two different type of Transfer events

One of my inner contracts is using safeTransferFrom from https://github.com/vectorized/solady/blob/main/src/utils/SafeTransferLib.sol , for DN404.sol part.
Based on my debugging that doesn't seem to trigger the associated 721 minting/transferring

Am I correct or missing here something?

I decided to take a look at ERC404 and thought I could do it better. I completely rewrote ERC404 to be completely compliant with ERC1155 and ERC20 standards. I chose to mix these two instead of ERC721/ERC20 for several reasons:

1. ERC1155 and ERC20 have no function conflicts whereas there are function signature conflicts when mixing ERC721 and ERC20
2. ERC1155 is already a widely adopted standard meaning any platform which supports ERC1155 will also support ERC404 fully
3. All I need to do now is create a few standardized error messages for the potential errors while synchronizing ERC1155 and ERC20
4. No new functions are needed
5. Batch transfers possible in ERC1155 meaning users can batch specific NFTs with their token transfers.
6. No ownership required, ownership can be added into the implementation contract allowing for developers to choose how centralized/decentralized their projects are (no previous token standard has onlyOwner functions)
7. Token ID space can be opened back up from 1 - uint256.max, only preventing tokenId 0 since id 0 is where we store the ERC20 data.

If anyone is interested in trying my rendition of ERC404 as an ERC1155 in action I have it [https://sepolia.etherscan.io/address/0xde39999e3e500e4b4842f6a87fa1e6a4c95d0010#code](deployed to sepolia) or on [https://github.com/TechnicallyWeb3/TW3404](my repo).

Hello DN404 community and developers,

I'm reaching out to propose an enhancement aimed at increasing the liquidity of already minted NFTs through the DN404 protocol. Specifically, I believe there is a significant opportunity to extend the utility and accessibility of our existing NFT assets by implementing a mechanism that allows for the locking up of an NFT in exchange for DN404 tokens that carry the identical token ID as the original NFT.

The current scope of DN404, which primarily focuses on tokens minted after 2024, seems to target a rather narrow market and community. By broadening this approach to encompass existing NFTs, we could significantly expand our reach and impact within the broader NFT ecosystem.

However, as I attempt to draft a contract to realize this functionality, I've encountered challenges in devising a robust logic that accurately matches the token IDs of the locked-up ERC721 tokens with the DN404 tokens returned to the user. This issue is crucial for ensuring that users can reclaim their original NFTs upon returning the DN404 tokens, thereby maintaining a seamless and secure exchange process.

I'm opening this issue to solicit feedback, suggestions, and potential collaborations from the DN404 community and developers. Our goal is to refine this concept further and explore viable implementations that could bring this idea to fruition. I believe that by working together, we can overcome the technical hurdles and create a more fluid and dynamic NFT market that benefits all stakeholders involved.

I don't know if this idea has already been addressed or if it's impossible, but I'll raise an issue. Thanks.

1. Instead of burning and minting, transferring NFTs when transferring FT tokens
2. ERC721 transfer event should be emitted
3. Due to the issue of fragment quantity during the transfer, it may be necessary to additionally burn and mint an NFT
4. For burning, add the free NFTs tracking(tokenId and total Amount) with a tmp address (ie. address(0))
5. For minting, get NFTs from the tmp address

Thanks for your reading! Not sure it makes sense.

Vectorized/solady#875

Use the z3 script to hunt for smaller constants, since we don't need to cater for the zero case.

Since ERC20 of solady supports EIP-2612 I think it would make sense if DN404 also supports EIP-2612 as well.

Or, for the meantime I should be using the ERC20Permit extension from openzeppelin?

cc @Vectorized

This shouldn't be a surprise, but if you create a DN404 with higher than 2.7k supply (in units, aka 18dec) and attempt to transfer ~2.7k tokens to another address, the gas consumption to mint the NFTs is over 30m reverting with oog on mainnet.

There's probably no workaround for this, but it's at least worth documenting somewhere.

Fairly easy to verify:

contract RevertTest is SoladyTest {
    SimpleDN404 dn;

    function setUp() public {
        dn = new SimpleDN404("DN404", "DN", 2700 * 10 ** 18, address(this));
    }

    function testTransfer() public { // gas: 30715623
        dn.transfer(address(1), 2_700 * 10 ** 18);
    }
}

Would be great if we have one, for example restrict NFT transfers for some contracts or only enforce NFT transfers by checking onERC721Received function call, etc.

Has anyone had any success combing DN404 and the LayerZero Omnichain Fungible Token (OFT)?

This would allow the token to be transferred across multiple blockchains without asset wrapping.

The documentation specifies that this is only for fungible tokens but I would imagine that by using this hybrid this could be acheived.

For marketplaces like Opensea

• Upon initialization handshake, the mirror will try to get the owner from the base contract. If there is an owner, the owner will be updated to that owner, and a OwnershipTransferred(address indexed oldOwner, address indexed newOwner) event will be emitted. Store the current owner in the deployer slot.

• Upon logging a batch NFT mint / burn, try to get the owner from the base contract. If the owner is different from that of the deployer slot, a OwnershipTransferred(address indexed oldOwner, address indexed newOwner) will be emitted, and the owner in the deployer slot will be updated.

Not sure if this will work, someone help me try.

How can I retrieve the list of NFTs from a wallet similar to the OpenZeppelin's ERC721Enumerable utility with functions like tokenOfOwnerByIndex and tokenByIndex? I've tried using _getDN404Storage().owned[wallet].map[index] but couldn't make it work. @Vectorized

Only for the non-synchronization functions.

User story

As a developer creating new DN404 token with custom base unit, I want to have built in compatibility to set base unit (WAD) value for my project rather than using the default WAD=10**18 value.

Why

I was building a DN404 token and I realized that my requires base unit to be set as 10**24 instead of the default value.

Status Quo

Currently, I cannot override the value of _WAD as it is a constant value used in multiple functions

Potential Solution

Instead of using _WAD as a constant variable, create a view function that can be overwritten by developers.

Note: The choice for view function over pure is to allow community to create factory contracts for DN404 where the base unit can be set as a state variable which is then used inside _WAD internal function.

Hello guys,

I am currently testing the DN404 protocol, and I've encountered inconsistencies regarding NFT IDs.
Here is the scenario:

User A and User B are participating in the protocol.
User A purchases 4 NFTs with the IDs 1, 2, 3, and 4.
User B purchases 1 NFT with the ID 5.
User A sells the NFTs with the IDs 3 and 4 as tokens on a DEX. These two IDs are burned.
User A returns to purchase another entire unit token (1 NFT) on a DEX. The new NFT is minted with the ID 6, resulting in a loss of reference to the IDs 3 and 4.

This process raises concerns about consistency in NFT ID. Shouldn't there be a mechanism in place to maintain consistency and ensure that IDs are not lost?
If I'm not mistaken, The ERC404 protocol addresses this by adding a queue for burned IDs to be minted again later, ensuring consistency with the NFT IDs

Thanks for advance

At mint function in NFTMintDN404:

the function allows to mint an "amount" of NFTs to the wallet of the caller, simulating a collection initial public sale.
it marks with "true" the wallets that minted whatever amount as long as the amount is "valid"
it increases the "numMinted" variable by one (1), instead of taking into consideration the "amount",
then, mints the "amount" to the wallet, offsetting the minted amount from the "recorded minted amount"

"numMinted" is used in isValidMint as part of the check for MAX_SUPPLY overflow. This issue will make that check not work properly.

Also, is confusing and not coherent. Because it allows to mint up to an amount and then, never again.
Lets say the maximum amount to mint per tx is 10,
If an user mints 2, and later changes his mind and tries to mint again, the function will revert, as the wallet has been already marked.

function mint(uint256 amount) public payable isValidMint(publicPrice, amount) {

        // if the user has already minted ANY number of tokens, this will revert, not allowing further mints

        if (minted[msg.sender]) revert InvalidMint();
            minted[msg.sender] = true;

        // numMinted only increases by one, not taking into account the **amount**
        // this will make isValidMint() not catch the minting overflow for collection

        unchecked {
            ++numMinted;
        }

        _mint(msg.sender, amount * _WAD);
    }

Additionally, maxMint should be called maxMintsPerTx or something like that. As it is a constructor param, it suggests that the name is referring to the max supply, or max mintable NFTs.

These helpers are very useful and would be great to be able to inherit and optionally override instead of having to rewrite in derived contracts. That contract size limit can sneak up on you.

Unless there's a reason these are set to private instead of internal virtual 🤔

So that it doesn't occupy the dispatch tree of the public functions.

And we can use assembly to direct return the string, bypassing Solidity's implicit return copy, leading to smaller bytecode.

Dear, when i put an ipfs on setbaseuri on remix, i have a problem that i don't understand.
Métadonnées json work fine but image don't appaer on opensea.
Please i need understand this problem.
Thanks

Currently, it would be possible to use staticcall for mirrorERC721 in order to detect if the contract is DN404 however this could also cause an issue with abi.decode since it doesn't catch decoding errors effectively

ethereum/solidity#10381

Therefore, the cleanest method would be supporting an arbitrary value for supportsInterface function

#68

Try to make it zero-cost abstraction.

If _useOneIndexed() is overriden to return false, the tokens will range from 0...(n-1) instead of 1...n.

Hello,
I'm considering creating a collection with a supply of 100,000 items and wanted to consult on whether this could potentially lead to any issues regarding gas fees or security within the collection. Specifically, I'm concerned about whether such a large supply might cause transactions to become excessively expensive or if there are any security vulnerabilities that could arise from managing a collection of this size. Additionally, is there a risk of the collection's transactions getting stuck or failing due to the high number of items?

Could you please advise on any best practices or considerations I should be aware of to avoid potential issues with gas costs, security, or transaction reliability for a collection of this magnitude?

Thank you for your assistance.