protocol-speccing

A rulebook for writing issue specifications for an on-chain protocol indexer. An indexer is software that reads blockchain activity and records protocol updates in a searchable form.

In plain words
What is it for?
Use it to document contract functions, events, payload formats, data types, and cross-chain flows between hub and spoke domains for indexer development.
Why use it?
It keeps specifications focused on what the blockchain emits and requires, rather than mixing those facts with implementation or architecture decisions.

Cursor rule for Cursor

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 rules/centrifuge/api-v3/protocol-speccing
Clone the repo
git clone --depth 1 https://github.com/centrifuge/api-v3

Made for: Cursor.

Per session 0 Nothing until a file matches its globs; then the whole rule loads.
When invoked 559 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.00000 $0.00559
Opus 5 $0.00000 $0.00280
Sonnet 5 $0.00000 $0.00112
Haiku 4.5 $0.00000 $0.00056

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

Security

Grade A, and why

protocol-speccing 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 2d 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.

.cursor/rules/protocol-speccing.mdc · 50 lines

How it starts

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

Protocol Speccing Guidelines

When creating issue specifications for the cfg-api-v3 indexer to track updates from cfg-protocol-v3, follow these strict guidelines to ensure accuracy and consistency. The events might be local to a single domain or span across Hub and Spoke.

1. Issue Structure

  • No Solution Design: Do not provide indexer solution design or architectural details in the issue unless specifically requested. Stick purely to on-chain specifications.
  • Clear Headings: Use predictable sections like ## Description, ## On-Chain Specifications, ## Data Type Notes, and ## Indexer Requirements.

2. On-Chain Flow

Break the event flow down according to the required domains (Hub, Spoke, or both).

For Cross-Chain Flows (e.g., Hub to Spoke, or Spoke to Hub)

Define the process across the two domains:

  • Initiating Domain: Identify the Contract (e.g., Hub.sol or Spoke.sol), Function, and the initiating Event (e.g., UpdateContract). If it uses a payload, detail the abi.decode shape and enum values.
  • Finalizing Domain: Identify the finalizing Contract (e.g., Spoke.sol, Hub.sol, or manager contracts), Function (e.g., trustedCall or message handler), and the emitted Event upon completion.

For Single-Chain Flows

Define the process within its specific domain:

  • Domain (Hub or Spoke): Identify the Contract.
  • Identify the Function executing the state change.
  • Identify the Event Emitted.
  • Describe the chronological order if multiple events are triggered sequentially.

3. Data Type Notes

Explicitly highlight internal data types, and specific mapping operations. If spanning domains, highlight the differences:

  • Assets: The protocol often uses AssetId (a custom type mapped to uint128). This may need to be resolved to address asset and uint256 tokenId.
  • Addresses: Be aware of encoding addresses as bytes32 (common in cross-chain payloads) which are later resolved to standard address types.

Read the full file on GitHub · 50 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. 2d ago First seen · 50 lines · 0 tokens per session scan A 6dd6d64c1a46

Subscribe to this mod's changes

protocol-speccing is a cursor rule published in the GitHub repository centrifuge/api-v3 (5 stars, last pushed 5d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 559 tokens. 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-31.