---
title: ST0x Documentation

---

<!-- index -->

# Welcome to ST0x

The Global 24/7 Decentralised Exchange is closer than we think.

"The next generation for markets… will be the tokenization of securities" - Blackrock CEO, Larry Fink

## Introduction
By bridging tokenized equities with decentralized finance (DeFi), we’re building an open, efficient, and inclusive financial ecosystem—where anyone can access the world’s most liquid markets.

The $255T global equities market is rapidly evolving, driven by tech innovation, globalization, and the rise of empowered retail investors—especially millennials and Gen Z. These shifts demand platforms that break down barriers and democratize access.

Tokenization is the key. It enables fractional ownership, real-time settlement, and liquidity at a scale never seen before. By 2030, tokenized assets could reach $16T, or 10% of global GDP (BCG).

ST0x integrates this potential with DeFi principles—removing intermediaries, boosting transparency, and unlocking new levels of efficiency. We’re not just enabling access; we’re reshaping the foundation of capital markets.

## A New Capital Market Infrastructure
ST0x unifies liquidity across on-chain and off-chain markets, giving users seamless access to global trading venues across jurisdictions and asset classes—equities, bonds, commodities, and digital assets.

Users can trade in real time and publish orders directly to the ST0x orderbook, where they’re instantly aggregated with liquidity from other venues for maximum exposure and execution potential. Orders remain user-owned and secured on-chain.

Trades are executed the moment liquidity intersects—whether sourced internally or externally. ST0x abstracts the complexity, letting users define what they want to trade while the system routes to the best available liquidity, anywhere.

# How to

In order to make a trade head to the 'New order' section in the website. Choose your Order type:

- Limit order
- DCA
- Active Liquidity
- Portfolio Strategy

ST0x current does not support market orders, place limit orders that will be cleared against avilable liquidity.

If liquidty is not avilable solvers will goto the S1 bridge to pull it through for your order.

Once your order is deployed your assets will be held in your own vault, not your wallet.

In order to change this order head to the 'Order list' section, click show my orders, click on your order and adjust it as you see fit.

As your trade clears the asset you have swapped for will be sitting in your vault until you withdraw it.

# FAQs

**Q: Is ST0x the Issuer of the Equities?**

No, we work with an Issuer called S1. We provide an environment for trade for those assets

**Q: Are all assets backed?**

Yes, all assets are backed 1-1

**Q: Who custodys the offchain assets?**

S1 is partnered with Charles Schwab, the worlds largest broker

**Q: Is this a Synethtic?**

A: No, this is the real deal

**Q: Do I have to do KYC / AML?**

You do not have to do KYC, you are operating on a DEX. When you hold S1 issued assets your relationship is with S1.

S1 does run AML scanners to ensure that anyone holding the Equity tokens is not engaging in money laundering, terrorist financing, or other illicit activities. If such activity is detected, you will be blacklisted and your holdings will be frozen.

# Architecture

## Tech Components

ST0x technology infrastructure has 3 main components and works with the Issuer S1 to add 2 components:

**S1 Issuer:**

1. **Tokenization Layer:** This layer transforms traditional assets into tokenized representations using advanced standards like semi-fungible tokens (SFTs). It embeds compliance rules, custom ownership structures, and audit capabilities directly into smart contracts, ensuring regulatory alignment and enabling secure, transparent asset management.
2. **Liquidity Bridges:** A trust-based bridge enabling seamless 1:1 conversion between shares and tokens, with each token backed by a corresponding share held in custody. Independent arbitrageurs provide rapid liquidity and help align on-chain and off-chain prices, periodically rebalancing via the bridge to maintain market efficiency.

**ST0x DEX:**

3. **Programmatic Intents System:** A decentralized smart contract platform that facilitates complex, custom trading strategies. Utilizing Rainlang, an intuitive on-chain programming language, users can create and execute dynamic strategies with self- custody of funds, ensuring unparalleled control and adaptability.
4. **Solvers:** Solvers are off-chain agents that monitor intent-based orders and compete to fulfil them by submitting optimal on-chain transactions. They enable efficient execution by sourcing liquidity, routing through protocols, or arbitraging across markets to maximise outcomes for users.
5. **Interfaces:** The platform offers multiple interaction options, including a user-friendly web interface, a robust SDK for integration into third-party applications, and the ability for advanced users to interact directly with smart contracts. These interfaces simplify user engagement while maintaining flexibility for diverse use cases.


# Tokenisation Layer

S1 leverages a Semi-Fungible Token (SFT) standard, integrating non-fungible ERC-1155 and ERC-20 tokens.

The ERC-1155 token acts as a repository for essential data related to off-chain assets, including audit history, and is accessible by all users via IPFS. Users can then exchange the asset linked to the ERC-1155 token in a fungible manner using ERC-20 tokens.

The framework includes various user roles that can govern, validate and audit interactions between multiple parties. These roles and rules can be flexibly deployed to achieve the desired market structure and respond to regulatory and compliance constraints. Each role possesses a set of capabilities and relationships within the predefined framework enabling the construction of strong and transparent decentralized power structures.
The S1 contract also oversees token transfers, minting, and burning through the RFQ issuance process, validating cryptographically signed coupons and maintaining accompanying record-keeping.

* “Connectors” - Participants that can create on-chain assets
* “Disconnectors” - Participants that can remove on-chain assets
* “Certifiers”- Participants that certify the validity of information contained in the tokenized asset contracts and the alignment between on-chain and off- chain assets at set intervals after tokenization
* “Tierers” - Participants that enforce and verify the respect of AML/KYC rules
* “Handlers” - Participants that can move assets during freezes
* “Confiscators” - Participants that can freeze or seize tokenized asset holdings from users

## Asset Issuance and Redemption

The S1 contract operates as an interpreter contract, designed to analyze custom logic used to define all asset data and ownership guidelines for ERC-20 tokens. This mechanism requires all token transfers to adhere to these guidelines.

Its customizable nature empowers issuers to incorporate bespoke requirements such as trading/ownership restrictions, counterparty verification etc. This ensures strong control over distribution, ownership and adherence to distinct jurisdictions and asset-level regulations.

This creates assets that are programmable and self-governing massively reducing operational costs.

The issuance and redemption operators of tokenised assets via the tokenisation layer will be restricted to approved third-party participants. Admission to perform these functions will be granted only after verification that the entity holds the necessary licences and has successfully completed all applicable AML and KYC checks.

Upon admission, S1 assumes the role of a super admin and establishes the necessary blockchain permissions (including minting permissions). This effectively starts the market creation process.

### Issuance Process

The issuance of tokens representing financial instruments will be subject to a strict and comprehensive process to ensure compliance with all relevant laws and regulations including national laws as appropriate and globally applicable regulations such as MIFID.

With regards to equities, issuance will be subject to the following prior to tokenization and admission for trading:

- Issuance of a stock certificate representing the primary asset; and
- Publication of a prospectus in line with Regulation (EU) 2017/1129 (“Prospectus Regulation”).(Right now we are operating under prospectus exemption but will be obtaining Prospectuses in the coming months)

Once these are completed, the relevant Connector (i.e. the issuer of the token) will encode all financial and non-financial data related to the primary asset and its GDR as well as information regarding the issuer itself, reference to its custodial arrangement etc into the token’s smart contract.

An independent third party (“Tierer”) then verifies the completeness, veracity and validity of the information programmed by the Connector.

The Connector is then granted authorization to mint and manage the associated ERC-1155 and ERC-20 tokens. This creates on-chain endpoints allowing users or solvers to interact with the connector’s liquidity.

## Ownership and Security Considerations

The ST0x SFT contracts (Offchain Asset Vault – ethgild repo) follow a standard OpenZeppelin ownership model. While the contracts are non-upgradeable, the owner can update the authoriser, which controls critical functions like minting and burning.
This creates a major risk: if the mint function is compromised, an attacker can irreversibly drain supply within a single transaction, leaving no time to respond.

To mitigate this, ownership is typically placed behind an M-of-N multisig (e.g. Gnosis Safe). However, as TVL increases, so does attacker sophistication. Multisigs have been breached via phishing, interface hijacks, and supply chain exploits. For example, ByBit’s Gnosis Safe was compromised by a state actor for $1.5B by targeting the front end used by its signers.
In practice, increasing M and N offers diminishing returns due to operational overhead and signer correlation. The Ronin hack ($600M+) showed this clearly—4 of 5 compromised keys were controlled by the same entity, rendering the 5-of-9 setup ineffective.

Multisig security is fragile at scale and requires a level of operational discipline that many organisations are not equipped to maintain.

### Implications of an Infinite Mint

An infinite mint—commonly known as a “rug”—is the worst-case scenario for any token. Its existence as a standard term highlights both its frequency and severity.

The attack is straightforward: a compromised mint function allows an attacker to issue an unlimited number of tokens. Whether billions or trillions, the effect is the same—liquidity is rapidly drained across all sources. On-chain, this can happen in a single transaction, leaving zero time to respond.

The damage is irreversible. While token holders can be restored via snapshot and reissuance, liquidity providers—especially on-chain LPs—suffer total and permanent loss. As automated market participants, they are wiped out instantly.

Reputational fallout further damages the token’s viability. LPs are unlikely to support a reissued version (e.g. “Token 2.0”), severely impairing long-term liquidity and trust.

This scenario also exposes the fragility of protocol “security modules” that rely on native token insurance. In a real exploit, the market collapses before any recovery process can be actioned, rendering such protections largely ineffective.

### Implications of Other Forms of Compromise

Beyond infinite minting, a compromised authoriser introduces several critical attack vectors. Since the authoriser governs core permissions, an attacker could:

- (Un)certify SFTs to control transferability
- Confiscate tokens from any holder
- Burn confiscated tokens from any wallet

These are either functionally equivalent to an infinite mint or constitute recoverable vandalism, addressable via snapshot and airdrop—provided the damage is limited to on-chain state.

Crucially, since all real-world assets (RWAs) are held off-chain, an attacker cannot access their intrinsic value without also breaching institutional settlement processes—typically infeasible due to physical custody and multi-step controls.

An edge case is the infinite freeze attack. While it yields no direct gain for the attacker, it can severely damage LPs. For instance, if tokens in a Uniswap pool are indefinitely frozen, LPs cannot withdraw their paired assets. Even with a recovery plan, the economic impact is similar to a full rug.

Though less likely than a mint exploit, infinite freeze scenarios merit inclusion in comprehensive threat models.

### Limitations of Straight Timelocks

A common mitigation for ownership-level compromise is a simple timelock—e.g. enforcing a 24-hour delay between proposing and executing ownership changes. This can deter phishing-based attacks but provides little defence against full key compromise.

If an attacker gains control of the signing keys, they can repeatedly repropose themselves as owner, turning the system into a war of attrition. The attacker only needs to succeed once, incentivised by the protocol’s full TVL, while defenders must respond successfully every time, with far fewer resources.


This asymmetry is especially dangerous given that private key compromise accounted for an estimated 43–69% of all crypto thefts in 2024. While high-profile exploits like the ByBit hack drew attention, key theft remains the most frequent and effective attack vector.

Once a compromise is visible on-chain, market confidence collapses. Token holders observing the conflict between attacker and defender typically exit immediately, regardless of the outcome. Even without a successful exploit, visible risk can cause irreversible reputational damage.

Timelocks also introduce a secondary risk. Unlike an instant exploit, which allows for a clean pre-attack snapshot, trading often continues during the delay window. A post-event snapshot can then create unfair outcomes: sellers keep proceeds, while buyers are left with worthless tokens.

In short, while timelocks add friction to some attacks, they fail to prevent the most common threats and can complicate recovery when a compromise becomes public.

### Owner-Controlled Freeze Mechanism

As an alternative to traditional timelocks, the ST0x framework introduces an owner-controlled freeze state for critical compromise mitigation. This operates alongside the certification freeze—both must be inactive for transfers to proceed.

Unlike the certification freeze, the owner freeze:

- Ignores override roles (e.g. confiscators, handlers)
- Maintains its own allowlist for exempt senders and receivers

The freeze can be triggered automatically during sensitive operations (e.g. ownership or authoriser changes) or manually in response to threats. In the event of an attack, the system can remain frozen while a migration is prepared.

Although a compromised owner could alter freeze logic or exempt their own address, this does not grant additional tokens or access off-chain assets. Any malicious exemptions can be tracked and excluded during recovery. Governance processes should account for potential griefing scenarios, such as LPs being frozen intentionally.

### Token Implementation

The token contract introduces minimal but essential modifications to support this freeze logic, assuming the owner is a governance contract (not an EOA or basic multisig). Ownership remains a layer above the authoriser, though future consolidation may be considered.

New onlyOwner methods:

- ownerFreezeUntil(uint256 timestamp)
- Sets the freeze until a specific time. Cannot be shortened by future calls.
ownerFreezeAddSender(address sender) / RemoveSender(...)
- Maintains an allowlist for senders exempt from the freeze.
ownerFreezeAddReceiver(address receiver) / RemoveReceiver(...)
- Maintains an allowlist for receivers exempt from the freeze.

Freeze enforcement logic:

If now < freezeUntil and neither sender nor receiver is exempt, all transfers revert, including mints, burns, and confiscations. Emitted data and events are unaffected.

### Example Owner Contract: Governance Recommendations

There is no universal owner contract. However, a minimally viable implementation should enforce the following:

- Automatic freezes triggered by sensitive operations:
- Ownership changes
- Authoriser updates
- Modifications to freeze logic or exempt lists
- Preset freeze duration, not attacker-controlled at runtime
- Manual emergency freeze option for multisig-controlled governance
- Timelocks on exemption removals to prevent instant griefing
- Freeze duration sufficient to enable response in worst-case timing scenarios (e.g. holidays)
- Governance structure capable of coordinating a token migration during a persistent freeze

# Liquidity Bridges

## Trust and safety is vital

Bridges occupy an exceptionally sensitive position, acting as the gateway between two financial systems. They must be robust and secure to instil confidence in users, protocols, and institutions regarding the assets issued through them.

Any risk introduced into the bridging process will, at some point, be tested. If such a risk materialises, the resulting failure could be catastrophic—potentially destabilising an entire ecosystem.

The USDC depegging event underscored this vulnerability, ultimately requiring intervention from the US government. Similarly, the BUSD depegging event led to a collapse in market capitalisation from $16 billion to $2 billion.

## Conversion Between Shares and Tokens Without Price Risk

The S1 bridge provides a direct, price-stable pathway between traditional shares and blockchain-based tokens. This system ensures that tokens can always be redeemed for their corresponding shares—and vice versa—regardless of market conditions.

S1’s German entity acts as custodian, holding the underlying assets under a ring-fenced structure. For every token minted, a corresponding share is held in custody on a 1:1 basis at all times.

**Minting Process**

1. The user transfers shares to the trust.
1. The trust verifies receipt of the shares.
1. The trust mints the equivalent number of tokens to the user.

**Burning Process**

1. The user initiates a token burn.
1. The trust verifies the burn.
1. The trust transfers the corresponding shares to the user.


## Arbitrageurs: Aligning On-Chain and Off-Chain Prices

Arbitrageurs play a vital role in maintaining price alignment between tokenised assets on-chain and their corresponding shares off-chain. By holding inventory in both environments, they provide faster liquidity and help stabilise price discrepancies. Importantly, if an arbitrageur exhausts inventory in one direction, it does not represent a systemic failure—only a temporary inefficiency.

These independent entities maintain inventories of both on-chain tokens and off-chain shares. They offer rapid conversions, often at a premium, with many competing to provide the most efficient pricing.

**How Arbitrage Works**

An arbitrageur monitors prices and trades when a disparity arises between the token price on-chain and the share price off-chain. When a significant imbalance in inventory builds up, they periodically rebalance through the slower bridge mechanism (e.g., daily).

**Example**

An arbitrageur holds 1,000 TSLA tokens on-chain and 1,000 Tesla shares off-chain.

1. They observe TSLA tokens trading on-chain at $252, while Tesla shares are trading off-chain at $250.
1. They sell 1 TSLA token from their on-chain inventory.
1. They buy 1 Tesla share off-chain through their brokerage account.
1. This captures a $2 profit (minus fees) and maintains a relatively balanced inventory.

If the on-chain price remains higher throughout the day, and the arbitrageur repeats this process, by day’s end they might hold 50 TSLA tokens on-chain and 1,950 Tesla shares off-chain. To rebalance, they transfer 950 shares via the slow bridge to mint 950 tokens, restoring their 1,000/1,000 balance for the next trading cycle.

# Programmatic Intents System

The Programmatic Intents System is an on-chain smart contract platform that allows users to deploy complex token trading strategies using dynamic algorithms. Tokens move between vaults based on strategies expressed in Rainlang, an adaptable, on-chain domain-specific language.

## Key Features

**Rainlang**

Rainlang is an on-chain smart contract language designed for creating trading orders. Its intuitive syntax makes it accessible, allowing users of all levels to understand the intent behind the code. Rainlang is open-source, permissionlessly extensible, and supports multiple interpreters to accommodate various versions.

**Orders**

Orders written in Rainlang offer near-limitless flexibility in strategy design. Each order specifies a maximum trade amount and price ratio, and execution occurs only if these exact terms are met.

The logic used to reach the final agreement can originate from on-chain oracles and smart contract data, or from off-chain signed data provided by solvers. The strategy ensures the correctness of this data by verifying the signature. Any logic can then be implemented on top of this, offering highly flexible trading intent.

**Strategies**

Strategies are a combination of conditions following custom logic that result in one or multiple Orders.

Strategies written in Rainlang can be deployed to achieve multiple objectives including On- chain market making, Treasury strategies, Portfolio / Fund strategies, Stablecoin arbitrage, Broker token arbitrage, DCA, Volatility-based strategies, Momentum-based strategies, Reversal-based strategies, Correlation arbitrage, DCF flows on fixed income products, buy side / sell side strategies

**Execution Model**

Strategies remain live on-chain until removed, without the need for ongoing execution fees from the order creator. Instead, the protocol incentivizes third-party solvers to fulfill orders by capitalizing on arbitrage opportunities, ensuring continuous execution.

**Vault System**

Tokens are deposited into vaults created by users that function as virtual accounts. Orders reference these vaults for inputs and outputs, allowing for complex and interconnected strategies. All vaults operate under a self-custody model, maintaining user control. Users deploy their own funds in and out of these vaults from their wallet.

## Order Book

The ST0x orderbook is an on-chain smart contract that incorporate dynamic algorithms directing token transfers between vaults.

Strategies formulated using Rainlang must determine a maximum amount and a price ratio for but offer near-limitless flexibility beyond this. Furthermore, Rainlang itself is permissionless extensible – the protocol facilitates the integration of multiple interpreters supporting various versions of the language.

Instead of granting token approvals, users deposit their tokens into vaults that function as virtual accounts within the orderbook. Orders reference input/output vaults, and each order can have multiple inputs and outputs. For instance, a user could accept a range of different stablecoins for WETH. Additionally, distinct orders can reference the same vaults, enabling the construction of even more sophisticated meta-strategies.


Strategies deployed on-chain remain active until filled or removed.
Order placers do not bear the gas costs associated with continuous strategy execution. Instead, the protocol fosters an ecosystem where fillers capitalize on arbitrage opportunities, guaranteeing active strategy execution without imposing burdens on the original order placer. Arbitrage can occur between two orders on the orderbook or between an order and external liquidity.

As a result, the ST0x orderbook resembles an intent-driven system.


## Order Lifecycle

Strategy writing: A user formulates a strategy including target assets and trade logic.

- Order deployment: User deposits required tokens into a Vault within the Rain orderbook and deploys the order on-chain. Vaults act like virtual accounts for the order. Once a strategy is deployed, it is visible to all participants who can interact with it.
- Order execution: When a participant (also referred to as a "filler") finds an order they want to interact with and the strategy's conditions are met, they execute the order. This involves the specified tokens moving between the designated input and output vaults as per the order's strategy.
- Order completion: The order lifecycle concludes with after successful execution and settlement. Depending on the design of the strategy, an order might be a one-time event or could remain live, waiting for the next execution that meets its conditions.
- Order & token removal: A placer can remove an order from the orderbook at any time prior to execution. Similarly, users can initiate token withdrawals from their vault and into their EOA or wallet at any time.

# ST0x Solvers

Solvers play a pivotal role in the functioning and efficiency of the market. The issuance contract and the Execution engine present trading intent from multiple different orders. To execute, trade orders must be triggered; this is performed by solvers.

A solver is a bot that analyzes the blockchain for arbitrage opportunities and automatically triggers trades between parties whose trading intents overlap.

It is important to note that solvers are not counterparties in the exchange. Their role is limited to triggering transactions between the parties.
Solvers can trigger trades in the ST0x Programmatic Intents System (order-to-order), between the Programmatic Intents System and the issuance contract (secondary-primary) or between any other external points of liquidity.
Anyone can program and deploy solvers on ST0x DEX to seek to capture arbitrage opportunities and thereby participate in improving the overall efficiency of the venue.

The ST0x solver is integrated with 200+ liquidity venues.

# ST0x Interface

The ST0x interface serves as a window into the on-chain activities, providing users with a clear and organized view of the data to better understand and navigate the trading environment. It abstracts the complexities of on-chain transactions and organizes information into a user- friendly format that enhances the overall trading experience.

- Tokenization Layer: the interface displays all records and transaction histories, allowing users to track their assets and past activities with ease.
- Market View Display (“MVD”): The MVD allows users to view the order book, market depth and other relevant data that enable the monitoring of market conditions and support the identification of potential trading opportunities.
The interface also includes some Order Management System (“OMS”) functionalities, including an order entry interface with pre-set strategies, such as limit orders, market orders (which operate through an auction mechanism), stop-loss, and take-profit orders.

Importantly, the interface does not allow users to interact directly with another user's liquidity or manipulate existing orders. There is no direct route provided for users to take liquidity from other orders. Instead, each user adds their own strategy to the orderbook, which can only be executed when a solver fulfills the exact terms specified by the user.

Users connect to the interface through their own wallets, maintaining full self-custody of their assets throughout the process. This ensures that all trades are conducted securely and independently, with each user maintaining control over their own funds and strategies.

## SDK for Distributors

ST0x has developed an SDK that enables distributors to easily connect to ST0x DEX. This SDK can be utilized by decentralized protocols looking to add additional functionality or by regulated institutions that wish to trade on our platform.

- The SDK offers the code needed to perform the same functions as the ST0x interface but integrates them into the distributor’s own app or interface.
- It includes code for viewing trades directly within the distributor’s environment.
- ST0x does not provide any infrastructure for taking orders directly or determining trade routes. The SDK only facilitates the addition of user strategies to the order book.

## Account abstraction

The SDK provides the essential components needed to interact with the DEX and execute trades. It can accommodate both self- and delegated custody models.

ST0x also intends to offer a self-custody solution to web2 partners that may not want users to manage their own wallets or lack the required custodial licenses. This service leverages Circle's signing methods, gas sponsorship, and smart contract accounts to simplify the user experience.

With this solution, users will be able to sign in using social logins, complete KYC, and trade without the need to manage gas fees or set up a traditional wallet. It is important to note that users utilizing this service will maintain full control over their assets.

This approach can be an attractive solution for Web2 Fintech companies that bridges a gap between traditional financial platforms and blockchain environments, providing seamless access to on-chain trading without compromising security.