The challenge is adapting that infrastructure to meet the SEC’s requirements, from participant eligibility and trading limits to market halts and reporting.
This article breaks down some of the key technical requirements, engineering controls, and operational procedures.
The layers of a TSV
- Public ledger: The blockchain hosting the venue.
- Tokenized assets: Transfer-restricted security tokens paired with permitted assets (like a tokenized NMS stock, a stablecoin, or a tokenized money market fund).
- Identity and credentials: Systems that establish and communicate participant eligibility.
- Eligibility controls: Rules governing which wallets may hold a security.
- Liquidity and trading: An AMM or dedicated liquidity pool.
- Venue control layer: Software that applies venue rules across participants, assets, trades, and operations.
The control layer has four responsibilities
Issuer controls govern who may hold a security; venue controls govern who may trade through the venue. These controls serve different purposes and may need to work together.
- Admission and participation: Maintain the asset registry and verify participant credentials.
- Trade enforcement: Check eligibility, asset admission, market halts, and volume limits before execution.
- Auditability and reporting: Record decisions, preserve evidence, and publish required transaction data.
- Operational control: Manage permissions, upgrades, emergency actions, and market-data inputs.
What happens when a trade is executed?
A TSV checks each trade against its rules before it settles. Take a permissioned pool trading a tokenized stock against a stablecoin.
- The participant initiates a swap. A wallet submits a transaction to buy the tokenized stock with a stablecoin.
- The venue runs its checks. Inside the swap, the trading path confirms that the participant holds a valid credential, the stock is admitted, trading is not halted, and the stock has room left in its volume budget.
- The trade settles or fails. If every check passes, both sides settle atomically in one transaction. If any check fails, for example because the participant’s credential was revoked, the transaction fails and nothing settles.
- The venue records the outcome. An indexer captures every fill and every refused transaction, and the archive keeps each decision with the inputs it read.
Implementation example: Moonsong’s open-sourceToken ACL SAS Gate (opens in a new tab)checks a participant’s credential before a wallet can hold a transfer-restricted token. (Note: This is an unaudited reference implementation.)
What can be reused? What must be built?
Existing ledger infrastructure, token standards, credential services, and AMMs may provide much of the foundation for a new TSV. The work lies in integrating them with venue-specific controls for trade enforcement, market halts, volume limits, evidence, and reporting.
The implementation depends on several key decisions:
- Trading model: An existing AMM may provide liquidity and swap infrastructure. However its execution path must support the venue’s required checks and its pricing needs review, since pool-balance pricing can drift from the exchange price. A dedicated pool offers more control over that path.
- Eligibility model: Token-level controls govern who can hold a security; venue-level controls govern who can trade through the venue. The design must account for both.
- Market-data dependencies: Halt status and trading-volume limits require reliable inputs and a defined process for getting updates into the trading controls.
- Control and evidence: Upgrade permissions, emergency actions, transaction records, and reporting need to be designed together so the venue can enforce its rules.
The right architecture depends on what already exists, which requirements the venue must satisfy, and where new controls are needed.
Moonsong can assess your existing infrastructure and define the engineering work required to build a TSV.