Ed’s Tokenized Securities Railshuman-curated, LLM-maintained

Reference architecture for trading tokenized securities

3 min read

In plain English: an overview of how a tokenized-stock trading system fits together, from letting an investor in, through the trade, to updating the official record. Deeper pages on each part will be added as the roadmap ships.

The shared ledger and one trade, end to end. One shared ledger: issuer / TA, KYC provider, identity registry, token contract, venue, oracle, wallet holder and cash issuer (stablecoin or tokenized deposit) all connect to the same ledger; everyone works from the same record. One trade in five steps: Order: order book, RFQ or onchain pool. Match: oracle: open? price fresh? Halted: rejected. Check: both wallets eligible; both legs usually prefunded. Atomic swap: token and cash swap at once: both legs or neither. Record: balances update at once; native: the register; wrapped: reconcile. Reference information only. Not investment advice.

Illustrated overview: the shared ledger and one trade, end to end. The text diagrams below give the detail.

End-to-end components

flowchart LR
    subgraph Access["1 · Access"]
      KYC["KYC /<br/>onboarding"] --> REG["Identity registry<br/>/ allowlist"]
      WAL["Wallets<br/>and keys"]
    end
    subgraph Trading["2 · Trading"]
      VEN["Onchain venue:<br/>permissioned pool"]
      HYB["Hybrid:<br/>offchain match"]
      ORA["Oracle and<br/>halt controller"]
    end
    subgraph Asset["3 · Asset"]
      TOK["Token contract<br/>+ compliance hook"]
      CASH["Cash token: stablecoin<br/>or tokenized deposit"]
    end
    subgraph Records["4 · Records"]
      MR["Mint / redeem<br/>+ reconciliation"]
      TA["Transfer agent / register<br/>or custodian"]
      CA["Corporate actions:<br/>multiplier"]
    end
    WAL --> VEN
    WAL --> HYB
    ORA --> VEN
    VEN --> TOK
    HYB --> TOK
    TOK --> REG
    VEN --> CASH
    TOK --> TA
    MR --> TOK
    MR --> TA
    CA --> TOK
    CA --> ORA
    classDef access fill:#dbeafe,stroke:#2563eb,color:#1e3a8a
    classDef trading fill:#fef3c7,stroke:#d97706,color:#78350f
    classDef asset fill:#dcfce7,stroke:#16a34a,color:#14532d
    classDef records fill:#ede9fe,stroke:#7c3aed,color:#4c1d95
    class KYC,REG,WAL access
    class VEN,HYB,ORA trading
    class TOK,CASH asset
    class MR,TA,CA records
    style Access fill:#eff6ff,stroke:#2563eb
    style Trading fill:#fffbeb,stroke:#d97706
    style Asset fill:#f0fdf4,stroke:#16a34a
    style Records fill:#f5f3ff,stroke:#7c3aed

Terms: KYC · allowlist · wallets · keys · permissioned pool · hybrid matching · offchain · oracle · halt · compliance hook · stablecoin · tokenized deposit · mint · redeem · reconciliation · transfer agent · custodian · corporate actions · multiplier

Colors: blue = access, amber = trading, green = asset and cash, purple = records.

One trade, end to end

sequenceDiagram
    autonumber
    participant I as Investor<br/>wallet
    participant K as KYC /<br/>registry
    participant O as Oracle +<br/>halt control
    participant V as Venue: pool<br/>or matcher
    participant T as Stock token<br/>+ compliance
    participant C as Cash<br/>token
    participant R as Transfer<br/>agent
    rect rgb(219, 234, 254)
    Note over I,K: Onboard
    I->>K: onboard
    K-->>I: wallet allowlisted
    end
    rect rgb(254, 243, 199)
    Note over I,O: Order and pre-trade checks
    I->>V: order or swap
    V->>O: symbol open?<br/>price fresh?
    O-->>V: open / halted
    end
    alt halted or stale
        V-->>I: reject
    else open
        rect rgb(220, 252, 231)
        Note over V,C: Settle: atomic DvP, both legs or neither
        V->>T: canTransfer<br/>(seller, buyer)?
        T->>K: both verified?
        K-->>T: yes
        V->>T: deliver stock token
        V->>C: deliver cash
        end
        rect rgb(237, 233, 254)
        Note over T,R: Record
        T-->>R: transfer event
        Note over R: update<br/>register,<br/>reconcile
        end
    end

Terms: DvP · atomic settlement · oracle · halted · compliance · transfer agent · reconcile

Phases: blue = onboard, amber = order and checks, green = atomic settlement, purple = record. Same colors as the component map above.

Components

ComponentWhat it does
Token contract + compliance hookOnly eligible wallets can hold or receive
Mint / redeem + reconciliationSupply matches real shares
Venue (permissioned pool or hybrid)Matches and settles trades
Oracle + halt controlFresh prices; stop when the stock is halted
Transfer agent / registerThe official record stays in sync with the chain

Key rules

  1. Only allowlisted wallets ever receive the stock token (ERC-3643).
  2. Both legs of a trade settle or neither does (atomic settlement).
  3. No trading while the primary exchange has the stock halted (SEC order).

vs traditional trading infrastructure

Traditional trading uses broker order routing, exchange order books or RFQ, CCP netting and T+1 settlement at DTC, with eligibility enforced by brokers and the transfer agent. Tokenized rails move eligibility into the token, settle atomically and run 24/7. See Settlement & matching and Post-trade (Reg NMS) model.

Sources

Public originals for the facts on this page.

Graph View

Backlinks