# Collateral overwritten instead of accumulated

Collateral writes that assign instead of add, or key by owner/minter rather than the specific position

_Area: DeFi accounting and math bugs. Seen in 2 disclosed reports; latest 2026-03-24. Updated 2026-10-24._

## How it works
Collateral bookkeeping assumes each deposit is recorded once, against the right identity, and that later writes add to or reject existing state. The bug appears when a write path assigns a stored amount instead of accumulating it, or when the storage key is the wrong identity (minter/owner instead of the specific vault or position). The invariant "stored collateral equals the sum of all valid deposits for this position" breaks silently: the ledger still looks populated, but it no longer reflects reality.

## Where it shows up
- A commit/register/add-collateral function writing `mapping[key] = newInfo` unconditionally, with no add and no revert on an existing key [E2](https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3.md).
- Collateral lookups keyed by owner, minter, or token address rather than the specific vault/position ID [E1](https://bugbountylibrary.com/r/dhl%3A20260324-univ3collateraltoken.md).
- Accept/fill/borrow functions that read that stored state but let the caller omit an expected-collateral argument [E2](https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3.md).
- Collateral use that never verifies the asset was actually transferred or is not already locked elsewhere [E3](https://bugbountylibrary.com/r/dhl%3A20230617-pawnfi.md).

## How to review
For every write to collateral storage, check the exact property: does the new stored value equal old value plus this deposit (or does it revert on an existing key)? For every read, confirm the key uniquely identifies the position that will borrow against it — enumerate sibling vaults/positions for one owner and confirm a single deposit is not visible to all of them [E1](https://bugbountylibrary.com/r/dhl%3A20260324-univ3collateraltoken.md). Confirm the accept path pins expected collateral so a front-run cannot change it [E2](https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3.md). Confirm custody: the asset is transferred and not already pledged elsewhere [E3](https://bugbountylibrary.com/r/dhl%3A20230617-pawnfi.md).

## Variants seen
- Re-commit overwrites stored amount, letting a borrower shrink escrow before acceptance [E2](https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3.md).
- Collateral keyed by minter, so one NFT backs many vaults [E1](https://bugbountylibrary.com/r/dhl%3A20260324-univ3collateraltoken.md).
- No transfer verification; already-staked NFT reused as collateral [E3](https://bugbountylibrary.com/r/dhl%3A20230617-pawnfi.md).

## Impact and severity
High to critical: repeated borrowing against one position drained reserves (~57K USD) [E1](https://bugbountylibrary.com/r/dhl%3A20260324-univ3collateraltoken.md); escrow reduced to 1 wei [E2](https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3.md); ~820K USD drained via reused staked NFT [E3](https://bugbountylibrary.com/r/dhl%3A20230617-pawnfi.md). Worse when accept paths lack expected-collateral checks and when one owner controls many vaults.

## Why fixes fail
Evidence does not show incomplete fixes for these reports.

## Evidence
- E1: https://bugbountylibrary.com/r/dhl%3A20260324-univ3collateraltoken.md
- E2: https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3.md
- E3: https://bugbountylibrary.com/r/dhl%3A20230617-pawnfi.md