Mapping Invariants
Start here before designing or implementing assertions. This skill defines the invariant‑mapping workflow and hands off to the other skills.
Meta-Cognitive Protocol
Adopt the role of a Meta-Cognitive Reasoning Expert.
For every complex problem:
1.DECOMPOSE: Break into sub-problems
2.SOLVE: Address each with explicit confidence (0.0-1.0)
3.VERIFY: Check logic, facts, completeness, bias
4.SYNTHESIZE: Combine using weighted confidence
5.REFLECT: If confidence <0.8, identify weakness and retry
For simple questions, skip to direct answer.
Always output:
∙Clear answer
∙Confidence level
∙Key caveats
When to Use
- Starting a new protocol assertion effort.
- You need a structured method to discover invariants.
- You want the step‑by‑step path before
designing-assertions and implementing-assertions.
When NOT to Use
- You already have a vetted invariant list.
- You only need implementation details. Use
implementing-assertions.
- You only need testing guidance. Use
testing-assertions.
Quick Start
- Build the protocol map (assets, roles, entrypoints, state, routers).
- Enumerate invariants by category (access control, accounting, pricing, solvency, limits, modes).
- Rank invariants by impact and likelihood (losses, control‑plane, liveness).
- Identify exceptions and acceptable violations.
- Pick data sources (state, logs, call inputs, slots).
- Choose enforcement location (chokepoint vs per‑contract).
- Produce the invariant matrix and trigger map.
- Hand off to
designing-assertions → implementing-assertions → testing-assertions.
Skill Map
designing-assertions: turn the invariant map into triggerable invariants and edge cases.
implementing-assertions: write Solidity assertions and cheatcode logic.
testing-assertions: build PCL/forge tests for assertions.
backtesting-assertions: replay mainnet txs to validate triggers.
pcl-assertion-workflow: set up PCL project, store/submit/deploy.
assertion-troubleshooting: diagnose non-triggering or failing assertions.
Workflow
- Protocol map: read docs/specs/audits/tests; list contracts, assets, roles, and critical entrypoints.
- Invariant inventory: express “states that must never occur” and rank by impact.
- Spec classification: split global invariants vs action-specific postconditions (GPOST/HSPOST).
- Exception audit: capture legitimate exceptions (bad debt, emergency modes, timelocks).
- Observation plan: decide which values/events you will read to validate each invariant.
- Trigger plan: select the narrowest trigger that guarantees coverage.
- Coverage check: confirm each invariant is reachable from at least one trigger and entrypoint.
- Feasibility check: internal calls are not traced; call inputs are ordered per selector; modified mapping keys must be derived from call inputs or logs; if an invariant depends on
msg.data, plan to reconstruct it from selector + args because call inputs exclude the selector.
Heuristics
- Start with loss‑bearing invariants: solvency, accounting integrity, and upgrade control.
- Prefer cross‑function invariants over per‑function reverts already in code.
- If you cannot observe an invariant reliably, rephrase it to observable signals.
- For lending protocols, classify actions by health‑factor impact and list allowed transitions.
- If an invariant depends on intermediate call frames, plan to use
forkPreCall/forkPostCall from the start.
Deliverables
- Invariant matrix (definition, source, exceptions, priority).
- Trigger map (selector/slot/balance mapping).
- Data source list (storage layout, logs, call inputs).
- Test plan (positive/negative, fuzz, backtest candidates).
Rationalizations to Reject
- “We can skip invariant mapping and write code directly.”
- “We only need owner checks.” (Protocols usually fail on accounting and pricing.)
- “One broad assertion is enough.” (Gas and coverage risks.)
- “We’ll add exceptions later.” (Most false positives come from ignored exceptions.)
References
- Invariant Mapping Workflow
- Protocol Example Patterns
- Lending Protocol Invariant Checklist
1---2name: mapping-invariants3description: Phylax Credible Layer assertions invariant mapping. Use when starting a protocol to map invariants before writing phylax/credible layer assertions or tests.4---5
6# Mapping Invariants
7
8Start here before designing or implementing assertions. This skill defines the invariant‑mapping workflow and hands off to the other skills.
9
10## Meta-Cognitive Protocol
11Adopt the role of a Meta-Cognitive Reasoning Expert.
12
13For every complex problem:
141.DECOMPOSE: Break into sub-problems
152.SOLVE: Address each with explicit confidence (0.0-1.0)
163.VERIFY: Check logic, facts, completeness, bias
174.SYNTHESIZE: Combine using weighted confidence
185.REFLECT: If confidence <0.8, identify weakness and retry
19For simple questions, skip to direct answer.
20
21Always output:
22∙Clear answer
23∙Confidence level
24∙Key caveats
25
26## When to Use
27- Starting a new protocol assertion effort.
28- You need a structured method to discover invariants.
29- You want the step‑by‑step path before `designing-assertions` and `implementing-assertions`.
30
31## When NOT to Use
32- You already have a vetted invariant list.
33- You only need implementation details. Use `implementing-assertions`.
34- You only need testing guidance. Use `testing-assertions`.
35
36## Quick Start
371. Build the protocol map (assets, roles, entrypoints, state, routers).
382. Enumerate invariants by category (access control, accounting, pricing, solvency, limits, modes).
393. Rank invariants by impact and likelihood (losses, control‑plane, liveness).
404. Identify exceptions and acceptable violations.
415. Pick data sources (state, logs, call inputs, slots).
426. Choose enforcement location (chokepoint vs per‑contract).
437. Produce the invariant matrix and trigger map.
448. Hand off to `designing-assertions` → `implementing-assertions` → `testing-assertions`.
45
46## Skill Map
47- `designing-assertions`: turn the invariant map into triggerable invariants and edge cases.
48- `implementing-assertions`: write Solidity assertions and cheatcode logic.
49- `testing-assertions`: build PCL/forge tests for assertions.
50- `backtesting-assertions`: replay mainnet txs to validate triggers.
51- `pcl-assertion-workflow`: set up PCL project, store/submit/deploy.
52- `assertion-troubleshooting`: diagnose non-triggering or failing assertions.
53
54## Workflow
55- **Protocol map**: read docs/specs/audits/tests; list contracts, assets, roles, and critical entrypoints.
56- **Invariant inventory**: express “states that must never occur” and rank by impact.
57- **Spec classification**: split global invariants vs action-specific postconditions (GPOST/HSPOST).
58- **Exception audit**: capture legitimate exceptions (bad debt, emergency modes, timelocks).
59- **Observation plan**: decide which values/events you will read to validate each invariant.
60- **Trigger plan**: select the narrowest trigger that guarantees coverage.
61- **Coverage check**: confirm each invariant is reachable from at least one trigger and entrypoint.
62- **Feasibility check**: internal calls are not traced; call inputs are ordered per selector; modified mapping keys must be derived from call inputs or logs; if an invariant depends on `msg.data`, plan to reconstruct it from selector + args because call inputs exclude the selector.
63
64## Heuristics
65- Start with loss‑bearing invariants: solvency, accounting integrity, and upgrade control.
66- Prefer cross‑function invariants over per‑function reverts already in code.
67- If you cannot observe an invariant reliably, rephrase it to observable signals.
68- For lending protocols, classify actions by health‑factor impact and list allowed transitions.
69- If an invariant depends on intermediate call frames, plan to use `forkPreCall`/`forkPostCall` from the start.
70
71## Deliverables
72- Invariant matrix (definition, source, exceptions, priority).
73- Trigger map (selector/slot/balance mapping).
74- Data source list (storage layout, logs, call inputs).
75- Test plan (positive/negative, fuzz, backtest candidates).
76
77## Rationalizations to Reject
78- “We can skip invariant mapping and write code directly.”
79- “We only need owner checks.” (Protocols usually fail on accounting and pricing.)
80- “One broad assertion is enough.” (Gas and coverage risks.)
81- “We’ll add exceptions later.” (Most false positives come from ignored exceptions.)
82
83## References
84- [Invariant Mapping Workflow](references/invariant-mapping-workflow.md)
85- [Protocol Example Patterns](references/protocol-examples.md)
86- [Lending Protocol Invariant Checklist](references/lending-invariant-checklist.md)