data-availability-enforcement

A security check for blockchain data-availability systems such as Arweave or Celestia, where validators are expected to make committed data available. It checks whether a block's data commitment is backed by proof that the data was actually published, shared, or sampled.

In plain words
What is it for?
Use it when auditing storage or data-availability blockchains, especially publish ledgers, data roots, blob commitments, availability proofs, and validator checks.
Why use it?
It catches cases where a producer can claim or commit to data without being forced to make that data available. That gap can undermine a system whose economic model depends on stored data.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/plamentsv/plamen/data-availability-enforcement
Any agent
npx skills add PlamenTSV/plamen --skill data-availability-enforcement
Clone the repo
git clone --depth 1 https://github.com/PlamenTSV/plamen

Made for: Claude Code, Codex.

Per session 55 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,311 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00055 $0.02311
Opus 5 $0.00028 $0.01156
Sonnet 5 $0.00011 $0.00462
Haiku 4.5 $0.00006 $0.00231

Measured 3d ago against content hash 16328d793030, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

data-availability-enforcement scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

agents/skills/injectable/l1/data-availability-enforcement/SKILL.md · 165 lines

How it starts

The opening of the file, as written. The whole thing — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Injectable Skill: Data Availability Enforcement

L1 trigger: L1_PATTERN=true AND protocol-type is one of: storage, data_availability, da_chain, da_layer, blob_storage. Detection: recon finds a "publish ledger", "data root", "blob commitment", "DA root", or "ingress proof" structure in the block header AND the protocol's economic model assumes miners store data. Inject Into: depth-consensus-invariant, depth-state-trace Language: Go and Rust Finding prefix: [DA-N] Status: v0.1 — derived from a prior DA-chain audit post-mortem

When This Skill Activates

Data availability chains are L1s whose primary function is to commit to and serve user data, not just to settle transactions. Examples: Arweave (permanent storage), Celestia (rollup blob DA). The trust model is fundamentally different from settlement L1s: validators must enforce that committed data is actually available, not just that the commitment is well-formed.

The single most common DA-chain bug class is: the block header carries a commitment to data X, the producer is paid for committing to X, but nothing in the protocol forces the producer to actually publish X. Honest miners assigned to store X cannot, get penalized, and the chain becomes unreliable.

1. Commitment Inventory

Enumerate every block-header field that commits to data the protocol expects to be stored elsewhere:

  • "Publish ledger" / "Submit ledger" / "DA root" / "blob commitment" / "data root"
  • "Ingress proof root" / "chunk merkle root"
  • "Replication committee assignments" / "partition assignments"

For each, identify:

  1. The exact field path in the block header struct
  2. The economic action attached to inclusion (reward, partition assignment, slashing trigger)
  3. The set of actors expected to store the committed data after inclusion

Write the inventory to scratchpad/da_commitment_inventory.md.

2. Availability Check Audit

For EACH commitment in the inventory, the validator must enforce that the data is actually available. Three valid mechanisms:

Read the full file on GitHub · 165 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 3d ago First seen · 165 lines · 55 tokens per session scan A 16328d793030

Subscribe to this mod's changes

data-availability-enforcement is a skill published in the GitHub repository PlamenTSV/plamen (281 stars, last pushed 1mo ago), licensed MIT. It adds 55 tokens to every session and 2,311 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.