In brief
How developer interfaces expose observations without becoming protocol authority by themselves.
First Contact#
RPC, wRPC, APIs, explorers, and indexers are observation and integration surfaces. They are essential for developers, but they do not replace the protocol source path when a claim is about consensus behavior.
Working Model#
Developer pages should ask what object an interface exposes, which fields it preserves, how it handles replay or recovery, and whether a disagreement with another surface is a protocol fact or an observation-layer issue.
Expanded Interface Boundary#
RPC, wRPC, REST APIs, explorers, and indexers are how many readers first touch Kaspa data. That makes them educationally important, but also risky. An interface can show an object or status without proving every protocol fact the reader may infer from it.
The source-safe habit is to ask four questions. What object is the interface exposing? Which source-defined fields does it preserve? Is the interface reporting node policy, consensus evidence, indexer-derived state, or a cached/explorer observation? What would settle a disagreement between two surfaces?
This page should route exact implementation questions to RPC/proto/service/source paths and indexer source paths. It can teach the boundary without claiming that every endpoint is a complete proof of protocol behavior.
A developer should read an interface response as a typed observation. Query calls, subscriptions, optional fields, missing-field conversions, explorer rows, and indexer endpoints can all be useful, but their authority depends on what they expose and how they derive it. If a page claims an endpoint proves accepted state, it must cite the source path that connects that endpoint to accepted evidence. If it only reports what an API observed, it should be labeled as observation evidence.