gistfile1.md

Exchange Contract Additions Specification

New Functions Overview

1. batchCancelOrder - Exchange.sol

• Purpose: Allow users to cancel multiple orders in a single transaction
• Implementation: Reuse existing cancelOrder function in a loop
• Benefits: Gas efficiency for users needing to cancel multiple orders
• Access: Public function, orders can only be cancelled by their original creator

2. batchBurn Function - Minter.sol (fantasy card?)

• Purpose: Allow token holders to burn their own tokens
• Implementation: Simply allow anyone to call the burn function for an array of token.
• Access: Public function, only callable by token owner or approved address

3. batchBuyAndBurn - Exchange.sol

• Purpose: Purchase multiple NFTs and send them directly to address(0), effectively burning them
• Implementation: Similar to batchBuy but with address(0) as the recipient
• Benefits: Enables bulk burning operations, useful for deflationary mechanics
• Access: Public function with onlyEOA and nonReentrant modifiers
• Payment: Supports both ETH and whitelisted ERC20 tokens

4. batchSell - Exchange.sol

• Purpose: Allow sellers to execute multiple sell operations against buy orders in one transaction
• Implementation: Reuse existing sell function in a loop
• Benefits: Gas efficiency for sellers matching multiple buy orders
• Access: Public function with onlyEOA and nonReentrant modifiers
• Validation: Includes merkle proof verification for each token ID

5. mintCardsTo - Minter.sol

• Purpose: Allow privileged addresses to mint cards directly to a specified recipient
• Implementation: Uses existing _executeBatchMint function
• Access: Only callable by addresses with MINTER_ROLE
• Benefits: Enables administrative operations like airdrops or rewards
• Validation: Requires valid collection and recipient addresses

Technical Requirements

• All functions must maintain existing security checks
• Proper event emissions for each operation
• Array length validation for batch operations
• Reuse existing single-operation functions where possible
• Maintain nonReentrant protection
• EOA-only restrictions where applicable

Testing Requirements

The following scenarios should be covered:

• Batch operations with varying array sizes
• Failed operations in middle of batch
• Gas optimization verification
• Permission and signature validations
• ETH and ERC20 payment handling
• Merkle proof validations
• MINTER_ROLE access control for mintCardsTo

Security Considerations

• Reentrancy protection
• Array length limits
• Gas limitations for large batches
• Signature replay protection
• Price manipulation protection
• Access control validation
• Role-based access control for privileged operations

This specification serves as a starting point for implementation and can be expanded based on specific requirements or concerns raised during development and review.