🛡️ LPCG MEMES — Security Review

• Reentrancy — fully defended. mint and withdraw share a nonReentrant lock, so the ERC-1155 receiver callback fired during mint cannot re-enter to drain funds or inflate supply.
• Checks-Effects-Interactions. Every validation (active, window, quantity, LPCG gate, per-wallet cap, max supply, exact ETH) runs before balances change and before any external call.
• Exact payment. msg.value == price × qty is enforced — no under/over-payment, no way to pay and receive nothing.
• Supply & caps are unbypassable. maxSupply and per-wallet eligibility are checked in full-width 256-bit math; no caller can exceed them.
• Safe payouts. Revenue splits use a gas-limited push with a owed[] pull fallback — a misbehaving payee can only fail its own leg, never block the mint or other payees.
• Withdraw is a textbook pull pattern (zero-before-call, reentrancy-locked) and only ever pays the caller's own balance.
• Burn-to-claim checks balance and runs after all validations — a minter can never be made to burn and then fail to mint.
• Receiver safety. Transfers to contracts enforce the ERC-1155 acceptance magic value and revert on non-receivers, so tokens are never stranded.
• Access control. Every admin function is onlyOwner; mint is correctly public; no missing modifiers.

Severity	Finding	User-exploitable?
MEDIUM	Share percentages aren't validated. A drop whose sharesBps sum to >10000 could strand payout funds (creator-side). Fix: require sum ≤ 10000 at creation.	No — owner config only
LOW	No safeBatchTransferFrom though ERC-1155 is advertised — some marketplaces' batch moves would revert. No fund risk.	No
LOW	balanceOfBatch doesn't require equal array lengths (view-only spec deviation).	No
LOW	transferOwnership allows the zero address — an owner foot-gun (could brick admin). Owner-only.	No
LOW	Payee-count / zero-payee hygiene in splits (owner-set). The gas:30000 cap is a good mitigation.	No
INFO	uri() doesn't escape title/description — only the owner sets these; worst case is malformed metadata, not an exploit.	No
INFO	uint32(qty) truncation on the minted counter — cosmetic only; caps are checked in 256-bit and can't be bypassed (practically unreachable).	No
INFO	safeTransferFrom doesn't forward data to the receiver callback (spec nicety, no safety impact).	No

We read the mint contract line by line, looking hard for ways someone could steal money, mint more than allowed, or trick buyers. We didn't find any. When you mint, you pay exactly the listed price and get your tokens in the same transaction — no outsider can drain your funds or cheat you, and nobody can mint past a drop's supply or per-wallet limit. The contract is well protected against the classic reentrancy drain attacks. The only thing to watch is on the creator's side, not yours: the contract doesn't double-check that a drop's split percentages add up, so the team sets those carefully. A few minor housekeeping items could affect how some marketplaces display or batch-move tokens, but none put anyone's money at risk. Bottom line: safe to mint.