> For the complete documentation index, see [llms.txt](https://docs.selcier.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.selcier.xyz/the-platform/public-explorer.md).

# The public Explorer

An open view of each Selcier company, from corporate actions and anchored documents to transfers, holder counts and supply, with everything checkable on Robinhood Chain.

Whatever Selcier records on-chain can be read in the Explorer, a public, read-only site at [explorer.selcier.xyz](https://explorer.selcier.xyz). No account is required.

Console, Portfolio, the API and the Explorer all draw on one indexed event stream. Nothing appears here that the chain does not already contain. The difference is organization: figures are arranged by company and share class rather than as raw transactions, and each one links to the transactions it came from.

## Pages you can browse

### Company directory

Companies deployed through the `SelcierFactory` are all listed here, with name, share classes, total holders and deployment date. Because the list is built from `CompanyDeployed` events, a company the factory did not deploy cannot appear.

### A single company

Opening a company reveals:

* its contract addresses: `IdentityRegistry`, `TrustedVerifiers`, its vaults, `Governance`, `DisclosureRegistry` and `IssuerTimelock`, plus one `SelcierShareToken`, `RuleEngine` and `ValuationOracle` per share class
* supply, holder count and current multiplier for each share class
* the most recent [Reference Valuation](/fundamentals/valuation-publishing.md) for each class, dated and sourced
* a chronological history of corporate actions, votes, distributions, Liquidity Windows and offerings

### A single share class

Each class page is divided into these parts:

| Part                  | Contents                                                                                                              |
| --------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Supply**            | Raw token supply and current `uiMultiplier`, along with the share count those two produce                             |
| **Holders**           | How many holder wallets and identities exist. Wallet addresses are the only identifier shown for an individual holder |
| **Transfers**         | References accompany the full log of `SharesRedeemed`, `SharesIssued` and `Transfer` events                           |
| **Rules**             | Modules active in the `RuleEngine`, with a hash of every module's configuration                                       |
| **Controls**          | All pauses, freezes, recoveries and multiplier changes, scheduled actions still waiting to execute included           |
| **Valuation history** | All `ValuationPublished` events on a chart over time, labeled by source                                               |

### Raises and windows

An offering page reports terms, the raised amount measured against minimum and maximum, subscriber count and outcome. A Liquidity Window page reports mode, dates, the reserve price where one exists, order count, clearing price and settled volume.

### Anchored documents

This list holds each `DisclosureRegistry` entry with kind, hash, URI and timestamp. Download a public document and the Explorer hashes it in your browser, then compares that result with the on-chain value. Holder-only documents still display a hash, which lets holders check the copy delivered through Portfolio.

### Actions in the queue

Module changes and upgrades queued in any company's `IssuerTimelock` are listed here, together with recoveries and multiplier changes scheduled on a share token. An entry tells you when it can execute. The page guarantees public notice: a sensitive change cannot take effect without appearing first.

## What stays private

Names, contact details, verification documents and claim contents are never displayed. You can tell that a wallet holds a verified identity, but not whose identity it is. [Data visibility](/fundamentals/data-visibility.md) sets out the full boundary.

## Checking it yourself on Blockscout

Treat the Explorer as a convenience rather than an authority: its conclusions should be reachable without relying on it. To support that, displayed values link to their source transaction or contract on [robinhoodchain.blockscout.com](https://robinhoodchain.blockscout.com).

Here is how to confirm a number independently:

1. On the share class page, copy the address of the `SelcierShareToken`.
2. In Blockscout, call `totalSupply()` and `uiMultiplier()` on that contract, then compute the share count as `totalSupply × uiMultiplier / 1e18`.
3. Rebuild the history of supply changes by filtering the token's logs for `SharesIssued`, `SharesRedeemed` and `RecoveryExecuted`.
4. Call `ruleEngine()` on the token, fetch the module list from that `RuleEngine`, and compare the result against the Rules part of the page.
5. Look up the token's address in the factory's `ShareClassDeployed` event to prove the `SelcierFactory` deployed it.

You will find the factory address per network in the Explorer footer and in the response to `GET /v1/contracts`. All other addresses trace back to it, which makes it the one root of trust.

{% hint style="info" %}
Software that needs this data can call `GET /v1/events` through the [REST API](/build-on-selcier/rest-api.md), or index the logs in the [Chain event catalog](/build-on-selcier/chain-events.md) on its own.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.selcier.xyz/the-platform/public-explorer.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
