# Unbounded or duplicate registration without dedupe

Registration/deposit paths that append without dedupe, cap, or uniqueness check, or caps that removal paths never decrement

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2026-02-05. Updated 2026-10-25._

## How it works
A registration, deposit, or insert path accepts entries without proving the new entry is distinct or that the container is below a bound. The code assumes either that callers cannot repeat submissions or that a size cap elsewhere actually holds. When that assumption breaks, an attacker controls how many entries exist, or which key is occupied, and the container or registry grows or fills on the attacker's terms.

## Where it shows up
- Mempools, queues, or `VecDeque`/array-backed stores appended on each RPC or deposit call, with validation against unchanged or pending state rather than entry identity [E2](https://bugbountylibrary.com/r/cantina%3Acitrea_jul2025%3A3.1.2.md).
- Registries enforcing one entry per key (adapter/maturity, pool id) where the key is derived deterministically from a truncated timestamp or other predictable value [E1](https://bugbountylibrary.com/r/sherlock%3A2022-11-sense%3AH-4.md).
- Size caps checked with `==` or a counter, where the removal path only deletes the node under a narrow guard (e.g. `numOrders==1`) [E3](https://bugbountylibrary.com/r/c4%3A2025-07-gte-spot-clob-and-router%3AM-03.md).
- Any insert path with no uniqueness check, no per-caller limit, and no eviction.

## How to review
Identify the counted unit and the bound. Confirm every admission path rejects duplicates by identity (not just by state validity) and enforces a hard cap. Confirm every removal path decrements the same unit the cap checks, including partial removals. For deterministic keys, ask whether an outside party can pre-register the key before the legitimate caller derives it. The invariant: container size and key occupancy are bounded and only change through paths that maintain the bound.

## Variants seen
- Duplicate deposits accepted into an unbounded mempool, exhausting memory and blocking legitimate bridge deposits [E2](https://bugbountylibrary.com/r/cantina%3Acitrea_jul2025%3A3.1.2.md).
- Predictable future key (first-of-month maturity) pre-registered by an attacker, making the victim's registration revert [E1](https://bugbountylibrary.com/r/sherlock%3A2022-11-sense%3AH-4.md).
- Partial removal leaves the tree node, so the size cap is never reached and the book grows without limit [E3](https://bugbountylibrary.com/r/c4%3A2025-07-gte-spot-clob-and-router%3AM-03.md).

## Why fixes fail
A cap that is checked but not maintained by the removal path is silently disabled [E3](https://bugbountylibrary.com/r/c4%3A2025-07-gte-spot-clob-and-router%3AM-03.md); dedupe that relies on state validation rather than identity still admits repeats [E2](https://bugbountylibrary.com/r/cantina%3Acitrea_jul2025%3A3.1.2.md).

## Impact and severity
Denial of service: blocked rolling [E1](https://bugbountylibrary.com/r/sherlock%3A2022-11-sense%3AH-4.md), blocked legitimate deposits and memory exhaustion [E2](https://bugbountylibrary.com/r/cantina%3Acitrea_jul2025%3A3.1.2.md), unbounded order book growth [E3](https://bugbountylibrary.com/r/c4%3A2025-07-gte-spot-clob-and-router%3AM-03.md). Severity is high where the path is permissionless and the key or entry is attacker-chosen; worse when the bound is the only protection against resource exhaustion.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2022-11-sense%3AH-4.md
- E2: https://bugbountylibrary.com/r/cantina%3Acitrea_jul2025%3A3.1.2.md
- E3: https://bugbountylibrary.com/r/c4%3A2025-07-gte-spot-clob-and-router%3AM-03.md