canonical reference.
This section is the authoritative public lookup surface for network parameters, interfaces, addresses, schemas, lifecycle labels and release compatibility. Values appear here only after they can be tied to a qualified build or verifiable network state.
network parameters
Chain identity, native currency metadata, RPC endpoints, explorer URLs, genesis hashes and supported environments.
02 / DEPLOYMENTScontract addresses
Canonical deployed addresses grouped by network, protocol role, implementation relationship, version and lifecycle state.
03 / INTERFACESABIs & interfaces
Functions, events, errors, interface identifiers, proxy boundaries and compatibility notes for integrators.
04 / SCHEMASregistries & schemas
Registry keys, record ownership, field definitions, identity schemas, naming rules and versioned shared identifiers.
05 / STATUSstatus definitions
Consistent meanings for planned, implemented, qualifying, deployed, deprecated and retired components.
06 / RELEASESversioning
Release identity, compatibility windows, migrations, activation points, breaking changes and historical references.
how to use this section
Integrators should treat this Reference section as the public source of truth for values that must be exact. Architecture and user guides explain concepts and workflows; Reference pages define canonical identifiers, versions, addresses and lifecycle state.
qualification rule
A value becomes canonical only when it is tied to a named environment or release, verified against the relevant repository or network state, and published without ambiguity about status or version. Draft values, examples and internal test data are not canonical.
historical records
Superseded values remain documented when they are needed to decode historical transactions, events or application behavior. Historical visibility does not imply current support.