> For the complete documentation index, see [llms.txt](https://docs.metalex.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.metalex.tech/building-on-the-protocol/reference/contracts/cybercorp.md).

# CyberCorp

The root contract of a cyberCORP: the onchain record of the legal entity.

* **Source:** [`src/CyberCorp.sol`](https://github.com/MetaLex-Tech/cybercorps-contracts/blob/develop/src/CyberCorp.sol)
* **Inherits:** `Initializable`, `BorgAuthACL`, `UUPSUpgradeable`, `ICyberCorp`
* **`DEPLOY_VERSION`:** `"5"`; a company that has not upgraded reports `"3"` or `"4"`

## State

| Variable                         | Type               | Meaning                                                                 |
| -------------------------------- | ------------------ | ----------------------------------------------------------------------- |
| `cyberCORPName`                  | `string`           | Legal name, including designation ("Inc.", "LLC").                      |
| `cyberCORPType`                  | `string`           | Entity type as free-form text (e.g. "corporation"). **Not an enum.**    |
| `cyberCORPJurisdiction`          | `string`           | Jurisdiction of formation.                                              |
| `cyberCORPContactDetails`        | `string`           | Contact information.                                                    |
| `defaultDisputeResolution`       | `string`           | Default dispute-resolution mechanism for agreements.                    |
| `companyPayable`                 | `address`          | Address that receives payments on the company's behalf.                 |
| `issuanceManager`                | `address`          | The cyberCORP's IssuanceManager.                                        |
| `dealManager`                    | `address`          | The cyberCORP's DealManager.                                            |
| `roundManager`                   | `address`          | The cyberCORP's RoundManager.                                           |
| `upgradeFactory`                 | `address`          | Factory whose reference implementation gates upgrades.                  |
| `cyberCertPrinterImplementation` | `address`          | Unused. Holds its slot in the storage layout.                           |
| `companyOfficers`                | `CompanyOfficer[]` | Officers (`{eoa, name, contact, title}`).                               |
| `escrowedOfficerSignatures`      | `bytes[]`          | Reusable pre-authorized officer signatures.                             |
| `extension`                      | `address`          | Optional corp-level extension contract that interprets `extensionData`. |
| `extensionType`                  | `bytes32`          | Type selector for the active extension schema.                          |
| `extensionData`                  | `bytes`            | Raw extension payload interpreted by the active extension contract.     |

## Functions

```solidity
function initialize(address _auth, string _name, string _type, string _jurisdiction,
    string _contact, string _disputeResolution, address _issuanceManager,
    address _companyPayable, CompanyOfficer _officer, address _upgradeFactory,
    address _roundManager) external;

function setcyberCORPDetails(string _name, string _type, string _jurisdiction,
    string _contact, string _disputeResolution) external;        // onlyOwner
function setIssuanceManager(address) external;                    // onlyOwner
function setDealManager(address) external;                        // onlyOwner
function setRoundManager(address) external;                       // onlyOwner
function setCompanyPayable(address) external;                     // onlyOwner
function addOfficer(CompanyOfficer) external;                     // onlyOwner
function updateOfficer(uint256 index, CompanyOfficer) external;   // onlyOwner
function removeOfficer(address) external;                         // onlyOwner
function removeOfficerAt(uint256) external;                       // onlyOwner
function isCyberCORPOfficer(address) external view returns (bool);

function addEscrowedOfficerSignature(bytes signature) external;             // onlyRole(200)
function setEscrowedOfficerSignature(uint256 index, bytes signature) external; // onlyRole(200)
function getEscrowedOfficerSignature(uint256 index) external view returns (bytes);
function getEscrowedOfficerSignatureCount() external view returns (uint256);

function setExtension(address _extension, bytes32 _extensionType) external; // onlyOwner
function setExtensionData(bytes _extensionData) external;                   // onlyOwner
function clearExtension() external;                                         // onlyOwner
function getExtensionURI() external view returns (string);
```

## Officers and BorgAuth roles

* `addOfficer` reverts `DuplicateOfficer` for an `eoa` already listed. It grants the new officer role `200` unless the address already holds a higher custom role, which it leaves untouched.
* `updateOfficer` replaces the record at an index. When the `eoa` changes, it grants the new address under the same rule and revokes the old one, but only when the old role is exactly `200` and no other index still lists that `eoa` (an older company's officer list can hold duplicates).
* `removeOfficer` and `removeOfficerAt` revoke the role only when it is exactly `200` (a custom role granted outside the officer lifecycle survives) and the address is not listed at another index.
* `isCyberCORPOfficer` reports whether an address holds a role at or above `OWNER_ROLE` (99). See [Access control](/building-on-the-protocol/reference/access-control.md).

## Corp-level extension

`setExtension` installs an `ICyberCorpExtension` contract plus a schema selector. The contract must report `supportsExtensionType(_extensionType)`, or the call reverts `ExtensionTypeNotSupported`. Setting or replacing the extension clears any stored `extensionData`; `setExtensionData` then stores the payload, reverting `ExtensionNotConfigured` if no extension is set. `getExtensionURI` returns the extension-rendered JSON fragment for the current payload, and the [CertificateUriBuilder](/building-on-the-protocol/reference/contracts/certificateuribuilder.md) appends it to the metadata of every Ledger Entry Token (LET) the company issues.

## Events

`CyberCORPDetailsUpdated`, `OfficerAdded`, `OfficerUpdated`, `OfficerRemoved`, `CompanyPayableUpdated`, `EscrowedOfficerSignatureAdded`, `EscrowedOfficerSignatureUpdated`, `CyberCORPExtensionSet`, `CyberCORPExtensionDataUpdated`, and `IssuanceManagerUpdated` / `DealManagerUpdated` / `RoundManagerUpdated` (new address, old address), which the three manager setters emit.

## Errors

`NotRefImplementation`, `SignatureRequired`, `InvalidEscrowSignatureIndex`, `InvalidOfficerIndex`, `DuplicateOfficer`, `InvalidExtension`, `ExtensionTypeNotSupported`, `ExtensionNotConfigured`.

## Upgrades

`_authorizeUpgrade` is `onlyOwner` **and** requires the new implementation to equal `ICyberCorpSingleFactory(upgradeFactory).getRefImplementation()`; otherwise it reverts `NotRefImplementation`. The constructor calls `_disableInitializers()`, so the implementation contract itself can never be initialized.

This call upgrades the CyberCorp proxy only. Moving a company to v5 takes six calls: this one, `upgradeToAndCall` on the IssuanceManager, DealManager and RoundManager, and the IssuanceManager's two beacon upgrades. `corpUpgradeCalls` in `script/upgrade-v5.s.sol` builds the batch. A company left part-way through can see deal, round and issuance calls revert; see [Upgrade a cyberCORP](/building-on-the-protocol/how-to/upgrade-a-cybercorp.md).

This path needs the CyberCorp to sit behind its own ERC-1967 proxy. The oldest cyberCORPs are beacon proxies on MetaLeX-owned beacons, and for them `upgradeToAndCall` reverts `UUPSUnauthorizedCallContext`. See [Upgrade model](/building-on-the-protocol/reference/upgrade-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.metalex.tech/building-on-the-protocol/reference/contracts/cybercorp.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.