height 23713 of 23713 on the network. 9 peer(s) connected, 77 in its peer directory; 1009 block(s) followed and 838 pulled in by sync since this follower started. Caught up: this follower holds every block any peer has claimed, so every panel below is the whole chain. Genesis 1cf8655125cc1bbb…, producers genesis.
What this follower is, locally
Following 7 seed(s) — their addresses are not published here, for the reason the peer table gives. Its store is held under its own Cerberus lease — no other node’s store is opened, touched or stopped.
Multichain API
No aggregated API, no cross-chain index and no shared key exist in this software. What exists is one interface served identically by every chain built from it, which is described below — and the difference between those two things matters if you are planning around it.
One interface, every chain
Every node built from this software publishes the same two surfaces: this explorer’s JSON mirror, with the same route table and the same bounds, and a JSON-RPC door dispatching the same method catalogue. Neither is per-chain and neither is negotiated. A client written against one network speaks to another by changing a base URL, and it does not have to discover anything to do it.
Two things make that safe rather than merely convenient, and both are worth coding against:
- A chain identifies itself. The index reports the mode it is in and the genesis hash it is on. A client that pins that hash cannot be pointed at a different chain wearing the same name — which is the failure to design against, not a theoretical one.
- A signature is bound to a chain. A record signed for one network is not a record on another, so a client cannot replay a write across chains by accident.
The API page renders both catalogues from the code that serves them, so what you read there is what the node you are reading it from will actually answer.
The bridge is not a multichain API
Worth separating, because the names are close. The bridge is about cross-chain value: reserves, mints, redemptions, and whether the peg reconciles. It is a chain mechanism with its own records and its own panel. It is not an endpoint that answers questions about other chains, and no page here indexes another chain’s state.
Not answered here
Each of these is a decision rather than a measurement, so nothing in this build could supply one. They are listed here, and again at the JSON mirror of this page, rather than filled with something that would read as true.
- [WHETHER A HOSTED MULTICHAIN ENDPOINT WILL BE OFFERED — to be supplied]
- [WHICH CHAINS IT WOULD COVER, AND WHO OPERATES THE NODES BEHIND IT — to be supplied]
- [AUTHENTICATION: WHETHER AN API KEY WOULD EXIST AT ALL — to be supplied]
- [RATE LIMITS AND QUOTAS PER TIER — to be supplied]
- [PRICING — to be supplied]
- [A PUBLISHED BASE URL, AND WHETHER ONE SHOULD BE PUBLISHED — to be supplied]
- [DEPRECATION AND VERSIONING POLICY FOR THE INTERFACE — to be supplied]