Context
Both adapters already capture pause status (status on Blend, is_paused() on K2) in raw data, but neither feeds it into a score. This is the "third adapter trigger" CLAUDE.md warns about — the longer it stays unscored, the more adapters have to be retrofitted later.
Scope
In scope: resolve the taxonomy question — new factor, multiplier on the overall score, or display-only flag — then implement it consistently across all adapters.
Out of scope: implementing before the taxonomy decision is made.
Acceptance criteria
Difficulty
Intermediate — needs familiarity with the codebase or methodology
Relabelled from "Easy" on 2026-08-25. The original estimate assumed the taxonomy question could
be settled from the adapters' existing raw fields. It could not. Getting the decision right required
reading both protocols' contract source — Blend's require_action_allowed and
execute_set_pool_status/execute_update_pool_status for the seven-value status enum (the
published docs name the states but publish no numeric mapping, and the mapping in search results is
partly wrong), and K2's validation.rs/emergency.rs plus the ReserveConfiguration bit layout in
its audited source. That reading is what turned up the finding the whole decision rests on: Blend
never blocks a withdrawal at any status, while K2's pause blocks withdrawals, repayments and
liquidations, so the two protocols' "paused" states are not the same state.
Whatever is decided, the implementation is not self-contained either: it touches
core/src/types.ts, the Adapter interface (and so ADAPTER_INTERFACE_VERSION), both adapters, a
DB migration, indexer persistence, the store, API.md, and the dashboard.
Notes / open questions
A paused pool is arguably a safety signal (admin responding to a threat) as much as a risk signal (something is wrong). That ambiguity is exactly why this needs deciding rather than defaulting.
Context
Both adapters already capture pause status (
statuson Blend,is_paused()on K2) in raw data, but neither feeds it into a score. This is the "third adapter trigger"CLAUDE.mdwarns about — the longer it stays unscored, the more adapters have to be retrofitted later.Scope
In scope: resolve the taxonomy question — new factor, multiplier on the overall score, or display-only flag — then implement it consistently across all adapters.
Out of scope: implementing before the taxonomy decision is made.
Acceptance criteria
METHODOLOGY.mdupdatedDifficulty
Intermediate — needs familiarity with the codebase or methodology
Relabelled from "Easy" on 2026-08-25. The original estimate assumed the taxonomy question could
be settled from the adapters' existing raw fields. It could not. Getting the decision right required
reading both protocols' contract source — Blend's
require_action_allowedandexecute_set_pool_status/execute_update_pool_statusfor the seven-valuestatusenum (thepublished docs name the states but publish no numeric mapping, and the mapping in search results is
partly wrong), and K2's
validation.rs/emergency.rsplus theReserveConfigurationbit layout inits audited source. That reading is what turned up the finding the whole decision rests on: Blend
never blocks a withdrawal at any status, while K2's pause blocks withdrawals, repayments and
liquidations, so the two protocols' "paused" states are not the same state.
Whatever is decided, the implementation is not self-contained either: it touches
core/src/types.ts, theAdapterinterface (and soADAPTER_INTERFACE_VERSION), both adapters, aDB migration, indexer persistence, the store,
API.md, and the dashboard.Notes / open questions
A paused pool is arguably a safety signal (admin responding to a threat) as much as a risk signal (something is wrong). That ambiguity is exactly why this needs deciding rather than defaulting.