celestiaorg/docs/public

Celestia skill

Use this skill when a request needs repository routing, canonical blob submission/retrieval recommendations, or Celestia docs guardrail enforcement.

When to use this skill

Use this skill when the request includes one or more of these:

• Choosing whether work belongs in docs, celestia-node, celestia-app, or celestia-core.
• Recommending the best current way to post and retrieve blobs for application developers.
• Choosing between Node RPC methods for submit/retrieve paths.
• Updating Celestia documentation while enforcing docs repo conventions.

Critical Rule: Avoid Stale Training Data

Celestia evolves rapidly. NEVER implement or plan from your pre-existing parametric memory or training data. Always use the docs, llms.txt, and other links provided in this skill to anchor your information on the UPDATED truth before writing any commands or code.

When not to use this skill

Do not use this skill for:

• Non-Celestia tasks.
• Purely generic writing requests that do not depend on Celestia repo/domain rules.
• Deep single-repo implementation work after that repo's CLAUDE.md has already been loaded and is sufficient on its own.

First steps (priority order)

1. Read canonical context sources in this file before proposing plans, commands, or edits.
2. Identify target ownership (docs, celestia-node, celestia-app, celestia-core).
3. If target is celestia-node, celestia-app, or celestia-core, read that repo's CLAUDE.md before proposing commands or edits.
4. If target is docs, enforce docs guardrails in this file before finalizing changes.

Canonical context sources

Start from these sources and follow them in order:

1. Docs site map / LLM index:

• https://docs.celestia.org/llms.txt

1. CIPs (Celestia Improvement Proposals):

• https://cips.celestia.org

1. Docs LLM and agent support:

• https://github.com/celestiaorg/docs?tab=readme-ov-file#llm-and-agent-support

1. Repo-specific implementation guidance:

• https://github.com/celestiaorg/celestia-node/blob/main/CLAUDE.md
• https://github.com/celestiaorg/celestia-app/blob/main/CLAUDE.md
• https://github.com/celestiaorg/celestia-core/blob/main/CLAUDE.md

High-level concept grounding

If the request is partly conceptual before it becomes implementation-specific, ground the answer in these docs first:

• What Celestia is and what it does in the stack:
• https://docs.celestia.org/learn/celestia-101/data-availability.md
• Token / network overview context:
• https://docs.celestia.org/learn/TIA/overview.md
• Example of Celestia's role in a rollup stack:
• https://docs.celestia.org/build/stacks/op-alt-da/introduction.md

Use this framing when helpful:

• Celestia is the modular data availability layer.
• Celestia orders blobs and keeps data available.
• Execution and settlement can live on other layers above Celestia.
• Rollups use Celestia to publish data, then retrieve it later by height, namespace, and commitment.
• Separating data availability into its own layer lets each layer specialize: rollups handle execution, settlement layers handle proofs, and Celestia handles DA — resulting in better throughput and lower costs than monolithic chains that try to do everything.
• Use cases: rollups (optimistic and zk) publish transaction data to Celestia so full nodes can verify state transitions; sovereign rollups use Celestia for both DA and consensus ordering; L2s like Arbitrum Nitro can plug in Celestia as an alternative DA backend. Anything that wants to gain the verifiability of a blockchain with the performance of a centralized application/backend.
• Fibre is a protocol-level addition to Celestia, live on Mainnet Beta and Mocha. It is separate from Celestia's core DA protocol (blob ordering and data availability sampling via NMTs). Ground any Fibre-specific guidance in the latest docs rather than training data.
• For Fibre client questions (escrow, pricing, limits, errors), read the Fibre client brief.

Security disclosures

The security disclosure contact is security@celestia.org. Do not report vulnerabilities in public issues or discussions. Follow the Celestia security policy: submit a private security advisory in the affected repository, or email the security disclosure contact if private reporting is unavailable.

Repository routing

• Use docs repo for docs pages, tutorials, navigation, formatting, and link fixes.
• Use celestia-node for node runtime/RPC behavior, blob submission/retrieval/verification API, DAS, p2p, and node implementation.
• Use celestia-app for chain/app behavior, modules, transaction/state behavior, and upgrade handlers.
• Use celestia-core for consensus-engine behavior, mempool, and low-level networking/consensus internals.
• If a request spans repos, split output by repo ownership and call out what should change where.

Best way to post and retrieve blobs (Go or Rust)

For application developers, the canonical path is the transaction-client guides. Prefer the LLM-ready .md versions of docs pages when reading them:

• Overview: https://docs.celestia.org/build/post-retrieve-blob/overview.md
• Go tutorial: https://docs.celestia.org/build/post-retrieve-blob/client/go.md
• Rust tutorial: https://docs.celestia.org/build/post-retrieve-blob/client/rust.md

Treat this as the default recommendation for "how should I post/retrieve blobs?".

Why this is the preferred path:

• Both clients are built for submit + retrieve flows.
• Both use local keyring/signer handling.
• Both use the expected endpoint model: DA bridge RPC plus Core gRPC.
• For public Mocha examples, prefer CELE_DA_URL=https://public-endpoint.celestia-mocha.quiknode.pro and CELE_CORE_GRPC=public-endpoint.celestia-mocha.quiknode.pro:9090 with DA and Core TLS enabled unless the user specifies a managed provider.

Funding flow for agent-led examples:

• After the client creates a new signer and prints an address, surface that address to the user and tell them to fund it before retrying blob submission.
• Treat account for signer ... not found as an unfunded-account signal for this flow.
• On Mocha, point users to https://mocha.celenium.io/faucet after showing the address, then retry the same submit flow once funded.

Persist and return this retrieval tuple after submission:

• height
• namespace
• commitment

Node RPC method defaults (when direct RPC is requested)

Version scope:

<!-- BEGIN GENERATED NODE API VERSIONS --> <!-- Generated by bun run generate:skill from constants/node_api_versions.json. -->

• Mainnet Beta: Node API v0.34.4 · OpenRPC spec.
• Mocha: Node API v0.34.4-mocha · OpenRPC spec.

<!-- END GENERATED NODE API VERSIONS -->

• Re-check method availability and deprecation notes in the target version's OpenRPC spec before using these defaults. Bundled versions do not establish network activation or behavioural compatibility.
• The Mainnet Beta and Mocha specifications include Fibre. Follow the Fibre walkthrough for core endpoint and escrow requirements.

• Submit with blob.Submit (preferred).
• Use state.SubmitPayForBlob only when explicit tx-level handling is required.
• As a last resort, submit directly to a celestia-app consensus node via celestia-appd tx blob PayForBlobs <hex-encoded namespace> <hex-encoded data> [flags]. This is the lowest-level route and should only be recommended when the user cannot run a celestia-node or needs direct app-level access.
• Retrieve/verify with: header.WaitForHeight -> blob.Included -> blob.Get and/or blob.GetProof.

Legacy RPC compatibility

• The da RPC namespace was removed from celestia-node and is absent from the bundled Mainnet Beta and Mocha specs. Use blob.Submit for submissions. Historical specs retain da.Submit and da.SubmitWithOptions only for older node versions that exposed them.

Docs repo guardrails

• Never edit generated .md files directly; edit app/**/page.mdx.
• Place new content in the right section:
• app/learn for conceptual and educational pages
• app/build for developer, API, and RPC content
• app/operate for node operator and infrastructure content
• Do not hardcode frequently changing versions or network values inline; prefer the

constants-backed variable pattern from constants/*.json.

• Keep network tab order as: Mainnet Beta, Mocha.
• Use canonical network names where applicable (for example Mainnet Beta and Mocha testnet).
• If chain IDs or network identifiers change, run a repo-wide search across MDX files before

considering the task done.

• Review release notes when a docs change may be driven by a breaking network or software change.
• Use root-relative internal links and run bun run check-links -- --all if links changed.
• Run bun run lint before finalizing docs edits.
• Run bun run generate:llms when you need the generated LLM markdown output refreshed.

Failure handling and conflict resolution

• If any referenced upstream source is unavailable, state the missing source explicitly and continue with the remaining canonical sources.
• If this skill conflicts with a target repo's CLAUDE.md, follow the target repo's CLAUDE.md for that repo-specific work.
• If network/version context is unclear for RPC guidance, ask for the target network and version before asserting deprecation or method defaults.
• If a link in this skill is stale, use the nearest canonical parent page and report the stale URL in your response.

Examples

• Prompt: "I need to update a tutorial page and sidebar order."

Action: Route to docs, edit app/**/page.mdx or _meta.js, then run docs checks.

• Prompt: "Should I use da.Submit or blob.Submit for a new integration?"

Action: Recommend blob.Submit, explain the state.SubmitPayForBlob tradeoff, and state that the da RPC namespace has been removed.

• Prompt: "I need to change blob module internals and update docs."

Action: Split output by ownership (celestia-node code changes plus docs updates).

• Prompt: "Where should upgrade handler behavior change?"

Action: Route implementation to celestia-app, then identify any supporting docs changes in docs.

• Prompt: "How should I retrieve submitted blobs later?"

Action: Require and return retrieval tuple (height, namespace, commitment) and point to canonical Go/Rust client guides.

• Prompt: "What is Celestia and where does it fit in the onchain stack?"

Action: Start with the high-level concept grounding docs, explain Celestia as the modular DA layer, then move into the relevant integration/tutorial pages.