code/cl8y-dex-terraclassic

Fork 0

Security: no anomaly checklist with thresholds for small TVL incident scenarios [SEC-G02] #435

New issue

Closed

opened 2026-06-29 16:08:48 +00:00 by totdking · 9 comments

totdking commented

2026-06-29 16:08:48 +00:00

(Migrated from gitlab.com)

No description provided.

totdking commented

2026-06-29 16:09:56 +00:00

(Migrated from gitlab.com)

Summary

No document defines anomaly thresholds or response actions for the small-TVL scenarios listed in SEC-G02. The blacklist-decision.md runbook defines when to apply blacklist controls after an exploit is confirmed, but it does not define proactive thresholds (e.g., single wallet drains >X% pool in one block, LP add/remove cycle profit exceeding Y%, route slippage deviation beyond Z%). The incident template lists triage checks but no anomaly detection criteria or automatic escalation triggers.

What Was Checked

docs/runbooks/blacklist-decision.md: covers confirmed-evidence criteria for wallet/token/pair blacklist. No proactive anomaly thresholds defined.
docs/templates/incident-dex-indexer.md: triage section checks contract pause state, tx codes, indexer DB/LCD reachability. No anomaly pattern checklist.
docs/security-posture.md: mentions "monitoring" as a requirement but specifies no thresholds or commands.
All docs and runbooks searched: no anomaly checklist with defined thresholds found.

Expected (per checklist)

The incident runbook must include a simple anomaly checklist covering at minimum: single wallet drains more than a defined percentage of a pool in one session; repeated add/remove cycles with profit; sudden deviation in route slippage beyond an expected band; many failed txs from one address in a short window; LCD-heavy route flood. Each entry must include a defined threshold and a response action (investigate, pair pause, rate limit increase, blacklist escalation).

Actual

No anomaly checklist exists. The current runbooks are reactive (applied after confirmed exploitation). There is no proactive anomaly detection guide for operators monitoring a live small-TVL system.

Evidence

docs/runbooks/blacklist-decision.md: confirmed-evidence only, no proactive thresholds
docs/templates/incident-dex-indexer.md: no anomaly pattern section
docs/security-posture.md lines 68-72: TVL band table references monitoring but specifies no thresholds

Suggested Fix

Add an anomaly checklist section to docs/templates/incident-dex-indexer.md (or a new docs/runbooks/anomaly-signals.md) covering: (1) single wallet LP withdraw or swap draining more than a defined percentage of pool reserves in one session -- trigger: pair pause; (2) repeated add/remove cycles by one wallet within a short window -- trigger: investigate for sandwich or pool drain profit; (3) route slippage on a quote exceeding an expected band relative to reserves -- trigger: check reserve consistency; (4) many failed txs from one address (error codes) in a rolling window -- trigger: rate-limit review or wallet investigation; (5) spike in LCD-heavy endpoint 429s -- trigger: rate limit review. Each entry must include a defined threshold and a first response action.

Verification Checklist

An anomaly checklist section or runbook defines thresholds for: pool drain percentage, add/remove profit loop, route slippage deviation, failed tx volume, LCD-heavy flood
Each entry includes a defined threshold value and a response action
The checklist is linked from the incident template

Labels

security, pre-launch

Cc: @PlasticDigits

### Summary No document defines anomaly thresholds or response actions for the small-TVL scenarios listed in SEC-G02. The `blacklist-decision.md` runbook defines when to apply blacklist controls after an exploit is confirmed, but it does not define proactive thresholds (e.g., single wallet drains \>X% pool in one block, LP add/remove cycle profit exceeding Y%, route slippage deviation beyond Z%). The incident template lists triage checks but no anomaly detection criteria or automatic escalation triggers. --- ### What Was Checked - `docs/runbooks/blacklist-decision.md`: covers confirmed-evidence criteria for wallet/token/pair blacklist. No proactive anomaly thresholds defined. - `docs/templates/incident-dex-indexer.md`: triage section checks contract pause state, tx codes, indexer DB/LCD reachability. No anomaly pattern checklist. - `docs/security-posture.md`: mentions "monitoring" as a requirement but specifies no thresholds or commands. - All docs and runbooks searched: no anomaly checklist with defined thresholds found. --- ### Expected (per checklist) The incident runbook must include a simple anomaly checklist covering at minimum: single wallet drains more than a defined percentage of a pool in one session; repeated add/remove cycles with profit; sudden deviation in route slippage beyond an expected band; many failed txs from one address in a short window; LCD-heavy route flood. Each entry must include a defined threshold and a response action (investigate, pair pause, rate limit increase, blacklist escalation). --- ### Actual No anomaly checklist exists. The current runbooks are reactive (applied after confirmed exploitation). There is no proactive anomaly detection guide for operators monitoring a live small-TVL system. --- ### Evidence - `docs/runbooks/blacklist-decision.md`: confirmed-evidence only, no proactive thresholds - `docs/templates/incident-dex-indexer.md`: no anomaly pattern section - `docs/security-posture.md` lines 68-72: TVL band table references monitoring but specifies no thresholds --- ### Suggested Fix Add an anomaly checklist section to `docs/templates/incident-dex-indexer.md` (or a new `docs/runbooks/anomaly-signals.md`) covering: (1) single wallet LP withdraw or swap draining more than a defined percentage of pool reserves in one session -- trigger: pair pause; (2) repeated add/remove cycles by one wallet within a short window -- trigger: investigate for sandwich or pool drain profit; (3) route slippage on a quote exceeding an expected band relative to reserves -- trigger: check reserve consistency; (4) many failed txs from one address (error codes) in a rolling window -- trigger: rate-limit review or wallet investigation; (5) spike in LCD-heavy endpoint 429s -- trigger: rate limit review. Each entry must include a defined threshold and a first response action. --- ### Verification Checklist - [ ] An anomaly checklist section or runbook defines thresholds for: pool drain percentage, add/remove profit loop, route slippage deviation, failed tx volume, LCD-heavy flood - [ ] Each entry includes a defined threshold value and a response action - [ ] The checklist is linked from the incident template --- ### Labels `security`, `pre-launch` Cc: @PlasticDigits

totdking commented

2026-06-29 16:15:51 +00:00

(Migrated from gitlab.com)

mentioned in issue #381

PlasticDigits commented

2026-06-30 02:21:48 +00:00

(Migrated from gitlab.com)

mentioned in merge request !966

Brouie commented

2026-06-30 02:59:04 +00:00

(Migrated from gitlab.com)

Ran the #435 ladder against issue-435-anomaly-signals-sec-g02.

check_anomaly_signals_docs.py -> OK (linked from incident template, security-posture, blacklist-decision)
verify-issue-435.sh -> PASS 5 / FAIL 0

Checklist maps:

thresholds for pool drain / add-remove loop / slippage / failed-tx / LCD flood: anomaly-signals.md A1–A5 each carry a numeric threshold (A1 >15% reserve in 1blk/10min, A2 >=3 cycles/30min net >0.5% TVL, A3 >30% slippage or >5% vs sim, A4 >=10 failed wasm/15min one addr, A5 >20% 429 over 5min or one IP >50% of 429s)
every row has a First-response + Escalation action
linked from the incident template Triage section

One honest flag: the threshold numbers are operator-judgement for a bootstrap-TVL launch, not calibrated against live volume yet — fine as a starting runbook, worth a tune once there's real flow.

Docs-only, no contract/indexer change. Verified on my side — @PlasticDigits good to merge !966 and close.

Ran the #435 ladder against issue-435-anomaly-signals-sec-g02. - check_anomaly_signals_docs.py -> OK (linked from incident template, security-posture, blacklist-decision) - verify-issue-435.sh -> PASS 5 / FAIL 0 Checklist maps: - thresholds for pool drain / add-remove loop / slippage / failed-tx / LCD flood: anomaly-signals.md A1–A5 each carry a numeric threshold (A1 >15% reserve in 1blk/10min, A2 >=3 cycles/30min net >0.5% TVL, A3 >30% slippage or >5% vs sim, A4 >=10 failed wasm/15min one addr, A5 >20% 429 over 5min or one IP >50% of 429s) - every row has a First-response + Escalation action - linked from the incident template Triage section One honest flag: the threshold numbers are operator-judgement for a bootstrap-TVL launch, not calibrated against live volume yet — fine as a starting runbook, worth a tune once there's real flow. Docs-only, no contract/indexer change. Verified on my side — @PlasticDigits good to merge !966 and close.

PlasticDigits commented

2026-06-30 05:39:54 +00:00

(Migrated from gitlab.com)

mentioned in commit 8de9d708e1

mentioned in commit 8de9d708e1e81796eeaf799d4ef81517d858e72b

PlasticDigits commented

2026-06-30 05:39:56 +00:00

(Migrated from gitlab.com)

mentioned in merge request !969

PlasticDigits commented

2026-06-30 05:41:35 +00:00

(Migrated from gitlab.com)

mentioned in commit 69f9902458

mentioned in commit 69f990245821e0efd5d95826a85f02118db8d60f

PlasticDigits commented

2026-06-30 05:41:51 +00:00

(Migrated from gitlab.com)

mentioned in merge request !970

PlasticDigits commented

2026-06-30 06:49:02 +00:00

(Migrated from gitlab.com)

Verification — #435 (SEC-G02)

Result: PASS — all acceptance criteria met on main after merge of !966.

What was verified

Criterion	Result	How
Anomaly checklist defines thresholds for pool drain %, add/remove profit loop, route slippage deviation, failed tx volume, LCD-heavy flood	PASS	`docs/runbooks/anomaly-signals.md` rows A1–A5 cover all five SEC-G02 scenarios with numeric thresholds
Each entry includes a defined threshold value and a response action	PASS	Every row has Threshold, First response, and Escalation columns; `python3 scripts/check_anomaly_signals_docs.py` → OK
Checklist linked from incident template	PASS	`docs/templates/incident-dex-indexer.md` Triage section links to anomaly runbook; also cross-linked from `security-posture.md` (bootstrap TVL row) and `blacklist-decision.md`

Commands run

python3 scripts/check_anomaly_signals_docs.py  → OK
bash scripts/qa/verify-issue-435.sh            → PASS 5 / FAIL 0

Manual review: opened anomaly-signals.md (A1 >15% reserve / 1 blk or 10 min → pair pause; A2 ≥3 cycles / 30 min net >0.5% TVL → investigate; A3 >30% slippage or >5% vs simulate → reserve check; A4 ≥10 failed wasm / 15 min → rate-limit review; A5 >20% 429 over 5 min or one IP >50% → rate limit review), incident template Triage link, and security-posture bootstrap row.

Follow-ups

Threshold numbers are operator-judgement for bootstrap TVL — revisit when sustained protocol TVL crosses ~$5M (noted in runbook). No contract/indexer changes required for this doc-only issue.

## Verification — #435 (SEC-G02) **Result: PASS** — all acceptance criteria met on `main` after merge of !966. ### What was verified | Criterion | Result | How | |-----------|--------|-----| | Anomaly checklist defines thresholds for pool drain %, add/remove profit loop, route slippage deviation, failed tx volume, LCD-heavy flood | **PASS** | `docs/runbooks/anomaly-signals.md` rows **A1–A5** cover all five SEC-G02 scenarios with numeric thresholds | | Each entry includes a defined threshold value and a response action | **PASS** | Every row has **Threshold**, **First response**, and **Escalation** columns; `python3 scripts/check_anomaly_signals_docs.py` → OK | | Checklist linked from incident template | **PASS** | `docs/templates/incident-dex-indexer.md` Triage section links to anomaly runbook; also cross-linked from `security-posture.md` (bootstrap TVL row) and `blacklist-decision.md` | ### Commands run ```text python3 scripts/check_anomaly_signals_docs.py → OK bash scripts/qa/verify-issue-435.sh → PASS 5 / FAIL 0 ``` Manual review: opened `anomaly-signals.md` (A1 >15% reserve / 1 blk or 10 min → pair pause; A2 ≥3 cycles / 30 min net >0.5% TVL → investigate; A3 >30% slippage or >5% vs simulate → reserve check; A4 ≥10 failed wasm / 15 min → rate-limit review; A5 >20% 429 over 5 min or one IP >50% → rate limit review), incident template Triage link, and security-posture bootstrap row. ### Follow-ups Threshold numbers are operator-judgement for bootstrap TVL — revisit when sustained protocol TVL crosses ~$5M (noted in runbook). No contract/indexer changes required for this doc-only issue.

PlasticDigits (Migrated from gitlab.com) closed this issue

2026-06-30 06:49:03 +00:00