The emergence of programmable capital may be more important than tokenization itself.

On September 17, the SEC gave builders of onchain securities markets something concrete to work with: a conditional exemption allowing certain venues to trade tokenized U.S. stocks through automated market makers and liquidity pools.

I have spent years thinking about what happens after a security becomes a token. The ownership record is one piece. The harder work is connecting that record to the rules governing who can buy it, how it trades, what it pays and how it settles.

That is the work I call programmable capital. It runs through the companies we are building and the book I am writing about programmable capital markets. The SEC’s action creates room to test part of that architecture in public equities, under defined conditions.

A token can represent ownership. Programmable infrastructure can help carry out the agreement behind it.

What the SEC actually opened

The Innovation Exemption grants temporary relief from the Exchange Act’s definition of an exchange to qualifying Tokenized Securities Venues, or TSVs. It also provides conditional relief from the definition of a dealer to certain liquidity providers. The exemptions are set to expire five years after publication.

The SEC has placed boundaries around the experiment. The framework covers qualifying tokenized National Market System stocks, with limits on the number of symbols and trading volume. Holders must retain the rights and privileges of the equivalent traditional shares. Venues must observe trading stoppages on the primary listing exchange, and their smart contracts must be public and auditable.

The SEC’s fact sheet also distinguishes these securities from tokens that merely provide synthetic exposure to a stock. A TSV planning to trade shares tokenized by an unaffiliated third party must give the underlying issuer notice and an opportunity to object.

Those conditions define a specific opening for market infrastructure. They do not confer approval on any of the companies or technologies discussed here.

What interests me is the permissioned use of automated market makers. Software and pooled capital can become part of the mechanism through which eligible participants trade securities. Builders now have a defined setting in which to test how that mechanism performs alongside shareholder rights, issuer involvement and market controls.

The agreement can become part of the infrastructure

Financial records have been digital for decades. Moving a record to a blockchain is useful only to the extent that it improves what companies, investors and market operators can do with it.

Consider the life of a security. An investor’s eligibility must be checked. Transfers may be restricted. A distribution must reach the correct holder. A conversion provision may become effective when a specified event occurs. Each step depends on knowing who owns the security, what the governing documents require and which actions are permitted.

Programmable infrastructure offers a way to connect those steps. A transfer workflow can check an eligibility record before allowing ownership to change. A distribution process can use the ownership record and the agreed payment terms. A conversion event can trigger the next stage of the security’s lifecycle once the required conditions have been established.

The legal agreement still governs. Someone still has to verify the inputs, resolve exceptions and remain accountable when something goes wrong. Code cannot decide an ambiguous contractual question merely because the contract has been tokenized.

I see the opportunity in reducing the distance between the agreement and its administration. More of the routine work can follow the same rules and use the same records, instead of requiring each participant to reconstruct the transaction in a separate system.

That changes the design brief for financial infrastructure. Issuance, ownership, compliance and corporate actions need to work together throughout the life of the security. A convenient trading interface is only one part of the job.

Settlement and liquidity have to work together

Execution and settlement have traditionally been separate events, with institutions managing records and obligations between them. Bringing the exchange of an asset and its payment closer together can reduce some of those dependencies.

Atomic settlement takes that idea further: the asset and payment exchange are linked so that both complete together, or neither completes. Whether a particular system achieves that outcome depends on its design, the assets involved and the legal treatment of the transfer.

A market also needs available capital, dependable custody and participants willing to provide liquidity. Faster settlement alone cannot supply those things. An automated market maker still needs capital in its pool and a pricing mechanism that works under the conditions it encounters.

This is why I think about liquidity, clearing, custody and settlement as connected design problems. The SEC’s framework gives builders room to examine some of those relationships in practice. The useful evidence will come from how venues operate: whether investors can trade reliably, whether ownership remains clear and whether the controls work when market conditions become difficult.

Bitcoin belongs in this infrastructure discussion as well. I am interested in the work being done around Bitcoin and Lightning because it asks how an established network can support more financial activity.

In our ecosystem, Orobit is the protocol and developer tool layer. Its documented architecture separates contract execution from Bitcoin: SCL software performs the calculations, while Bitcoin anchors commitments and establishes their order. Lightning provides a route for payments and asset movement within that design.

Those distinctions shape what we are exploring. Connecting a programmable security to payment infrastructure requires clear answers about where execution occurs, which record establishes ownership and when a transaction becomes final. Calling the whole system “Bitcoin infrastructure” should never obscure those responsibilities.

Capital formation is part of the same problem

The SEC’s action concerns qualifying public stocks. My broader thesis also includes private capital, where a company’s financing terms can be closely tied to the economics of its business.

One structure we have been developing is a Revenue Participation Convertible Security Token, or RPCST. Conceptually, it combines contractual participation in company revenue with predetermined provisions for conversion into equity.

Its usefulness would depend on the terms. What revenue counts? How is it verified? When are distributions due? What triggers conversion? Which investors are eligible, and what restrictions apply to a transfer?

Programmable infrastructure can help administer those terms once they are properly defined. Revenue participation, conversion provisions and ownership records can become connected parts of the same security lifecycle. The structure still requires appropriate documentation, reporting and compliance with applicable securities law. The public stock exemption does not resolve those separate requirements.

For an entrepreneur, the appeal is practical. A financing arrangement should fit the business raising the capital. Better administration can make a carefully designed structure more workable for both the company and its investors.

This is also where much of our work at SQRL comes together. We have organized the business around payments, enterprise infrastructure and markets because a company raising capital eventually needs to connect all three.

Within SQRL Markets, we are developing Token Clear around tokenization, compliance, security lifecycle management and corporate actions. We are also exploring clearing and custody infrastructure that could serve multiple clients across traditional securities and digital assets. Orobit provides the protocol work underneath the broader strategy; SQRL is the commercial and institutional implementation layer.

These are development efforts with their own technical, commercial and regulatory requirements. My objective is to make the pieces work as a system, so an issuer’s financing terms can remain connected to ownership, distributions and subsequent market activity.

Identity belongs in the design

There is a more immediate problem with any system that expects people to move financial assets: they need to know whom they are dealing with and where the assets are going.

Long wallet addresses place too much of that burden on the user. Domain names made the internet easier to navigate by giving people a readable way to reach an address. Digital finance needs a similarly usable experience, backed by the identity and access controls appropriate to the transaction.

That is part of our interest in True I/O’s work around the Universal Communications Identifier, or UCID, and BTC Names. A readable financial identity can make the interface easier to use. The underlying system must still establish the relationship between that identity, the recipient and the permissions required to receive an asset.

For securities, that connection reaches beyond convenience. Investor eligibility and transfer restrictions depend on reliable identity information. If a security’s rules are programmable but the identity records are disconnected, the workflow breaks at the point where it needs to make a decision.

I want sending an asset to feel as intuitive as sending an email. Getting there requires considerable work beneath the interface, particularly when the asset carries legal rights and restrictions.

What I want to see built

Working through these questions became the foundation of my forthcoming book on programmable capital markets. The same issues kept appearing across securities offerings, payments, Bitcoin infrastructure and digital identity. Each project depended on another part of the financial system working well enough to support it.

That experience has made me more interested in integration than in the number of assets issued on a blockchain. I want to see whether an issuer can administer a security more accurately, whether an investor can understand and exercise the rights attached to it, and whether market participants can move between payment and ownership records with fewer reconciliation problems.

Established financial institutions have substantial roles in that work. Custody, price discovery, investor protection and risk management remain necessary. Programmable infrastructure gives those institutions new ways to perform some of their functions and creates room for new operators to prove their value.

The five year exemption gives builders a period in which to gather operating evidence. It also gives regulators a chance to examine how these venues behave before deciding on a more durable framework.

For our own work, the test is concrete. Can we connect the terms of a security to its ownership record, permitted transfers, payments and corporate actions in a system that institutions can use and investors can trust? That is where I intend to spend the opportunity the SEC has opened.

The views expressed here are my own and are provided for informational purposes only. Nothing in this article constitutes an offer to sell or solicitation to purchase any security, investment advice, legal advice, or a representation that any company, platform or technology discussed has received regulatory approval. Any securities, market infrastructure or financial activities described would remain subject to applicable laws, regulations and required approvals.

‍