The MetaLeX Securities Tokenization Protocol
MetaLeX’s securities tokenization protocol is powerful, unique, ultra-cryptonative, and maximally programmable.
Design Principles for Securities Tokens
MetaLeX designed its tokenization protocol with some unique core principles in mind.
Securities tokens should be just as good as non-tokenized securities—they should do all the same things, but better.
Securities tokens should be tradeable legal instruments—enabling direct, peer-to-peer transfers of legal rights onchain.
Securities tokens should be programmable—enabling onchain governance & automated dividends, mergers, conversions, vesting, etc.
Securities tokens should be personal property—enabling investors to have direct, real ownership of companies.
Securities tokens should be disintermediating—enabling direct relationships between investors and companies.
Securities tokens should be open and composable—enabling many protocols/businesses to permissionlessly ‘build on top of them’ or with them.
Securities tokens should be participatory—enabling voting, staking, and other “DAO-like” experiences.
Securities tokens should be social—enabling clubbing, flexing, mogging, SocialFi and ‘degen mode’.
Securities tokens should be compliance-capable—enabling issuers can choose their own compliance strategies and risk tolerances–and because this happens transparently onchain (smart contract ‘hooks’ and ‘flags’ and the ability of issuers to permanently disable admin controls if desired), investors can tailor their investment decisions accordingly.
Securities tokens should reduce agency costs—enabling issuers and investors to strike new trust balances with autonomously enforced governance.
Securities tokens should be time-and-pain-saving—enabling new efficiencies with automation.
Securities tokens should be DeFi-ready—enabling use in AMMs, credit protocols, and more.
Securities tokens should be primed for the ‘cybernetic economy’ and ‘software 3.0’ —enabling agent-owned companies (BORGs), company-owned agents, and proplet
-style ownership/governance of robots.
Good crypto-protocol design is good crypto-protocol design–the principles don’t magically change just because the protocol you’re designing is meant to handle centralized assets. We take inspiration from the protocol design philosophies of Satoshi, Vitalik Buterin and
Nikolai Mushegian–embodying timeless principles like governance minimization, disintermediation, credible neutrality, and transparency.
Let’s break down the details and see how these principles play out.
Crypto’s Disruption Moment in Capital Markets--Disintermediation
Current capital markets are heavily intermediated. In the early 20th century, paper stock certificates could not trade at scale–people were running across Manhattan with sacks of paper stock certificates to settle trades. An electronic system was necessary, but guess what? Before Bitcoin, electronic systems were all centralized databases. Thus, to scale capital markets, we were forced to create a complex system of rent-seeking intermediaries like broker-dealers, DTCC, Cede & Co, Broadridge, and more–in today’s system, these intermediaries are the true ‘owners’ of most securities, and everyone else just has debt-like ‘account positions’ on their centralized subsystems. This has many downsides–added cost, added frictions, inefficiencies (T+2 settlement, etc.), centralized antiquated forms of privacy (Broadridge “OBO” system and ensuing data honeypots),and can be exploited to enable naked shorting, vote miscounting, stealth hostile investor activism, and many other market abuses that favor massive financial institutions.
Crypto blows this whole stack open because tokens can trade at scale on decentralized ledgers. We no longer need these intermediaries between companies and their investors. The companies and the investors can now interact directly, at scale again—this enables issuance and trading to be ‘peer to peer’ just like it used to be in the old days of paper certificates, but without the downsides. In fact, not only do tokenized securities lack the downsides of paper–they scale better than Wall Street’s centralized back-office electronic systems ever have or could.
MetaLeX’s securities tokenization protocol starts with a key insight: To make digital securities truly useful, we must have a ‘back to the land’ moment in corporate finance–oldschool p2p corporate finance, updated for the cybereconomy.
cyberCORPs—Putting Securities Issuers Onchain
Every security is issued by some legal entity (aka the “issuer”). Most securities tokenization protocols treat the issuer as a black box–they are somewhere, offchain, obscure, invisible, un-represented. Sometimes the issuer simply has a blockchain address with ‘god mode’ authority over the securities tokens—or, worse, the issuer has delegated all of this to an intermediary, such as a broker/dealer or transfer agent, who controls such an address.
The MetaLeX approach is different. We believe that to put securities onchain, you must put securities issuers onchain. Thus, on MetaLeX, every securities issuer is mirrored onchain via smart contracts and associated data structures we call cyberCORPs.
Each cyberCORP (via CyberCorp) stores the related legal entity’s name, type, jurisdiction, contact info, and governance info (director and officer identities) (categories of data specified in CyberCorpConstants) and acts as the coordinating authority for that cyberCORP’s securities lifecycle management (IssuanceManager, CyberCertPrinter, CyberShares, DealManager, and RoundManager). To enforce consistency, cyberCORPs are spawned via a smart contract factory construction (CyberCorpFactory and CyberCorpSingleFactory) as part of the MetaLeX protocol.
cyberCerts - Non-Fungible Digital Securities
The centerpiece of the MetaLeX tokenized securities protocol is our non-fungible tokens (NFTs)—securities certificates reimagined for the cyber-economy.
cyberCERTs are
-compliant and encode all critical information about the relevant security. We call them ‘certs’ or ‘cyberCERTs’ for short.
cyberCERTs are intended to have two potential functions, depending on jurisdiction, context, and strategy:
they may be used as transferable legal instruments—just like traditional paper stock certificates, getting legally transferred from one stockholder to another—e.g., in a sale/purchase transaction—by the current owner “endorsing over the certificate to” the new owner (with a private key signature, onchain)
they may be used as entries in an onchain securities ledger; this is possible because they embody all the same information and history of issuances and transfers that would be recorded in a traditional stock ledger entry
The information embedded in cyberCERTs includes:
name, jurisdiction and entity type of the securities issuer
name, electronic address, and (if applicable) jurisdiction and entity type of the securities owner
the class, series, and number of units of the security represented by the certificate (owned by that owner):
signatures of the authorizing corporate officers
URIs linking to the text of the underlying legal agreements determining the terms of the securities
SVG code to generate a visual representation of this information, looking much like a traditional securities certificate with the image fully stored and rendered onchain– — no external hosting required
endorsement history array to record transfers (important to comply with chain-of-title and securities ledger recordkeeping requirements).
other relevant metadata necessary or desirable for programmability or compliance—for example, purchase price, voting power, valuation cap, etc.
cyberCERTs ground a system of registered securities ownership that can be coupled tightly or loosely with token ownership. Changes in the name of the registered owner (i.e., transfers of securities) occur by the MetaLeX protocol editing the name of the registered owner on the cyberCERT (always leaving an auditable trail), or subtracting a number of shares owned by one registered owner and minting a new cyberCERT in the name of the new owner with those shares added. The protocol embeds hooks to gate transfer logic with any kind of desired permissioning or purchase/sale logic. Onchain signatures track the transfer trail, just as certificates are ‘endorsed’ from seller to buyer to buyer to buyer.
The mere transfer of an NFT, by itself, will generally not change record ownership (the NFT metadata must be mutated for that). But, depending on the cyberCORP’s strategy, the NFTs can still be harnessed in various ways. For example, if NFTs are ‘soulbound’ (non-transferable) then a cyberCERT NFT at an address can be treated as a simpler form of onchain credential that does not involve checking detailed metadata information. If NFTs are more transferable, they can be used as “Instruction Tokens” for more bearer-like or contingent un-registered transfers or “Control Agreement Tokens” for the pledging of securities as collateral. (More on this below). In jurisdictions that recognize electronic securities certificates, “possession” of the NFT could be used by creditors and credit protocols to perfect their rights in the securities as collateral, even though registered ownership has not changed. If/when cyberCerts become liquid, we expect issuers’ Bylaws, Terms of Service and other applicable documents to reflect policies regarding the legal effects of transferring (or not transferring) NFTs independent of changes in the information they record.
cyberCERT metadata can be manually or automatically mutated to reflect securities conversion events (See below, “Cert<>Cert Conversions”).
cyberCERTs can also be embedded with programmable rights logic like liquidation waterfall rights, voting rights, etc. (See below, “Programmability”).
Cert<>Cert Conversions
Many securities types are intrinsically convertible. For example, Simple Agreements for Future Equity (SAFEs) are intended to convert into shares of preferred stock in the issuer’s first priced share sale round. Even certain classes of stock—for example, Preferred Stock—may have the right to convert to another class of stock (Common Stock) upon certain events. Some securities, like SAFTs or SAFTEs, may convert into non-securities tokens (like governance tokens or utility tokens).
cyberCERTs are programmable to accommodate such conversions, either manually or automatically. This occurs through a converter smart contract that feeds into other ‘conversion plan’ smart contracts. SafeCertificateConverter is the first ConversionPlan instance and sets forth traditional SAFE → shares conversion logic based on the purchase price and post-money valuation cap of each issued SAFE cyberCERT. Conversions are also possible on a more ‘offchain logic’ basis by the issuer voiding a SAFE cyberCERT and minting a new stock cyberCERT. The legal logic (how many shares to give) would have to be computed offchain or via a script using the data in the SAFE cert metadata (the stored investment amount and valuation cap.
For now, these conversions require trusting the issuer to effectuate them, just like with manual offchain SAFE conversions. But since many of these conversions are deterministic, we anticipate making conversion events more automatic and trustless over time. For example, a certain smart contract could monitor whether a given cyberCORP has sold preferred shares in a new round, and if so, could convert the outstanding SAFE cyverCERTs into tokens representing the correct number of preferred stock shares based on the SAFE’s legal rules. Similarly, cyberCERTs representing preferred shares could convert into common shares when the cyberCORP governance logic approves a merger or IPO.
As projects become more comfortable committing to this onchain deal logic, more and more of ‘corporate finance’ will become onchain ‘CorpFi,’ and the MetaLeX protocol grows increasingly powerful. Companies could agree in their SAFEs that they will only do their “Equity Financing Event” onchain on the MetaLeX protocol—this could then feed into various automations so that the conversion of SAFEs is guaranteed and/or automatic once the Equity Financing Event is completed. This type of arrangement strikes new trust balances and can form the basis of a revolution of what Nick Szabo called ‘social scalability’--striking a new trust balance between investors and projects, minimizing monitoring costs, async communications, and manual processes, and dramatically improving capital markets by bringing companies onchain.
The Importance of the NFT Standard and its Embedded Metadata
To satisfy our design principles summarized at the start of this article, we had to make cyberCERTs just as good, if not better, than paper securities certificates. This means they must be tamper-proof and what securities they represent must be obvious from the NFT itself, without checking any extrinsic sources. Many ‘art NFTs’ or ‘collectible NFTs’ simply use the NFT metadata field to provide a URL to some image stored on a server–this would not be good enough, as the image could be changed retroactively (or, even if using IPFS, un-pinned so it becomes unavailable). This is not good enough for legal instruments–MetaLeX had to do better.
Scalable Vector Graphics (SVGs) are 2D images that can be specified entirely in an XML-based markup language. We can thus store the ‘certificate image’ for each cyberCERT in the smart contract for each cyberCORP, in text that looks something like this:
This SVG string is Base64-encoded and inserted into the JSON metadata for that NFT in its ‘image’ field so that it’s stored in the ERC-721 smart contract. By keeping the entire image data onchain (within the smart contract’s logic), this embedded SVG approach has many advantages. The system avoids any reliance on external storage or links, which guarantees persistence: the image will not be affected by someone’s server somewhere going down or IPFS content getting ‘un-pinned’. It makes dynamic updates possible (e.g., can change the number of shares to reflect a stock split). Additionally, it makes the cyberCERT tamper resistant (similar to having holograms and high-bond paper for paper securities certificates), and any change that did occur would leave a record on the blockchain. From the issuer’s point of view, the image remains programmable through future upgrades to the MetaLeX protocol, which may be needed to meet changing legal requirements. It is also composable, as any program (such as a specialized securities wallet) can read from the SVG data and make changes on top to improve UX. Because we use ERC-721s with SVGs, in the general case every NFT wallet and NFT marketplace should be able to display cyberCERTs out of the box.
cyberScrip - Fungible, Liquid Securities
In the MetaLeX securities tokenization protocol, we use the term “cyberSCRIP” to refer to the more tradeable, fungible, liquid, high-velocity version of our tokenized securities.
In tradLaw, “scrip” sometimes refers to certificates of conditional ownership, and other times to substitutes for legal tender or currency issued by a company. Traditionally, ‘scrip’ can represent a contingent claim to fractional shares of stock–the scrip themselves don’t have rights to vote on corporate affairs, receive dividends and notices, etc., but if you own enough scrip, you can turn those in, identify yourself, and redeem them with the corporation for real shares that do have such rights. A different kind of ‘scrip’ was issued in ‘company towns’ to pay workers of the company so that they could buy goods and services from other stores in the company town–essentially, a corporate points system.
A more cryptonative use of scrip is stablecoins. USDC and other similar stablecoins can be seen as scrip, because they do not have rights unto themselves, but when held by a client of the stablecoin issuer in sufficient amounts, that client will have rights of redemption for the backing assets of the stablecoin. In this sense, USDC, USDT and all other custodial stablecoins fundamentally work almost exactly like old-fashioned scrip.
MetaLeX scrip is analogically similar to these prior use cases—it consists of ERC20 fungible securities tokens that can be generated from cyberCERTs. This is done by calling the scripifyCert function of IssuanceManager. Conversely, scrip (ERC20s) can be re-assembled back into full certificates (‘cert’ NFTs) via the convertScripToCert function of IssuanceManager, which burns a specified amount of scrip and either ‘unvoids’ a matching voided cert (from which the scrip was originally generated) or mints a new cyberCERT for the underlying amount of securities (based on the scrip:securities units ratio).
Converting cyberSCRIPs to a cyberCERT, of course, requires having enough of the scrip tokens and satisfying any other conditions the issuer has set on rights activation (e.g., KYC/AML). This is all accomplished by linking a CyberScrip instance with each CyberCertPrinter instance through a beacon proxy.
By breaking a given securities class/series into fungible ERC20 units, cyberSCRIP can serve a number of purposes within the MetaLeX ecosystem:
trading at scale (fully liquid securities trading freely on public exchange platforms, e.g. AMMs);
vesting protocols (they can vest/unlock as small amounts of tokens representing small numbers of securities over time, as opposed to certificates, which typically represent many securities as a single token);
collateral tokens in DeFi credit protocols (when collateral is liquidated, partial liquidation must be possible, and most credit protocols expect ERC20s);
improve unit economics—for example, if a security is trading at too high a price per share, the cyberCERT:cyberSCRIP conversion ratios can be set to create tradeable units in denominations less than one whole share;
serve as inert ‘pre-securities’ or ‘contingent securities’ that give price exposure without rights, or enable ownership in unpermissioned environments;
function as ‘souvenir tokens’ mirroring an offchain stock ledger;
serve as ‘Instruction Tokens’ or ‘Control Agreement Tokens’ (discussed below);
allow for greater privacy;
use for voting, dividend distribution or other programmatic functions, if desired.
How cyberCerts and cyberScrip Work Together
So, why do we have two token types, both certs and scrips, and how do they work together? Certs and scrips work together to get similar functionality to “ERC404” and other NFT particle-ization/fractionalization protocols–holders and issuers can switch back and forth between the robust registered ‘certificated securities’ NFTs model of securities ownership and the more liquid, tradeable, ‘scrip’ model of securities ownership. This unlocks multiple design patterns for how entities handle their onchain securities, which feeds into a variety of legal and corporate finance strategies.
Design Pattern #1: Exclusively Use Certs Pre-Public, Switch to Scrip When Public
The cyberCERT format is ideal for pre-IPO, illiquid or semi-liquid securities. Because the securities represented are not SEC-registered for public offers, they are not intended to trade at scale—they are more designed for occasional peer-to-peer OTC trades or for pledging as collateral in secured credit arrangements (perhaps enhanced by cybernetic legal agreements and smart contract escrows, such as LeXscroW).
Thus, one design pattern is simply to use cyberCERTs as the exclusive way of representing the issuer’s securities while the company is ‘privately held’ (i.e., has not IPO’d), and switch to cyberSCRIP at the public stage. This can be done under either of two theories:
(1) the cyberCERTs are conceptualized as actual securities certificates, and the issuer additionally keeps a separate stock ledger (cyberCERT trades will *usually* end up getting registered on the ledger, but there may be lag); or
(2) the blockchain itself is conceptualized as the issuer’s stock ledger (or a part of it), and the cyberCERTs are conceptualized as entries on that ledger.
This would be similar to any private company that either uses a ‘certificated stock’ model or a self-administered ‘book-entry’ (uncertificated) model. In ether case, when a private issuer gets a new investor, it generally interacts with and registers their ownership of securities directly. The certificates or stock ledger entries registering that ownership are ‘legended’ (transfer-restricted) and cannot trade without the issuer’s permission, and it is understood that such trading will basically never be allowed until the issuer ‘goes public’ in an SEC-registered IPO. The issuer can toggle cert transferability on, on a case-by-case basis, for limited events like a fund transferring the security to one of its affiliates or a one-off OTC sale that the issuer and its major investors have decided to permit (e.g., a departing founder selling shares to a remaining founder).
When the issuer ‘goes public’ (e.g., registering an IPO with the SEC), such that its shares are freely tradeable, the issuer would switch to a cyberSCRIP system. The issuer could convert all cyberCERTs (preferred shares, convertible notes, etc.) into common stock cyberCERTs, and ‘scripify’ the common stock cyberCERTs to enable the ERC20 version of its shares to trade onchain at scale. This can be done on a disintermediated basis or plugging into the more traditional intermediated capital markets structure. A single cyberCERT “jumbo certificate” representing all common stock of an issuer could be issued to an intermediary like Cede & Co, and then fractionalized into many cyberSCRIPs that serve as ‘Instruction Tokens’ or ‘Control Agreement Tokens’ (as discussed below). The cyberSCRIPs could trade on cryptosecurities exchanges directly, or could be held in the wallets of various sub-intermediaries (brokers) and used to create “securities entitlements” for retail holders, so that trading occurs on more centralized, regulated ledgers—potentially including private ledgers acting like “dark pools” for confidential trades.
Design Pattern #2: Treat the Blockchain as a 'Souvenir'/'Mirror' System, or use Instruction Tokens or Control Agreement Tokens, using cyberSCRIP
Recall that one of our design goals for the MetaLeX protocol, explained in the Intro, was to enable treating tokens as definitive legal instruments embodying securities property rights. But, with scrip, the MetaLeX protocol can also accommodate another strategy–one where the issuer treats its securities as being un-tokenized, offchain book-entry securities, but still uses cyberSCRIP to ‘mirror’ or them as part of a chain of actions that can lead to changes in legal ownership.
There are several variations of this:
The blockchain, or specific smart contracts on a blockchain, and scrip tokens are used as a ‘mirror’ of an offchain legal ledger maintained by the issuer or its transfer agent. Here tokenization is essentially a transparency mechanism rather than a legal one. All actual legal changes occur on an offchain securities ledger, and the blockchain state is intended to ‘mirror’ the state of the offchain ledger through token balances at addresses that have an offchain legal identity. However, the tokens are legally meaningless/inert--mere souvenirs or ‘courtesy copies’ of a definitive offchain ledger.
The same as #1, but the scrip tokens now do have a legal function beyond mere mirroring/transparency. They serve as “Instruction Tokens”--when a token is sent from one address to another, this is meant to serve as a message to the issuer (or its transfer agent) that it should make a certain registered ownership change on its offchain securities ledger. Again, this only works in a permissioned system, as the issuer must know who the owners are of both addresses for an “instruction” constructed this way to make sense, and all participants must be in privity with the issuer such that they can benefit from the issuer’s commitment to treat the sending of tokens as a type of enforceable instruction. Note that, in this model, the securities are still not truly ‘tokenized’--the issuer treats token sends as messages, but it may still have considerable discretion on how to respond to those messages (for example, it could view a certain transfer as illegal and therefore refuse to ‘register’ it, i.e., refuse to follow the intended ‘instruction’).
The same as #2, but the scrip tokens are now deemed ‘Control Agreement Tokens’--the issuer has entered into a public agreement to treat a transfer of the token from one address to another as an assignment of rights from one ‘controller’ of the securities to another. This is a specific legal concept, which means the issuer *must* obey the new controller’s instructions--including an instruction to change the name the securities are registered in on the offchain ledger. Thus, this option is essentially a stronger, more bearer-like version of #2--the issuer has a broader mandate regarding what instructions it would need to follow from the token holder, and has less (or no) discretion to disregard those instructions. There is still a potential lag in changes of ownership and the securities are still not truly ‘tokenized’, but many of the same benefits are achievable.
Most securities tokenizations to date followed pattern #1. They were heavily permissioned, and their legal model involved a transfer agent maintaining the definitive list of securities owners and permitted transfers, while the blockchain tokens become a kind of ‘souvenir of ownership’ that is intended to mirror the transfer agent’s offchain book-entry ledger. For example, Overstock calls its tokenized shares “digitally enhanced securities” and explains that:
“Computershare, the transfer agent. . .will maintain a pseudonymized “courtesy carbon copy” on a publicly-available distributed ledger of certain records [of the shares] that [Computershare] maintains. . . [and will do so] as a convenience and with no controlling effect. Computershare’s conventional records, and not the blockchain records, will govern the record ownership for the [shares] in all circumstances. The distributed ledger will only be updated to reflect changes that are first made to Computershare’s official books and records”
As a result of this structure:
“Computershare will not register peer-to-peer transfers of record ownership of the [shares], and the only way to effect a sale of the [shares] is through. . .an ATS-executing broker-dealer . . .”
Of course, this means that despite putative ‘tokenization’ of the shares, the tokens are not transferable legal instruments and all share transactions remain heavily centralized and intermediated. The tokens are mere ‘souvenirs of ownership,’ at best.
In contrast, patterns #2 and #3 are at least partially ‘cryptonative’ variations on the book-entry approach, as the tokens (or movements of the tokens) do at least have some legal import in themselves and therefore serve as assets of a kind. However, they serve as instructions (treating the blockchain as a messaging bus) or as assignments of rights under ancillary agreements (control agreement) only, rather than truly representing the securities, and thus the securities themselves are not truly “tokenized”.
Though the MetaLeX protocol can accommodate these patterns via cyberSCRIP, we view them as less than ideal and has having questionable utility long-term. Settlement lags, and may be uncertain due to ongoing issuer discretion. This undercuts many of the best benefits of blockchains, including efficient liquidations in DeFi protocols. Moreover:
(1) ‘Souvenir tokens’ are just that, souvenirs. There are many potential ways of publicly displaying that certain people own certain securities on a lagging/non-definitive and essentially illustrative basis, it is not clear why moving tokens around on a blockchain is a particularly good method for this.
(2) Instruction Tokens do not make a lot of sense--if people want to use a blockchain as a messaging bus, there are better ways. Blockchains simply can be used to send actual literal messages in text form, and this can be done programmatically just like tokens can be transferred programmatically. The torturous logic of construing a token transfer as a kind of message is not required for any real reason.
(3) Control Agreement Tokens are a little better, but still--we can think of better/clearer ways to effectuate and record agreements rights assignments than by sending ERC20 tokens among blockchain addresses. For example, the cyberCERT mutation approach could more clearly show the semantics of contract rights assignment while leaving an easily auditable trail, all of which would be clearer and provide better UX/auditability than extrinsically construing transfers of ERC20s as contract rights assignment events.
In general, under all these approaches, settlement speed/finality is comparatively weaker than for normal crypto bearer asset transactions, and the UX of how tokens tie into the legal layer is abstract, indirect, and un-intuitive.
Nevertheless, despite these drawbacks, we acknowledge these approaches are being taken by ‘tokenization’ projects today--especially ones that rely heavily on intermediaries such as securities broker-dealers and DTC. Approaches #2 and #3 will also be acknowledged by the Permanent Editorial Board for the Uniform Commercial Code in a forthcoming report. Thus the MetaLeX protocol needs to be able to accommodate them, and it can--via cyberSCRIPs. Moreover, it is true that at least some of the benefits of blockchain are admittedly retained under these approaches--using PKI and existing crypto wallet infrastructure for trade authorizations and portfolio management, composability, transparency, etc. can still have value.
Regardless of which of these cyberSCRIP design patterns is used, cyberCERTs can still be useful from time to time alongside these scrip-based systems. For example, certain investors, such as PE funds, are accustomed to a certificated securities model and have built their compliance functions around it–they may want an exception that their particular securities be certificated and held by a third-party custodian. Or, they may want stronger property rights by holding their book-entry position as an NFT. The issuer could accommodate this by issuing a cyberCERT for those particular shares, and the issuer would then have an overall hybrid book-entry system and certificated securities system, which is legally acceptable.
Design Pattern #3: Degen Mode
Issuers who want to be bolder, more cryptonative, and launch their securities into the market on a liquid basis faster, can experiment with what we affectionately call ‘degen mode’.
This model uses certs and scrips in tandem, as follows:
Certs represent true securities ownership, registered to the name of the securities owner (who will thus be entitled to dividends, voting rights, rights in mergers and acquisitions, etc.)
Scrips represent no actual rights, but when held in sufficient quantities by an eligible person (someone KYC’d/AML’d by the issuer and otherwise fitting the issuer’s criteria for securities ownership), can be converted into certs which do have rights.
Example: a holder might need to have at least 1,000,000 scrip (representing 500 whole shares of stock) to convert back into a certificate, and such holder might need to clear extensive KYC/AML checks attested to by the corporation’s compliance multisig. A condition manager contract enables the issuer to impose any type of KYC/AML or other process on scrip holders who wish to convert their scrip back into certificates. This is very similar to the distinction between ordinary USDC or USDT holders, and those special holders who can actually redeem their stablecoins for fiat from Circle or Tether.
Sound familiar? It should. This is basically the same legal strategy used for custodial stablecoins. A typical holder of USDC or USDT has no rights per se–but when USDC or USDT are held by qualifying clients/customers of Circle or Tether, respectively, those persons have legal rights with respect to them (the right to redeem 1:1 for underlying fiat equivalents, and perhaps other rights).
This strategy also is embedded in most corporate statutes, which expressly authorize issuing scrip to represent fractional shares of stock. For example, here is the relevant provision of the Wyoming Business Corporation Act Art. 6, §17-16-604:
In theory, startups could even use scrip like memecoins–launch the scrip first as a memecoin, and then make it convertible into securities later, all on the same ‘CorpFi’ tokenization protocol.
MetaLeX’s protocols are intended to be flexible and unlock your creativity. Issuers are free to work with their counsel (including potentially MetaLeX’s sister law firm, MetaLeX Pro) to use scrip however they think makes the most sense for them.
Securities Tokens Programmability
Programmability – Deal Management
MetaLeX’s protocol includes onchain deal management to automate and secure corporate transactions like fundraising and equity issuances. Instead of exchanging signed PDFs and wiring money in escrow accounts, issuers and investors can use smart contracts to handle the entire deal flow – from proposal, to signature collection, to payment and closing. A dedicated DealManager contract orchestrates each deal’s lifecycle in a transparent way. Founders (or token holders) can propose a deal onchain with all key terms (e.g. investment amount, valuation cap, asset to be issued/transferred) and a chosen legal template (such as a SAFE or stock purchase agreement). The proposal is identified by a unique ID and is essentially a structured term sheet recorded onchain. Both parties then cryptographically sign the deal (via EIP-712 signatures) to indicate acceptance of the terms. The DealManager tracks these signatures and any other requirements before closing.
Crucially, the protocol employs an automated escrow (the LeXscroWLite module) to eliminate counterparty risks. When a deal is proposed, the issuer’s promised asset (e.g. the new NFT security certificate to be issued) is minted and held in escrow, and the investor’s payment obligation is recorded. Funds are not transferred immediately; instead, the investor sends the payment to the smart contract escrow where it’s held pending finalization. The DealManager contract ensures that all conditions are met before executing the swap: for example, it will verify that both parties have signed, that any required KYC/AML or accreditation checks pass, and that no time deadlines have expired. MetaLeX’s LeXcheX module issues soul-bound NFTs to represent an investor’s accreditation status onchain, allowing the contract to automatically check investor eligibility (per SEC rules, etc.) before accepting funds. Custom conditions can also be attached via an extensible ICondition interface – meaning deals can include bespoke requirements (like a minimum raise threshold, regulatory approval, or whitelisted buyer addresses) that must return true for the deal to close.
Once all conditions are satisfied, the DealManager moves the deal to finalization. At this point, the escrow performs an atomic swap: the investor’s funds are released to the company’s wallet, and simultaneously the NFT certificate (representing the security) is released to the investor. This automatic closing ensures neither side can default after the other has performed – it’s all-or-nothing execution by code. If a deal falls through (e.g. a party fails to sign or fund by the deadline), the contract can safely unwind: funds are returned to the investor and the provisional NFT can be voided or burned, just as a canceled paper deal would result in tearing up the unsigned stock certificate.
Beyond single transactions, MetaLeX’s protocol is designed to handle broader deal logic. The RoundManager and the new RoundManagerFactory coordinate funding rounds involving multiple investors. The RoundManager is now fully deployed and can manage a set of parallel tickets under one funding round (for example, a Seed round with 10 SAFE agreements to different investors) and can enforce round-level parameters–such as a total cap on funds raised, min/max ticket size, or a common closing date for all deals in the round. Tickets can be allocated on a first-come-first-served (public round) basis or via expression of interest (EOIs) evaluated by the issuer. With the new FCFS functionality, funds are escrowed, allocations respect per‑investor min/max, total caps, and any unused tail from price granularity is automatically refunded. After the round window expires or the cap is reached, investors can recall unfilled EOIs for refunds, and the issuer or an authority officer can reject EOIs or approve finalization to force refunds where appropriate. The RoundManager uses the RoundManagerFactory to deploy itself and supports multiple round types (e.g., public or private rounds) and types of securities. In short, RoundManager lets companies orchestrate an entire fundraising round onchain–from expressions of interest to automatic settlement–while being tightly integrated with the related securities tokenization protocol, which we think is key to unlocking the programmability benefits of tokenized securities rather than just focusing on liquidity/transferability benefits of tokenization. For a detailed breakdown of this functionality and how MetaLeX’s webapp helps navigate it, see MetaLeX’s article on cyberRaise.
In the future, similar onchain deal mechanisms could facilitate secondary transfers and complex transactions. For instance, a shareholder could sell their tokenized shares to a new investor via the DealManager (using a purchase agreement template) – the contract would handle collecting payment from the buyer and transferring the NFT from the seller, all with onchain signatures and escrow, in a single atomic transaction. Even M&A transactions or buybacks could be structured as onchain deals, enabling things like an acquisition’s terms to be signed and settled through smart contracts. By handling deals programmatically, MetaLeX eliminates the need for lawyers or brokers to intermediate each transaction and eliminates most async coordination and possible errors, while ensuring compliance (through coded conditions) and preserving a full audit trail of the agreement’s execution onchain. It’s deal-making reimagined for Web3 – faster, safer, and integrated directly into the lifecycle of the tokenized securities.
Programmability – Governance and Economics
Putting securities onchain not only streamlines trading and fundraising, it also opens the door to automated governance and financial logic embedded in the securities themselves. MetaLeX’s tokenization protocol is built to support the programmable enforcement of shareholder rights, voting, and economic preferences at the smart contract level. In practice, this means many aspects of corporate governance and finance can be handled by code, reducing the potential for human error or malfeasance and ensuring investors’ rights are honored exactly as written in the code (and corresponding legal documents).
Shareholder Voting: Because each share or security is represented by a token (ERC-721 certificate or ERC-20 scrip), tallying votes for shareholder resolutions can be done onchain in real time. For example, a corporation could call a stockholder vote on some proposal, and token-holders could cast their votes by signing a transaction (or off-chain message that gets verified onchain) associated with their token holdings. The smart contracts can count votes weighted by the number of shares each wallet holds, just as a traditional tabulator would count votes by shares owned. This eliminates the need for proxy intermediaries – votes go directly from token-holders to the onchain tally. MetaLeX’s roadmap includes integrating “DAO-like” voting mechanisms for security holders, effectively turning the cap table into a built-in voting platform. This could be done via modules that either interface with existing DAO governance tools (like Snapshot or onchain Governor contracts) or via custom voting contracts where the CyberCorp’s board can initiate votes and the outcome is automatically recorded. By doing so, shareholder meetings and elections can be conducted in a continuous, transparent fashion, open to all tokenized stockholders globally and tallyable instantly – a stark improvement over mailed paper proxies and closed-door tabulations. NOTE: While the cyberCORP contracts record the official stock ledger and can be integrated with voting dApps or modules, formal on-chain voting (e.g., for shareholder resolutions) would be handled via additional governance contracts or off-chain tools at present; we expect voting functionality to be added to the cyberCORPs protocol in a later version.
Board and Management Governance: The cyberCORP framework already keeps track of directors and officers onchain (recorded in the CyberCorp contract), and it could be extended so that certain governance actions require onchain approval. For instance, adding a new board member or issuing more shares might be gated by an onchain vote of existing directors or shareholders. The system could also mint special “Board Seat” NFTs to board members, conferring them the rights to propose or vote on board resolutions through the smart contract (instead of via signed minutes). Because everything is onchain, these governance actions can be made auditable and enforceable by code – the company charter or bylaws could effectively be translated into smart contract rules. This drastically reduces “agency costs” by trustlessly ensuring that officers and insiders cannot take major actions (like diluting shareholders or selling assets) without the requisite onchain approval of token holders or designated overseers. MetaLeX envisions blending traditional corporate governance with DAO principles – for example, a company could even give tokenized shares (perhaps non-voting shares) to a community DAO and let that DAO have a say in certain decisions, creating a bridge between corporate governance and decentralized governance.
Economic Rights & Waterfall Logic: Securities often carry complex economic rights – e.g. preferred stock may have a liquidation preference or anti-dilution adjustments, certain shares might be entitled to cumulative dividends, etc. By tokenizing these instruments, MetaLeX can encode these economic rules into smart contracts. One approach is to use extensions or condition contracts attached to a class of tokens. For example, a “Preferred Stock Extension” contract could be linked to a Preferred share certificate token, such that if the company experiences a liquidation event (an exit), a smart contract can automatically calculate and distribute proceeds according to the pre-programmed waterfall: perhaps ensuring that the Preferred shareholders receive their 1× return before Common shareholders get paid. Instead of lawyers and bankers handling waterfall calculations in spreadsheets at the time of exit, an onchain waterfall module could pull in the sale price (via an oracle or an input by the company) and trustlessly disburse funds to token holders in the correct order of priority. Similarly, dividend logic can be built in: a company treasury contract could have a function to distribute a dividend, which loops through all shareholder tokens and pays out each class the appropriate amount (for instance, paying any accrued dividend to Preferred first, or giving Common a higher dividend if Preferred is non-participating and already paid). These tasks can be automated by smart contracts, as noted in policy discussions – smart contracts can handle corporate actions like dividend distributions directly to token holders. This not only saves time but enforces fairness: no one can be left out or paid the wrong amount due to oversight or bias, since the code executes the exact formula everyone agreed to.
Programmability - Compliance Controls
Lastly, programmability extends to compliance in economic activities.
Transfer restrictions can be built into the token contracts – for instance, the CyberCertPrinter (ERC-721 certificate contract) supports toggling transferability and even checking conditions on each transfer. An issuer might require that any buyer of its stock token passes an onchain accreditation check or is not from a banned jurisdiction. Smart contract hooks can call out to compliance oracles (for sanctions screening, 12(g) shareholder count limits, holding periods for Reg D or Reg S, etc.). Transfer restriction hooks can be set for all transfers of a given class of cyberCERT or cyberSCRIP, and in the future issuers may activate per-certificate hooks. This is powerful – it allows, for example, a KYC whitelist contract, or rules like no transfers until a certain date, etc., to be enforced onchain.
Of course, there is also always the less fine-grained ‘nuclear option’ of the issuer simply toggling transferability off and on on a class-wide or individual-CERT basis--this can be leveraged in combination with manual offchain legal/admin processes to fit nearly any compliance need, albeit it is a less efficient and trust-minimized compliance solution than custom hooks.
For cyberSCRIP (ERC20 version of securities) only, the cyberCORP can freeze an address (preventing transfers) and can force-transfer or force-burn tokens outside the normal hooks (e.g. to enforce a court order or correct an error). These are initially enabled at deployment, on the theory that, as explained above, ‘scrip’ are likely to be treated in a stablecoin-like fashion from an issuer perspective. However, unlike with most stablecoins, these features can be permanently disabled by the issuer to assure investors they will never be used–facilitating a ‘bearer-like’ experience. The configuration selected by a particular issuer will, again, likely depend on a range of issuer-specific compliance and commercial considerations. The protocol is designed to accommodate a wide range of potential needs, including even “non-securities corporate memecoin that is convertible into securities,” as explained above.
Because of these features, the economic life of the security (trading, payouts, conversions) can all be entwined with legal compliance logic. This ensures that as the tokens move or generate value, they continuously respect the regulatory parameters set by the issuer – preventing unauthorized trades or distributions by design. In summary, MetaLeX’s tokenized securities behave like “living” financial instruments: they don’t just sit passively in a cap table, but actively execute governance decisions and economic flows according to rules, much like a mini DAO built around each corporation’s equity. This level of automation in governance and economics is unprecedented in traditional markets and is poised to make companies both more efficient and more accountable to their stakeholders.
Decentralized Upgradeability
The MetaLeX protocol’s smart contracts are upgradeable, but in a manner that requires opt-in consent from the companies using them. All major components – including the CyberCorp core contract, the IssuanceManager, DealManager, RoundManager, and even the token contracts like CyberCertPrinter and CyberScrip – employ upgradeable proxy patterns. However, MetaLeX Labs cannot unilaterally push upgrades, and likewise an individual company cannot upgrade its instances to arbitrary new code that hasn’t been vetted by MetaLeX. Instead, upgrades follow a co-approval model: MetaLeX can publish new implementation contracts (new versions of the logic), but it is up to each company (the issuer) to decide if and when to adopt the upgrade on their own contracts. This means any change in the protocol’s logic is effectively voluntary and under shared control, rather than mandated solely by MetaLeX Labs.
This places MetaLeX Labs in the role of ‘protocol steward’ rather than being an intermediary like a securities broker or securities transfer agent, and is a major distinction from all other securities tokenization protocols on the market today.
Alternatively, MetaLeX’s opt-in design allows a company to remain on their original contracts indefinitely if desired. This could be used to mitigate trust issues between a company and its investors or between MetaLeX Labs and a company
Legal Analysis
MetaLeX’s approach is radical in technical terms, but it is carefully designed to fit within existing legal frameworks for securities and corporations. A common question is: can an onchain token really represent a legal share of stock or other security? The short answer is yes – especially in forward-thinking jurisdictions like Delaware and Wyoming.
Corporate Law - Certificated Securities Model with cyberCERTs
In this model, the ERC-721 cert token is the share certificate, and thus the token embodies the stockholder’s legal rights. Both Delaware and Wyoming corporate statutes give a solid legal foundation for use of tokenized stock certificates.
By designing the NFT metadata of MetaLeX certs to include all information required by DGCL 158 and 202 (signatures of two corporate officers + the name of the stockholder + the number, class, and series of shares and all applicable transfer restrictions), MetaLeX’s tokenized certs are enforceable as stock certificates under Delaware corporate law. Wyoming, meanwhile, explicitly validates blockchain share certificates: Wyoming Stat. §17-16-625 allows articles or bylaws to authorize “share certificates in the form of certificate tokens” and deems an electronic transaction that transmits the token to the investor, signed by two officers’ private keys, as issuance of the certificate. Therefore, a Delaware corporation using cert tokens is relying on traditional law (with a tech twist), while a Wyoming corporation has modernized law directly on point–in either case, the courts should recognize the tokens as valid share certificates. Both are buttressed by the Federal ESIGN Act, which prohibits denying legal effect, validity, or enforceability to a signature, contract, or other record solely because it is in electronic form or, in the case of a contract, because an electronic signature or electronic record was used in the contract’s formation, though see below under “Commercial Law” for important limits to this in the context of negotiability and collateralization (issuance should be fine).
Corporate Law - Book-Entry/Stock Ledger Model with cyberCERTs
In this model of tokenization, the corporation’s shares are primarily tracked in “book-entry” form using a blockchain as definitive securities ledger. cyberCERTs serve as entries on this ledger--recording each securities issuance and transfer, and the names of the past and current owner of each security.
This method is clearly permitted under Delaware and Wyoming law. In a Delaware corporation, the board can resolve that all shares be uncertificated (
), meaning shareholders do not receive physical certificates but rather the corporation maintains records of their holdings on a ledger. By default, that ledger could be a traditional database or even Excel sheet, or a blockchain. Delaware’s 2017 amendments to §224 and §219 made it clear that the “stock ledger” can be kept on “one or more distributed electronic networks or databases” (such as a blockchain) as long as the corporation can retrieve and print the information as needed. For Wyoming corporations, the law is similarly accommodating. Wyoming’s Business Corporation Act (W.S. §17-16-724, §17-16-730, etc.) permits electronic networks for tracking ownership.
Corporate Law - Souvenir Model with cyberSCRIPs
In the “souvenir” model of tokenization, the corporation’s shares are primarily tracked in offchain “book-entry” form and the corporation uses MetaLeX ‘scrip’ tokens (ERC20) to fully or partially represent shares on an informational / souvenir basis. As explained above, the tokens and blockchain in this model have no real legal import. Thus, they do not require any specific legal basis under corporate law. It is legal to maintain various copies of information about who owns an issuer’s securities, in various formats, for informational purposes.
Corporate Law - Instruction Tokens and Control Agreement Tokens with cyberSCRIPs
Delaware and Wyoming corporate law both cross-reference their States’ respective implementations of the Uniform Commercial Code to govern transfers of shares and use of shares as lending collateral and other similar matters. This creates a clear basis in corporate law for treating cyberSCRIPs as Instruction Tokens or Control Agreement Tokens, as explained below in the commercial law section.
Corporate Law - Degen Mode
In corporate practice, scrip certificates were historically used when companies did stock splits resulting in fractional leftovers – shareholders might get a scrip certificate and once they collected enough to form a full share, they’d trade it in. The degen model essentially uses that concept intentionally at scale, and both Delaware and Wyoming corporate law permit doing so. DGCL §155 explicitly allows issuing “scrip or warrants” representing fractional shares and not entitling the holder to voting or dividends unless converted to full shares, but, due to recent (2025) amendments following the U.S. Corporate Transparency Act, the scrip must initially be issued in registered form (i.e., to a particular named holder, rather than as a ‘bearer instrument’). The corporation’s board of directors can impose conditions on the scrip, like an expiration date or that it’s void if not exchanged by a certain time. Section 17-16-604 of the Wyoming Business Corporation Act is similar, but differs from DGCL §155 in that it still nominally allows for ‘bearer scrip’ (i.e., scrip not originally registered to a particular named person). Given the recent narrowing of the U.S. Corporate Transparency Act by FinCEN interpretation / enforcement policy, it may be that Delaware ‘jumped the gun’ on its amendments and that other jurisdictions like Wyoming may allow ‘bearer scrip’ indefinitely.
From a stockholder rights perspective, until conversion, scrip holders are not stockholders. That means they do not get to vote on corporate matters, they are not counted for quorum, they don’t receive dividends directly, etc. The corporation can even disclaim any fiduciary duty to scrip holders (beyond contractual obligations) since they are not equity owners yet. However, there should be a clear contract (perhaps the terms of the token or the offering memo) outlining what rights scrip holders do have – the contingent right to convert under certain conditions.
Securities Law
What about regulatory compliance (SEC rules, etc.)? Tokenizing a security doesn’t exempt it from securities laws – MetaLeX’s protocol is built to accommodate those laws, not bypass them. For example, most early-stage securities are sold under exemptions like Regulation D (Rule 506(b) or 506(c)) which require verifying investors are accredited and restricting resales. MetaLeX makes this easier by integrating onchain accreditation (via LeXcheX NFTs) and by allowing tokens to be initially non-transferable or trade-restricted until certain conditions (like a 1-year holding period under Rule 144) are met. Smart contracts can enforce the “Rule 144” holding period by simply not allowing transfers before a timestamp, or require that any buyer address is also accredited if the token is still within its restricted phase. Similarly, Regulation S (offshore offerings) has an “anti-flowback” rule preventing U.S. persons from buying the securities for a certain period – this too can be enforced by coding geographic or citizenship-based transfer conditions (using identity oracles) for that duration. By embedding these restrictions, MetaLeX tokens can carry their compliance rules with them, ensuring that trading on a DEX or peer-to-peer won’t accidentally violate securities laws – the token itself will refuse to move in disallowed ways. This is a powerful concept: rather than relying on a web of contracts and trust that people will follow the rules, the compliance is continuous and automatic.
Another legal concern is the role of transfer agents and record-keeping. In public markets, registered transfer agents traditionally manage share registries and updates, which has led some to assume one must always have such an intermediary. However, if a blockchain is the official ledger, the need for a separate transfer agent can disappear. In fact, forcing a traditional transfer agent into a blockchain-based system can negate many benefits. MetaLeX’s vision is aligned with the idea that a properly designed smart contract system is the transfer agent in effect – it maintains the ownership ledger, timestamps each transfer, and handles corporate actions exactly as a good transfer agent would, but more efficiently. U.S. regulators are actively studying this area; an SEC Commissioner (Hester Peirce) and others have been asked to modernize rules to accommodate blockchain record-keeping and perhaps relax the legacy transfer agent requirements for tokenized securities The trajectory is clear: the law is moving toward embracing onchain records, given their immutability, transparency, and real-time accuracy. MetaLeX’s framework is flexible: issuers can configure their token’s transfer controls to either strictly enforce investor verification and holding periods (complying with Rule 144, etc.) or to allow freer trading when legally permissible. This way, MetaLeX meets current legal requirements and is ready for a more open regulatory environment if and when it arrives.
Property Law
From a property law perspective, tokenized securities on MetaLeX are treated as personal property of the holders, just like stock certificates. The holder has direct dominion over the token (controlled by their private key) and, unless combined with a book entry approach on an intermediated basis, the represented security, rather than a broker or bank holding it on their behalf. This direct ownership model has legal advantages: it means, for instance, that incidents of ownership (like the right to vote, to receive dividends, or to pledge the security as collateral) are exercised by the holder without needing permission from intermediaries. So long as the issuing company recognizes the token holder as the shareholder of record (which the cyberCORP contract does by design), the token holder can assert all their rights in court if needed. In case disputes do arise, the onchain records and cryptographic signatures provide strong evidence – arguably stronger than paper in some ways, since every transfer or vote is timestamped and verifiable. Courts are increasingly open to blockchain records; there have been cases and statutes acknowledging that a digital record or signature should carry legal weight similar to a paper one. MetaLeX pairs its tech with traditional legal documentation (e.g. each token can be linked to a legal agreement text, and CyberCorp data includes real-world identities of officers and shareholders) to ensure that the system’s outputs are admissible and understandable in legal settings.
Commercial Law
The Uniform Commercial Code (UCC) is a set of uniform model laws designed to standardize commercial transactions across the United States, developed by the American Law Institute (ALI) and the Uniform Law Commission (ULC). States then choose to adopt parts of this model law, creating their own versions of the UCC, such as the California Uniform Commercial Code or New York Uniform Commercial Code. Crypto people could think of this model as being similar to having core devs (ALI, ULC) that write a protocol (UCC) and then states as being like validators that choose to adopt particular instantiations (clients) of that protocol. Thus, the UCC is not binding law, but many U.S. states’ laws are based heavily on it (nearly verbatim, but sometimes with fairly heavy modifications, especially in Wyoming re: crypto).
The UCC comes into play with tokenized securities in several important ways. Let’s take Delaware law as an example:
Delaware’s corporate law, the DGCL (DGCL s. 201), cross-references Delaware’s as-adopted version of Article 8 of the UCC for determining issues of transferability of stock, stock certificates, and uncertificated stock, but also provides that if there are any inconsistencies between the DGCL and Article, the DGCL will be controlling on those inconsistencies.
Delaware’s as-adopted version of UCC Article 9 (6 Del. C. § 9-101 et seq) will determine creditor’s rights when it comes to creditors lending against securities as collateral.
The UCC (and Delaware’s implementation thereof) classifies tokens themselves not as securities, but as Controllable Electronic Records, under Article 12 (Delaware version: 6 Del. C. § 12-102(a)(1)). Interestingly, Wyoming’s implementation of the UCC differs here--it has not adopted the Controllable Electronic Records article, and instead actually classifies tokens in several different ways depending on their nature; in some cases, they may directly constitute Article 8 securities.
The UCC (and Delaware’s and Wyoming’s implementations thereof) recognize the concepts of “instructions” and “control agreements” relating to uncertificated securities, and as discussed above (and further below) these concepts can be tied to tokens and blockchains as part of a chain of transactions that issue or transfer securities.
Currently, the Uniform Commercial Code (UCC) does not explicitly recognize securities that are issued and transferred in an un-intermediated digital form (e.g. as blockchain tokens held directly by investors). Under Article 8 of the UCC, an investment security can only fall into one of three categories, none of which squarely cover a natively electronic, peer-to-peer instrument:
Certificated securities: A security represented by a physical certificate (traditionally paper). (An
to Article 8 makes clear this means a tangible paper certificate, not an electronic record).
Uncertificated securities: A security recorded on the issuer’s books or stock ledger with no certificate issued. For example, many modern corporations simply track share ownership in an electronic register maintained by the company or its transfer agent, without any paper certificates.
Security entitlements: A contractual/bailment interest that an investor holds through a securities intermediary (such as a broker or bank) rather than directly with the issuer. In the UCC’s indirect holding system, the investor is an “entitlement holder” whose broker or custodian maintains an account for them and, in turn, holds the underlying securities or another security entitlement to the underlying securities (often as a fungible bulk position at a depository like DTCC’s Cede & Co., which itself be either uncertificated or certificated).
Thus, under the UCC, tokens themselves are never securities. The UCC assumes all certificated securities are in paper form and that any purely electronic representation of a security would either be pure book-entry on the issuer’s own books and records or would be an ‘entitlement’ within a brokerage account.
Why the gap? Nowhere does UCC Article 8 provide for a security that is represented solely by an electronic token or digital record in the investor’s possession/control (with no paper and no intermediary). Instead, if a company today tokenizes its shares on a blockchain, UCC Article 8 presumes a classification into the above framework–where a security is either disintermediated/directly negotiable and on paper or is intermediated and electronic. Disintermediated/directly negotiable and electronic is a missing category in the UCC. The UCC’s securities provisions are also carved-out from the U.S. Federal ESIGN Act, so that the ESIGN Act’s general preemptive rule requiring legal equivalence between paper and electronic transactions/documents does not apply to UCC-governed securities transactions.
In practice, this means using cyberCERTs to be literal securities certificates is probably not the best move currently in the U.S., though could be reasonably clear in Wyoming because it has not adopted UCC Article 12 and expressly allows for tokenized stock certificates in its corporate code. But that is okay, as cyberCERTs can function almost identically within a context where they are viewed as stock ledger entries and the blockchain itself is viewed as (or as part of) the corporation’s official stock ledger--as clearly permitted by both Delaware and Wyoming corporate law as well as the UCC. This usage pattern/legal approach still preserves almost all of the same UX and legal conveniences as securities certificates, and if anything gives holders even stronger property rights in their securities, as stock ledger entries (and changes therein) are absolutely definitive, whereas secondary certificate transfers may have post-transfer settlement risk.
Additionally, cyberCERT NFTs or cyberSCRIP ERC20s may be used in other ways in this system, compatibly with the UCC, and the MetaLeX tokenization protocol also accommodates these alternative approaches:
Although a token is not a security under the UCC, a token (or certain transactions in a token) can nevertheless be construed as “instructions” or as representing “control agreement rights” relating to uncertificated securities.
“Instructions” are defined under Article 8 as “a notification communicated to the issuer of an uncertificated security which directs that the transfer of the security be registered or that the security be redeemed”. A corporation can have terms and conditions (eg in its Bylaws) that provide that when a certain token is sent by a securities owner within a blockchain system to another address, this is construed as an instruction to the issuer to re-register ownership of some associated tokens to a new person.
Article 8 defines a purchaser as having “control” of an uncertificated security when “the issuer has agreed that it will comply with instructions originated by the purchaser without further consent by the registered owner”. Thus, a cyberSCRIP can serve as a “Control Agreement Token” such that a registered owner’s transfer of control of the Control Agreement Token would constitute the corporation’s agreement with the transferee of control of the Control Agreement Token and the registered owner that the corporation will comply with instructions concerning some designated amount of shares without further consent of the registered owner--this is a very ‘certificate-like’ UX since although final settlement and true registered ownership of the security may lag the token-based transaction, if legal agreements are established and communicated effectively, a purchaser of the token can have high confidence they, for all practical purposes, own the associated securities.
In all, existing law allows for a range of different uses of the MetaLeX protocol to, in effect, ‘tokenize’ securities, with different trust models, settlement properties, etc., depending on the particular token model (cyberCERT vs cyberSCRIP) and legal model (tokenized certificate, tokenized ledger, instruction token, or control agreement token) selected. These models can also be mixed and matched in various ways, to create hybrid approaches.
The Future
The journey doesn’t end with simply tokenizing equities and SAFEs, SAFTs, and other convertibles – MetaLeX is laying the groundwork for a cybernetic economy where companies, investors, and even autonomous agents interact seamlessly through onchain legal protocols. In the near term, MetaLeX will expand its feature set and integrations to further enhance what onchain corporations (cyberCORPs) can do. On the roadmap are modules for things like onchain cap table analytics (a sort of “Crypto Carta” to manage dilution modeling, option grants, splits/mergers, etc.), and enhanced governance tooling such as shareholder DAO voting (letting token holders vote on proposals with the same ease as DAO token voting – this is explicitly being developed). We also expect Board of Director tools – for example, tracking board resolutions onchain, or even issuing special governance tokens to board members that let them vote or veto in accordance with the company’s charter. Because the system is upgradeable, new modules (e.g. a “Litigation DAO” module or an insurance module for onchain D&O insurance) could be plugged into existing cyberCORPs, much like installing apps in an operating system.
A major theme of MetaLeX’s vision is blurring the lines between traditional corporations and decentralized autonomous organizations. In the future, a cyberCORP might seamlessly interface with DAO communities – imagine a Delaware corporation that issues a class of stock to a community-run DAO, so that onchain governance by the community directly influences corporate decisions.
Conversely, a corporation could spawn BORGs, which could feed into agentic AI strategies. For instance, a cyberCORP could have an AI agent that runs a certain business process or holds some assets; using MetaLeX’s framework, that agent could own shares, execute contracts, or even form its own sub-entity onchain under the parent company’s oversight. This opens the door to scenarios like AI-managed investment funds, machine-run subsidiaries, or “robot shareholders” – once science fiction, now legally and technically conceivable.
In this future, intermediaries like broker/dealers, proxy solicitors, DTCC/Cede and Broadridge should be completely unnecessary. Each stockholder can simply opt-into autonomous governance strategies onchain–think about ‘governance vaults’ analogous to Yearn DeFi vaults, to jog your intuition; these would replace the role of proxy solicitors and ISS.
MetaLeX is already exploring these frontiers by combining its CyberCorp OS with its BORG protocol for autonomous organizations, for instance in our GAIB BORG experiment (article, app). The long-term result could be a world where agents, people, and companies all transact and share ownership in a unified, programmable environment – e.g., an AI agent could become a stakeholder in a human company, and that relationship is enforced by smart contracts and recognized legally.
Another exciting area is onchain corporate finance beyond equity. Today, MetaLeX focuses on equity and convertibles, but tomorrow could bring debt securities (tokenized bonds or notes), onchain collateralization of corporate assets, and integrations with DeFi. We refer to this as “CorpFi”. Because MetaLeX’s tokenized securities are DeFi-ready by design (ERC-20 scrip can plug into AMMs, lending platforms, etc.), we anticipate an ecosystem where a startup that raised money via cyberRaise could then, for example, list its scrip tokens in a liquidity pool to provide price discovery, or use its equity tokens as collateral to borrow stablecoins for working capital. Traditional financial operations – from taking a loan to paying suppliers – might be augmented by the ability to do these via smart contracts using the company’s own tokenized cap table. MetaLeX will likely partner or integrate with decentralized exchanges and money markets to facilitate this cross-pollination of CeFi and DeFi. Compliance conditions would travel with the tokens, ensuring that even when interfacing with open protocols, the securities only end up in permissible hands or contexts.
Features to handle corporate actions like stock splits or mergers are on the horizon too: since those could involve updating many tokens or exchanging one set of tokens for another, MetaLeX is working on smooth batch operations or upgradeable token contracts to support such events. Over time, many of the corporate procedures that are manual today (consents, filings, audits) could be automated or made trustless. For example, onchain accounting is a compelling future integration – if a company’s revenue is in crypto, it could feed directly into smart contracts that allocate those funds per the budgeting or dividend rules set by the company. One could envision real-time financial statements that are always up-to-date onchain, or profit-sharing contracts that instantly route a percentage of each sale to token holders as a dividend.
As legal systems evolve and comfort with blockchain grows, MetaLeX aims to be at the forefront, ensuring that companies can be incepted onchain and stay onchain for their entire lifecycle. This means a company’s formation, fundraising, operations, governance, and eventual exit could all occur through smart contracts that interface with real-world law.
It’s a bold vision: corporations that are as programmable as DeFi protocols, yet legally grounded – bringing the DAO ethos into the world of traditional equity. If successful, this will redefine what it means to own and run a company: ownership becomes more direct and liquid, governance becomes participatory and transparent, and the whole corporate apparatus becomes as efficient as software.
That is the endgame MetaLeX is driving towards, and each new module or integration (from compliance oracles to AI governance tools) is a step on that path. The result could be nothing less than a transformation of capital markets and enterprise. MetaLeX’s protocol is poised to be a catalyst of that change – turning today’s paper-bound deals and siloed ledgers into tomorrow’s cybernetic, composable corporate economy.