# Use of _mint in ReraiseETHCrowdfund#_contribute is incompatible with PartyGovernanceNFT#mint

ReraiseETHCrowdfund mints contribution NFTs with _mint while PartyGovernanceNFT.mint uses _safeMint, so a contract contributor without ERC721Receiver can never claim, permanently locking voting power.

- Payout: Contest reward
- Severity: medium
- Program: PartyDAO
- Credited: 0x52
- Disclosed: 2023-06-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-04-party-findings/issues/42
- Library page: https://bugbountylibrary.com/r/c4%3A2023-04-party%3AM-01
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:dos

**Target:** ReraiseETHCrowdfund / PartyGovernanceNFT Solidity contracts
**Root cause:** ReraiseETHCrowdfund#_contribute uses _mint (no receiver check) for the soulbound CrowdfundNFT, but the later claim path calls PartyGovernanceNFT#mint which uses _safeMint, reverting for any owner contract lacking onERC721Received.
**Steps:**
1. Contract without ERC721Receiver calls ReraiseETHCrowdfund#_contribute; `_mint(contributor)` succeeds, granting a soulbound CrowdfundNFT.
2. Contribution period ends; contributor attempts to claim via the path at ReraiseETHCrowdfund.sol#L374 calling `party.mint(contributor, votingPowerByCard[i], delegate)`.
3. PartyGovernanceNFT#mint executes `_safeMint(owner, tokenId)` at L162, which reverts because the owner contract does not implement onERC721Received.
4. NFT is soulbound and non-transferable, so the contribution and voting power are permanently unclaimable, DoSing that party share.
**How found:** Code-reading comparison of the two minting paths: noticed _contribute uses plain _mint while the claim path routes through PartyGovernanceNFT#mint which uses _safeMint, and reasoned that a contract contributor lacking ERC721Receiver would pass the first mint but fail the second, with no transfer escape due to soulbound NFTs.
**Insight:** When a protocol mints an NFT in one place and re-mints/claims it elsewhere, compare the minting primitives (_mint vs _safeMint): an unchecked first mint plus a safe second mint creates a permanent lock for contract recipients, amplified when the token is soulbound and non-transferable.