An AIP stage checklist before protocol parameter changes helps researchers separate forum discussion from executable governance. The primary keyword is AIP stage checklist, and the search intent is protocol due diligence: understand what has actually moved toward vote, payload and implementation.
Radar treats parameter governance as operational risk. A proposed LTV, cap, freeze, oracle or liquidation change can affect users before they notice it in a front end.
The checklist below is evergreen because mature protocols repeatedly move from discussion to vote to execution, and the riskiest moment is often when users assume the proposal is still only theoretical.
Confirm The Governance Stage
Start by identifying whether the item is a temp check, ARFC, direct-to-AIP, AIP, emergency guardian action or executed payload. Each stage carries different certainty and timing.
AIP-stage proposals deserve extra attention because they usually include concrete payloads, vote links and implementation assumptions. The researcher should stop treating the change as a vague roadmap item once execution machinery is visible.
Read The Exact Parameter Delta
Do not summarize a risk change only by headline. Record the current value, target value, affected markets, chains and asset modes. LTV, liquidation threshold, reserve factor, supply cap and borrow cap changes affect different user groups.
Mode-specific changes matter. E-Mode, isolation mode and deprecated markets can create exceptions that the title does not capture. A safe-looking parameter restoration can still leave one branch constrained.
Map User Impact Before Execution
A deposit user, borrower, liquidator, vault strategist and bridge user can all experience the same proposal differently. Before the vote ends, map who gains capability, who loses margin and who must take action.
Pay special attention to timing. A change that restores borrowing power after an incident may reduce friction, while a cap reduction or freeze can trap users who waited for the front end to warn them.
Verify Payload And Follow-Up
If code or transaction payloads are linked, confirm that the payload matches the forum specification. After execution, check chain transactions, protocol dashboards and follow-up comments for deviations.
A good AIP-stage review ends with monitoring tasks: vote start, vote end, execution delay, target markets, user actions and the next forum thread. Governance is not finished when the title changes stage.
- Identify the exact governance stage before reacting.
- Record parameter deltas by market, chain and mode.
- Map which user groups are affected before execution.
- Verify payloads and follow-up transactions after the vote.
Keep A Governance Stage Log
An AIP stage checklist works best as a living log, not a one-time note. Record the first forum post, the stage label, the vote link, the expected execution chain, the payload owner and any guardian or risk-service comments. That record helps separate a proposal that is still social consensus from one that is already operationally ready.
For protocol users, the most important detail is usually not the headline parameter but the affected surface area. A single AIP can touch Ethereum, Base, Arbitrum, Linea or other deployments differently. It can also restore one market while leaving another frozen, capped or excluded from a mode-specific setting.
After execution, compare the final onchain state with the forum text. If the dashboard, payload and market parameters disagree, treat the discrepancy as a follow-up risk item until maintainers clarify it. The checklist should end only when the actual protocol state matches the decision users relied on.
Researchers should also keep track of communication channels after the vote. Forum updates, Snapshot posts, governance portals, risk-provider dashboards and chain explorers may not update at the same speed. When a parameter change is sensitive, the safest workflow is to wait for at least two confirming surfaces before treating the protocol state as settled.
This avoids a common discovery mistake: assuming the most recent comment is the final state. Governance is a process, and the checklist should follow that process until the user-facing risk has actually changed.
The checklist is finished only when monitoring confirms the live parameter state.
Continue this cluster
Continue this cluster with governance and protocol-risk checklists that help researchers evaluate executable changes before users are surprised.
