[SEC-Q2] P2P escrow: confirmation-timeout согласовать с финальностью Base L2 #1154

Closed
opened 2026-07-19 17:05:43 +00:00 by andrei · 1 comment
Owner

Из SEC-Q2 MEDIUM backlog (аудит, срез 2026-07-10).

Таймаут подтверждения escrow не согласован с реальной финальностью Base L2 — возможен спор при reorg/задержке. Пересчитать таймауты от блоков финальности, состояние — строго через state machine, авто-cancel по истечении.

Из SEC-Q2 MEDIUM backlog (аудит, срез 2026-07-10). Таймаут подтверждения escrow не согласован с реальной финальностью Base L2 — возможен спор при reorg/задержке. Пересчитать таймауты от блоков финальности, состояние — строго через state machine, авто-cancel по истечении.
Author
Owner

Закрыто как covered (анализ 2026-07-20, evidence из master; код опередил трекер — issue из среза 2026-07-10, фиксы SEC-Q2-2026 приземлились позже).

Заявленный intent («confirmation-timeout escrow согласовать с финальностью Base L2, пересчитать таймауты от блоков финальности; спор при reorg/задержке») уже реализован:

  1. Confirmation-timeout = финальность L2api/src/services/p2pEscrow/clients.ts:50-56 (AUDIT-423 BC-002 + SEC-Q2-2026): ESCROW_CONFIRMATIONS=64 (L2 finality), ESCROW_RECEIPT_TIMEOUT_MS=200_000 пересчитан именно от блок-тайма Base (~2s): 64×2s=128s + slack. Прежний 60s был структурно недостижим (escrow таймаутил даже на успехе). waitAndVerifyTx ждёт confirmations: 64.
  2. Reorg-safetyapi/src/cron/bridge-reorg.ts (AUDIT-2026-05-29): per-chain CONFIRMATIONS (Base=64, ETH=12, Arbitrum=4800 с учётом L1-driven finality, Polygon=128), finalizedBlock(tip - conf) + finalized block-tag. Cursor не чекпоинтит 0-conf tip → reorg не теряет/не двоит события.
  3. Статус меняется только после finalitycreate.ts:266, deposit.ts:68: waitAndVerifyTx (64 conf) вызывается СИНХРОННО до DB-update статуса; reorg в пределах 64 conf не апрувит преждевременно.
  4. Нет race auto-expiry vs pending-settlementESCROW_EXPIRY_HOURS=24 (helpers.ts:16) → expiresAt = 24h, а confirmation-window ~200s (~430× запас). Escrow-expiry cron (escrowExpiry.ts) исключает статусы SETTLED/REFUNDED/DISPUTED/EXPIRED и не тронет escrow пока 24h не пройдут.

Остаточного гапа нет.

**Закрыто как covered (анализ 2026-07-20, evidence из master; код опередил трекер — issue из среза 2026-07-10, фиксы SEC-Q2-2026 приземлились позже).** Заявленный intent («confirmation-timeout escrow согласовать с финальностью Base L2, пересчитать таймауты от блоков финальности; спор при reorg/задержке») уже реализован: 1. **Confirmation-timeout = финальность L2** — `api/src/services/p2pEscrow/clients.ts:50-56` (AUDIT-423 BC-002 + SEC-Q2-2026): `ESCROW_CONFIRMATIONS=64` (L2 finality), `ESCROW_RECEIPT_TIMEOUT_MS=200_000` пересчитан именно от блок-тайма Base (~2s): 64×2s=128s + slack. Прежний 60s был структурно недостижим (escrow таймаутил даже на успехе). `waitAndVerifyTx` ждёт `confirmations: 64`. 2. **Reorg-safety** — `api/src/cron/bridge-reorg.ts` (AUDIT-2026-05-29): per-chain `CONFIRMATIONS` (Base=64, ETH=12, Arbitrum=4800 с учётом L1-driven finality, Polygon=128), `finalizedBlock(tip - conf)` + `finalized` block-tag. Cursor не чекпоинтит 0-conf tip → reorg не теряет/не двоит события. 3. **Статус меняется только после finality** — `create.ts:266`, `deposit.ts:68`: `waitAndVerifyTx` (64 conf) вызывается СИНХРОННО до DB-update статуса; reorg в пределах 64 conf не апрувит преждевременно. 4. **Нет race auto-expiry vs pending-settlement** — `ESCROW_EXPIRY_HOURS=24` (`helpers.ts:16`) → `expiresAt` = 24h, а confirmation-window ~200s (~430× запас). Escrow-expiry cron (`escrowExpiry.ts`) исключает статусы SETTLED/REFUNDED/DISPUTED/EXPIRED и не тронет escrow пока 24h не пройдут. Остаточного гапа нет.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
europa-tech-srl/europatech#1154
No description provided.