Launching a cyberCORP

Starting a cyberCORP on MetaLeX is intended to be straightforward for both crypto-native founders and those without blockchain expertise. There are two primary pathways to launch: via the web application interface or by interacting with the smart contracts (for developers and advanced users). Underneath both methods, the same factory contracts are used – ensuring that a cyberCORP created through the UI is functionally the same as one created via code.

Using the Web App: On the cyberCORPs app site, a founder can click “Start a Raise” (or a similarly labeled button) and will be guided through the process. The first step collects basic corporate information – company name, entity type, jurisdiction, etc. – and then asks whether the founder is launching a multi‑investor round or a bespoke single‑investor deal. Choosing Round prompts for inputs such as the series type, raise cap, ticket sizes, and round style, and the system wires these details into a Round Manager that will handle issuance for the round. Choosing Deal continues directly to the single‑investor flow. Behind the scenes, when the founder submits this form and confirms the transaction in their wallet, the app calls the CyberCorpFactory smart contract to deploy a new cyberCORP instance GitHub GitHub. The factory takes a unique salt (to allow deterministic addresses and prevent duplicates) and the provided inputs, then performs a sequence of actions in one go: It deploys a fresh BorgAuth contract and immediately assigns the founder’s wallet the Owner role (this ensures the creator will control the new corp’s permissions) GitHub. It deploys a new CyberCorp contract (the core proxy that represents the company onchain) via a minimal proxy or beacon. It simultaneously deploys an IssuanceManager and a Round Manager for the corp (each as their own upgradeable proxy) and wires their addresses into the CyberCorp’s state. A Deal Manager can also be deployed for bespoke one‑off deals, but the Round Manager is the default orchestrator for multi‑investor fundraising rounds GitHub GitHub. It also sets up a CyberCertPrinter implementation reference and URI builder for token metadata, so that the IssuanceManager can spawn actual certificate contracts as needed GitHub GitHub. All of this is abstracted away from the user; from their perspective, within one transaction their new cyberCORP “organization” is created onchain. The factory emits a CyberCorpDeployed event with the addresses of the new contracts GitHub, which the front-end listens for to confirm deployment. If the founder was creating a raise immediately (which is likely the case when using the UI for a SAFE), the CyberCorpFactory can go a step further via a convenience function: deployCyberCorpAndCreateOffer GitHub GitHub. This performs the steps above and then initializes a deal offer in the same flow. It will call the IssuanceManager to create the necessary CyberCertPrinter(s) for the deal (for example, a SAFE certificate contract, possibly with a particular extension if it’s a hybrid deal) GitHub, and then call the DealManager to proposeAndSignDeal with the founder’s provided terms and signature GitHub. A companion deployCyberCorpAndCreateRound function could likewise form the corp, deploy the certificate printers, and call createRound with the founder’s terms and signature. If such a helper is not yet available, adding one would provide parity with the deal flow. Essentially, using these one-click methods, a founder can both form their onchain company and launch their first fundraising transaction. The UI experience would be: fill in your company info and terms, click Launch, and after confirmation, get a link to share with investors.

Using the Contracts or Scripts: More technical users (or those integrating MetaLeX cyberCORPs into a larger system) can interact directly with the MetaLex-Tech/cybercorps-contracts repository and its deployment scripts. The repository provides Foundry scripts (e.g. deploy.s.sol) and contract APIs that mirror the UI functionality. For instance, a developer could call CyberCorpFactory.deployCyberCorp(...) with their parameters to get a new corp, or use deployCyberCorpAndCreateOffer(...) for a combined operation GitHub. The docs recommend referring to these deployment scripts and templates in the repo GitHub – they contain sample values and illustrate how to format inputs like the officer struct (which includes the officer’s address and initial role) or deal term arrays. By studying or reusing these scripts, one can programmatically launch cyberCORPs as part of a larger deployment pipeline (for example, spinning up multiple test corporations, or integrating cyberCORP formation into a product’s backend).

Once a cyberCORP is launched, the next steps typically involve issuing any initial equity and configuring the organization’s settings. The IssuanceManager that powers the Round Manager can mint founder stock certificates or automatically record SAFE conversions, keeping the cap table in sync. If the corp was created via a fundraising flow, an initial certificate (for the SAFE or equity being issued to the investor) is likely already minted. However, if a corp is created standalone (with no immediate deal), the founder might want to issue founder’s stock onchain to represent their own shares. This can be done by calling the IssuanceManager’s createCertPrinter to set up, say, a Common Stock certificate contract, and then using the IssuanceManager to mint shares to the founder’s address. Similarly, if the company has multiple co-founders or previous investors, one can mint tokens to each of them so that the full cap table is reflected onchain from day one. After launching, founders are encouraged to configure transfer‑restriction hooks such as Whitelist or Toggle to enforce compliance on share transfers. The founder (or whatever governance process they have) should also ensure the MetaVesT and LeXscroW integrations are configured if needed. MetaVesT is MetaLeX’s token vesting/lockup protocol, which is BORG-compatible and can be used for automating token or equity vesting schedules forum.zknation.io mobile.x.com. A cyberCORP can integrate MetaVesT to handle things like employee token vesting or lockups for early investors. For example, if the company wants to issue tokens to an advisor with a 1-year lockup, the MetaVesT contract can be deployed and linked, so that those tokens release gradually without manual oversight mobile.x.com. Meanwhile, LeXscroW (or specifically LexScroWLite as discussed) is likely already embedded for deals, but a corp could also use escrow conditions for other purposes – say, holding funds in escrow until a milestone is reached even outside of the initial SAFE context. Ensuring the companyPayable address is a secure multi-sig controlled by the appropriate people is another post-launch step (this way, when funds flow in from deals or other revenue, multiple officers can manage them securely). In essence, launching a cyberCORP bootstraps a company into the MetaLeX “legal OS”. From that point forward, the company can use various MetaLeX modules: it can execute financing rounds (SAFEs, equity, convertible notes) onchain via deals; it can manage its cap table and equity token transfers via the issuance system; and it can plug in things like MetaVesT for automated vesting or other future modules for compliance. All of this with the assurance that every action is transparent and governed by code where appropriate. The MetaLeX docs and repository will be the go-to reference for developers – for example, to find template IDs for standard agreements or to see how to format a legend (restriction notice) on a stock token. MetaLeX encourages developers to read through the cybercorps-contracts code for deeper understanding, and even to run the tests to see sample workflows of creating a corp and going through a deal (the test suite likely demonstrates a mock SAFE round from start to finish).