Interfaces and their status
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. An experimental developer-facing node interface exists for internal testing, covering submitting transactions, querying node state, browsing blocks and transactions, and checking status; the broader developer API design is being explored. None of these is publicly reachable, their methods, formats and versions are not published, and nothing is publicly available for live use.
Before you read: Conceptual reference.
Which developer-facing interfaces exist experimentally, and where will the formal interface reference be? This page lists interface families — not methods — with the status of each: those exercised in the internal experimental implementation, and those planned or being explored. It also explains what the experimental interface is not, what is not published and why, and how to plan an application around interfaces before any release.
What “interface” means here
An interface, in this documentation, is a way in which applications, tools and operators would interact with nodes and the network: sending work in, reading information out and checking how things stand.
This page groups interfaces into families by purpose. It does not list methods, and it does not describe how any interface is built. The family names are documentation terms, not names used by any implementation.
Families in the experimental implementation
Status of this section: Experimental implementation exists — internal testing only; not publicly reachable, not released and not supported.
- Submitting transactions. An experimental transaction-submission and validation layer exists in an internal prototype. What a submitter would observe is described on Transaction lifecycle: from submission to result.
- Querying node state. Reading state from a node, including retrieving proofs that a value is part of committed state. See Querying network data and browsing activity and Committed state and inclusion proofs.
- Browsing blocks and transactions. An experimental block and transaction browsing interface exists for internal testing. See Querying network data and browsing activity.
- Checking status. An experimental finality status query exists, but it reports nothing as final because the finality component is not yet connected; see Agreement and finality status. Basic node status and metrics also exist; see Node monitoring and observability.
What the experimental interface is not
- Not available. It is not publicly reachable or available for use.
- Not the intended developer API. It exists for internal testing, and the broader developer API design is being explored separately.
- Not stable. It may change or be removed without notice.
- Not compatible. No compatibility with any other platform’s interfaces is claimed.
- Not a security boundary. No security property is claimed for it. Protection against excessive or repeated requests is a separate topic, described on Request abuse and replay protection.
Interfaces that are planned or being explored
| Interface | Status | Where it is described |
|---|---|---|
| A broader developer API | Being explored — its public interface and support are not settled | This page; versioned reference would follow a release |
| Language SDKs for submitting confidential jobs and retrieving results | Planned — no SDK is available | Submitting work and retrieving results |
| A SQL-style way to declare and query confidential data | Being explored | Querying confidential data |
| Richer public and permissioned explorers | Being explored | Querying network data and browsing activity |
Each of these is described at the level of what it would let a developer do. None has a published syntax, method list or release.
What is not published, and why
Method names, parameters, results, error codes, endpoints, interface style, wire formats and versions are not published.
The reason is simple: no interface has been released, and documenting an internal prototype in detail would invite applications to depend on something that will change. Versioned reference would be added only once an interface is released, under the conditions set out on Conceptual reference.
Further technical reference is not yet available.
Planning around interfaces today
Once interfaces are implemented, enabled and publicly released, developers are expected to work from versioned reference. Until then:
- Do not build against the experimental interface. It is internal and will change.
- Isolate network access in your design. Keep the part of an application that talks to the network separate from the rest, so that it can be adapted when reference is released.
- Design for failure. Plan for the failure categories on What can go wrong: failure and error concepts.
- Follow the versioning policy. Versioning, compatibility and deprecation describes the policy that would govern released interfaces.
Assumptions, trust and limitations
Status is stated per family. An experimental family is internal and unsupported, and its existence is not evidence that the planned or explored interfaces exist. Family names may change as the design settles.
Not yet available, and how this page will grow
Once interfaces are released, this page would link each family to its versioned reference and show the version identity. Further technical reference is not yet available.
What this page does not claim
This page does not claim any public interface, method names, parameters, formats, error codes, endpoints, interface style, versions, authentication or compatibility, and it does not claim that any interface is stable. Anything not stated here as available should be treated as unavailable.
Related pages
- Querying network data and browsing activity — the query and browsing families in context.
- Transaction lifecycle: from submission to result — the submission family in context.
- Versioning, compatibility and deprecation — the policy for released interfaces.
- What can go wrong: failure and error concepts — failures to plan for.
- Conceptual reference — the section overview and when versioned reference would be added.
Glossary
References
No approved public references yet.
