The unglamorous rebuilding of equity markets, in code

Permissionless liquidity is the founding promise of decentralised finance. For securities subject to fifty years of disclosure, accreditation and settlement law, that promise is the architectural problem to solve, not the destination.

On 28 May 2024, after almost a decade of industry consultation, the United States cut its standard equity settlement cycle from two business days to one. The change was technical, almost invisible to retail investors, and yet it cost market participants in the high hundreds of millions of dollars to implement. Banks rewired their treasury operations. Custodians rebuilt overnight batch jobs. Buy-side firms hired weekend coverage. The Depository Trust & Clearing Corporation rehearsed the cutover for two years and still spent the night before live.

The detail matters because it tells you what an equity market actually is. Not the brokerage app on a phone, not the ticker tape, not even the matching engine, but the dense layer of legal obligations, settlement guarantees, holder records and regulatory reports that sits underneath every trade. That layer is what allows an equity share to be a legally enforceable claim on a fraction of a company, deliverable on a known date, traceable to a real human or institution, taxable in a known jurisdiction, and revocable when the law says it should be.

In the language of capital markets infrastructure, this is plumbing. It is unglamorous, expensive, and almost invisible until it fails. It is also, as a generation of crypto-native builders has belatedly discovered, the part of equity markets that does not transplant cleanly into a smart contract.

The result is a quiet architectural reckoning across the small but serious community of teams now building tokenised-equity infrastructure. The first generation of security-token offerings, beginning around 2018 with platforms such as Polymath, Securitize and tZERO, focused almost entirely on issuance. The second generation, now under construction, is forced to reckon with what happens after issuance: how shares trade, settle, distribute dividends, accept votes, and stay legally distinct from the wallet they happen to be sitting in. The answers, where they are credible, look strikingly little like decentralised finance. They look like exchanges.

This article sets out the design principles that the second generation appears to be converging on, and the reasoning behind each. It is not a survey of vendors or a product comparison. The interesting question is what the constraints of regulated equity force any builder to choose, regardless of brand.

The matching-engine question

Begin with the most visible architectural choice: how does a buyer find a seller?

Decentralised finance has produced two answers. The dominant one is the automated market maker, or AMM, exemplified by Uniswap, Curve and their many forks. Liquidity is supplied by passive providers who deposit pairs of tokens into a pool; prices emerge from a deterministic curve over the pool's reserves. Anyone can provide liquidity and anyone can take it. Around $100bn of crypto trading volume now flows through AMM-style pools each month.

The second is the on-chain order book, used by venues such as dYdX (in its first incarnation) and a long tail of derivatives protocols. Buyers and sellers post limit orders; a matching engine pairs them by price-time priority. This is the model every traditional stock exchange has used for several decades.

For tokenised equity, the AMM model is structurally incompatible with the legal wrapper around the asset.

The reasons are worth setting out in some detail because they recur across every adjacent design question.

1. Identity

An equity issued under United States Regulation D, Regulation S, or Rule 144A imposes obligations on every person or institution that holds the share: minimum accreditation thresholds, residency restrictions, beneficial-ownership disclosure above 5 per cent, restrictions on resale within a specified holding period. An AMM liquidity provider receiving LP tokens that represent a fractional claim on a pool of shares is, in legal substance, a holder of those shares. The pool's smart contract cannot perform an accreditation check on an anonymous depositor, and there is no plausible reading of existing securities law in which a deposit constitutes a registered transfer of beneficial ownership to a counterparty whose identity is unknown to the issuer.

This is not a defect that can be fixed by adding a know-your-customer screen at the LP onboarding stage. The pool itself, as a continuous trading venue, transforms the LP's claim every time a swap happens; the LP is, in effect, holding a constantly rebalancing book of equity inventory that includes positions taken from counterparties they have never approved. The legal wrapper of an equity does not bend to algorithmic rebalancing.

2. Price formation

An AMM prices trades by reference to its own reserve ratios, not to any external fact about the security. For a token whose value is fundamentally exogenous, set by news, earnings, dividends, corporate actions, peer multiples, the curve will diverge from fair value the moment information arrives. Arbitrageurs are the mechanism that, in conventional crypto markets, drag pool prices back toward external markets. In a regulated equity, every arbitrage trade requires a compliance check on both counterparties, in two jurisdictions, against current accreditation status, lock-up timers and ownership caps. The arbitrage is slow when it should be fast, and prices stale when staleness is a regulatory concern.

3. Settlement and disclosure

An AMM pool is the holder of record. When the issuer pays a dividend, the legal entity owes the cash to whoever held the share at the record date, not to whoever was a liquidity provider in the pool at that moment, on a curve. Pro-rating dividends across LPs is technically possible and economically incoherent. The same applies to votes: shareholder voting rights belong to the shareholder of record, not to a synthetic claim on a fluctuating slice of inventory.

4. Best execution

American Securities and Exchange Commission Rules 605 and 606, and the European MiFID II RTS 27 and 28 regimes, both presume an order-driven market. Their disclosure templates are full of fields that simply do not exist in an AMM: order type, capacity (principal versus agent versus riskless principal), execution time stamped to the millisecond, price improvement against the national best bid and offer. A venue that cannot populate these fields cannot demonstrate best execution to its regulators, and a venue that cannot demonstrate best execution cannot legally operate as a regulated marketplace in the United States or the European Union.

The cumulative weight of these objections has driven serious tokenised-equity builders towards the central limit order book model, often combined with periodic batch auctions at session boundaries. This is the same model that NYSE, Nasdaq, the London Stock Exchange and Euronext have used since their last major upgrades. It is not a coincidence; it is what working with regulated equity forces.

The on-chain implementation of a CLOB is itself a design question. Pure-on-chain order books, where every limit order rests in contract storage and the matching engine traverses the queue at consensus speed, are gas-prohibitive for any venue that wants institutional throughput. The pragmatic compromise, emerging across credible second-generation platforms, is to keep the placement of orders on-chain, where every event is publicly auditable, but to perform the traversal of the price-time queue off-chain in a memory-resident matching engine. Crosses are submitted back on-chain, where the smart contract validates that each cross respects every side's limit, the security's tick and lot constraints, the venue's halt status, and the per-trade compliance gate before it creates a settlement instruction.

This is, in effect, the same separation of concerns that allows the New York Stock Exchange to match orders in microseconds and settle them through the DTCC two days later. What changes in the smart-contract version is that the settlement layer becomes programmable, the audit trail becomes a public event log, and the compliance check moves from being a periodic batch reconciliation to a per-trade revert.

The settlement question

If matching is the surface, settlement is the structure. It is also the part of equity-market design where conventional crypto wisdom is most clearly wrong.

Crypto-native builders tend to assume that atomicity, both legs of a trade settling in the same transaction, is the obvious goal. It is not the goal of major equity markets. The Bank for International Settlements, in its long-standing typology, distinguishes three models of delivery-versus-payment: Model 1 (gross simultaneous), Model 2 (gross securities, net cash), and Model 3 (net securities, net cash). Different markets have chosen different models for different reasons: Model 1 is the strongest guarantee but is gas-intensive and forecloses netting; Model 3 is the most capital-efficient but requires a central counterparty to absorb the risk between matching and settlement.

The American post-trade infrastructure, run by the National Securities Clearing Corporation and DTC, is closest to Model 3 in equities and Model 1 in fixed income. The May 2024 transition to T+1 did not change the model; it shortened the window during which the central counterparty bears settlement risk. The reason the industry resisted T+0, even though many observers, including the SEC commissioners, would have preferred it in principle, is that T+0 is incompatible with the netting that allows the system to settle the equivalent of $50 trillion in annual notional with a fraction of a per cent in actual capital movement.

Settlement cadence is a market-microstructure choice, not a technological default.

The right answer for an early-stage private placement may be T+0 atomic. The right answer for a tokenised version of an S&P 500 constituent, post-2024, is T+1. The right answer for a European corporate bond is T+2. The right answer for an exchange-traded fund operating in seven jurisdictions may be all three, depending on the leg.

The architectural implication is that the settlement layer cannot hardcode a single value-date offset. Each security needs to carry its own settlement profile, and the engine that processes settlement instructions needs to enforce it: not before the value date, not without the cash leg if the trade is delivery-versus-payment, not with the cash leg if it is free-of-payment, not at all if the buyer's reservation has been cancelled.

This is also where one of the most common bugs in first-generation security-token contracts surfaces. A naïve implementation treats settlement as a single function: receive a trade, debit the seller's tokens, credit the buyer's tokens, transfer the cash, emit an event. This works when everything works. It catastrophically fails when something does not. If the trade fails on the cash leg, the buyer's stablecoin custodian was paused, the bridge has been delayed, the wallet was compromised between matching and settlement, the seller's tokens have been moved but the cash has not. There is no clean rollback in a smart contract. There is no clearing house to take the loss.

The robust answer, drawn directly from the post-trade plumbing of legacy equity markets, is to model settlement as a state machine with explicit transitions. A trade creates an instruction in a CREATED state. Funding the cash side moves it to FUNDED. Successful execution at value date moves it to SETTLED. Failure at value date moves it to FAILED and starts a buy-in window, typically three business days in conventional markets, during which the venue's settlement service may attempt to source replacement shares in the open market and force-allocate them to the seller's account. After the window, if the trade is still unresolved, it moves to CANCELLED, and the buyer's reserved cash is unwound back to their account.

This is the kind of detail that separates a serious infrastructure protocol from a demo. It is also the kind of detail that has no analogue in the AMM world, because in an AMM there is no separate settlement step at all: the swap is the trade is the settlement. The cost of that simplicity is that AMMs cannot serve any market where the settlement guarantee needs to be conditional on conditions that are not yet observable at trade time. Equities, with their record dates, ex-dividend dates, lock-up timers, and corporate-action lifecycles, are precisely such a market.

The compliance question

The matching and settlement questions are about how the market moves. The compliance question is about who is allowed to be in the market at all, and under what conditions.

Anyone who has spent time inside a transfer agent's compliance team knows that the apparent simplicity of "is this transfer allowed?" hides a tangled tree of conditional rules. Is the security listed? Is the wrapper still active? Is the seller a known investor? Is the buyer? Is the buyer accredited at the right tier, Reg D's general accredited threshold, or Rule 144A's qualified institutional buyer threshold? Has the lock-up period expired, and if so, by how much, given that the lock-up tier (six months, twelve months, twenty-four months) is set by the security's offering exemption? Is the buyer's jurisdiction on the security's restricted list under Regulation S? Would the trade push the buyer over the issuer's per-holder cap? Would it admit a new holder past the issuer's holder-count limit? Would it push aggregate foreign ownership over the issuer's CFIUS-driven cap?

A compliance team handling this through email and spreadsheets, as many private-securities transfer agents still do, takes hours or days per transfer. A compliance team handling it through a smart-contract validator, if the validator is well-designed, takes a single block.

Compliance must be a single deterministic validator with explicit ordered precedence.

Every state-changing path on the equity ledger, transfer, agent transfer, mint, burn, bridge lock, bridge mint, calls the same validator with the same arguments. The validator returns a single result code. Zero is a pass; non-zero is a precise failure reason.

The ordering matters more than it appears. If a transfer fails for two reasons simultaneously, the buyer is sanctioned and the lock-up has not yet expired, which one does the validator surface? The answer cannot be "both" if the contract is to be deterministic; it cannot be "whichever is checked first" if the order is implementation-defined. It must be a fixed, documented, and tested precedence that the compliance team and the regulator can both reproduce off-chain.

The precedence itself is not arbitrary. The most basic checks come first: is the amount non-zero, is the venue paused, is the security halted? The legal-wrapper checks come next: is the security listed, is the wrapper active? Then the per-side investor checks: is each side a known investor, is either side flagged as sanctioned or insider? Then the per-side restricted-list checks for trading windows and pre-clearance tickets. Then the per-policy tier and lock-up checks. Then, last, the aggregate caps: per-holder, holder-count, foreign-ownership.

This ordering is not just a design preference. It is what allows the venue's compliance team to run a parallel off-chain validator and reconcile against the on-chain result on every transfer. If the on-chain validator says the trade was rejected for the buyer's accreditation tier, but the off-chain shadow validator says it should have been rejected first for the seller's lock-up, the two have diverged and the team has a real problem to investigate. If the codes are arbitrary, no such reconciliation is possible.

Similar logic applies to the relationship between the validator and the restricted list. The European Market Abuse Regulation, MAR, requires issuers to maintain insider lists and trading windows; the United States imposes equivalent obligations through Section 16 reporting and the company's own Section 10b5-1 compliance regime. A robust on-chain implementation models these as a separate orbital with its own state, the list of restricted accounts per security, the current trading window, the queue of pre-clearance tickets, and exposes them to the main compliance validator as a single check. When a corporate-actions team wants to open a trading window for the holders subject to a quiet period, they update the window in the orbital; the validator does the rest.

What this looks like, from the perspective of an institutional holder, is that they place an order; the order is validated at place time and again at match time; the rejection (when it comes) cites a specific code; their compliance team reads the code, fixes the underlying issue, refreshes accreditation, files a beneficial-ownership disclosure, requests pre-clearance, and the next order succeeds. This is not the experience of using DeFi. It is, deliberately, the experience of using a regulated brokerage account that happens to settle on a public ledger.

The bridge question

Tokenised equity will, in any realistic deployment, span more than one chain. Issuance often happens on a permissioned or semi-permissioned chain, where the issuer can run a heavyweight know-your-customer pipeline before any token is minted. Secondary trading often wants to happen on a public chain, where the liquidity is. Some venues are entirely on a single chain, but the multi-chain case is the case that exposes the architectural choices most clearly.

The crypto-native answer to multi-chain is the bridge, and the past five years have produced a long catalogue of bridge failures, from the Ronin hack of March 2022 (around $625m in losses) to the Wormhole exploit of February 2022 ($325m), to a steady drumbeat of smaller incidents at less visible bridges. The common thread in the worst failures is over-reliance on multisig validators with concentrated key custody.

For tokenised-equity infrastructure, the trust model can be tighter than for general-purpose bridges, because the legal wrapper around the asset usually means the same legal entity governs both chains. The same issuer issues on chain A and operates the trading venue on chain B; the same operator runs the bridge attestor on both sides. This does not justify weak cryptography, but it does mean that a trusted-remote registry, in which the venue operator explicitly registers each peer chain's canonical address and authorises a small, audited set of attestors to relay messages between them, is a defensible architecture. It is not the only architecture, light-client bridges, where the destination chain runs a state-proof verifier of the source chain, are strictly more trust-minimised, but it is the architecture that fits the institutional case.

The detail that matters more than the trust model is supply parity. A lock-and-mint bridge has a simple invariant: across all peer chains, the total amount of a security locked on outgoing bridges must equal the total minted on incoming bridges. If the invariant breaks, the global supply of the token has diverged from the issuer's authorised supply, and the issuer has a regulatory problem. Robust implementations expose two accumulators per security per chain, locked outbound, minted inbound, that any party can read and reconcile. Drift in the reconciliation is the first signal of a deeper problem: a stuck inbound message, a replay attempt, a source-chain reorganisation that was not handled correctly.

The same robustness principle applies to the per-day flow limit that most institutional bridges impose. A surprisingly common bug, observed in more than one production deployment, is a daily limit that increments use-counters but never resets them, silently turning the daily cap into a lifetime cap. The fix is mechanical: a UTC day-id that rolls over on first access of a new day, lazily zeroing the use counter. The fact that it is mechanical does not mean it is universal; the bug has appeared often enough to be worth flagging in any architectural review.

The pattern

Step back from the specifics and a pattern is visible across all four questions. Each design choice, taken seriously, ends up looking less like decentralised finance and more like programmable traditional finance.

1. Matching

A central limit order book: placement on-chain, traversal off-chain, crosses settled by the smart contract.

2. Settlement

A delivery-versus-payment state machine with explicit fail handling and a buy-in window.

3. Compliance

A deterministic ordered validator that any auditor can replay.

4. Cross-chain

A trusted-remote bridge with explicit supply-parity accumulators.

There is nothing in this list that the New York Stock Exchange, the DTCC, the European Securities and Markets Authority, or the Financial Industry Regulatory Authority would find unfamiliar in concept. The novelty is that the implementation is in code, the audit trail is a public event log, the upgrades are governed by an on-chain ceremony rather than a committee meeting, and the participants can be cryptographic identities rather than only legal ones.

That is the genuine contribution of the second generation of tokenised-equity builders. It is not that they have invented a new market structure. It is that they have made the existing market structure programmable, auditable, and composable across institutional boundaries, while preserving the legal wrapper that makes the asset class regulable in the first place.

The plumbing made visible

The first generation of crypto markets bet that legal infrastructure could be replaced. The bet has not paid out, at least not for assets where the legal wrapper carries actual value. Equity, of all financial assets, is the one most thickly wrapped in law, and the cleanest test case for what a legally compatible programmable market actually has to look like.

The honest answer, after a decade of iteration, is that it has to look quite a lot like the markets we already have, only with the plumbing visible, the rules deterministic, and the upgrades on-chain. The achievement is not the destruction of the old system. It is the rebuilding of the old system on terms a regulator, an issuer and an investor can each verify for themselves.

That is unglamorous.

It is also, as the work of the past few years has begun to demonstrate, the part of the project that is actually working.