implement initial drop logic

[tota79]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 16, 2024 1:48pm

[leovigna]

Fix CI but then good to go.

[leovigna]

Run npm run clean && npm run clean -- --force to purge the turbo repo cache which might fix things.

[leovigna]

Currently the ERC721DropLib makes good re-use of the ERC721ClaimLib.ClaimCondition struct.
However, the ClaimCondition has the supplyClaimed field which is unused and is a "state" field that updates dynamically.
A good refactor would therefore be to decouple "static" structs managed by the admin, from "dynamic" structs that update as assets are minted.

First, we refactor the ERC721ClaimLib as follows

struct ClaimCondition {
        uint256 startTimestamp;
        uint256 endTimestamp;
        uint256 maxClaimableSupply;
        //uint256 supplyClaimed; //REMOVE THIS
        uint256 quantityLimitPerWallet;
        uint256 pricePerToken;
        address currency;
    }

//Used by ERC721ClaimLib
struct ClaimConditionState {
        uint256 supplyClaimed;
        mapping(address => uint256)) accountClaims; //formerly "walletClaims"
}

struct ERC721ClaimStorage {
        mapping(bytes32 => ClaimCondition) claimConditions;
        mapping(bytes32 => ClaimConditionState) claimConditionStates;
    }

///...Update read/write logic accordingly in ERC721Claim Lib

The ERC721DropLib can use ClaimCondition but NOT ClaimConditionState (since it maps claims per user)
We can still follow the same pattern of using a struct to decouple "static" from "dynamic" fields however.

struct DropCondition {
        bytes32 merkleRoot;
        //mapping(address => uint256) accountClaims; //REMOVE THIS
    }
struct DropConditionSate {
        mapping(address => uint256) accountClaims; //track account claims and update accodingly
    }