> 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/issuer-console.md).

# Console for issuers

A company runs its share classes, transfer rules, raises, liquidity and corporate actions from Console, and any sensitive change there passes through multi-sig approval first.

Finance teams, legal operations and board members share one workspace on Selcier for managing a company's tokenized equity: Console, available at [app.selcier.xyz/console](https://app.selcier.xyz/console).

Silent changes do not exist here, because each Console action corresponds to a signed record or an on-chain transaction. Editing a rule, scheduling a split and opening a Liquidity Window all follow one path: Console builds the transaction, gathers the approvals required, then submits to Robinhood Chain. Once sequenced, the outcome is visible in the [Explorer](/the-platform/public-explorer.md).

## The workspace, area by area

### Landing view

Start here for a summary of on-chain state. It covers supply per share class, holder count, the current [Reference Valuation](/fundamentals/valuation-publishing.md), offerings and windows that are open, approvals awaiting signatures, and timelocked actions coming up. Below that, a feed of recent events links through to the underlying transactions.

### Classes and their tokens

A dedicated [Selcier Share Token](/fundamentals/tokenized-share-classes.md) stands behind each share class. Rows here give the token address, supply, holder count, current `uiMultiplier` and a status of active or paused. Available actions are creating a class, viewing its document root, scheduling a multiplier change, and pausing or unpausing the token.

### Cap table and holder records

Search the cap table and open any holder to find their verified identity, linked wallets, balance per class, the claims recorded against their identity, and lots with acquisition dates and lock status. Three actions are available: inviting holders, freezing a specific amount, and starting a [recovery](/fundamentals/tokenized-share-classes.md) when a wallet is lost. Personal details stay in the platform's access-controlled storage, and only Console members holding the right permissions can see them.

### Rule configuration

[Transfer rules](/fundamentals/compliance-modules.md) are configured per share class. Each module can be switched on or off. Its parameters may include vesting schedules, ROFR terms, transfer windows, an ownership cap, a holder cap, holding periods and allowed regions. A preview shows what will happen ahead of submission. To test a specific case, the built-in checker takes a proposed transfer between two holders and reports the exact reason code it would produce.

### Primary raises

This area is for creating and running [primary offerings](/markets-and-capital/primary-raises.md). Define a raise by its price per share and minimum ticket, its lower and upper limits, its dates, the stablecoin it accepts, and the claims investors need. During an open offering, subscriptions are tracked against both limits in real time.

### Liquidity routes

Three routes are managed here. [Permissioned pools](/markets-and-capital/gated-pools.md) require an opt-in, [RFQ trading](/markets-and-capital/quote-based-trading.md) is switched on per class, and [Liquidity Windows](/markets-and-capital/scheduled-windows.md) are configured one at a time. A window needs a mode (batch auction or tender), the claims required of sellers and buyers, a reserve price, a volume cap, a per-seller cap, and any holder of a right of first refusal. Clearing price, volume and participant counts stay on record for past windows.

### Payouts

Dividends and similar payments are funded through the `DistributionVault`. A distribution needs a total amount, an asset and a record block, and a claim deadline is optional. Claim progress is displayed for each distribution. [Send a payout to holders](/walkthroughs/send-a-payout.md) has the steps.

### Votes

Token-weighted proposals start here, with a snapshot block, voting period, quorum, options and a binding or advisory label. Finalization of results happens on-chain. Background is in [Shareholder voting](/fundamentals/shareholder-voting.md).

### Disclosure

Board resolutions, company updates, valuation reports, financial statements, offering documents and share class terms can all be uploaded. Console anchors the hash of each one in the `DisclosureRegistry`, and you decide whether the contents are public or limited to verified holders.

### Signing and delays

The company's `IssuerTimelock`, a multi-sig paired with a waiting period, governs anything sensitive. For each pending action you can see who has signed, how many signatures remain, and when the timelock expires. Signers approve from this screen using their own wallet or hardware key. Adding or removing signers and changing the approval threshold happen on the **Signers** tab.

| Delay by default | Sensitive action                 |
| ---------------- | -------------------------------- |
| None             | Pausing or unpausing             |
| 24 hours         | Adding or removing a rule module |
| 48 hours         | Changing a multiplier            |
| 72 hours         | Recovering a wallet              |
| 7 days           | Upgrading the token              |

The recovery and multiplier delays are enforced by the share token contract itself.

### Keys and logs

API keys are created and rolled from this area. Engineers can also add webhook endpoints, inspect request logs, and move the view between sandbox and live data. For what can be built on top, see [Developer tools](/the-platform/developer-tools.md).

## Permissions across a team

Two separate systems apply. A person's Console role determines what they can see and prepare. Signing power depends on the on-chain role held by their wallet.

| Role in Console   | Permissions                                                                                                    |
| ----------------- | -------------------------------------------------------------------------------------------------------------- |
| Owner             | Full access, which includes managing members and signers                                                       |
| Admin             | Queues work for approval, and handles governance, distributions, liquidity, offerings, rules and share classes |
| Signer            | Uses their wallet to approve actions pending in the `IssuerTimelock`                                           |
| Cap table manager | Works with documents, lots and holders, reading and editing alike                                              |
| Viewer            | Reads everything apart from personal details                                                                   |
| Developer         | Handles request logs, webhooks and keys for the API                                                            |

An audit log captures each member action, and the Owner can export it whenever needed.

{% hint style="info" %}
Preparing something in Console does not bypass the approvals configured on-chain. Even a compromised Console account has no ability to change rules or move tokens alone.
{% 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/issuer-console.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.