> 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/under-the-hood/access-control.md). # Access control Who can act on a company's contracts and where each party's authority stops, plus the wallet recovery procedure, the delays on sensitive changes and how signers are rotated. Each privileged function on a Selcier contract is gated by a role, and each role sits with a named party. Nobody has all of them. Configuration is the company's domain, the share record is the registrar's, and Selcier runs the infrastructure. Anything touching a holder's balance takes agreement from more than one of these parties. ## Who holds what | Role | Holder | Permitted | Not permitted | | -------------------- | ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | `DEFAULT_ADMIN_ROLE` | The company's `IssuerTimelock` | Managing transfer rule modules (adding, removing, configuring), upgrading share tokens, changing verifiers, fees, agents and delays, granting and revoking roles | Acting ahead of its signers' approval or the delay attached to the function | | `ISSUER_ADMIN` | The operational multi-sig of the company | Setting up offerings, Liquidity Windows, distributions and votes, scheduling multiplier changes, enabling RFQ, approving recoveries | Minting or burning outside an offering, altering transfer rules directly, moving a holder's tokens unaided | | `REGISTRAR` | The company itself or an administrator it has appointed | Minting and burning in line with cap table records, carrying out share class conversions, freezing and unfreezing, adding vesting grants, approving and executing recoveries | Altering transfer rules or the terms of an offering | | `OPERATOR` | Selcier, by way of an HSM or MPC relayer dedicated to the company | Registering and unlinking holder identities, revoking claims, co-approving recoveries, relaying transactions, sponsoring gas | Moving a holder's tokens unaided, minting, freezing, changing configuration of any kind, getting around the `RuleEngine` | | `PAUSER` | The registrar and the company (`ISSUER_ADMIN`) | Calling `pause` and `unpause` on a share token | Anything beyond those two calls | | `MINTER` | The `OfferingVault` of the company | Minting to subscribers at an offering's close | Burning, freezing, or minting apart from offering settlement | | `PUBLISHER` | `ISSUER_ADMIN`, the `OfferingVault` and the `LiquidityWindow` | Publishing Reference Valuations to the `ValuationOracle` | Anything beyond publishing | | `ANCHORER` | `ISSUER_ADMIN` and the registrar | Anchoring documents in the `DisclosureRegistry` | Anything beyond anchoring | | Verifier | Whichever identity providers `TrustedVerifiers` lists | Issuing signed claims, limited to topics it is trusted on | Holding, moving or configuring tokens | Assignments are stored on-chain, where anyone may read them. Each role change produces an event, and the Explorer shows who currently holds which role at every company. ## Limits on the operator The point of `OPERATOR` is to spare holders from dealing with gas and companies from running infrastructure. Its design keeps it small: * A transaction from the operator faces identical `RuleEngine` checks to anyone else's. * Minting, burning, freezing and reconfiguration are all off limits. On-chain, what it can do is link wallets to identities, revoke claims, and act as one of the three recovery parties. * In a recovery it supplies at most one of the three approvals, or cancels alongside the other two parties, and even an approved recovery has to sit through its timelock. Holders are not stranded if Selcier's infrastructure goes down: they can pay their own gas and call the share token directly from their wallets. ## Restoring a lost wallet Losing a wallet does not mean losing a position. Selcier shifts the holdings onto a replacement wallet tied to the same identity, and no one holds them in custody during the move. {% stepper %} {% step %} ### Confirm identity again A verification provider checks the holder a second time. Their existing identity in the `IdentityRegistry` then gets the replacement wallet registered against it. {% endstep %} {% step %} ### Gather two approvals Two of the three parties (`ISSUER_ADMIN`, `REGISTRAR`, `OPERATOR`) each call `approveRecovery(lost, replacement, ref)` on the share token, and `RecoveryApproved` fires on each call. Once a second, different party has approved, `RecoveryScheduled` fires and states when execution becomes possible. Holding several roles does not let one account approve twice. {% endstep %} {% step %} ### Sit through the delay For the whole delay, which defaults to 72 hours, the pending recovery is publicly visible. Should the holder still control the original wallet, its transfers are blocked in the meantime. Any of the three parties may also call off the recovery, and `RecoveryCancelled` records that. {% endstep %} {% step %} ### Carry out the move With the delay over, `recover(lost, replacement, ref)` is called by the registrar. The replacement wallet receives the entire balance, including any frozen amount, along with the lot history, and `RecoveryExecuted` logs the amount. Vesting schedules and holding periods continue unchanged. {% endstep %} {% endstepper %} The `DisclosureRegistry` anchors a hash of the registrar's record, and `ref` is what connects that record to this recovery. ## Delays on sensitive changes A holder should not be caught out by a change, so such changes wait. The `IssuerTimelock` handles most of them: M-of-N signers approve, then a delay chosen by the function being called runs. The share token enforces its own delay for recoveries and multiplier changes. Defaults can be raised by a company, but floors cannot be undercut. | Action | Default | Limit | | ------------------------------------------------------------------------------------------------------------------- | ---------------- | ----------------- | | Recovering a wallet | 72 hours | Floor of 48 hours | | Split or reverse split (multiplier change) | 48 hours | Floor of 48 hours | | Transfer rule module: add, remove or configure | 24 hours | Floor of 24 hours | | Upgrading a share token | 7 days | Floor of 7 days | | All remaining `IssuerTimelock` actions (for example role grants, or changes to verifiers, fees, agents and signers) | 48 hours | Floor of 48 hours | | Pause | None (immediate) | Fixed | | Unpause | None (immediate) | Fixed | Immediate pausing reflects its purpose as a safety control. The remaining delays give holders, venues and integrators time to notice a change and respond. While an action is pending, the Explorer displays it with its execution time, and webhook endpoints are sent events like `multiplier.scheduled` and `recovery.scheduled`. ## Changing signers People move on: an officer departs, a board seat turns over, a multi-sig key needs replacing. Signers and the threshold of the `IssuerTimelock` are its own data, and only the timelock can alter them, through `addSigner`, `removeSigner` and `setThreshold`. Taking a signer off the list also strips their approvals from all pending actions. Since `ISSUER_ADMIN` is a separate multi-sig wallet, replacing one of its signers happens in that wallet and leaves the Selcier contracts alone. 1. Under **Approvals → Signers** in the Console, propose adding a signer, removing a signer, or altering the approval threshold. 2. Current signers approve the proposal at the threshold in force. 3. It then passes through the `IssuerTimelock`, and executes when the delay ends. Meanwhile the Explorer lists it as pending. A registrar change follows the same route with one addition: the `REGISTRAR` role moves only after both the outgoing and the incoming registrar have approved. As a result, the share record is never left with a party that has not agreed to take it. Operator keys are rotated by Selcier on a fixed schedule, and at once if a compromise is suspected. Where a rotation swaps the `OPERATOR` address on-chain, it is a role grant like any other: it goes through the company's `IssuerTimelock` and is recorded on-chain. These controls are placed in wider context in the [Security model](/under-the-hood/security-model.md). --- # 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/under-the-hood/access-control.md?ask=&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.