> 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/how-cybercorps-works/upgrades-and-control.md). # Upgrades and what MetaLeX controls What MetaLeX can and cannot do to a cyberCORP: published implementations, opt-in upgrades, fees, templates, shared contracts, and the owner role the deploying factory keeps. A platform that held admin keys over every issuer's records would be acting as each issuer's transfer agent. It would take on the registration and intermediary liability that come with that role, and the issuers' control of their own companies would be nominal. cyberCORPs is designed so that MetaLeX develops and maintains the protocol without holding authority inside a company's contracts. The exceptions are the deploying factory's owner role, the oldest companies' beacons and the contracts all companies share, and this page states each one. ## An upgrade needs a MetaLeX release and the company's opt-in Each company's `CyberCorp`, `IssuanceManager`, `DealManager` and `RoundManager` sit behind their own UUPS proxies. Every one of them authorizes `upgradeToAndCall` only when two checks pass. The caller must hold `OWNER_ROLE` on the company's BorgAuth (the function is `onlyOwner`), and the new implementation must equal the reference implementation that the contract's recorded factory publishes (`getRefImplementation()`). Anything else reverts `NotRefImplementation`. MetaLeX publishing an implementation therefore upgrades no company, and a company can stay on its implementation indefinitely. A company also cannot move to an implementation MetaLeX has not published, so it cannot escape the protocol's invariants by upgrading to a fork, and because the check is an exact match, the only target is the factory's current release. A company's LET contracts and scrip run as beacon proxies on two beacons that its own IssuanceManager owns. The owner moves each beacon with one call (`upgradeCertPrinterBeaconImplementation`, `upgradeScripBeaconImplementation`), which moves every LET contract, or every scrip contract, of the company at once, and each call is held to the factory's published reference in the same way. Because each company opts in, versions coexist on the same chain. On Ethereum, Base and Arbitrum the factories publish v5 reference implementations, so a new company starts on v5, and an existing company keeps its deployed version until its owners upgrade it. Integrations read `DEPLOY_VERSION` on each contract instead of assuming one version per chain. A company upgrades its six contracts together, since mixed versions break deal, round and issuance calls. [Upgrade a cyberCORP](/building-on-the-protocol/how-to/upgrade-a-cybercorp.md) gives the steps, and [Run your company](/using-the-apps/company.md) covers the upgrade in the app. The oldest companies run on beacon proxies whose beacons MetaLeX owns. Their owners cannot upgrade them, and MetaLeX can move those beacons for all such companies at once. ## The deploying factory keeps OWNER\_ROLE Every address at level 99 or above on a company's BorgAuth holds `OWNER_ROLE`. That includes the officers (level 200), the company's own manager contracts, and the factory that deployed the company: `CyberCorpFactory` for most companies, with `PumpCorpFactory`, `MetaDAOFactory` and `ParentCoFactory` deploying the same way. BorgAuth gives its deployer `OWNER_ROLE`, and the factory code does not give it up. An owner can change any address's role on BorgAuth and call every owner-gated function in the company's contracts, upgrades included. The current factory code never uses the role after the deployment transaction, but the factories are upgradeable by MetaLeX. While a factory holds the role, the guarantee that MetaLeX cannot push an upgrade, or change the company's roles, rests on MetaLeX not upgrading that factory to code that would. Anyone can check a company by reading `BorgAuth.userRoles()`, and an owner can remove the role with `updateRole(, 0)`. [Access control](/building-on-the-protocol/reference/access-control.md) lists the roles the protocol assigns. ## MetaLeX publishes releases, sets fees and owns the shared contracts MetaLeX develops the contracts and publishes new implementations to the factories. It sets the platform fees on the factories: a primary rate for rounds and deals, a separate rate for secondary trades, and per-company overrides of either. It maintains a library of agreement templates, but template creation on the `CyberAgreementRegistry` is permissionless, so anyone can register a template, and a standalone agreement creates its own template when it is made. MetaLeX operates LeXcheX as an oracle, which means MetaLeX or a delegate signs accreditation attestations into the credential registry. MetaLeX also owns the contracts every company shares, among them the factories, the agreement registry, the `CertificateUriBuilder` that renders each LET's metadata and certificate image, and the certificate extensions. An upgrade to one of them reaches every company that uses it, with no opt-in. A company's owner can point its IssuanceManager at a different URI builder with `setUriBuilder`. The reference apps (the cyberCORPs app, cyberRAISE, ACE, cyberSign and LeXcheX onboarding) are MetaLeX's as well. Nothing in the contracts depends on them or on the services behind them, and any front end can call the contracts directly ([Integrate from a frontend](/building-on-the-protocol/how-to/integrate-from-frontend.md)). A front end that helps investors find issuers may fall under the SEC staff's April 2026 statement on covered user interface providers, whoever runs it. [Regulatory context](/how-cybercorps-works/regulatory-context.md) has the details. ## Funds, approvals and the register stay with the company MetaLeX holds no issuer funds. Money in flight sits in the LeXscroW escrow logic built into each company's own DealManager and RoundManager, and it moves only along the deal's signature, finalization and expiry paths. Deals are proposed and approved by the company's own BorgAuth owner and its signing officers, with no MetaLeX approval step. The company's BorgAuth roles belong to its officers, its governance addresses (board or officer multisigs) and its own contracts, and no MetaLeX wallet holds one. The only MetaLeX-controlled entry is the deploying factory described above. MetaLeX keeps no register that overrides or competes with the chain. For tokenized units, the register of holders is the company's Ledger Entry Token (LET) contracts onchain. The cyberCORPs app's [cap table](/using-the-apps/company/captable.md) is the company's own working record. It mirrors the LETs and can also hold untokenized positions recorded offchain. The company's officers keep it in the app, and it exports to CSV, Excel and OCF. Which record is the company's legally definitive securities ledger depends on its governing documents. MetaLeX-form bylaws designate the onchain LETs for tokenized shares (see [Constitutive vs. pointer tokenization](/how-cybercorps-works/constitutive-vs-pointer.md)). ## See also * [Upgrade model](/building-on-the-protocol/reference/upgrade-model.md) * [Factories](/building-on-the-protocol/reference/factories.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/how-cybercorps-works/upgrades-and-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.