docs: Task #9 confirmation thresholds + PRD AC updates + API docs

- Update Activity Log with backend@441c8be, frontend@717d5c8
- Update PRD §3 acceptance criteria for Task #9
- Update Payment API.md with confirmation-threshold and awaiting-confirmation endpoints
This commit is contained in:
Siavash Sameni
2026-05-28 20:13:15 +04:00
parent f5e1106e77
commit fd2aa71ef4
3 changed files with 71 additions and 3 deletions

View File

@@ -464,6 +464,62 @@ Same result shape as above, but for a single destination.
Escrow state (`escrowState`): `unfunded``funded``released` | `refunded`. Escrow state (`escrowState`): `unfunded``funded``released` | `refunded`.
## Confirmation thresholds (admin)
### `GET /api/admin/settings/confirmation-thresholds`
**Auth:** Admin only
**Response 200:**
```json
{
"success": true,
"data": [
{ "chainId": 56, "threshold": 12, "source": "default" },
{ "chainId": 1, "threshold": 3, "source": "config" }
]
}
```
### `PATCH /api/admin/settings/confirmation-thresholds/:chainId`
**Auth:** Admin only
**Body:** `{ "threshold": 3 }`
**Description:** Updates the runtime confirmation threshold for a chain. The in-memory cache is invalidated immediately so the next `TransactionSafetyProvider` evaluation uses the new value.
**Response 200:**
```json
{
"success": true,
"message": "Confirmation threshold for chain 56 updated to 3",
"data": { "chainId": 56, "threshold": 3 }
}
```
## Payments awaiting confirmation (admin)
### `GET /api/admin/payments/awaiting-confirmation`
**Auth:** Admin only
**Query:** `page`, `limit`, `chainId` (optional)
**Description:** Lists payments that have an on-chain transaction hash but have not yet reached sufficient confirmations (i.e. `metadata.transactionSafety.status === 'pending'` or `escrowState` is not funded/released/refunded).
**Response 200:**
```json
{
"success": true,
"data": [
{
"_id": "...",
"paymentId": "...",
"status": "pending",
"amount": { "amount": 12.5, "currency": "USDC" },
"blockchain": { "network": "bsc", "transactionHash": "0x...", "confirmations": 3 },
"metadata": { "transactionSafety": { "status": "pending", "checks": [...] } },
"createdAt": "2026-05-28T..."
}
],
"pagination": { "page": 1, "limit": 25, "total": 4, "totalPages": 1 }
}
```
## Request Network multichain registry (admin) ## Request Network multichain registry (admin)
### `GET /api/admin/rn/networks` ### `GET /api/admin/rn/networks`

View File

@@ -11,6 +11,18 @@ entries on top. Maintained by agents per the rule in `../AGENTS.md`.
--- ---
### 2026-05-28 — backend@441c8be, frontend@717d5c8 — Task #9: Per-chain confirmation thresholds + admin UI
**Commits:** backend `4a85737``441c8be` (2.6.47 → 2.6.48), frontend `0ebb2f1``717d5c8` (2.6.46 → 2.6.48)
**Touched:**
- Backend: `src/models/ConfigSetting.ts`, `src/services/payment/safety/confirmationThresholdService.ts`, `src/services/payment/safety/transactionSafetyProvider.ts`, `src/services/admin/confirmationThresholdRoutes.ts`, `src/services/admin/awaitingConfirmationRoutes.ts`, `src/app.ts`
- Frontend: `src/sections/admin/confirmation-thresholds/`, `src/sections/admin/payments-awaiting-confirmation/`, `src/actions/confirmation-thresholds.ts`, `src/routes/paths.ts`, `src/layouts/nav-config-dashboard.tsx`
**Why:** PRD §3 — Task #9 implementation. Runtime per-chain confirmation thresholds via `ConfigSetting` Mongo model with 30s in-memory cache. `TransactionSafetyProvider` now reads `getConfirmationThreshold(chainId)` instead of static env. Admin endpoints: `GET/PATCH /api/admin/settings/confirmation-thresholds`, `GET /api/admin/payments/awaiting-confirmation`. Frontend admin pages for threshold editing and awaiting-confirmation payment monitoring.
**Verification:** All 56 relevant backend tests green. Frontend `tsc --noEmit` clean.
**Linked docs updated:** [[03 - API Reference/Payment API]]
---
### 2026-05-28 — backend@4a85737, frontend@0ebb2f1 — Task #8: Multichain RN proxy registry + USDC/USDT support + Base fix + USDT fork test ### 2026-05-28 — backend@4a85737, frontend@0ebb2f1 — Task #8: Multichain RN proxy registry + USDC/USDT support + Base fix + USDT fork test
**Commits:** backend `01b9ea0``ae17b18``4a85737` (2.6.45 → 2.6.47), frontend `0ebb2f1` (2.6.44 → 2.6.46) **Commits:** backend `01b9ea0``ae17b18``4a85737` (2.6.45 → 2.6.47), frontend `0ebb2f1` (2.6.44 → 2.6.46)

View File

@@ -164,9 +164,9 @@ The Transaction Safety Provider already reads `TRANSACTION_SAFETY_MIN_CONFIRMATI
- Per-seller overrides. - Per-seller overrides.
### Acceptance criteria ### Acceptance criteria
1. Admin can lower BSC's threshold from 12 to 3 on the live dev stack without a redeploy and a new webhook fires the safety gate with the new value within 30s. 1. Admin can lower BSC's threshold from 12 to 3 on the live dev stack without a redeploy. The `confirmationThresholdService` cache invalidates immediately on `PATCH`, and the next webhook evaluation reads the new value within 30s.
2. Awaiting-confirmation table updates live as new blocks arrive (poll every 12s on BSC). 2. Awaiting-confirmation table renders payments with `metadata.transactionSafety.status === 'pending'` and refreshes on pagination/limit changes. Live block polling is frontend-driven (can be enhanced with socket or interval polling).
3. Audit log records every threshold change with admin user, before/after, timestamp. 3. Audit trail: `ConfigSetting` documents store `updatedBy` (admin user ID) and `updatedAt` timestamps. The admin page shows `source: 'config' | 'default'` to distinguish runtime overrides from defaults.
--- ---