Tokensoft Investment Accounts: Atomic Delivery-vs-Payment Settlement for Regulated Security Tokens

Security tokens solve the issuance problem. They don't automatically solve the trading problem.

When a company issues equity as an ERC-1404 security token, it gains all the compliance automation benefits of on-chain issuance: automated whitelist enforcement, fractional ownership, programmable vesting, and a global investor base. But when those investors want to trade with each other — selling to new investors, transferring positions, building secondary market liquidity — they run into a wall that didn't exist in the primary issuance context: settlement risk.

Tokensoft built Tokensoft Investment Accounts (TIA) to eliminate that risk. TIA is a full secondary market trading platform for ERC-1404 security tokens — combining an off-chain order book with an on-chain atomic delivery-versus-payment (DvP) settlement contract. The result: no custody risk, no settlement failure risk, no principal risk, and full ERC-1404 compliance enforcement at settlement time.

The Settlement Risk Problem

In traditional finance, delivery-versus-payment (DvP) is a fundamental settlement principle: the delivery of securities and the payment for those securities must occur simultaneously, or neither occurs. DvP eliminates the "Herstatt risk" scenario — named after a 1974 German bank failure — where one counterparty delivers their leg of a trade before receiving the other leg, and the counterparty defaults before completing their side.

The blockchain enabled a new and elegant version of DvP: atomic settlement. In a single Ethereum transaction, both the securities leg and the cash leg of a trade can be transferred simultaneously. Either the entire transaction succeeds — buyer receives tokens, seller receives payment — or the entire transaction reverts. There is no in-between state where one party has delivered and the other has not.

But implementing this for ERC-1404 security tokens introduces a complication that no standard atomic swap protocol handles: the securities have transfer restrictions. An atomic swap that attempts to move ERC-1404 tokens to a non-whitelisted buyer will fail at the smart contract level — after the settlement contract has already been constructed, approved, and submitted. Tokensoft's DvP Settlement contract solves this by integrating ERC-1404 compliance enforcement into the settlement flow itself.

How TIA Works

The Order Book Layer (Off-Chain)

TIA maintains a bulletin board order book — an off-chain system where buyers and sellers post orders and discover each other's intent to trade. This is the "bulletin board" model familiar from traditional OTC securities trading: orders are posted, reviewed, and matched manually by the licensed broker-dealer, rather than automatically by an algorithm. This design preserves broker-dealer oversight — a regulatory requirement for secondary trading of restricted securities — while enabling price discovery.

Order states are managed as a state machine: OPEN → FILLED or CANCELLED. Orders are immutable once posted; they can only transition forward through the state machine, never backward. This prevents manipulation of the order record and creates a verifiable audit trail of every order in the book.

The DvP Settlement Contract (On-Chain)

When the broker-dealer matches a buyer and a seller, both parties are asked to pre-approve the DvP Settlement contract via the standard ERC-20 approve() mechanism. This approval delegates to the settlement contract the authority to transfer the relevant tokens from each party's wallet — but only in the context of a valid, matched settlement transaction.

The broker-dealer then calls settle(bid_order_id, ask_order_id) on the DvP Settlement contract. In a single atomic transaction:

1. The settlement contract verifies both order IDs are valid and in OPEN state
2. The ERC-1404 transfer restriction check is evaluated: can the seller transfer to the buyer under the token's compliance rules? If not — if the buyer is not whitelisted, or if the tokens are locked, or if the transfer would violate an ownership cap — the entire transaction reverts. Nothing moves.
3. If the compliance check passes, both legs execute simultaneously: the securities move from seller to buyer, and TsUSDC (Tokensoft's 1:1 USD-backed settlement token) moves from buyer to seller
4. Both order states update to FILLED

Either the entire transaction succeeds or the entire transaction reverts. There is no state where the buyer has paid but not received tokens, or where the seller has delivered tokens but not received payment. Principal risk is eliminated at the protocol layer.

What the Broker-Dealer Never Touches

A critical regulatory feature of the TIA architecture: the broker-dealer calls the settlement function but never holds custody of the funds. The ERC-20 approve() mechanism is a delegated transfer authority — the tokens and cash remain in the buyer's and seller's wallets until the moment of settlement, and then move directly between them. The broker-dealer's key authorizes the settlement but is never in the chain of custody for either asset. This is the technical implementation of the principal vs. agent distinction in securities regulation.

One Contract Per Broker-Dealer

The architecture deploys one DvP Settlement contract per licensed broker-dealer. This is not an optimization — it's a compliance requirement. Regulators and auditors need to be able to attribute every settlement transaction to a specific licensed entity. A single shared contract would make that attribution impossible. The per-broker-dealer deployment creates a clean, auditable chain from every on-chain settlement transaction back to the regulatory entity that authorized it.

TsUSDC: The Settlement Currency

The cash leg of TIA settlements uses TsUSDC — Tokensoft's own 1:1 USD-backed stablecoin, issued under the Tokensoft platform. TsUSDC enables settlement in US dollars without requiring either party to use a third-party stablecoin (which may have its own compliance and counterparty considerations). It is the on-chain equivalent of the wire transfer leg in a traditional DvP settlement — stable, dollar-denominated, and fully within Tokensoft's compliance framework.

Security Architecture

Reentrancy Protection

The DvP Settlement contract employs state-change-before-transfer reentrancy protection — a standard but critical Solidity security pattern. Order states are updated to FILLED before any token transfers execute. An attacker attempting to exploit a reentrancy vector would find the order already marked filled on reentry, causing the reentered call to revert. This pattern, combined with well-defined state machine transitions, prevents the class of attacks that have compromised several prominent DeFi protocols.

Compliance at Settlement Time

The ERC-1404 compliance check is not a pre-flight check run before the transaction is submitted — it is executed inside the settlement transaction itself, in the same block, against the current state of the token contract's whitelist. This means that if a buyer's whitelist status changes between order matching and settlement execution — for example, if a compliance check reveals a sanctions issue — the settlement will fail with the correct error, protecting all parties from an inadvertent non-compliant transfer. The token contract state at settlement time is authoritative, not the state at order-posting time.

Where This Goes

Secondary market infrastructure for security tokens addresses a market that is only beginning to take shape. The regulatory framework for digital securities has matured considerably since TIA was built — the SEC's digital asset guidance, FINRA's evolving position on blockchain-based settlement, and the international equivalents all point toward atomic DvP as the settlement standard for tokenized securities.

Traditional financial market infrastructure — transfer agents, clearing houses, broker-dealers — is steadily moving toward digital securities. The settlement primitives Tokensoft built for TIA map directly onto how those institutions think about DvP: simultaneous delivery and payment, broker-dealer as authorized intermediary (not custodian), per-entity contract deployments for regulatory attribution, and an immutable on-chain audit trail.

Tokensoft built this infrastructure years before it became a mainstream priority for traditional finance. The codebase, operational history, and compliance architecture reflect that head start.