SEC Innovation Exemption: The Token Layer It Left Open

The problem: an open chain, a closed pool, and no set place for the gate

IN SHORT Where the gate sits decides what a venue can still enforce once a token leaves the pool.

Under conditions, the SEC (the US Securities and Exchange Commission) now lets tokenized NMS stock (shares listed in the US; NMS stands for National Market System) trade on a public blockchain. The trades happen in pools that only approved wallets can use.

The order describes two places the check can live, in the pool or in the token, and mandates neither.

That’s where someone who helped write a token standard can add something. So I read the order from that angle.

Words to know before reading the order

IN SHORT An open chain with a gated pool works like a members-only room inside a public building.

What the SEC granted on 17 September

IN SHORT Release No. 34-106402 gives two exemptions, each for five years and each under conditions.

The first is for a Tokenized Securities VenueTokenized Securities Venue (TSV) A trading venue that runs pools for tokenized NMS stock and sets the standards for who may trade there. See the glossary (TSV) that runs AMM liquidity poolsAMM liquidity pool AMM means automated market maker: smart contracts that hold two assets, here a stablecoin and a stock token, and set the price by a formula. See the glossary for tokenized NMS stockTokenized NMS stock Roughly, a share listed on a US stock exchange (NMS: National Market System), turned into a blockchain token by its issuer or by an unaffiliated third party. See the glossary. It exempts the venue from the legal definition of an “exchange”.

The second exempts some liquidity providers in those pools from the definition of a “dealer”. The table lists the main conditions.

Permissioned trading on a permissionless chain

IN SHORT The chain must stay open to everyone, while trading on the venue is restricted.

A TSV’s smart contracts “must be auditable, public, and deployed on a public, permissionless distributed ledger”. That’s a permissionless blockchainPermissionless blockchain A public blockchain that, generally, anyone can read or write to without asking for authorization. See the glossary, which the order says “generally means that anyone can read or write to the distributed ledger without authorization.”

Footnote 55 then adds: “A permissioned AMM Liquidity Pool can be deployed on ‘permissionless’ blockchain.”

The order then gives two ways to build the gate. A pool “may be encoded with criteria or a list of persons” so only allow-listed wallets trade.

“Alternatively, a Tokenized NMS Stock could be encoded with criteria to only allow transfers” to the wallets of people who meet the venue’s rules. One check sits in the venue, the other in the asset.

So a public chain was a design question before it was a regulatory one. I covered that tradeoff in when RWA (real-world asset) tokenization needs its own chain.

Describe the access procedure; no implementation is mandated

IN SHORT The order asks the venue to describe how it grants access, not to use a given mechanism.

Item (f) of the required notice is the closest the order gets to an access spec. It asks for the criteria and “the procedures for approving access (e.g., white-listing or permissioning)”.

It also asks when the venue refuses or limits access. Sanctions from OFAC (the US Treasury’s Office of Foreign Assets Control) and AML/CFT rules (anti-money laundering and countering the financing of terrorism) are among the reasons.

If another firm runs the checks for the venue, the order says the TSV is still responsible. The procedure stays the venue’s, whatever code or vendor runs it.

Pool layer vs token layer: OKXICE next to ERC-3643

IN SHORT OKXICE checks a badge in the pool on every trade; ERC-3643 checks the receiver inside the token on every ordinary transfer.

OKXICE TSV published its public notice on 4 October. Its operator, OKXICE LLC, is a joint venture between Intercontinental Exchange Holdings and OKC USA Holding. I use it because it’s concrete, not as an endorsement.

Its own disclaimer says the SEC “has not passed upon the merits or accuracy of the disclosures”. Its pools are Uniswap v4 pools on X Layer, a public blockchain. An add-on contract, the “OKXICE TSV Hook”, enforces who may use them.

Only wallets holding a valid soulbound tokenSoulbound token (SBT) A token that can’t be transferred and stays in one wallet. A venue can issue one as a badge: this wallet passed our checks. See the glossary (SBT) from the venue may trade or add liquidity. That’s the pool layerPool layer Putting the access check in the trading pool: only approved wallets can trade there. Transfers outside the pool never reach that check. See the glossary. The steps below follow the notice.

ERC-3643 puts the same kind of check inside the token: the token layerToken layer Putting the access check in the token contract itself, so an ordinary transfer fails unless the receiver is eligible, wherever it happens. See the glossary. A normal transfer or transferFrom fails unless two things hold. The receiver is verified in the Identity Registry (isVerified), and the compliance contract says yes (canTransfer).

It also fails if either wallet is frozen or the token is paused. In ERC-3643, an agent is an address the token owner appoints to run operations such as mint (creating new tokens), freeze or recovery. Those privileged agent operations follow other rules, shown in the box below.

function transfer(address _to, uint256 _amount) public override whenNotPaused returns (bool) {
    require(!_frozen[_to] && !_frozen[msg.sender], "ERC-3643: Frozen wallet");
    require(_amount <= balanceOf(msg.sender) - (_frozenTokens[msg.sender]), "ERC-3643: Insufficient Balance");
    require( _tokenIdentityRegistry.isVerified(to), "ERC-3643: Invalid identity" );
    require( _tokenCompliance.canTransfer(from, to, amount), "ERC-3643: Compliance failure" );
    _transfer(msg.sender, _to, _amount);
    _tokenCompliance.transferred(msg.sender, _to, _amount);
    return true;
}

What happens when a token leaves the pool

IN SHORT A pool check never sees a token that moves from one wallet to another outside the pool.

The order itself limits the exemption to “activity performed through the functionalities and systems provided by a TSV”. A plain wallet-to-wallet transfer isn’t a trade in the pool.

The OKXICE notice also says the stock can trade elsewhere. Another venue can offer it if it meets the tokenizer’s requirements, the tokenizer supports it, and it meets the exemption’s conditions that apply to it.

Does the stock token itself enforce the tokenizer’s whitelist on every transfer? The notice doesn’t say, and I won’t guess.

Neither layer is “the right one”. A pool gate fits venue rules: who trades here, volume caps, halts. A token gate fits holder rules: who may hold this security at all.

CMTAT is the token standard of the Swiss Capital Markets and Technology Association. I compared how ERC-3643, ERC-1400 and CMTAT place those checks in a separate episode.

A worked example: a wallet flagged after onboarding

IN SHORT Revoking a badge closes the pool to a flagged wallet, but by itself it doesn’t stop that wallet’s direct transfers.

This is a generic design, not OKXICE’s stock token: the notice doesn’t describe that token on this point. It does say the venue may burn or revoke the SBT after a sanctions match, and remove the wallet from the whitelist.

Add a freeze in the token and the second case changes. In ERC-3643, setAddressFrozen blocks ordinary transfers to and from that wallet, on any venue. Privileged agent operations still follow separate rules.

Each condition mapped to a control

IN SHORT Mapped row by row, the order’s conditions don’t all land cleanly in one layer.

Here’s how I’d map the order’s conditions to on-chain controls. The OKXICE column is what its notice says. The ERC-3643 column is what the standard can implement, not a claim that it satisfies anything.

Freeze and recovery are powers held by the token owner and the agents it appoints. That raises its own governance question: who can trigger them?

I went through it for automated operators in the Know Your Agent episode.

What a token contract can’t prove on its own

IN SHORT Some of the order’s conditions can’t live in a smart contract, however good the token standard is.

The order says the token must give holders “the same rights and privileges” as the traditional stock. Same interest, same dividends, same votes, same share on liquidation.

OKXICE says it checks this with the tokenizer’s legal statements, a reserve attestation and written steps for passing rights through. That’s paperwork and operations, and it should be. A token standard can’t prove a dividend will be passed through.

The middle layer is where I’d look hardest. OKXICE’s contracts use no oracles, the services that bring outside data on-chain. Halts come from a third-party data feed instead.

Its own risk section says errors or delays in that data “could cause trading to continue during a halt”. The pause is code. Its timing isn’t.

What I’d ask a venue before trusting its notice

IN SHORT Before trusting a TSV notice for a client or an integration, I’d want written answers to five questions.

None of these answers make a venue compliant or not; that’s a legal judgment. They tell you which layer is doing the work. For the token-layer side in depth, start with ERC-3643 explained.

If you read a TSV notice yourself

Sources: SEC order, Release No. 34-106402, SEC fact sheet, OKXICE TSV public notice (4 Oct 2026), ERC-3643 specification.

FAQ