# WNS creator fee can be bypassed when taking bid

Tensor take_bid passes user-controlled min_amount into the WNS royalty approve CPI, so setting min_amount=0 zeroes creator royalties.

- Payout: Contest reward
- Severity: high
- Program: Tensor
- Credited: krikolkk
- Disclosed: 2025-01-31
- Write-up quality: 7/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_tensor_nov2024.pdf#3.1.5
- Library page: https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.1.5
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:high tech:solana technique:source-review vuln:business-logic vuln:fee-bypass

**Target:** Solana marketplace take_bid instruction / WNS royalty approve CPI
**Root cause:** take_bid forwards the user-supplied min_amount (slippage guard) as the price argument to the WNS approve CPI, which computes the royalty from that value instead of the actual bid amount.
**Steps:**
1. Call take_bid with `min_amount = 0` inside a multicall/transaction that enforces slippage separately.
2. Instruction reaches take_bid.rs#L250-L257 and invokes approve with `price: min_amount` (0).
3. Royalty computed from 0, so no creator fee is deducted from the buyer.
4. Transaction-level slippage check still reverts if received amount is below expectation.
**How found:** Code reading of take_bid.rs: noticed min_amount (a slippage parameter) was reused as the price argument in the royalty approve CPI, then reasoned that a zero min_amount yields zero royalty.
**Exploitation:** Buyer submits take_bid with min_amount=0 wrapped in a multicall that performs its own slippage check; the approve CPI deducts zero royalty while the NFT still transfers to the buyer, saving the creator fee.
**Insight:** When a slippage/limit parameter is reused as an amount in a downstream CPI, check whether an attacker can set it to an extreme (0) to null out fee or royalty math while enforcing protection elsewhere in the transaction.