home / skills / sounder25 / google-antigravity-skills-library / 22_state_overlay_consistency
This skill detects and prevents state-visibility violations across execution contexts within a transaction to ensure consistent code and storage visibility.
npx playbooks add skill sounder25/google-antigravity-skills-library --skill 22_state_overlay_consistencyReview the files below or copy the command above to add this skill to your agents.
---
name: State Overlay Consistency Checker
description: Detect and prevent state-visibility violations across execution contexts within a single transaction.
---
# SKILL-022 — State Overlay Consistency Checker
## Status
**PROPOSED → VERIFIED (after EELS reproduction)**
## Purpose
Detect and prevent state-visibility violations across execution contexts within a single transaction.
This skill ensures that state mutations (code deployment, storage writes, warm slots, balances) performed in one execution frame (e.g., CREATE, CREATE2) are visible and inherited by all subsequent execution contexts (CALL, DELEGATECALL, STATICCALL) during the same transaction.
This skill exists to stop silent gas under-charging and consensus-breaking execution paths.
## Problem Class
### Silent Overlay Forking
A transaction performs:
1. **CREATE / CREATE2**
2. Writes code to state
3. Immediately performs **CALL** to the created address
**But:**
- Child execution context does not see the deployed code.
- Call executes as if target is empty.
- Gas accounting under-charges.
- Final balances diverge from expected EELS state.
This failure is invisible to standard unit tests unless gas and state continuity are explicitly validated.
## Trigger
- **Manual:** `verify state continuity`
- **Automatic (any single transaction):**
- CREATE → CALL
- CREATE2 → CALL
- CREATE → DELEGATECALL
- TSTORE → CALL
- SSTORE → CALL
## Preconditions
- Transaction-scoped execution
- Nested execution contexts / overlays
- Ability to inspect:
- Code
- Storage
- Gas accounting
- Frame hierarchy
## Core Invariants
### 1. Code Visibility Invariant
If code is written at address A at time T, then:
`GetCode(A)` MUST return non-empty for all execution frames at time > T within the same transaction.
**Violation ⇒ FAIL**
### 2. Overlay Inheritance Invariant
Every child execution frame must:
- Inherit parent overlay state
- Not fork from base/global snapshot
- Preserve:
- Code hashes
- Storage roots
- Warm slot sets
**Unexpected divergence ⇒ FAIL**
### 3. Gas Propagation Sanity Check
For any CALL:
- If target address has non-empty code: Child execution must consume gas.
- If total gas charged equals base cost only (e.g., 2600): Flag as probable invisible execution.
This check is heuristic but high-confidence.
### 4. Write-Then-Read Consistency
Detect patterns:
- SetCode → GetCode
- SSTORE → SLOAD
- TSTORE → TLOAD
If a read does not observe a prior write within the same transaction, fail immediately.
## Output
### PASS
```json
{
"status": "PASS",
"frames_checked": 7,
"mutations_verified": 14
}
```
### FAIL
```json
{
"status": "FAIL",
"failure_type": "state_overlay_inconsistency",
"address": "0x05d4acfafec9c8ac000000000000000000000000",
"symptoms": [
"CALL charged base gas only",
"child execution gas == 0",
"deployed code invisible"
],
"root_cause_hint": "Subcall created fresh overlay without inheriting parent state"
}
```
## Severity
- **Critical**
- Silent gas mis-accounting
- Invalid execution semantics
- Potential consensus divergence
- Auto-block recommended
## Integration
| Skill | Role |
|-------|------|
| **SKILL-007** | Requires invariants |
| **SKILL-017** | Detects stuck execution |
| **SKILL-018** | Hard pre-execution gate |
| **SKILL-019** | Red-team scenario gen |
| **SKILL-020** | Postmortem logging |
## Design Principle
State changes are meaningless unless they are observable.
### Origin
Derived from:
**CS-001 — State Overlay Visibility Failure during CREATE2 → CALL execution.**
This skill exists to prevent gas-math patches that mask state-propagation bugs.
This skill detects and prevents state-visibility violations that occur when execution frames within a single transaction do not inherit their parent overlays. It ensures deployed code, storage writes, warm slot sets, and gas accounting remain consistent and observable across CREATE/CREATE2 and subsequent CALL/DELEGATECALL/STATICCALL frames. Use it to catch silent gas under-charging and consensus-risking execution paths before they reach production.
The checker inspects transaction-scoped execution frames and validates a set of core invariants: code visibility, overlay inheritance, gas propagation sanity, and write-then-read consistency. It walks the frame hierarchy, compares code hashes, storage roots, warm slot sets, and gas accounting between parent and child frames, and flags any divergence as a failure. Heuristic gas checks detect cases where a call appears to have been charged base gas only despite a non-empty target.
What constitutes a definitive failure versus a heuristic warning?
Read-after-write mismatches (e.g., SetCode → GetCode returning empty) are definitive failures. Gas-propagation checks are heuristic but treated as high-confidence when combined with other overlay divergences.
When should this skill auto-block a transaction?
Auto-block recommended for critical environments when a code-visibility or overlay-inheritance invariant fails, because such failures can silently break gas accounting and risk consensus divergence.