MaxCurators bounds curators and open invitations together. The curator list renders on the index page, and only curators can grow it, but a bound costs nothing and an unbounded list on a public page is a page someone can break.

PageSize is how many rows any table here shows at once. Every list is paginated and every page reads only its own records, because vm/qrender is gas-metered (3B per query) and a Render that outgrows it stops answering instead of slowing down. At the caps a page reads its 25 records, one lookup per URL it may mark flagged (each row's main RPC on the index; the zone's RPC and gnoweb on its page), the zone serving this chain for the printed command, the curators, and a few index nodes. Escaping free text is what dominates: about 97k gas a character on a node, so a page of full-length fields costs on the order of a billion, still under the ceiling.

ReviewWindow is how many blocks must pass before the author of a change may change it again, a rate bound rather than a review deadline (100 blocks is minutes): after a zone was proposed or last edited (by anybody) before its proposer may edit or withdraw it, and after an endpoint was registered before its registrant may withdraw it. Every edit bumps the revision a curator's decision must name, and a withdrawal plus a fresh proposal or registration does the same with a new revision or id, so without a wait a proposer or a registrant acting every block would keep their entry out of every curator's reach. Curators are not limited.

AcceptCurator makes the caller a curator, if a curator invited it.

AddCurator invites another address to curate. Only a curator may. The address becomes a curator when it calls AcceptCurator itself.

Two steps, deliberately: a curator set is the one thing a mistake here can lose for good. With a one-step add, a sole curator who invites a mistyped address and then steps down leaves a registry nobody controls; accepting is the proof that somebody holds the key. An invitation dies with its inviter: removing a curator withdraws every invitation they sent.

ApproveZone makes a zone official. revision is the zone's Revision as you read it (the zone page's Approve link carries it): if the zone changed since, its content or its status, the approval fails and you read it again. The reason is optional.

ClearUnreviewed removes, in one call, every endpoint on a zone that is zones.Endpoint.Clearable (nobody ruled on it, and no reviewer registered it past the caps), and returns how many. There are never more than zones.MaxUnverifiedPerZone: clearable endpoints are a part of the review queue its gate holds there, and no reset makes one. It is the answer to a flood that cycles: registrants who withdraw and register again each review window keep the queue full, and one removal per transaction lets them refill it before a curator is done. throughRevision bounds it to what the curator read: an endpoint registered after it (a later Revision) is kept. The deposits go to the curator who signs. At most zones.MaxEndpointsPerZone are read.

EditZone replaces a zone's Info, every field but its slug and status. A curator may edit any pending or approved zone; the proposer may edit their own while it is pending. revision is the zone's Revision the edit was written against: it fails if the zone changed in between, its content or its status. Every edit bumps the revision, so a decision prepared against the old one fails too. A proposer edits only ReviewWindow blocks after the zone was proposed or last edited, and an edit that changes nothing is refused. On a pending zone the reason must be empty; on an approved one it is required and replaces the review on record, so the page names who changed the values, and why. A new chain id sends the zone's verified endpoints back to unverified. Leaving the local kind drops every endpoint on a private host, and is refused while one carries a curator's ruling (a verified one its registrant may withdraw first); the proposer's edit only drops endpoints that are theirs and that they could withdraw on their own (RemoveEndpoint), as for RemoveZone. A new main RPC or gnoweb a stranger (on an approved zone, its proposer too) already lists under its kind would make that listing the zone's own: on a curator's edit it is dropped if nobody ruled on it, and refuses the edit if a curator did; a proposer's edit refuses rather than drop what is not theirs; and a flagged listing refuses the edit whoever holds it. The registry validates the edit before it drops or resets anything, and a refusal reverts the edit with it. A rejected or retired zone cannot be edited.

FlagEndpoint tells readers not to use an endpoint. The reason is required. revision is the endpoint's, as for VerifyEndpoint; a flag is not bound to the zone, so editing the zone cannot hold off a warning.

GetEndpoint returns the endpoint with that id, and whether there is one.

GetZone returns the zone under slug, and whether there is one.

IsCurator reports whether addr may curate.

IsInvited reports whether addr holds a curator invitation it has not accepted yet.

ListAddresses is ListEndpoints reduced to the addresses, which is what a config file wants: ListAddresses("onyx", "peer", "verified").

ListEndpoints returns a zone's endpoints of that kind and verification, oldest first. "" matches any kind or verdict, so ("onyx", "", "") is everything on onyx and ("onyx", "peer", "verified") is what a cautious node should dial. The zone is required: one zone is at most MaxEndpointsPerZone rows, every zone together is a response no node should be asked for.

ListZones returns the zones with that status and kind, in the order they were proposed. "" matches any; "approved" is the official list.

ProposeZone files a new zone for review. Anybody may; it is listed as a proposal until a curator approves or rejects it. The review queue's caps (zones.MaxPending, zones.MaxPendingPerProposer) do not stop a curator, who also has the registry's last zones.ReservedForReviewers places, so neither a flood nor a full registry locks out the people who clear it.

kind is mainnet, testnet, devnet or local. gnowebURL and genesisURL may be empty; rpcURL may not, and is <scheme>://<host>[:<port>] with no path, which is what gnokey -remote takes.

RegisterEndpoint lists an endpoint on a zone and returns its id. On an approved zone anybody may, except the zone's own main RPC under rpc and gnoweb under gnoweb, which only a curator lists (or the proposer while the zone is pending: every proposer right ends at approval); on a pending one only the proposer or a curator, so a stranger cannot pin a proposal the proposer then cannot withdraw. It shows as unverified until a curator checks it. A curator also registers past the review queue's caps and into the zones.ReservedForReviewers places a gated registration may not take, never past zones.MaxEndpointsPerZone.

kind is rpc, gnoweb, seed, peer, indexer, faucet or explorer. addr is a URL, or <node id>@<host>:<port> for a seed or a peer. label is optional: who runs it, in your words.

RejectZone turns a proposal down. The reason is required, and public. revision is the zone's Revision you read, as for ApproveZone.

RemoveCurator revokes a curator, along with every invitation they sent, or withdraws one invitation. Only a curator may, and the last curator cannot be removed: a registry nobody can curate can never retire a dead zone.

Curators are equals: any one may remove any other, the admin included. That is the trust a curator set is, and it is why there are few of them.

RemoveEndpoint deletes an endpoint. revision is its revision as read: the removal fails if a verdict landed since, rather than delete one nobody saw. A curator may remove any. Its registrant may remove it unless a curator flagged or unverified it (a flag is a warning, an unverify carries why, and removing and registering it again would wipe either; a verified one the registrant may take down, since listing it again starts it unverified, and so one a reset sent back to unverified, since the reset says the zone changed, not it), only while its zone is pending or approved (a rejected or retired zone is a record, endpoints and all), and only ReviewWindow blocks after registering it (removing and registering again every block would give it a new id faster than a curator could flag the old one).

RemoveZone deletes a pending or rejected zone and its endpoints. revision is the zone's Revision you read: a removal meant for one proposal fails on another proposed again under the same slug. A curator may remove any pending or rejected zone. The proposer may withdraw their own only while it is pending, ReviewWindow blocks after it was proposed or last edited (so withdrawing and proposing again cannot dodge the edit wait), while every endpoint on it is theirs (the deposit is refunded to whoever signs the removal, so removing somebody else's endpoints would collect what they paid) and each one is one they could withdraw on its own (RemoveEndpoint): removing the zone must not wipe a curator's flag or unverify, or skip an endpoint's own wait. A rejected zone is the curators' record: only a curator removes it, or newer rejections push it out, and the rejection's deposit, paid by the curator, is not the proposer's to collect. A zone that was ever official is never removed this way: an approved one is retired, and a retired one is kept until newer retirements push it out.

Render is the whole public surface, three pages: the zone list (official, or retired with ?status=retired), one zone (?kind= narrows its endpoints), and the proposals (pending, or rejected with ?status=rejected). Every list takes ?page=.

RetireZone marks an official zone as no longer running, and sends its verified endpoints back to unverified. The reason is required: it is what an operator still holding the chain id will read. revision is the zone's Revision you read.

UnverifyEndpoint puts an endpoint back to unverified, for one that changed hands or needs checking again. revision is as for FlagEndpoint.

VerifyEndpoint marks an endpoint as checked against its zone. revision is the endpoint's revision as read (the endpoint table's revision column), and zoneRevision the zone's (the zone page shows it): the verdict fails if either changed since, another curator's verdict on the endpoint, or any edit or status change of the zone (what is verified is that it answers for this zone's chain id). The reason is optional. Each verdict may be given again with a new reason, to restate it.