Introducing Mainframe: Tokenize Securities without Intermediaries

Mainframe is online.

Mainframe is the first DeFi-style app that lets companies issue and administer tokenized securities entirely on their own. No brokers, no transfer agents, no depositaries--just you, your investors, and the blockchain.***

Under the hood, it uses the MetaLeX securities tokenization protocol, which is the only tokenization protocol with built-in corporate identity, corporate auth, deal management, and native NFT (ERC-721) <>FT (ERC20) inter-convertibility to enable true end-to-end onchain corporate finance with zero required intermediaries or offchain dependencies--no ‘cosplay tokenization’ required.

If you already raised funds on MetaLeX’s cyberRaise, you can log in now to experience the panel and manage all the securities you sold there. If you are new to MetaLeX, you can now login and tokenize securities on MetaLeX without having done a cyberRaise.

***Blockchains available: @base, @arbitrum, @ethereum.

Mainframe gives each issuer a browser-based workflow to create supported security classes, issue registered positions, review holders and certificates, configure class-level transferability, deploy a fungible scrip layer where appropriate, and approve recertification flows. It is the ongoing administration layer for securities that live onchain, not just the moment of issuance.

In practical terms, that means an issuer can:

• Manage an existing security class/series from cyberRaise. Many startups have raised funds on MetaLeX’s cyberRaise app and already have outstanding securities of a given class/series. They can use Mainframe to enable transferability, scripification, de-scripification, and also (as popularly requested) manually issue additional securities of the same class/series. This new manual option is especially useful to tokenize investments that were made offchain in paper form with traditional investors, outside of MetaLeX’s cyberRaise flow.

  

• Deploy a new security class/series. You can create any new class/series of securities manually by uploading the relevant documents--just ensure it really is authorized to be issued by your offchain entity (and feel free to let us know if you have questions about that).

• Issue units of that class/series to a specific holder. Enter the party, unit count, agreement, and sign. The token registering this ownership position appears in the holder’s wallet in the same block.

• Freeze or thaw transferability by class/series. Lock a class/series during a corporate action, unlock it for a structured secondary window, or prepare for merger consideration mechanics.

• Enable the fungible layer. Where legally and operationally appropriate, turn on scripification for DeFi-composable secondary liquidity, collateral, or settlement flows.

  

• View the ledger live. Holders, positions, class state, scripification state, and pending registration approvals appear in one issuer-facing view.

  

• Approve registrations. Pre-sign a registration path for a scrip holder who is not yet reflected as a registered holder.

The product surface is simple. The machinery underneath is not.

Our philosophy is that RWAs (tokenized real-world assets) are meaningless without RWEs (tokenized real-world entities). So, our protocol has a corporate identity and authorization layer fully integrated onchain--we call these RWEs ‘cyberCORPs.’ Every tokenized security is fully chain-traceable back to the definitive onchain representation of its issuer.

Most securities tokenization products keep the legal state in an offchain database controlled by a platform, transfer agent, broker, custodian, or cap-table vendor. The token is a receipt, mirror, instruction layer, hashlink back to that offchain table, or synthetic exposure. The blockchain shows something happened. It does not itself serve as the issuer’s authoritative register.

We call thatcosplay tokenization.

MetaLeX’s tokenization protocol is built different. Because we use NFTs with rich metadata as the core tokenization primitive, the issuer’s governing documents can make the smart-contract ledger legally operative by declaring it the official securities ledger, or, relevant property laws permitting, a securities certificate.

MetaLeX is not your transfer agent, Ethereum is.

MetaLeX does not hold an admin key that can rewrite the issuer’s cap table. MetaLeX does not hold a key that can reach into a holder’s position. Contract upgrades follow a co-approval model: MetaLeX can publish new implementations, and each issuer decides whether to adopt them, contract-by-contract.

In the style of true DeFi, our webapp is just a convenience interface--there is no intermediary between issuer and investors.

Every security issued through the cyberCORPs protocol is built from two primitives:

1. a per-holder NFT, representing a registered position; and

2. an optional fungible companion token (ERC20), which may be used to represent a bearer-style fractional security without rights, or an instruction token or control agreement token.

The initial tokenized security is an ERC-721 non-fungible token minted by the relevant ledger contract. It is tied to a named party, an executed agreement, a unit count, the signing officer’s details, and an endorsement history.

Depending on the entity type, governing documents, and applicable law, the NFT can take different legal roles.

Ledger Entry Token. The token metadata and associated ledger state constitute an entry in the issuer’s onchain securities ledger or equivalent ownership register. For Delaware corporations, this is grounded in DGCL §§ 219 and 224. For LLCs, LPs, and offshore entities, the analogous function is handled through the operating agreement, partnership agreement, memorandum and articles, or other constitutional documents.

Securities Certificate Token. For certain instruments, the token may function more like the legal certificate itself, in the tradition of an endorsed paper certificate or presentable instrument. This model is more instrument-specific and depends heavily on governing documents and applicable commercial law.

The point is not that every token is magically a security. Tokens do not make themselves legally operative. The governing documents, issuance documents, and applicable law determine what the token is and what legal consequences attach to changes in ledger state.

The scrip token. The optional fungible counterpart is an ERC-20 deployed for a particular ledger. Its closest cryptonative analog is a redeemable stablecoin. USDC does not itself contain a dollar bill. But a qualifying holder can present USDC to Circle for redemption under Circle’s terms. The fungible token works similarly against the issuer’s ledger.

In the cyberCORPs protocol, the default role is a Scrip Token: a liquid, DeFi-composable form of a security position. It can support secondary trading, collateral posting, market-making, or other DeFi integrations without immediately changing the upstream registered ownership record.

Scripification is reversible. A registered holder can scripify part or all of its ledger position, locking that portion of the registered holding and minting fungible tokens at the configured ratio. Later, a holder can present scrip back to the ledger.

There are two de-scripification paths:

• Registered holder path. A holder already on the ledger burns scrip and consolidates the units back onto its existing entry token.

• New holder path. A holder not yet on the ledger presents scrip after the issuer has pre-signed a registration approval, causing a new officer-signed entry token to mint.

That de-scripification mechanic is what lets the fungible layer be liquid without severing the relationship between the security and the issuer’s authoritative register.

Issuers who wish to offer scrip should have a Scrip Terms of Service in addition to the terms of the security. We will be releasing templates in the future; until then, feel free to discuss this option with the MetaLeX team or your attorneys.

Mainframe is not just a minting UI. It depends on legal machinery.

For a Delaware corporation, that machinery typically includes:

• the Certificate of Incorporation;

• the Bylaws;

• board approvals;

• issuance documents;

• transfer restrictions and legends;

• Scrip Token Terms of Service, where the fungible layer is enabled.

The Certificate of Incorporation can designate the onchain smart-contract system as the corporation’s stock ledger under DGCL §§ 158, 219, and 224. The Bylaws can define the token categories, describe how changes in record ownership occur, set transfer and exception-handling rules, and grant administrative authority to the board or authorized officers. The Scrip Token ToS governs scripification, presentment, the scripified share pool, and the rights or non-rights of scrip holders relative to registered owners.

The form of documents and precise terms change by entity type. LLCs use operating agreements. LPs use partnership agreements. Cayman, BVI, and other offshore entities use their local constitutional documents. The legal function remains the same: the entity’s governing documents designate the onchain system as the authoritative register, define the token mechanics, and specify who has authority to administer the system.

Without that legal layer, the tokens are just tokens.

With that legal layer, the tokens become part of the legal instrument stack.

Issuers also still need the usual legal analysis:

• valid issuance exemption or registration;

• valid resale exemption or registration, where applicable;

• transfer restrictions and legends;

• holder eligibility checks;

• sanctions, AML, and KYC controls where relevant;

• tax treatment;

• board, member, manager, stockholder, or other approvals;

• information rights and current-information packages where resale exemptions require them.

Unlike other securities tokenization protocols, our lawyers have cypherpunk proclivities and know that “compliance” is a spectrum with no one-size-fits-all model. So, administrative controls are optional, not mandatory. The protocol grants the issuer broad admin controls by default, but you may opt-out of admin permissions on a granular basis, as desired.

MetaLeX Pro, the legal arm of MetaLeX, is available to assist issuers with the legal aspects of their tokenization strategies.

MetaLeX has spent years building primitives that let real legal structure exist natively onchain.

• cyberCORP is the entity layer.

• cyberRAISE is the primary issuance layer.

• ACE is the cyberRAISE variant for token-denominated community rounds.

• BORGs are cybernetic organizations for onchain treasuries and working groups.

• LeXcheX handles eligibility and credential checks.

• MetaVesT handles vesting.

• LeXscroW handles escrow.

Each primitive answers a discrete question in a company’s life.

Mainframe answers the continuous one:

After issuance, where does the security live?

Offchain, the answer has been: a transfer agent, a cap-table vendor, and a lawyer with a PDF.

Onchain, the answer is Ethereum.

Mainframe is live now at

https://cybercorps.metalex.tech/mainframe, inside the cyberCORP app.

You can deploy on @ethereum, @base, or@arbitrum. (Let us know if you’d like to see other L2s added--and would use them!).

Mainframe is for issuers who want their securities to live in their own legal infrastructure.

Not in a broker’s omnibus account.
Not in a cap-table vendor’s private database.
Not in a transfer agent’s SaaS portal.
Not in a tokenization platform’s custody stack.

Their own ledger. Their own governing documents. Their own legally operative register.

For issuers that want to handle the process directly, Mainframe is the self-service surface. For issuers that want help with legal structure, governing documents, deployment, compliance design, or integrations, MetaLeX Labs and MetaLeX Pro can work with founders and their counsel.

In code we trust. Time to really tokenize securities.