Availability
Design principles
- Public read-only access to blockchain data.
- No write, signing, or wallet-management operations.
- No direct exposure of node RPC.
- Cached responses and rate limits to protect infrastructure.
- API outages do not affect access to the website.
- Document schemas, error codes, and limits before launch.
Planned resources
- Service status
- API availability, public chain height, and general network information.
- Blocks
- Paginated block list and lookup by height or public identifier.
- Transactions
- Look up a public transaction by its identifier.
- Addresses
- Public address history, without private wallet data.
- Network
- Aggregated, non-sensitive public information about peers and synchronization status.
Endpoints, response formats, pagination parameters, and rate limits will be defined in a versioned specification published before the API opens.
Website integration
The website is designed to remain self-contained. Any future integration will use a dedicated server-side access layer with timeouts, response validation, and an explicit unavailable state.
- No demonstration data should be displayed in production.
- An unavailable response must produce a clearly identified empty state.
- API errors must not reveal infrastructure information.
- The website must never depend on the API to render its static pages.