Representing Public Equity On-Chain

Posted on:July 27, 2026 at 09:00 AM

If you think representing a share of a public company on-chain is a matter of mapping a key to a value, please step away.

This article discusses registered equity in private and pre-IPO offerings, as well as public markets. The same technical questions often arise, but the legal and operational contexts vary. In private offerings, concepts like accredited-investor eligibility and lock-up periods are significant, while public securities may involve arrangements with issuers, transfer agents, brokers or nominees, and central depositories.

This is an Ethereum/EVM standards map, not a comparison of permissioned or non-EVM market-infrastructure networks.

When we work at the intersection of technology and finance, we get a front-row seat to the clash between “move fast and break things” and “move wrong and face the regulators.” The regulator is watching, and understanding both sides is a real advantage on an equity desk.

Three things to remember

  1. A token becomes legally authoritative only when the relevant legal framework designates its register as authoritative.
  2. A registered security needs enforceable transfer controls, recovery mechanisms, and an accountable administrator; the ERC-20 standard alone does not meet these requirements.
  3. Corporate actions still require a clear process for handling and managing record dates, entitlements, payments, and reconciliatio.

Let us look at the token that most of us already know.

ERC-20 describes a fungible token as a total supply, a balance for each address, and six core functions to move balances and to authorize others to move them on one’s behalf. It also specifies the Transfer and Approval events.

function totalSupply() external view returns (uint256);
function balanceOf(address account) external view returns (uint256);
function transfer(address to, uint256 amount) external returns (bool);
function allowance(address owner, address spender) external view returns (uint256);
function approve(address spender, uint256 amount) external returns (bool);
function transferFrom(address from, address to, uint256 amount) external returns (bool);

A contract that implements these functions and emits the required events for successful transfers and approvals is ERC-20 compliant, and almost every fungible token is one. The interface is small, and for that reason its meaning is easy to pass over. Let’s read transfer: in a plain ERC-20, the holder of a balance may move any part of it to any address, the move takes effect immediately, and no other party is consulted. The balance is the ownership. This is bearer behavior — an asset owned by whoever holds it, transferable by the holder alone.

ERC-20 does not require this. A compliant implementation can restrict transfers, freeze balances, or add a recovery path, and fiat-backed stablecoins already do. What ERC-20 lacks is any standardized way to express those controls — there is no common interface for who may hold, which transfers are allowed, how to reverse an error, or who administers the token. Compliance and recovery live entirely outside the standard, which is why everyone who needs them has had to bolt on their own.

A registered security has the opposite defaults. Ownership is not established by who holds the token; it is established by the issuer’s register. Someone maintains that register, and someone is empowered to change it — to freeze a holding, to reverse an erroneous transfer, to reissue shares to a holder who has lost access — including against the holder’s wishes. None of this is a defect of the traditional system. It is what the law requires, and it is exactly what a plain ERC-20 leaves no standard way to express.

In a private, pre-IPO offering, if Bob tries to send 50 shares of a company like SpaceX to Alice, there are questions. Is Alice an accredited investor? Is she on an OFAC sanctions list? Has Bob’s lock-up period expired? Does this transfer move the company toward a Section 12(g) registration trigger — the holder-of-record thresholds that, together with the asset test, can force it to register with the SEC?

So, the key point: the token is not the asset. The register is the asset. And a token becomes the authoritative register only when the applicable law, the issuer’s governing documents, and the regulated intermediaries around it treat it as one — not because the contract calls itself a register. For U.S. public equity that can mean issuer and transfer-agent records, a central securities depository holding through a nominee, and separate beneficial-owner records. The engineering job is to build the token so the legal framework can designate it the register; the law, not the code, confers the authority.

An architecture

The equity token stack

The equity token stack, base at the bottom. ERC-7943 provides a narrow interoperability waist; the dashed application layer is largely unstandardized.

Read from the bottom up; each layer adds meaning that the layer below cannot express. Base value moves tokens but does not know their legal holders. Identity records who an address is, similar to DNS, and is consulted rather than traversed. Compliance makes transfers conditional on identity, granting the register authority to freeze, force, and reissue tokens, while the interface presents these controls in an asset-agnostic way. The application layer for dividends, votes, and splits is still mostly underdeveloped.

Two layers can act as narrow waists. ERC-20 is a common waist for fungible value: its six functions and two events give compatible wallets and applications a shared way to read balances, move tokens, and track approvals. ERC-721, ERC-1155, and ERC-6909 have their own interfaces. ERC-7943 provides a common interface for regulated value. When an asset and its integrators implement it, the interface can act as a waist, connecting the compliance stacks and asset types below it to the wallets and exchanges above, allowing action on restricted assets without understanding the restrictions. Without such a waist, a regulated asset can be issued but not integrated, which renders it largely useless.

The interface separates the control and data planes. The control plane is the permission logic and compliance that determine whether a transfer is allowed; the data plane handles the movement of balances (transfer, transferFrom, forcedTransfer). ERC-7943 maintains this separation by requiring that the permission views neither revert nor change storage, so a decision can be read without side effects. The rule that restrictions must reside in the contract is the same point in other words: the enforcement point must live on-chain, so clients cannot bypass it, even when policy inputs or administration are off-chain.

How the standards accumulated

Representing equity on-chain means adding the control framework that ERC-20 lacks without breaking token interoperability. Each standard addresses a different regulatory or operational need. To understand the standards, we first need to understand the problems they solve and how to choose between them.

There isn’t one equity standard. Each new one tries to fix what the last one missed or couldn’t get adopted.

Several of these standards rely on ERC-165: it lets a contract declare which interfaces it implements, so wallets and custodians can detect the additional rules a token follows.

Token standards started with fungible tokens like ERC-20 and unique assets like ERC-721, while ERC-1155 supports both. Equity does not fit cleanly into any one of them. Within the same class, shares are fungible, but common, preferred, restricted, and freely tradable shares are not interchangeable.

Equity needs fungibility within each class and clear separation between classes. ERC-1400 handles this through partitions, while ERC-3525 uses semi-fungible tokens. Using a separate ERC-20 contract for every share class may reproduce the balances, but it fails to represent them as parts of one instrument.

Four standards show how the design evolved.

ERC-1400 was the first broad attempt at a security-token framework. It introduced partitions, transfer checks with reason codes, on-chain documents, and controller transfers. It was an influential Polymath and community standard rather than a finalized canonical EIP — its proposal never reached Final — but many of its ideas flowed into the standards that followed.

ERC-1450 takes a more direct approach: a Registered Transfer Agent controls minting, burning, and transfers, and direct transfer and approve are disabled entirely, so a regulated authority always sits in the transfer path. The current Final version includes recovery, freezing, and reason-code patterns.

ERC-3643, also known as T-REX, provides a full compliance framework. It keeps ERC-20 compatibility while adding on-chain identities, trusted claim issuers, modular compliance rules, recovery, freezing, and agent roles. A transfer succeeds only when the identity and compliance checks pass.

ERC-7943, or uRWA, takes the opposite approach. Instead of defining the entire compliance system, it provides a small common interface. Wallets, custodians, and protocols can check whether a transfer is allowed, inspect frozen balances, and support enforcement actions without knowing how the compliance system works underneath. It can sit on top of ERC-20, ERC-721, or ERC-1155. It reached Final status in 2026.

ERC-1400 introduced the main concepts, ERC-1450 centered the transfer agent, ERC-3643 built a complete compliance stack, and ERC-7943 added a common interoperability layer.

What equity requires

For a moment, let’s set the standards aside and look at what public equity needs: issuance, transfer restrictions, compliance, corporate actions, and record dates. Some standards cover parts of this well; others still have no common solution.

Issuance

Issuing shares means minting tokens. Canceling them means burning tokens. The difficult part is keeping the token balances aligned with the legal shareholder register. If the two disagree, the token no longer represents the equity.

This creates two requirements.

  1. Recovery. With a bearer asset, losing the private key means losing the asset. That does not work for registered securities. The legal register still identifies the owner, so an authorized agent needs a lawful way to move the holding to a new wallet. ERC-3643 supports this. Recovery is not a weakness; it is part of representing registered ownership.
  2. Administrative control. Minting, burning, freezing, recovery, and forced transfers are privileged actions, and the contract must define who can perform them. ERC-3643 uses owner and agent roles; ERC-7943 requires access control on its enforcement functions.

These powers should sit behind a multisig and, where practical, a timelock. A single key that can force transfers is an obvious security risk.

Transfer restrictions

Transfer restrictions are the core of regulated equity.

transfer and transferFrom should succeed only when a transfer meets the token’s rules, and fail otherwise. ERC-1400 improved this model by letting the contract explain why a transfer was rejected instead of returning a generic failure.

ERC-7943 turns this into a common interface that wallets, exchanges, and protocols can check before submitting a transfer:

function setFrozenTokens(address, uint256) external returns (bool);
function forcedTransfer(address, address, uint256) external returns (bool);
function canSend(address) external view returns (bool);
function canReceive(address) external view returns (bool);
function canTransfer(address, address, uint256) external view returns (bool);
function getFrozenTokens(address) external view returns (uint256);

The three view functions answer different questions:

This separation matters. An account may be blocked from receiving new shares while still being allowed to sell or return the shares it already holds.

The remaining functions support enforcement. setFrozenTokens freezes part of an account’s holding, getFrozenTokens reports the frozen amount, and forcedTransfer lets an authorized party move tokens for recovery or legal enforcement.

The main rule is that restrictions live in the contract. A rule enforced by a front-end or back-end is not enforced.

Compliance

Restrictions require inputs, and here the input is identity. ERC-3643’s structure is valuable: eligibility becomes a set of signed claims — that an address has passed Know Your Customer (KYC) verification, is an accredited investor, or sits in a permitted jurisdiction — issued by parties the token trusts and checked on every transfer.

ERC-3643 separates this into several components:

One point is easy to miss: institutional holders may use custody contracts or smart-contract wallets rather than externally owned accounts. When one of these holders must authorize a vote or submit an election, the process needs to validate contract signatures rather than assume a private key signed it. The standard for that is ERC-1271, the contract-signature-validation interface. Many smart-contract wallets, including some ERC-4337 accounts, implement ERC-1271 for off-chain signature validation. ERC-4337 itself specifies validateUserOp for UserOperation validation and governs how such accounts transact on-chain.

Corporate actions

One of the largest gaps is that no standard normatively defines dividends, voting, mergers, tender offers, elections, and buybacks as one complete system. The registry has a standard for NFT emote reactions; it has none that mandates how to pay a dividend. (ERC-1450 sketches these as non-normative patterns — guidance, not a required interface.)

The one active proposal aimed squarely at the presentation problem is ERC-8056, a draft that addresses one thing: reflecting stock splits and reverse splits while raw balances and total supply stay fixed. It uses a multiplier to change the holder’s effective balance without rewriting every raw balance or changing the underlying total supply.

It is a good solution to one problem, but a narrow one: it is a display-layer multiplier, not a corporate-actions system. Making a split’s displayed number correct is very different from modeling the event, which a register must do:

Voting, mergers, tender offers, elections, and buybacks have no dedicated standard. For those, developers still build a custom pipeline from snapshot to entitlement to distribution.

This also distinguishes two things both called tokenized stock. Some widely marketed products described as tokenized stock are synthetic: the holder has a contractual or beneficial claim rather than being entered as a shareholder, dividends may be paid off-chain by an intermediary, and voting rights may not pass through. Representing public equity, where the token is the register and a dividend is an enforceable obligation to the holder of record, is the harder problem, and the one the standards above are reaching for. The existence of the synthetic products should not be read as evidence that the harder problem is solved.

It helps to view a dividend as a sequence, since the pipeline is the same each time. The issuer declares the dividend and establishes a record date at a specific block or time, referred to as T. At T, the contract takes an authoritative snapshot of balances and creates a checkpoint keyed to T, recorded by the register. For each holder, an entitlement is calculated from that snapshot: the balance at T multiplied by the dividend rate. Identity claims may support eligibility checks, but tax residence, beneficial-owner and intermediary status, treaty documentation, withholding calculations, remittance, and reporting are jurisdiction-specific operational processes that normally remain off-chain. The resulting payment asset is then distributed to the holders of record, and events are emitted so indexers can account for the distribution. Any transfer that arrives after T does not affect legal entitlement; ownership is fixed at the snapshot. Each step is a contract call or an emitted event, and the accuracy of the whole depends on the first: the record time T must be authoritatively designated, and the balances at T read from an auditable source. A finalized block’s historical state is deterministic, so reading it later is not itself a risk — the fragility is in ad-hoc off-chain reconstruction that can drift from the authoritative record.

Record dates

Accurate entitlements on-chain rest on the balance at the record date rather than the holder’s current balance, which means designating a record block or time and reading balances as of it. Earlier implementations used ERC-20 snapshot extensions; more recent systems often use balance checkpoints of the kind governance tokens use. CMTAT, for instance, offers an optional snapshot module and an experimental income vault that distributes based on recorded balances. Because a finalized block’s state is deterministic, the balances as of the record block are fixed and auditable; what matters is that the record point is authoritatively designated and the accounting is auditable — preferably built into the token or a trusted registry rather than reconstructed after the fact by an external application.

Choosing a standard

When deciding how to represent an equity requirement on-chain, work through these questions in order. Earlier questions constrain the answers to later ones, so a later preference cannot override an earlier constraint.

  1. Is the token a legal register or a synthetic mirror? This affects everything that follows. A synthetic product is an ERC-20 token with a price oracle and an off-chain broker, and ERC-8056 can present split and reverse-split adjustments without changing raw balances. A legal register continues down this list.
  2. Is institutional interoperability needed now? If the instrument must transact with custodians, agents, and other institutions that already support ERC-3643, build on ERC-3643. Prioritize the standard that your actual counterparties and jurisdiction support over theoretical elegance.
  3. Must external systems check permissions without understanding the compliance logic? If so, consider implementing ERC-7943 on top, and verify that relevant systems support it. Wallets, exchanges, and protocols can then integrate against one interface rather than a bespoke set of rules. An asset external systems cannot safely access will be difficult to custody or trade.
  4. Are there multiple share classes in one instrument? Partitions from the ERC-1400 line or the semi-fungibility of ERC-3525 model them as a single instrument. Separate ERC-20 contracts can also work if an aggregate cap-table registry ties them together; the thing to avoid is uncoordinated per-class tokens with no unifying record.
  5. Do holders need to approve token movements without sending a transaction? Add ERC-2612 permit, so a holder signs an allowance off-chain (a relayer still pays the gas to submit it). Note the scope: ERC-2612 authorizes token spending, not votes or corporate-action elections — for those, collect off-chain signatures and validate them on submission, via ERC-1271 for contract holders.
  6. Is it a corporate action or a record date? No standard covers this normatively. Build a pipeline for snapshotting, entitlements, and distributions. If you only need to present a split or reverse split, ERC-8056’s multiplier handles that and no more.
  7. Must the instrument withstand a decade of regulatory change? Then plan for change — but upgradeability is a tradeoff, not a mandate. If you upgrade in place, use a proxy pattern (Transparent or UUPS, both of which rely on the ERC-1967 storage-slot convention) or a Diamond (ERC-2535); note that ERC-1167 minimal proxies are immutable clones and are not an upgrade mechanism. Immutable contracts plus governed configuration or a planned migration can be preferable, since an upgrade key is itself a standing risk. Whatever you choose, govern that key as carefully as the key that authorizes transfers.

Some rules

  1. Prefer existing standards. Choose the standard supported by your actual counterparties over one with better specifications. ERC-3643 is a full compliance framework; use it where it fits the jurisdiction and integrations you need.
  2. Understand adoption status. “Final” does not mean adopted, and “adopted” is not necessarily final. The most widely used security-token design was never a finalized standard; a finalized standard has value only if various stacks implement it. Judge a standard by who builds on it.
  3. Implement restrictions in contracts. Restrictions should live in the contract itself, not only in the interface. A rule that exists only off-chain is not a true rule.
  4. Model events, not balances. A dividend is a record date, an entitlement, a withholding, and a payment — not just a number that goes up.
  5. Prevent key loss from becoming share loss. Registered securities need a lawful recovery path, so that losing a key does not mean losing a share.
  6. Protect administrative keys. Treat the administrative keys as though they were the asset, and guard them accordingly.
  7. Prioritize interoperability. Treat interoperability as a deployment requirement, not a convenience. An asset external systems cannot read and evaluate will be difficult to custody, trade, or settle.

Conclusion

The registry contains hundreds of standards, many irrelevant to equity and several that overlap. One interface was only recently finalized, and there is still a gap around corporate actions. The goal of an equity standard is not to choose the most innovative option but to understand clearly which property of a plain ERC-20 each standard restores — the authority to restrict, freeze, reverse, or reissue, none of which ERC-20 standardizes — and to be honest about the areas where no standard yet exists. Familiarity with ERC-20 is common; for a registered security, it is the starting point, and, until the differences are understood, it poses a possible risk.

Sources and status as of now

This is a technical explainer, not legal advice. The legal effect of a token depends on the issuer’s jurisdiction, governing documents, offering terms, custody arrangement, and applicable regulation.