-
Notifications
You must be signed in to change notification settings - Fork 1
NFT Multiclaim Queue
This document provides a comprehensive overview of the process involved in claiming NFTs, starting from the initiation of a cron job to the final step of claiming the NFTs. This process is a critical component of our system, ensuring that NFT claims are processed efficiently and accurately. Process Breakdown
The journey begins with a cron job, specifically designed to trigger the NFT claim process. This job, defined in our system to run every minute, executes the processRedisOrdersHandler function. This function acts as the starting point, initiating the sequence of steps required to process and claim NFTs. The cron job is a crucial element, ensuring that the process runs regularly and without manual intervention, thereby maintaining a steady flow of NFT claims.
Once the cron job is activated, the system fetches orders from a Redis cache. These orders are identified by keys prefixed with cs_* (Hygragh ids all start by cs_), each representing an event pass ID linked to pending orders. The system then filters these orders, focusing on those marked as pending. This step is vital as it prepares the orders for processing, ensuring that only those requiring action are processed. The process involves checking the minter's wallet status to ensure it's not busy, a crucial check to avoid processing conflicts and ensure the wallet is ready for claiming NFTs.
Before diving into the NFT claiming process, the system sets the orders to a "busy" status. This is a preventive measure, ensuring that no order is processed more than once. By marking orders as busy, the system effectively locks them for processing, preventing any overlap or duplication in the claiming process. This step is implemented using the setOrdersToBusy function, which updates the order status in the Redis cache, marking them as busy and ready for the next step.
The heart of the process is the NFT claiming itself, executed by the multicallClaim function. This function is where the magic happens, with the system verifying order details, including the contract address for the NFT, and using the minter's wallet to claim NFTs for each order. This step is critical, as it involves direct interaction with the third-party NFT service, requiring precision and accuracy to ensure successful NFT claims. Errors at this stage are handled with care, with orders set back to "pending" if any issues arise, ensuring that no order is lost or overlooked. The orders are processed by batch of 20 at the moment but this number is "small" and can be increased when the load of the platform increase. Current time of claim for a batch is ~ 20 seconds on polygon Mumbai which should ensure 200 nfts per 10 minutes per eventPassId.
Following a successful NFT claim, the system updates the order status to reflect their completion. This step is crucial for record-keeping and tracking, ensuring that each order's status accurately reflects its current state. In cases where the NFT claim encounters issues, the system updates the order status to "error" or reverts it to "pending," depending on the nature of the problem. This flexibility in handling errors ensures that orders are not stuck in limbo and can be reprocessed if necessary.
The final step in the process involves cleanup activities, including resetting the minter's wallet status and deleting processed orders from the Redis cache. This step is essential for maintaining a clean and efficient system, ready for the next round of NFT claims. By ensuring that all temporary statuses and data are cleared, the system remains optimized and ready for continuous operation.
The NFT claim process is a meticulously designed sequence of steps, ensuring that from the moment a cron job is triggered to the final claim of NFTs, every action is executed with precision and care. This process not only ensures the efficient handling of NFT claims but also maintains the integrity and reliability of the system, making it a cornerstone of our NFT management infrastructure.
Since the claiming process is now dispatched into several wallets (cf. one for each pass), we use OpenZeppelin Defender in order to use gasless on those transactions.