# `LendingPool#flashAction` is broken when trying to refinance position across `LendingPools` due to improper access control

LendingPool.flashAction calls updateActionTimestampByCreditor, which only the current creditor may call, so refinancing across LendingPools always reverts.

- Payout: Contest reward
- Severity: medium
- Program: Arcadia
- Credited: 0x52
- Disclosed: 2023-12-17
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-12-arcadia-judging/issues/145
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-12-arcadia%3AM-6
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** LendingPool.flashAction / AccountV1.updateActionTimestampByCreditor
**Root cause:** flashAction invokes account.updateActionTimestampByCreditor() before flashActionByCreditor, but that function is gated by onlyCreditor; during refinance the caller is the pending (new) creditor, not the current one, so the call reverts.
**Steps:**
1. Initiate refinance of an account from LendingPool A to LendingPool B.
2. LendingPool B calls IAccount(account).updateActionTimestampByCreditor().
3. AccountV1 modifier onlyCreditor checks msg.sender == creditor (still LendingPool A) and reverts.
4. Transfer/flashAction never completes; cross-pool refinancing is impossible.
**How found:** Code reading of the flashAction flow: noticed updateActionTimestampByCreditor is called before flashActionByCreditor and traced the onlyCreditor modifier to see the caller identity mismatch during refinance.
**Insight:** When a flow hands control to a new party (pending creditor), audit every modifier-gated callback in the sequence for which identity is actually msg.sender at that point; ordering of timestamp/nonreentrant hooks vs. role checks is a common break.