The permissioned AMM platform for tokenized securities venues.
clarivyx is tokenized securities venue software: an auditable AMM core, an operator layer that keeps you inside your regime's conditions, and rulebooks that turn regulatory text into configuration — engineered to the SEC Innovation Exemption (TSV), the EU DLT Pilot Regime and the UK Digital Securities Sandbox. One codebase — deployed as your venue, under your licenses, on your chain.
Tokenization solved issuance. Secondary trading is the bottleneck.
Tokenized equities, funds and money-market instruments are live on public chains, and every major regime now has a conditional lane for onchain venues. The conditions are the product — and they are exactly what generic DeFi stacks do not have.
Assets are already onchain
Tokenized stocks, ETFs and MMFs from regulated issuers and custodians, with proof-of-reserves and creation/redemption rails. Supply is no longer the constraint — a compliant secondary market is.
The lanes are conditional
The SEC Innovation Exemption, the EU DLT Pilot Regime, and the UK Digital Securities Sandbox each permit DLT trading venues — conditional on permissions, halts, caps, notices, parity and reporting that order-book and DeFi stacks were never built to express.
Venue engineering is scarce
A permissioned AMM with supervisory-grade cap math, halt synchronization, notice workflows and records is a multi-year specialist program before your first trade. clarivyx is that program, productized and licensable.
Four layers. One venue stack.
Every economically significant action passes one compliance choke point onchain and one event stream offchain. Regulators and auditors read two doors — not twenty.
┌──────────────────────────── clarivyx ────────────────────────────┐ │ │ │ SDK (TypeScript) typed clients · web · APIs · surveillance │ │ ────────────────────────────────────────────────────────────── │ │ Operator (Rust) allowlist authority ─ halt-sync oracle │ │ cap monitor · issuer-notice workflow │ │ hash-chained books & records · USD reporting │ │ ────────────────────────────────────────────────────────────── │ │ Core (Solidity) PoolRegistry ── TSVPool (per pair) │ │ └── Policy ◄─ single choke point │ │ ────────────────────────────────────────────────────────────── │ │ Rulebooks (JSON) regime → configuration, release-gated │ │ │ └────────────────────────────────────────────────────────────────────┘
clarivyx Core — the venue
Per-pair pools with an immutable math library (constant-product at launch; pluggable curve later), a listing registry with per-asset metadata, and the Policy contract: one gate consulted on every swap and liquidity action — admission, venue pause, per-pool TVL caps, volume throttle. Governed-upgradeable, because rules evolve. Deliberately small audit surface: every line exists to be read.
clarivyx Operator — the regulated half
Event-sourced, deterministic, replayable. The allowlist authority mirrors admission onchain. The halt-sync oracle consumes primary-exchange halt feeds and fails closed on feed loss. The cap monitor throttles to per-symbol share-of-ADV limits with pause-guard. The issuer-notice workflow tracks 30-day clocks, receipts and objection states. Books & records are hash-chained; 24-hour USD volume reporting falls out of the event stream.
clarivyx Rulebooks — regime as config
Schema-validated, release-gated JSON per deployment: participant admission tiers, per-symbol caps, geofence sets, trading-hours policy, fee schedules, quote-asset policy. A new regime or a rule change is a rulebook review — not a fork, not a rebuild.
clarivyx SDK — one spec source
Types are generated from the contract ABI and event schema at one source, so your front-ends, institutional APIs and surveillance integrations consume identical shapes. No hand-written drift between what the pool emits and what your systems read.
One event stream, versioned from day one
Every action emits a schema-versioned event from one place in the code. Reporting, surveillance and supervisor extracts are downstream of a single stream — the format can evolve without breaking a single consumer.
{ "event": "SwapUSD", "schemaVersion": 1,
"pool": "0x…", "actor": "0x…",
"baseAsset": "TSLA", "quoteAsset": "USDC",
"baseDelta": "-12.5000", "quoteDelta": "+3210.75",
"usdNotional": "3210.75", "blockTimestamp": 1760000000 }
illustrative payload — SwapUSD, LiquidityUSD, AllowlistUpdated, PolicyPaused, PoolListed
A rulebook is a file
{ "regime": "us-tsv-equities", "chain": "base",
"participants": { "admissionTier": "full-KYC", "geofence": "US-persons" },
"caps": { "symbols": 75, "perSymbolShareOfAdv": "0.0025", "haltSync": "primary-exchange" },
"issuerNotices": { "clockDays": 30, "objectionHalts": true },
"pools": [ { "base": "TSLA", "quote": "USDC", "tvlCapUsd": 5000000 } ] }
illustrative excerpt — schema-validated, release-gated, per deployment
Published conditions, mapped to product behavior.
The same stack expresses each regime's rulebook. These are engineering mappings from the published instruments — interpretation and filing strategy stay with your counsel.
| Regime | What the regime demands of a venue | What clarivyx maps to it |
|---|---|---|
| US — SEC Innovation Exemption TSV · Release 34-106402 |
Permissioned AMM venue on a public permissionless ledger; bounded symbol count and per-symbol share of prior-month ADV; halt-sync with the primary exchange; issuer notice with 30-day clock and objection right; rights-parity tokenized stock; books & records; USD 24-hour reporting; US-person operator; statutory-disqualification screens. | Rulebook with symbol/ADV caps · cap monitor with pause-guard · halt-sync oracle on primary halt feeds · issuer-notice workflow (clocks, receipts, objections) · admission tiers incl. disqualification screens · hash-chained records · SwapUSD reporting stream. |
| EU — DLT Pilot Regime DLT MTF / DLT Trading Venue |
Authorization and ongoing supervision for DLT market infrastructures; instrument and threshold conditions; records and transparency obligations; smaller-platform capital treatment under the amending framework. | Rulebook variant per authorization scope · event-sourced records with replay for supervision extracts · threshold and instrument-scope configuration · EU-native quote-asset policy for payment instruments. |
| UK — Digital Securities Sandbox BoE + FCA |
Firm-specific limits set at gates; modified MLR participant standards; DLT trading venue and digital securities depository scope; designated settlement assets including qualifying stablecoins. | Per-firm limit configuration in the cap monitor · admission tiers as config · settlement-asset policy in the rulebook · evidence pack from the invariant suite mapped to your gate conditions. |
| ADGM — FSRA framework Digital securities · MTF |
Market permissions for digital-securities venues; recognized-intermediary participant model; fiat-reference-token treatment of settlement assets. | Permissioned admission via Policy choke point · participant-tier config · quote-asset admission flags per the FRT framework. |
| Crypto-only venues Non-security digital commodities |
AML/registration-driven admission per market; sanctions screening; no securities layers required while scope is non-security assets. | Crypto rulebook: tiered admission, geofence sets, per-pool caps, securities modules switched off — same core, same operator, different file. |
Go deeper on the regime that matters to you.
Reference pages on the venues, the conditions, and the engineering that satisfies them — written for the people building and approving the venue, not for search engines.
What is a Tokenized Securities Venue (TSV)?
The new SEC venue category: how a TSV works, what trades on it, and the conditions that define it.
US regimeSEC Innovation Exemption, condition by condition
Release 34-106402 mapped: symbol caps, ADV limits, halt-sync, issuer notices, rights parity, reporting.
PlaybookHow to become a TSV
The launch checklist: entity, notices, feeds, admission standards, software, and the go-live timeline.
ArchitecturePermissioned AMMs, explained
How an AMM satisfies trading-venue rules — one gate on every action — and what it must never be able to do.
EU regimeDLT Pilot Regime venue software
What DLT MTF and DLT Trading Venue applicants need from their stack, and the EU market-access realities.
UK regimeUK Digital Securities Sandbox
Venue software for DSS entrants: gates, firm-specific limits as configuration, and settlement assets.
Principles that survive diligence.
The operator can halt, never move
No operator keypath transfers participant funds. Compliance keys freeze activity; treasury keys that could move participant assets do not exist. The test suite asserts the absence of the codepath, not just the behavior.
One compliance choke point
Every pool action routes through a single Policy contract — admission, pause, caps, throttle in one place. Your auditors and your supervisor read one door, and every rule change is observable in one history.
Versioned events, one source
Every economically significant action emits a schema-versioned event from one place. Reporting, surveillance and extracts are downstream consumers — the audit trail is the product, not a bolt-on.
Rulebooks as configuration
Regimes differ by file, not by fork. Caps, tiers, geofences, hours and fees are schema-validated config, release-gated like code — so a rule change is reviewable, revertable and attributable.
Commercial source license
Licensees receive the full source under a commercial license agreement — readable, auditable, and modifiable within the deployment. Every dependency is license-reviewed and CI-enforced, so nothing restrictive or conflicting enters the build your agreement covers.
Canonical representations only
Instruments and legs are canonical, regulated-issuer representations on the deployment chain — never bridged. The registry records a representation tier per asset, and non-canonical assets are off by default.
Requirements first, then code.
The security program is derived before implementation: the public audit corpus and the exploit record are converted into the specific tests that must exist — then the implementation is built against them.
Audit corpus → requirements
Public audit reports across the AMM and exchange ecosystem, indexed by attack class and mapped to our modules. Each finding becomes a named requirement and a named test before the module is written.
Exploit classes → regression library
Every major exploit class — pool math, oracle manipulation, key management, governance capture, front-end and operational compromise — carries a prevention control and the regression test that would have caught it.
Invariants and property tests
Foundry invariant suites over the pool core; property-based tests over the operator's cap and halt math. A cap breach can mean a statutory pause — the system treats data-feed loss as fail-closed, and the tests encode that.
Continuous adversarial review
A multi-model review pipeline runs attack-class briefs across the codebase on a cadence, weighted by per-model hit rate. Findings file only when they reproduce as failing tests — then they become permanent regression coverage.
Built for operators entering the lane, not for demos.
Broker-dealers & special-purpose brokers
Adding an onchain venue capability to an existing regulated footprint — the venue leg without building a protocol team.
DLT Pilot & CASP applicants
EU applicants who need a DLT MTF-grade venue and an evidence story for authorization, without a from-scratch build.
UK Digital Securities Sandbox entrants
Gate-1 and Gate-2 participants whose limits are firm-specific — expressed here as configuration, with test evidence mapped to gate conditions.
Exchanges & market infrastructure
Registered venues extending hours, asset coverage or settlement onto public ledgers alongside the existing book.
Issuers & custodians
Tokenization programs that need the secondary lane their instruments require — venue software from a vendor, not a subsidiary.
Licensed fintechs
Operators with registrations or licenses in permissive regimes running crypto-first venues today, with a path to securities scope by rulebook.
Rulebook to evidence, in three moves.
Scope the rulebook
A working session on your regime, chain, participant model, instruments and caps. Output: a draft rulebook and the conditions-to-behavior mapping your counsel can mark up.
Deploy the stack
Core, operator and SDK delivered into your infrastructure and your keys — or run against a reference deployment while you stand up your own. Adapters, feeds and SDK integrate with your existing stack.
Collect the evidence
The invariant and property suites map test-by-test to your regime's conditions — a filing-support artifact showing which behavior is enforced where, and which test proves it.
Licensing is structured per deployment — integration, reference operation, and white-label tiers. Start with a technical briefing: hello@clarivyx.com.
Questions engineers and compliance officers ask.
What is a Tokenized Securities Venue (TSV)?
What is the SEC Innovation Exemption?
Which instruments and settlement assets can trade on a clarivyx venue?
Can a permissioned AMM actually meet exchange-style conditions?
Does clarivyx hold funds, keys, or custody?
Which chains are supported?
How are caps enforced without trusting a price oracle?
Can the same stack run a crypto-only venue?
What license terms does the code carry?
Does clarivyx provide legal or regulatory advice?
Bring your rulebook. We'll map it.
Tell us your regime, chain, participant model and target instruments. We'll return a draft rulebook and the conditions-to-behavior mapping — the fastest way to evaluate whether the stack fits your authorization path.