# ATA ownership and rent griefing

Idempotent ATA creation, init on derivable addresses, and buyer-paid rent that counterparties can close or reassign

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2025-01-31. Updated 2026-10-23._

## How it works
Associated token accounts (ATAs) have a deterministic address and a mutable owner. Programs assume that "create the ATA" is a safe, repeatable step. Two assumptions break. First, `create_idempotent` only succeeds if an existing ATA is already owned by the expected authority; the Token program lets an owner reassign ATA ownership, so a pre-existing ATA with the wrong owner makes the call fail [E1](https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.3.md). Second, Anchor's `init` fails outright if the account already exists, and the ATA address is derivable from public inputs, so anyone can pre-create it [E2](https://bugbountylibrary.com/r/cantina%3Aolas_lockbox_jan2024%3A3.2.2.md). A third shape is economic: if the program auto-creates an account with the buyer as payer, the counterparty who controls that account's lifecycle can close it and force re-creation, harvesting rent each time [E3](https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.9.md).

## Where it shows up
- `associated_token::create_idempotent` on an ATA whose authority is a third party (creator, seller, broker) [E1](https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.3.md).
- Anchor `init` on a PDA or ATA whose address derives from public inputs (program PDA, mint, position) [E2](https://bugbountylibrary.com/r/cantina%3Aolas_lockbox_jan2024%3A3.2.2.md).
- Instructions that auto-create counterparty accounts with `payer` set to the buyer or another party [E3](https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.9.md).
- Any flow where the account owner can reassign ownership or close the account after use.

## How to review
For every ATA or PDA the instruction creates, ask: who can make this account exist before my instruction runs, and who controls its owner and lifecycle afterward? The invariant: creation must succeed regardless of pre-existing state, or the address must not be attacker-derivable. Check that `create_idempotent` targets are owned by the expected authority, that `init` is replaced by `init_if_needed` plus explicit validation where pre-creation is possible, and that rent payers cannot be forced to fund accounts a counterparty can close and recreate.

## Variants seen
- Owner reassignment of an existing ATA breaks idempotent creation, blocking all buys [E1](https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.3.md).
- Attacker pre-creates a victim's ATA so `init` fails, permanently denying deposits [E2](https://bugbountylibrary.com/r/cantina%3Aolas_lockbox_jan2024%3A3.2.2.md).
- Seller closes auto-created ATA after each sale and re-triggers buyer-paid initialization to farm rent [E3](https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.9.md).

## Impact and severity
Denial of service on core operations (buys, deposits) and direct rent extraction from buyers. Severity rises when the griefing is permanent or repeatable and when the blocking party is a normal protocol participant (creator, seller) rather than an outsider. Deterministic addresses from public inputs make pre-creation cheap and hard to prevent without design changes.

## Evidence
- E1: https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.3.md
- E2: https://bugbountylibrary.com/r/cantina%3Aolas_lockbox_jan2024%3A3.2.2.md
- E3: https://bugbountylibrary.com/r/cantina%3Atensor_nov2024%3A3.2.9.md