Skip to content
Back to skills

Quicknode Core Workflow B

ASecurity

Analyze and specify a chain-data contract for QuickNode across network identity, API family, historical retention, archive access, pagination, and add-ons. Use when a workload needs historical state, traces, tokens, NFTs, or chain-specific APIs. Trigger with: "analyze QuickNode data requirements", "audit archive access", "design a QuickNode read workload".

  • 2,719 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 21, 2026
ai-agentsnodeapi

Works with

  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 21, 2026

npx -y skills add jeremylongshore/claude-code-plugins-plus --skill quicknode-core-workflow-b --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Quicknode Core Workflow B?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Quicknode Core Workflow B
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/jeremylongshore-quicknode-core-workflow-b-4e51a772/badge)](https://www.skillsdirectory.com/skills/jeremylongshore-quicknode-core-workflow-b-4e51a772)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: quicknode-core-workflow-b
description: 'Analyze and specify a chain-data contract for QuickNode across network identity, API family, historical retention, archive access, pagination, and add-ons. Use when a workload needs historical state, traces, tokens, NFTs, or chain-specific APIs. Trigger with: "analyze QuickNode data requirements", "audit archive access", "design a QuickNode read workload".'
allowed-tools: Read, Grep, Write, Edit
version: 2.0.0
argument-hint: '[chain-network-and-data-requirement]'
model: inherit
effort: high
license: MIT
author: Jeremy Longshore <jeremy@intentsolutions.io>
tags:
  - saas
  - quicknode
  - blockchain
  - archive
  - data-contract
compatibility: 'Supported APIs, archive availability, pruning, and add-ons vary by chain and network'
---

# QuickNode Chain-Data Contract

## Overview

Select an endpoint from required data semantics, not from a generic “Web3 RPC” label. Current state, historical block data, historical state, traces, token/NFT indexes, REST, gRPC, and WebSocket subscriptions have different availability and retention.

## Prerequisites

- Chain, network, and protocol requirements
- Oldest required block, state, or epoch
- Required methods, consistency, pagination, latency, and recovery behavior

## Authentication

Use an endpoint token for data-plane RPC, passed through the documented endpoint URL or `x-token` header. Use a separate account API key in `x-api-key` only for Admin API capability inspection. Never place either credential in the written data contract or its tests.

## Instructions

### Step 1: Inventory queries

Use Read and Grep to extract every RPC, REST, gRPC, subscription, and add-on method. Record block tags, pagination assumptions, expected response shapes, and historical lookback.

### Step 2: Classify historical semantics

Distinguish historical block retrieval from historical state queries. Determine whether the chain exposes archive mode, a pruning window, or a specialized endpoint path. Never infer “archive” from an Ethereum-centric example.

### Step 3: Verify the chain reference

Consult the current QuickNode API overview for the exact chain and network. Confirm supported APIs, protocols, chain ID, archive status, pruning policy, and product availability.

### Step 4: Separate standard and enhanced APIs

Identify standard chain methods versus QuickNode add-ons or indexed Token/NFT APIs. Record entitlement and method contract explicitly; a `qn_*` name does not guarantee it is enabled on every endpoint.

### Step 5: Design bounded reads

Use Write or Edit to add pagination, maximum range, explicit block tags, response-size controls, and checkpointing. Treat a missing next-page token or pruned-state response as a contract event.

### Step 6: Prove representative history

Test current, boundary-age, and oldest-required records in a non-destructive acceptance suite. Pin expected chain identity and response invariants without snapshotting volatile tip values.

## Tool Discipline

Use Read and Grep for query discovery and Write/Edit for the data contract and tests. This design skill does not enable add-ons, provision endpoints, or execute production queries.

## Output

- Chain/network/API capability matrix
- Historical retention and archive decision
- Pagination and checkpoint contract
- Representative acceptance cases and plan dependencies

## Examples

An analytics service needs historical contract state, not merely old block bodies. Its architecture selects an archive-capable network endpoint and tests a block older than the ordinary pruning boundary.

## Error Handling

| Failure | Response |
| --- | --- |
| Historical state unavailable | Recheck archive support and chain pruning policy |
| Method not found | Verify API family, add-on, chain, and endpoint entitlement |
| Page silently truncates | Require and persist the documented continuation token |
| Chain ID differs | Stop and correct the endpoint before consuming data |

## Resources

- [Chain-data evidence and source notes](references/official-docs.md)
- [Supported chains and pruning](https://www.quicknode.com/docs/platform/supported-chains-node-types)
- [Ethereum API overview](https://www.quicknode.com/docs/ethereum/api-overview)

Files in this skill

  • SKILL.md4.2 KB
  • references/official-docs.md596 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.