Governance and Officers

Operating a cyberCORP day-to-day involves both onchain code and offchain people. The governance model combines a BorgAuth-based role system with traditional corporate roles (officers, directors, etc.), allowing a company to define who can do what in the smart contracts. When a cyberCORP is created, it comes with a BorgAuth access control contract instance. BorgAuth is MetaLeX’s hierarchical role manager (originally developed for BORGs) that the cyberCORP leverages to manage permissions onchain. The founder or creator of the cyberCORP is typically assigned the highest role (Owner) by the factory at deployment GitHub GitHub. This Owner role (analogous to an ultimate admin) can then add others and assign them roles. In corporate terms, you might give your CFO or general counsel an “Officer” role onchain to let them, say, co-sign certain transactions or update certain records. Using the company officer functions provided, the Owner can call addOfficer(address, role) to add a new officer (e.g. a new executive or director) and removeOfficer(address) to revoke someone’s role GitHub GitHub. Under the hood, this updates the BorgAuth roles: for example, officers might be assigned a specific numeric role code (the contracts often use 200 for officers) which grants them predefined permissions. The cyberCORP smart contracts check these roles on sensitive functions. For instance, only an address with Owner role can change fundamental parameters like the company’s legal details or upgrade the contracts, whereas an address with an Officer role might be allowed to propose deals or manage certain tasks. This system provides fine-grained, onchain control over corporate authority. It’s akin to how a board of directors authorizes officers to act on behalf of a company – but here the authorization is enforced by code. If someone is removed as an officer, their onchain role is revoked immediately, preventing any further authorized actions.

The CyberCorp contract itself stores key corporate metadata which can be updated through governance actions. These include: the official entity name (e.g. Acme, Inc.), the entity type (“Corporation”, “LLC”, etc.), the jurisdiction of incorporation (e.g. Delaware, USA), and contact or identifying details GitHub. It also holds a default dispute resolution mechanism (for example, specifying arbitration or a certain court jurisdiction to handle legal disputes) GitHub. These fields are set at initialization (drawn from the inputs when the cyberCORP is deployed) and can be updated by authorized roles if needed (e.g. if the company reincorporates in a new state or changes its name) GitHub. Having these onchain is important not only for record-keeping but because they can be referenced by other parts of the system – for instance, generating legal documents or ensuring filings are correct.

Another important field is the companyPayable address GitHub. This is essentially the blockchain address representing the company’s treasury or bank account. Funds from deals (and potentially other onchain revenues) will flow into this address. In practice, this could be the address of a multi-signature wallet controlled by the company’s management. The cyberCORP Owner can update the payable address as needed (for example, if the company adopts a new multisig or a finance department wallet) via an onchain call GitHub. By centralizing all incoming payments to a known address, the cyberCORP makes it easier to track revenue onchain and even automate things like dividend payouts or expense management in the future.

It’s worth noting that cyberCORP contracts are upgradeable, reflecting the evolving nature of law and business needs. MetaLeX uses an upgradeability pattern (UUPS proxies or beacon proxies) for the CyberCorp core, IssuanceManager, and DealManager. The cyberCORP has an upgradeFactory address on record GitHub, which is authorized to perform contract logic upgrades. In practical terms, this means the company (with whatever governance process it chooses – perhaps board approval or tokenholder vote) can decide to upgrade the smart contracts to newer versions if bugs are found or features need to be added. For example, if regulations change and a new compliance module is required, MetaLeX Labs could publish an upgraded contract, and the cyberCORP’s Owner (or upgradeFactory) could install that upgrade without disrupting the organization’s operations or data (all shares and deals remain intact). This is crucial for longevity: a corporation might exist for decades, and the tech must be able to adapt over time. Of course, upgrades are permissioned – only the designated governance authority can execute them, preventing unauthorized changes. In the MetaLeX paradigm, this provides a balance between “code is law” and real-world flexibility: the code governs day-to-day, but the humans behind the company aren’t irreversibly locked into one code version if it proves imperfect.

In summary, governance in a cyberCORP is a hybrid of familiar corporate control and onchain rigor. Roles like CEO, CFO, directors, etc., map to onchain roles that gate smart contract functions. Company resolutions (like adding an officer or changing a detail) translate to transactions that update contract state. And because of the BorgAuth ACL, even if a private key is compromised or an officer goes rogue, their powers are limited by the role they hold – and removals are immediate and trustless once executed. It’s a system designed to make corporate governance more transparent and foolproof, while still allowing human judgment at the helm.