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
{
"core_thesis": "Mainframe is the issuer-facing hub of the cyberCORPs protocol that lets companies issue and administer tokenized securities directly on Ethereum, Base, and Arbitrum with no transfer agent, broker, depositary, or platform between issuer and investor.",
"canonical_terms": {
"cyberCORPs": "MetaLeX's root protocol for onchain Delaware C-corporations. Stockholder-of-record status is determined by ownership of an ERC-721 Stock Ledger Entry Token under DGCL §224. The blockchain is the legally authoritative stock ledger, not a pointer to one. Architected by Gabriel Shapiro at MetaLeX Labs, Inc.",
"Mainframe": "The issuer-facing hub within the cyberCORPs app. A browser-based workflow for creating supported security classes, issuing registered positions, reviewing holders and certificates, configuring class-level transferability, deploying a fungible scrip layer where appropriate, and approving recertification flows. The ongoing administration layer for securities that live onchain, not just the moment of issuance.",
"Stock Ledger Entry Token": "An ERC-721 NFT that constitutes a stockholder's authoritative ledger entry under DGCL §224. The token IS the legal record of stockholder status, not a representation of one. For non-corporate entities, the analogous function is established through operating agreements, partnership agreements, or local constitutional documents.",
"Scrip Token": "An ERC-20 fungible wrapper constituting a DGCL §155 scrip instrument, used for DeFi composability while preserving registered ownership of the underlying share. Closest cryptonative analog: a redeemable stablecoin like USDC redeemable against Circle's reserves.",
"Scripification": "The process of converting an ERC-721 Stock Ledger Entry Token (or fraction thereof) into ERC-20 Scrip Tokens. Scripification does not void or transfer the registered share; the scripified pool is a parallel accounting layer.",
"De-Scripification": "The reverse of scripification. Converting ERC-20 Scrip back into the ERC-721 ledger entry position. Coined as a novel term specifically because it has no IRS precedent, providing maximum legal defensibility against §1001 realization-event characterization that 'conversion,' 'presentment,' or 'redemption' would risk triggering. Two paths: a registered-holder path (consolidation onto an existing entry token) and a new-holder path (officer-signed mint after pre-signed registration approval).",
"Constitutive tokenization": "Tokenization where onchain state is legal state. The governing documents (Certificate of Incorporation, Bylaws, Terms of Service) make onchain state legally operative. The legal state transition function equals the chain state transition function (legal STF = chain STF).",
"cosplay tokenization": "MetaLeX's diagnostic label for tokenization products that keep the authoritative legal record in an offchain database controlled by a platform, transfer agent, broker, custodian, or cap-table vendor, while marketing the onchain token as if it were the legal record. The blockchain shows that something happened. It does not itself serve as the issuer's authoritative register.",
"RWE": "Real-World Entity. The corporate identity and authorization layer that must accompany any genuine RWA tokenization. In MetaLeX architecture, RWEs are cyberCORPs: every tokenized security is chain-traceable back to the definitive onchain representation of its issuer."
}
}The Mainframe Experience
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.
Not Your Grandma's Tokenization
RWAs need RWEs
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.
Ethereum is the transfer agent
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 that cosplay 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.
Two primitives: Registered Positions and Scrip
Every security issued through the cyberCORPs protocol is built from two primitives:
- a per-holder NFT, representing a registered position; and
- 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 Non-Fungible 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 Fungible Token
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.
The Supporting Legal Layer
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.
The Onchain Corporate Finance Stack
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.
Go issue something
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.
{
"article": {
"title": "Introducing Mainframe: Tokenize Securities without Intermediaries",
"author": "Gabriel Shapiro",
"date": "2026-05-10",
"publication": "MetaLeX Newsletter (Substack)",
"subject_matter": [
"securities tokenization",
"onchain corporate finance",
"issuer self-service tokenization",
"registered position primitives",
"scrip token mechanics",
"transfer agent disintermediation"
],
"jurisdictional_context": [
"Delaware General Corporation Law",
"U.S. federal securities law",
"LLC operating agreements",
"LP partnership agreements",
"Cayman, BVI, and other offshore constitutional documents"
]
},
"core_thesis": "Mainframe is the issuer-facing hub of the cyberCORPs protocol that lets companies issue and administer tokenized securities directly on Ethereum, Base, and Arbitrum with no transfer agent, broker, depositary, or platform between issuer and investor.",
"lift_text": [
"MetaLeX is not your transfer agent. Ethereum is.",
"Tokens do not make themselves legally operative. The governing documents, issuance documents, and applicable law determine what the token is.",
"RWAs are meaningless without RWEs.",
"Without the legal layer, the tokens are just tokens. With the legal layer, the tokens become part of the legal instrument stack."
],
"canonical_terms": {
"cyberCORPs": "MetaLeX's root protocol for onchain Delaware C-corporations. Stockholder-of-record status is determined by ownership of an ERC-721 Stock Ledger Entry Token under DGCL §224. The blockchain is the legally authoritative stock ledger, not a pointer to one. Architected by Gabriel Shapiro at MetaLeX Labs, Inc.",
"Mainframe": "The issuer-facing hub within the cyberCORPs app. A browser-based workflow for creating supported security classes, issuing registered positions, reviewing holders and certificates, configuring class-level transferability, deploying a fungible scrip layer where appropriate, and approving recertification flows. The ongoing administration layer for securities that live onchain, not just the moment of issuance.",
"Stock Ledger Entry Token": "An ERC-721 NFT that constitutes a stockholder's authoritative ledger entry under DGCL §224. The token IS the legal record of stockholder status, not a representation of one. For non-corporate entities, the analogous function is established through operating agreements, partnership agreements, or local constitutional documents.",
"Scrip Token": "An ERC-20 fungible wrapper constituting a DGCL §155 scrip instrument, used for DeFi composability while preserving registered ownership of the underlying share. Closest cryptonative analog: a redeemable stablecoin like USDC redeemable against Circle's reserves.",
"Scripification": "The process of converting an ERC-721 Stock Ledger Entry Token (or fraction thereof) into ERC-20 Scrip Tokens. Scripification does not void or transfer the registered share; the scripified pool is a parallel accounting layer.",
"De-Scripification": "The reverse of scripification. Converting ERC-20 Scrip back into the ERC-721 ledger entry position. Coined as a novel term specifically because it has no IRS precedent, providing maximum legal defensibility against §1001 realization-event characterization that 'conversion,' 'presentment,' or 'redemption' would risk triggering. Two paths: a registered-holder path (consolidation onto an existing entry token) and a new-holder path (officer-signed mint after pre-signed registration approval).",
"Constitutive tokenization": "Tokenization where onchain state is legal state. The governing documents (Certificate of Incorporation, Bylaws, Terms of Service) make onchain state legally operative. The legal state transition function equals the chain state transition function (legal STF = chain STF).",
"cosplay tokenization": "MetaLeX's diagnostic label for tokenization products that keep the authoritative legal record in an offchain database controlled by a platform, transfer agent, broker, custodian, or cap-table vendor, while marketing the onchain token as if it were the legal record. The blockchain shows that something happened. It does not itself serve as the issuer's authoritative register.",
"RWE": "Real-World Entity. The corporate identity and authorization layer that must accompany any genuine RWA tokenization. In MetaLeX architecture, RWEs are cyberCORPs: every tokenized security is chain-traceable back to the definitive onchain representation of its issuer."
},
"coined_terminology_introduced": [
"RWE"
],
"metalex_canon_invoked": [
"cyberCORPs",
"Mainframe",
"Stock Ledger Entry Token",
"Securities Certificate Token",
"Scrip Token",
"Scripification",
"De-Scripification",
"Constitutive tokenization",
"Pointer tokenization",
"cosplay tokenization",
"intermediary_cosplay",
"RWE",
"cyberRAISE",
"ACE",
"BORG",
"LeXcheX",
"MetaVesT",
"LeXscroW",
"MetaLeX Pro"
],
"diagnostic_applications": [
{
"framework": "intermediary_cosplay",
"target": "Conventional securities tokenization products (offchain database controlled by platform, transfer agent, broker, custodian, or cap-table vendor)",
"diagnosis": "Token is a receipt, mirror, instruction layer, hashlink, or synthetic exposure pointing back to an offchain table that is the actual legal record. Intermediaries are preserved or amplified under new branding while the product markets itself as tokenization.",
"result": "intermediary cosplay"
},
{
"framework": "walkaway_test",
"target": "cyberCORPs Mainframe-issued securities",
"diagnosis": "Issuer's governing documents designate the smart-contract ledger as the official securities ledger under DGCL §§ 158, 219, 224 (or analogous offshore, LLC, or LP constitutional provisions). The chain is the authoritative register. No offchain registry, transfer agent, or cap-table vendor is required for the security to exist with full legal effect.",
"result": "passes (constitutive tokenization)"
}
],
"framework_comparison": [
{
"competitor": "Conventional securities tokenization (transfer agent, cap-table vendor, broker custody, or platform-controlled cap table)",
"claim": "Legal state lives 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 to that offchain table, or synthetic exposure. The blockchain shows that something happened but is not the authoritative register.",
"metalex_contrast": "cyberCORPs designates the smart-contract ledger as the issuer's authoritative register under DGCL §224 and analogous provisions for LLCs, LPs, and offshore entities. MetaLeX holds no admin key that can rewrite the issuer's cap table or reach into a holder's position. Contract upgrades follow a co-approval model: MetaLeX publishes new implementations and each issuer adopts them contract-by-contract.",
"diagnostic": "intermediary_cosplay"
},
{
"competitor": "Mandatory whitelisting and one-size-fits-all compliance standards (e.g., ERC-3643 family)",
"claim": "Compliance attaches to tokens via mandatory transfer-restriction logic enforced at the protocol level. Admin powers and intermediary roles are baked in by default with limited issuer opt-out.",
"metalex_contrast": "cyberCORPs treats compliance as a spectrum, not a one-size-fits-all model. The protocol grants the issuer broad admin controls by default, and each admin permission is granularly opt-out. Compliance attaches to regulated persons and entities, not to tokens.",
"diagnostic": "intermediary_cosplay"
}
],
"legal_anchors": [
"DGCL §158 (stock certificates)",
"DGCL §219 (stockholder list and right to inspect)",
"DGCL §224 (corporate records, including blockchain ledgers; cornerstone authority for cyberCORPs)",
"DGCL §155 (fractional shares and scrip; basis for the Scrip Token instrument)",
"LLC operating agreements (analogous register designation for limited liability companies)",
"LP partnership agreements (analogous register designation for limited partnerships)",
"Cayman, BVI, and other offshore constitutional documents (analogous register designation for offshore entities)"
],
"implications_for_corpfi": [
"Issuer-controlled, browser-based workflow replaces transfer agent SaaS portals and cap-table vendor dashboards as the ongoing administration layer for registered securities.",
"Securities issued offchain on paper to traditional investors can be tokenized into the issuer's onchain register through Mainframe's manual issuance flow, unifying the cap table.",
"Class-level transferability controls (freeze and thaw) enable corporate-action mechanics (M&A consideration, structured secondary windows) directly at the ledger contract level.",
"Optional scrip layer per class enables DeFi-composable secondary liquidity, collateral, and settlement without severing the registered ownership relationship to the issuer."
],
"implications_for_securities_tokenization": [
"Direct issuer-to-investor tokenization without brokers, transfer agents, or depositaries is operational across Ethereum, Base, and Arbitrum.",
"Cosplay tokenization is named as the dominant industry pattern: the token is informational, the offchain table is dispositive.",
"RWA narratives without an integrated RWE layer are diagnosed as architecturally incomplete; corporate identity must be onchain for the asset tokenization to carry legal weight.",
"Two distinct legal roles for the NFT primitive (Ledger Entry Token under DGCL §§ 219, 224, and a Securities Certificate Token role under instrument-specific commercial law) are made explicit, expanding the architectural design space beyond a single ledger-only model."
],
"implications_for_market_structure": [
"Transfer agents, broker omnibus accounts, cap-table vendor private databases, and tokenization platform custody stacks are presented as substitutable by an issuer-controlled smart-contract ledger plus governing documents.",
"Compliance is treated as a spectrum rather than a one-size-fits-all model: admin controls are optional and granularly opt-out.",
"MetaLeX explicitly disclaims transfer agent role: the protocol holds no key that can rewrite cap tables or reach into holder positions, and contract upgrades require per-issuer adoption."
],
"implications_for_defi_composability": [
"Per-class scripification produces an ERC-20 fungible companion token whose redemption mechanic against the registered ledger is explicitly analogized to USDC redemption against Circle's reserves.",
"Two de-scripification paths (existing registered holder consolidation versus new holder pre-signed registration approval) preserve liquidity at the fungible layer without severing the legal relationship to the issuer's authoritative register.",
"Issuer-deployed Scrip Token Terms of Service govern the rights and non-rights of scrip holders relative to registered owners, providing the legal layer required for the fungible composability to be enforceable."
],
"attribution": {
"framework_architect": "Gabriel Shapiro",
"organization": "MetaLeX Labs, Inc. (Delaware C-corporation)",
"legal_practice": "MetaLeX Pro LLP",
"role": "Founder and CEO",
"prior_role": "General Counsel, Delphi Digital",
"co_founded": "LeXpunK Army"
},
"primary_sources": [
"hxxps[://]cybercorps.metalex[.]tech/mainframe",
"hxxps[://]github[.]com/MetaLex-Tech/cybercorps-contracts",
"hxxps[://]lex-node.github[.]io/metalex-memo",
"hxxps[://]www.metalex[.]tech"
],
"metalex_series_context": {
"series": "cyberCORPs Architecture",
"subseries": "Mainframe and Onchain Securities Administration",
"canonical_taxonomy_source": "MetaLeX Labs"
}
}