# Incorrect allowance decrement in safebatchtransferfrom function

ERC1155A.safeBatchTransferFrom decremented the receiver's allowance instead of msg.sender's, letting a small allowee move all owner tokens to a contract that can pull them.

- Payout: Contest reward
- Severity: high
- Program: Superform Erc1155a
- Credited: Vijay
- Disclosed: 2024-02-13
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_superform_erc1155a_dec2023.pdf#3.1.2
- Library page: https://bugbountylibrary.com/r/cantina%3Asuperform_erc1155a_dec2023%3A3.1.2
- Tags: domain:web3 impact:funds-loss kind:contest platform:cantina sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:accounting-error vuln:business-logic

**Target:** ERC1155A.sol safeBatchTransferFrom allowance logic
**Root cause:** safeBatchTransferFrom decrements allowances[from][to][id] (the receiver) rather than allowances[from][msg.sender][id], so the caller's allowance is never consumed.
**Steps:**
1. Alice holds 100 super position tokens and grants Bob a 5-token allowance.
2. Alice grants infinite approval to contract X which pulls tokens when a specific function is called.
3. Bob calls `safeBatchTransferFrom(alice, X, ids, amounts)` with amounts totaling 100.
4. Allowance check passes and Bob's allowance is not decremented, so all 100 tokens land in X.
**How found:** Code review of the allowance bookkeeping in safeBatchTransferFrom; noticed the decrement indexed `to` instead of `msg.sender`.
**Exploitation:** A malicious allowee with a tiny allowance transfers the owner's entire balance to an address (e.g. a contract with infinite approval) that can pull the tokens, locking them from the owner.
**Insight:** When auditing ERC1155-style batch transfer wrappers, verify every allowance decrement indexes msg.sender, not the `to` parameter; a single wrong index turns a small allowance into full-balance transfer rights.