> 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/walkthroughs/onboard-a-company.md).

# Bring a company on-chain

The path from a signed agreement to live share tokens on Robinhood Chain mainnet, which takes most companies less than four weeks.

Onboarding runs from company verification through to minting the first tokens on mainnet. In most cases the whole process takes less than four weeks. Cap table reconciliation tends to take the longest, so begin that work early.

## What to have ready

| Item              | Detail                                                                                                                                |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Company multi-sig | Holds the `ISSUER_ADMIN` role. An existing multi-sig works, as does a group of signers who will set one up.                           |
| Registrar         | Holds the `REGISTRAR` role. Agree up front who this is: the company itself, or the administrator keeping its authoritative cap table. |
| Cap table export  | Must be current, either in CSV or taken from your cap-table software.                                                                 |

{% stepper %}
{% step %}

### Get the company verified

Sign in to the [Console](/the-platform/issuer-console.md) and go to **Overview**, where Selcier requests the company's legal name and registered address, along with its officers and signers. A few business days is the usual turnaround. Completion gives the company a `companyId`: a `bytes32` on-chain and `cmp_...` in the API.

Under **Approvals**, add everyone who will sign off on actions. The threshold set here governs every sensitive Console action, so choose it carefully. Many companies begin with two of three signers.
{% endstep %}

{% step %}

### Pick the classes to bring on-chain

In **Share classes**, add each class that should go on-chain, Common or Series B Preferred for example. One class maps to one [tokenized share class](/fundamentals/tokenized-share-classes.md). Fill in these fields per class:

| Field             | Purpose                                                      |
| ----------------- | ------------------------------------------------------------ |
| Name and symbol   | What wallets and the Explorer display for the class          |
| Authorized shares | Upper limit on what the registrar can mint                   |
| Conversion terms  | Apply later, should the class convert into a different class |
| Share class terms | Goes on-chain as an anchored `SHARE_CLASS_TERMS` file        |

There is no need to cover every class at the start. A frequent first scope is common stock plus one preferred series.
{% endstep %}

{% step %}

### Load and check your cap table

Go to **Holders** and upload the file. One row represents one lot, so a holder with three acquisition dates needs three rows. Dates matter because holding periods and vesting are both tracked lot by lot.

{% code title="cap-table.csv" %}

```csv
holder_email,holder_name,share_class,quantity,acquired_at,lot_type,vesting_schedule
ana@example.com,Ana Ruiz,COMMON,120000,2022-03-01,founder,
ana@example.com,Ana Ruiz,COMMON,40000,2024-06-15,option_exercise,
li@example.com,Li Chen,COMMON,25000,2025-01-10,employee_grant,4y_1y_cliff_monthly
fund@example.com,Northfield Ventures II,SERIES_B,850000,2025-09-30,purchase,
```

{% endcode %}

Selcier compares the file with each class's authorized shares and flags discrepancies: duplicate holders, totals above the authorized amount, or missing dates, for example. Once reconciled, the table needs the registrar's sign-off in **Approvals**, and no tokens are minted without it.
{% endstep %}

{% step %}

### Bring holders into Portfolio

An approved cap table triggers an email invitation to [Portfolio](/the-platform/holder-portfolio.md) for every holder. Holders complete identity verification, which writes their claims to the company's `IdentityRegistry`. A holder may connect a wallet they already have or use an embedded one created by Portfolio. With gas sponsored, ETH is never required.

Anyone still onboarding keeps their position in the reconciled cap table, and their tokens are minted later to whichever wallet they register.
{% endstep %}

{% step %}

### Turn on compliance modules

In **Rules**, switch on the modules each class requires. The complete list is in [Compliance modules](/fundamentals/compliance-modules.md). A typical first setup looks like this:

| Module                  | Typical configuration                                                                        |
| ----------------------- | -------------------------------------------------------------------------------------------- |
| `RegionModule`          | Set to your service regions                                                                  |
| `EligibilityModule`     | Receivers must hold an `INVESTOR_ELIGIBLE` claim                                             |
| `HoldingPeriodModule`   | Applies a lockup per lot                                                                     |
| `EmployeeVestingModule` | Uses the schedules that came in with the cap table import                                    |
| `TransferWindowModule`  | Limits transfers to periods you define and, if configured, to the Liquidity Windows you open |
| `ROFRModule`            | Only when a right of first refusal belongs to the company                                    |

Aim to finish this configuration before mainnet: on a live class, rule changes pass through the `IssuerTimelock` and wait out a 24 hour delay.
{% endstep %}

{% step %}

### Run a testnet rehearsal

Selcier uses the sandbox to put an exact copy of your configuration on Robinhood Chain testnet (chain ID `46630`). Use that deployment for three checks:

* Verify each holder's balance against the cap table you reconciled.
* Try `canTransfer` on a handful of real scenarios and verify that you get the [outcome codes](/build-on-selcier/transfer-outcomes.md) you expect.
* Practice a pause, an approval and a scheduled recovery with your signers.

A rehearsal checklist appears in the Console, and mainnet deployment stays locked until each item passes.
{% endstep %}

{% step %}

### Go live on mainnet

Deployment starts from your approval in **Approvals**: in one transaction, `SelcierFactory` deploys the company's contract set and emits `CompanyDeployed`. The registrar next mints to each verified holder against the reconciled cap table, and every mint emits `SharesIssued` carrying a reference to its cap table record.

The company is now listed in the [Explorer](/the-platform/public-explorer.md), which shows its supply, its holder count and all events since deployment.
{% endstep %}
{% endstepper %}

{% hint style="success" %}
From here, you can [launch a raise](/walkthroughs/launch-a-raise.md) to bring in capital, or [schedule a Liquidity Window](/walkthroughs/schedule-a-window.md) so that existing holders have a way to sell.
{% 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/walkthroughs/onboard-a-company.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.