Bearer ≠ Bearer: Tokenization Myth‑Busters

When discussing tokenized securities and onchain companies, people (if you consider lawyers ‘people’) keep conflating the (true) ban on bearer certificates (which appears in corporate codes, tax codes, etc.) with a supposed legal duty of issuers to keep a perfect, real‑time share register—and then use that to argue against the possibility of P2P transfers and tokenization. This is a legally incorrect and highly confused take, for the reasons explained briefly here.

Myth 1: “Bearer shares are banned, so P2P tokens are illegal.”

Reality: What’s banned is issuing stock certificates in bearer form (i.e., instruments issued to “bearer,” not to a named owner).

Bearer certificates look like this:

Note that this instrument is issued in bearer (i.e., non-registered) form—it was not issued to a specific named person, and it contemplates that it may be transferred to unnamed persons and whichever unnamed person ‘bears’ it at a given time is the true owner. This is what makes it ‘bearer’.

That does not outlaw P2P transfers of registered shares.

• Nevada: “A corporation has no power to issue a certificate in bearer form, and any such certificate that is issued is void.” (NRS 78.235.) (Justia Law)

• Wyoming: “In no case shall a corporation issue share certificates in bearer form.” (W.S. § 17‑16‑625(f).) (Justia Law)

• UK (for global context): share warrants to bearer were abolished in 2015. (Legislation.gov.uk)

Banning bearer certificates ≠ banning P2P transfer of registered securities.

Myth 2: “If your register isn’t 100% real‑time accurate, you’re non‑compliant.”

Reality: Corporate/commercial law expressly tolerates a gap. Until a transfer is presented for registration, the issuer may treat the record holder as the owner for voting, notices, etc. That’s straight from the UCC.

• UCC § 8‑207: issuer “may treat the registered owner as the person exclusively entitled” to exercise rights until due presentment for registration of transfer. (Delaware Code Online)

In other words: off‑book P2P transfers can happen today (paper world) without any law being broken; the corporation updates the ledger when the holder eventually shows up.

Myth 3: “If a registered certificate changes hands P2P, the issuer basically issued bearer shares.”

Reality: No. A registered certificate can be transferred by delivery + indorsement; the purchaser acquires the transferor’s rights. That’s how paper has worked for decades.

• Delivery of certificated securities (possession rules). UCC § 8‑301. (Justia Law)

• Endorsement mechanics (blank/special; chain‑of‑title). UCC § 8‑304. (Justia Law)

• Purchaser acquires the transferor’s rights. UCC § 8‑302. (Justia Law)

The corporate ledger can lag reality without anyone “issuing bearer shares.”

Myth 4: “Transfer agents and centralized rails are mandatory for ownership to ‘count.’”

Reality: Not for private issuers. Delaware explicitly lets companies keep their stock ledger on ‘one or more electronic networks or databases,’ including distributed ledgers, so long as you can print it and it records transfers per Article 8. DGCL § 224. (Justia Law)

That’s the legal hook for onchain record‑keeping by or on behalf of the issuer. It supports both occasional OTC transfers (paper‑style) and more automated flows.

Myth 5: “Tokenization = bearer instruments.”

Reality: “Bearer” describes form at issuance, not the tech. Tokenization can express registered ownership (named holder) or “book‑entry”-style units, and it can also support a scrip layer for liquidity that converts into registered certificates upon KYC/AML and other conditions.

On MetaLeX specifically:

• Certs (ERC‑721): tokenized stock certificates that encode the issuer, named owner, class/series/units, officer signatures, and transfer legends—i.e., they’re registered instruments, not bearer paper.

• Scrip (ERC‑20): fungible “pre‑securities”/accounting units that can convert back into full certs when conditions are met (e.g., identity checks).

• Programmability: transfers can be gated; dividends/votes can run to the registered holder; conversions/governance are codable.

How issuers already handle “off‑book” paper—and how that maps to electronic certs

Paper today: If someone presents a certificate after a chain of private transfers, the issuer (or its agent) KYCs/AMLs the presenter (W‑9/W‑8BEN, sanctions), checks endorsement chains, may collect affidavits/indemnities, and then registers the transfer(s) on the ledger.

Electronic tomorrow (same playbook, better tooling):

• Risk‑based gates: code enforces transfer restrictions (legends, holding periods, Reg S flow‑back, 12(g) caps); issuer can hold back distributions until the new holder passes checks.

• Identity composition: front‑ends can require named recipients; ZK/attestation rails can reduce friction while improving auditability.

• Real‑time when possible, tolerance when not: front‑ends can push updates to the issuer, but perfection isn’t required—registration upon presentment remains the corporate‑law anchor (see Myth 2).

Where the actual gap is: the UCC’s treatment of disintermediated electronic securities

Article 8 recognizes (i) certificated (tangible) stock, (ii) uncertificated (book‑entry) stock, and (iii) security entitlements via intermediaries. It does not (yet) cleanly recognize a directly‑held, negotiable, electronic “certificate.” The 2022 UCC amendments added Article 12 (CERs), but did not change Article 8’s investment‑securities rules—so the “electronic certificate” category still isn’t first‑class. (American Bar Association)

That’s a commercial‑law fix (how we characterize/perfect priority, etc.), not a corporate‑law requirement for omniscient registers. Meanwhile, issuers can operate using existing models (registered certs, or book‑entry with onchain mirrors) and contract around residual uncertainty, as many do today.

Quick operating checklist for tokenized P2P flows

• Use registered issuance. No bearer form; satisfy certificate content/signature rules (e.g., DGCL § 158 requires two officer signatures on stock certificates). (Justia Law)

• Let transfers happen P2P, then true‑up. Recognize off‑book trades by endorsement (onchain signature), and update the ledger when presented (UCC § 8‑207 + § 8‑301/304). (Delaware Code Online)

• Gate economics and rights. Pay dividends/vote only to the registered holder; hold payouts on newly received tokens until KYC clears.

• Keep compliance composable. Encode transfer legends, Reg D/Reg S timing, sanctions screens, and 12(g) limits as conditions.

• Choose your ledger model. Treat the onchain ledger as (a) the definitive stock ledger (DGCL § 224) administered by/for the issuer, or (b) a mirrored “souvenir” layer anchored to an offchain transfer register—both are viable. (Justia Law)

Bottom line

• True: bearer certificates are prohibited.

• False: that means no P2P trading or that corporate law demands a perfect, real‑time ledger.

• Practical path: issue registered (not‑bearer) electronic certificates, allow P2P transfers with presentment‑on‑true‑up, and program compliance and payouts. The remaining friction is a UCC modernization task—not a show‑stopper for tokenization. (American Bar Association)