# Запрет получателя тикета, равного inflow-вольту (защита от заморозки очереди)

## Краткое описание
Закрыта HIGH-находка второго аудита (`Dev_Docs/audit/Solana-audit-2-by-Claude-11июня2026.md`).
Тикет с `recipient_wallet == адрес inflow_vault` приводил к алиасингу аккаунта в
`step_payout` (вольт одновременно источник и получатель), второй mutable-займ
лампортов в `transfer_from_vault` падал, и такой тикет навсегда блокировал
обслуживание очереди и замораживал средства вольта.

Исправление в `shine_payments`:
- `buy_ticket_by_purchase_usd` — `require!(recipient_wallet != config.inflow_vault)`;
- `process_manager_add_ticket` — запрет через `find_single_pda(INFLOW_VAULT_SEED)`;
- `process_change_ticket_recipient` — тот же запрет для `new_recipient_wallet`;
- `transfer_from_vault` — защита по умолчанию `require!(vault.key != recipient.key)`.

Ошибка во всех случаях — `InvalidTicketRecipient`.

## Что проверять (devnet/localnet)
1. Покупка тикета с `recipient_wallet = <адрес inflow_vault PDA>` → отклоняется
   (`InvalidTicketRecipient`), тикет не создаётся.
2. `manager_add_ticket` с тем же recipient → отклоняется.
3. `change_ticket_recipient` с `new_recipient = inflow_vault` → отклоняется.
4. Обычные покупки/выплаты с нормальным получателем → работают как раньше, очередь
   обслуживается, `step_payout` выплачивает корректно.
5. Регресс не затронул выплаты в `dao_wallet` и `call_reward` подписанту (их адреса
   не совпадают с вольтом).

## Ожидаемый результат
Тикет с получателем-вольтом невозможно создать; ранее существовавший вектор
перманентной заморозки очереди закрыт. Прочая логика выплат без изменений.

## Статус
pending