Building a Tokenized Securities Venue: From First Pool to Ongoing Liquidity Operations

The first pool is funded. An eligible participant buys. The transaction succeeds. The venue has demonstrated that a trade can execute.

The next question is whether it can keep serving the market it intends to build. Repeated purchases consume stock inventory. A price move changes where liquidity is useful. A delayed management action can leave yesterday’s configuration serving today’s orders.

For a Tokenized Securities Venue (TSV), those are product and operating decisions as much as technical ones. Participants experience them through the price, size and availability of their next trade.

Steer provides infrastructure across supported trading connections, liquidity management, programmable account permissions and operating data. A TSV evaluating those components needs an agreed plan: the service to deliver, the capital behind it, the actions software may take and the people responsible when conditions change.

The following six steps turn that plan into a concrete first-market brief. They focus on liquidity operations; a venue’s wider legal, access and reporting work remains part of its launch programme.

1. Define the trading service before selecting the strategy

Start with the participant and the order. Which asset pair will the venue support? What sizes should an eligible investor be able to buy and sell? Against which reference will execution be assessed, and which fees and transaction costs count?

A statement such as “support institutional liquidity” leaves too much open. A useful specification names the order sizes, cost limits, operating conditions and measurement method. It also explains what participants can expect when capacity is reduced.

That specification gives the product lead and liquidity partner a shared acceptance criterion. A funded pool can then be tested against the service the venue intends to offer.

Steer’s strategy configuration is evaluated against that objective. The venue chooses the service target; the capital provider agrees the exposure needed to pursue it. Neither a deposit total nor a strategy name establishes that the target can be met.

2. Connect trading routes and secure inventory

Opening balances answer how the market starts. The capital arrangement must also explain what happens after those balances change.

Identify who supplies stock tokens and the payment asset, how much is committed, and when those assets may be withdrawn. Then name the replenishment sources, settlement times and party funding any delay. A prospective source should not be counted as available inventory until its access and delivery terms are established.

Consider a market experiencing sustained buying. Moving the remaining stock into a tighter range may improve a nearby quote, but it does not obtain replacement stock. The venue needs to know whether its liquidity partner can replenish, at what cost, and what service is offered while delivery is pending.

Steer’s hook architecture connects eligible orders from supported trading channels to pool liquidity and supported issuer minting or redemption processes. For a TSV, the implementation must identify which connections serve secondary trading and which belong to a separate inventory-replenishment process. An issuer connection alone does not establish immediate delivery or funding.

Document the route from an eligible participant’s order to its completed settlement. If the design uses more than one source, specify what happens when only part of the order can complete, including partial fills, unsettled payments and refunds. Inventory acquisition and funding require explicit commitments from the parties providing them.

3. Configure liquidity around a written mandate

The liquidity mandate translates the service target and capital limits into operating instructions.

It should identify the reference-price source, acceptable data age, placement policy and conditions for adjustment. It should also state which actions may proceed automatically and which require intervention. A price input needs defined treatment when the source is stale, unavailable or inconsistent with market status.

Steer’s Dynamic Rebalance framework exposes controls for placement, range width, liquidity distribution and rebalance triggers, including external-data inputs. Smart Pools automates management across multiple concentrated-liquidity positions.

For a TSV, these are tools for expressing the agreed mandate. A supported configuration can be assessed for depth near the reference, coverage as prices move, inventory exposure and the cost of adjustment.

The implementation team should record the chosen settings and test them against the proposed market. Narrower ranges, for example, may improve local depth while requiring a more active response to price movement. The venue and capital provider need to accept that operating trade-off together.

4. Enforce operating permissions and test interruptions

A venue combines several kinds of authority: permission to trade, permission to deposit capital, authority to manage a position and authority to stop the market. Each must reach the intended contract or route.

Matador provides programmable permissions for supported smart accounts. Teams can define authorized operators, permitted contract calls, value limits and conditions for routed actions. This can give a liquidity operator or automated service defined authority within a configured policy. The integration must verify that the intended execution paths are covered and that policy changes have an owner.

These account permissions are separate from participant admission and the asset’s transfer restrictions. For example, restricting deposits into a liquidity vault does not by itself establish who may swap against the pool. Similarly, pausing a strategy does not necessarily stop trading against liquidity already deployed.

Define the conditions for stopping each relevant trading route and the evidence required before restarting it. Test those controls alongside the liquidity strategy so that a management pause is not mistaken for a market-wide stop.

Asset lifecycle events also need an owner. For splits, distributions or token upgrades, establish which balances, price units, token contracts and investor entitlements may change. Identify the data updates and reconciliations required before trading resumes. These responsibilities belong in the asset’s operating plan; they should not be assumed to be automated by a liquidity strategy.

Record the exact contract versions and applicable security reviews, upgrade authority and privileged-key roles. Assess whether other participants can exploit the ordering of strategy transactions, including through front-running, and define how those transactions are submitted and bounded. Assign responsibility for monitoring and responding to those risks.

Before launch, exercise the actual paths: rejected access, stale reference data, an unsuccessful management transaction, unavailable replenishment and a trading stoppage. For each, record the resulting market state, escalation owner and restart conditions.

Steer’s contribution is the configured behaviour of the hook, strategy and account-permission components included in the integration. Venue-wide access, halts and recovery must be assigned and verified across the complete trading system.

5. Measure the service and reconcile the capital

The operating review needs to answer two different questions: can participants execute the intended trades, and what is happening to the capital providing that service?

For execution, track quotes at agreed sizes in both directions, benchmark timestamps, periods below target and recovery time. For capital, reconcile opening assets, deposits, withdrawals, trading flows, fees, expenses and closing inventory. State the valuation method used to turn those balances into a reported value.

This prevents an apparently healthy capital total from obscuring weak quotes. It also prevents fee income from being treated as the complete result for liquidity providers.

Steer’s vault-accounting outputs include managed holdings, share supply and accumulated fees. Include the selected deployment’s position, transaction and accounting outputs in the integration specification. Confirm the available fields, access method and reconciliation process before relying on them in an operating report. The venue and its partners must assemble the full record, including activity outside the managed position.

An automated transaction completing successfully is useful evidence. Restoring the intended trading service within the agreed capital limits is the operating outcome to measure.

6. Make the second market easier to launch

The first implementation should leave behind more than a working pool. The handover should contain the approved configuration, responsibility map, interface and data-field specifications, completed acceptance-test report and operating runbook. Name an owner for each deliverable and record the conditions for launch acceptance. Another market can then reuse compatible work.

A second asset still needs its own assessment. Different transfer restrictions, reference-data behaviour, inventory sources or settlement terms may change both the strategy and its controls.

Steer’s configurable infrastructure provides a basis for reusing compatible hook connections, liquidity strategies, account-permission policies and accounting integrations. The venue’s opportunity is to standardize how those components are assessed and operated, while recording the decisions specific to each asset.

That gives engineering and operations teams a practical starting point for expansion: which components can be reused, which assumptions have changed and which tests must be repeated. It also makes the incremental work easier to scope with partners.

Agree what the first-market pilot must demonstrate

Use a small set of observable outcomes to connect the implementation to a launch decision:

Participant access and execution. Retain access-test results and buy/sell quotes at the target sizes, with all included costs and timestamped benchmarks.

Depth under changing conditions. Record results after directional flow, price movement and delayed strategy execution.

Recovery within limits. Retain the recovery actions, elapsed time, funding used and quotes available afterward. Test the outcome when the primary inventory route is unavailable.

Permission enforcement. Show that approved actions can proceed and that disallowed calls or amounts are rejected at the intended account or contract. Record who can change those permissions.

Interruption and restart. Exercise every relevant trading path, record the resulting market state and verify the conditions for restarting service.

Capital reconciliation. Reconcile asset movements, fees, expenses and balances across the pool and associated accounts. Include incomplete orders and any external settlement still pending.

These proposed acceptance tests give the venue, capital provider and technology team a common basis for deciding whether the scoped operation is ready. Record any unresolved failures, the owner of each issue and whether it blocks launch. They cover the implementation described here, rather than every obligation involved in operating a venue.

Bring Steer a market brief

A productive partner discussion starts with the asset pair, intended participants, buy and sell sizes, reference-price source, capital provider and replenishment arrangements. Add the proposed chain and pool implementation, intended order routes, venue controls and people authorized to approve strategy or permission changes.

That brief gives Steer and the TSV team a basis for defining the supported configuration, integration work and pilot evidence. It connects the first pool to the operation that must sustain it.

Building a TSV? Bring Steer your first trading pair, target order sizes, capital arrangements and operating requirements to scope the infrastructure and pilot.