# System could be wrapped and made useless without contract whitelisting

Anyone could wrap hPAL in a locker contract, lock tokens, and sell contract ownership, making locked voting power liquid and breaking the lock model.

- Payout: Audit contest
- Severity: high
- Program: Paladin
- Found by: Picodes
- Disclosed: 2022-05-10
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-03-paladin-findings/issues/77
- Library page: https://bugbountylibrary.com/r/c4%3A2022-03-paladin%3AH-02
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:governance

**Target:** HolyPaladinToken.sol lock/delegate functions
**Root cause:** Locking and voting-power delegation are callable by any contract, so a wrapper contract can hold locked hPAL while its ownership is transferred/sold, making the locked position liquid.
**Steps:**
1. Deploy contract C that calls HolyPaladinToken lock/deposit with hPAL and delegates voting power to C's owner
2. Alice deposits hPAL via C and locks them
3. Alice sells or tokenizes ownership of C, transferring effective control of locked hPAL
**How found:** Observed real-world veToken locker ecosystems (Convex, StakeDAO) and reasoned that Paladin's unrestricted lock/delegate calls allow the same wrapper pattern.
**Exploitation:** Alice wraps hPAL in a locker contract, locks tokens through it, delegates voting power to herself, then sells the contract's ownership to a buyer, giving the buyer the locked position and voting power while Alice recovers liquidity.
**Escalation:** Scaling via locker factories (as seen with Convex/StakeDAO) could capture large shares of voting power and rewards, misaligning governance with the protocol.
**Insight:** For ve-style lock tokens, check whether lock and delegate are callable by arbitrary contracts; if so, a transferable-ownership wrapper makes locked positions liquid and can capture governance.