You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enhancing Liquidity for Existing NFTs: Implementing Lock-up Mechanism to Return DN404 Tokens with Matching Token IDs #110
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.
Thnks you really ! Following what you said, I prefilled the existing bitmap with all 10,000 bits and replaced the existing bitmap with solady's LibBitmap.
Could you check the revised contract one more? Even if it's rough, It'd be very helpful for me.
Activity
Vectorized commentedon Mar 8, 2024
Rough idea: fill in all 10k bits in the
existsbitmap.Then whenever a token is wrapped, we will directly mint on the exact ID.
When it's burned in DN404, unset the bit in the
existsbitmap.abitocodes commentedon Mar 17, 2024
Thanks, I've written a contract based on your idea and will start testing it soon, I'll update and come here again.
https://github.com/abitofdots/convertERC721toDN404
Vectorized commentedon Mar 17, 2024
@abitofdots You gotta prefill all 10k bits in
existsbitmap too. It will cost some gas on deploy, but your customers won't need to pay that much gas.Also, for
_isTokenLocked, use Solady's LibBitmap, or the built-in bitmap in DN404. To save more gas.abitocodes commentedon Mar 18, 2024
Thnks you really ! Following what you said, I prefilled the existing bitmap with all 10,000 bits and replaced the existing bitmap with solady's LibBitmap.
Could you check the revised contract one more? Even if it's rough, It'd be very helpful for me.
https://github.com/abitofdots/convertERC721toDN404/blob/main/contracts/convertERC721toDN404.sol
Vectorized commentedon Mar 18, 2024
@abitofdots Can you write some tests to ensure that only the original owner of the token can unwrap the token?
Don't take my word for an approval of safety. I'm only 10% alert right now.
Something we will need to account for the edge case of collection where the token IDs start from 0 instead of 1. But this is homework for another day.
abitocodes commentedon Mar 23, 2024
Sure. I'll have the tests ready and share it with you soon. Thanks for your fast feedback always.