# Incorrect approval mechanism breaks all Magnetar functionality

Magnetar grants plain ERC20/YieldBox approvals while target contracts pull tokens via permitC, so nearly all Magnetar token transfers fail.

- Payout: Contest reward
- Severity: high
- Program: Tapioca DAO
- Credited: carrotsmuggler
- Disclosed: 2024-05-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/125
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AH-04
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:regression technique:source-review vuln:access-control vuln:business-logic

**Target:** Magnetar router contract and its token approval flow
**Root cause:** Target contracts were refactored to pull tokens via permitC (Pearlmit), but Magnetar still issues standard ERC20/YieldBox approvals, so the pull fails.
**Steps:**
1. Inspect `_depositYBLendSGL` in MagnetarAssetCommonModule.sol: it calls `_setApprovalForYieldBox(singularityAddress, yieldBox_)`.
2. Check SGLCommon `_addTokens`: transfers use pearlmit/permitC, not YieldBox allowance.
3. Inspect `_wrapSglReceipt`: it calls `IERC20(sgl).approve(tReceiptAddress, fraction)`.
4. Check BaseTOFT: it pulls tokens via permitC, not raw ERC20 allowance.
5. Observe no permitC approval is ever granted, so the transfer reverts.
**How found:** Code review comparing Magnetar's approval calls against the refactored target contracts' transfer paths, noticing the mismatch between ERC20/YieldBox approvals and permitC pulls.
**Insight:** When a protocol migrates its transfer mechanism (e.g. to permitC/Pearlmit), audit every integrator/router that grants allowances — stale approval style silently breaks all flows rather than reverting loudly at the approval site.