# Lack of isBelowMaxLtv check in _afterTokenTransfer function leads to breaching of max LTV limit

Silo ShareDebtToken transfer only checks recipient solvency, not max LTV, letting a user consolidate debt to exceed the 85% LTV limit.

- Payout: Contest reward
- Severity: medium
- Program: Silo
- Credited: ctmotox2
- Disclosed: 2025-03-19
- Write-up quality: 6/10
- Original: https://cdn.cantina.xyz/reports/cantina_competition_silo.pdf#3.2.11
- Library page: https://bugbountylibrary.com/r/cantina%3Asilo%3A3.2.11
- Tags: domain:web3 impact:integrity kind:contest platform:cantina sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:accounting-error vuln:business-logic

**Target:** ShareDebtToken._afterTokenTransfer in Silo lending protocol
**Root cause:** _afterTokenTransfer validates only isSolvent(recipient) after a debt-token transfer, omitting an isBelowMaxLtv check, so debt can be consolidated past the max LTV threshold.
**Steps:**
1. User1 deposits 100 assets; User2 deposits 100 assets into the Silo.
2. User1 borrows 80; User2 borrows 10 (both within 85% max LTV).
3. User1 calls `shareDebtToken.setReceiveApproval(user2, 10e18)`.
4. User2 calls `shareDebtToken.transfer(user1, 10e18)` moving debt to User1.
5. User1 now holds 90 debt against 100 collateral = 90% LTV > 85% max; transfer succeeds because only solvency is checked.
**How found:** Reviewer read _afterTokenTransfer and noticed the post-transfer check calls isSolvent but not isBelowMaxLtv, hypothesizing debt consolidation via transfer could breach the LTV limit.
**Exploitation:** Attacker controls two accounts, borrows near max LTV on each, then transfers debt tokens from one to the other via setReceiveApproval + transfer to concentrate debt above max LTV on a single position.
**Insight:** When a token transfer hook enforces solvency, check whether it also enforces the tighter LTV/health threshold — consolidating debt across accounts can pass solvency while exceeding max LTV.