Trade it where you issued it
In BuildA tenant can run several permissioned venues with their own members, calendar, and rules, where investors and desks trade listed token pairs.
DALP has issued, serviced, and settled regulated assets for two releases; secondary trading happened somewhere else. The Trading Venue closes that gap. The asset your compliance team configured is the asset your investors trade, under the same rules. The venue contract never gains custodian power over it.
An execution venue in front of your settlement layer
A venue is an exchange boundary: its own identity, access manager, admission policy, calendar, fee defaults, and escrow vault. A market is one trading line on one venue, listing any two platform tokens as base and quote, so the same pair on two venues is two markets with two books and two prices. Orders are signed intents the venue can neither fabricate nor alter, matching runs on price then time, and matched fills settle on chain in batches where one failing fill never blocks the rest.
- Market structure
- Central limit order book
- Venues
- As many per tenant as you need
- Listing
- The right to reserve, nothing more
- Compliance
- Token rules judge every delivery
Your book, your rules, your evidence
A venue combines order matching with admission rules, calendars, and records that operators can inspect. Configure the venue's controls alongside the listed tokens' transfer rules.
A venue keeps that activity on the platform, and you run as many venues as the business needs: one for retail members and one for institutional desks, or one per jurisdiction. Each venue admits its own members against its own required claims, keeps its own calendar and fee defaults, and answers for who may act on it from its own access manager. The token's own transfer rules remain the final judge when a leg is delivered. The platform records signed orders, book events, session transitions, auction results, stop triggers, fills, deliveries, undos, refused matches, and admission changes, and every record names the venue it belongs to, so one venue's trail is readable on its own.
- 1Sign
The trader signs the order's economic terms with their own key: price, quantity, expiry, and the maximum fee they accept. Settlement verifies that signature on chain before any token moves.
- 2Reserve
The venue commits the quantity through the token's own reservation backend: a hold inside the trader's own wallet for a DALP token, or the venue's escrow vault for a plain ERC-20. The order joins the book only once that reservation confirms on chain.
- 3Match
The engine matches on price, then on time. It refuses a trader's order against their own, and bounds a market order inside the market's price protection band.
- 4Deliver
A fill keeps both legs reserved until the market's holding period ends, then delivers them and the fee through each token's normal transfer path. A holding period of zero delivers in the fill's own transaction.
The venue holds no custodian power over what it lists
Listing grants the venue reservation authority. It does not give the venue forced-transfer, freeze, or recovery permissions. The one custodian role a listing adds goes to your organization's operations signer on both listed tokens, and the platform uses it for one job: reversing an already delivered trade after two operators approve a bust.
A resting order is backed by a reservation placed through the listed token's own reservation backend. For a DALP token that backend is the token's hold feature, and the units stay in the trader's own wallet: they cannot be spent elsewhere while the order works, and they leave the wallet only when the trade delivers. For a plain ERC-20, which has no such feature, the units sit in the venue's own escrow vault against the trader's approval, and the vault gives them back as a credit the trader claims rather than pushing them anywhere. Either way the venue can move only what it itself reserved, so two venues listing the same token can never reach each other's holds.
Markets that open and close like the ones your regulator knows
An institution running a venue answers to people who think in trading days, not in blocks. A market can trade continuously, or it can follow a trading calendar: a time zone, weekly session hours, and dated exceptions for holidays and half days. Sessions run themselves, and the operator can still delay an open, extend a session, close early, or halt at any moment. Every close computes an official closing price and anchors the next session's price limits with it.
A session market opens through a call auction, which collects orders without matching them and then clears them all at once. During the collection window everyone watches the same indicative opening price. At the open, the book clears at a single price chosen to maximise the volume that trades, and the settlement contract checks that one price against every filled order's own signed limit. The exact instant of the clear is drawn at random inside a published window and never announced, so there is no moment for a late order to aim at. Whatever does not match carries into continuous trading at its original place in the queue.
Protection for traders, guardrails for the market
A stop order rests dormant and reserves nothing. Capital commits only when a settled trade reaches the trigger price, and a trade that later fails settlement, or that the operator undoes, can never fire one. Around the traders, the operator sets price bands and per-order size limits that reject an out-of-bounds order when it arrives. Tightening a band never cancels a resting order quietly: the screen previews which orders the new limit would affect, and removing them is a separate, deliberate step.
Undo an error without pulling anything back
Every rulebook needs a remedy for a trade that should never have happened, and most remedies quietly assume somebody can pull the tokens back. This one does not need to.
Each market carries a holding period, set through the API when the market is listed. A fill inside a market with a holding period reports, prices, and publishes the trade at once, but keeps both legs reserved until the period ends. That window is the remedy, and the Console still calls it busting a trade. One operator proposes the bust, and the proposal holds the trade on the venue so its due time cannot deliver it. A second operator approves it, and the settlement service then undoes the trade by releasing both legs to their owners. No operator key can undo a trade on its own. No fee has moved, so nothing is refunded, and the unfilled remainders of both orders keep working. Published prices correct themselves afterwards, and the undone trade leaves clean history, candles, and published prices while staying flagged in both parties' record.
The same mechanism covers a delivery that cannot happen. If a token refuses a leg at its due time, or a custody event during the period leaves the reservation unbackable, the trade undoes itself the same way and both traders are told why. A market with a holding period of zero delivers inside the fill's own transaction and offers no window at all.
Restricted venue and market access
Restriction now works at two levels. A venue sets its own admission: the claims a participant must carry, whether membership is required, and whether the venue is even visible to someone it does not admit. An admitted-only venue is absent from every list, read, and stream for everyone else, and answers as not found. On top of that, a market can be created private and auction-only with its own approved list, keyed by identity, which only narrows what the venue already admits. That turns a restricted bond distribution or a secondary round into a first-class market with a full record behind it.
One boundary is worth stating for a reviewer: this is access control on the application surface, not secrecy on the chain. A venue's on-chain footprint, meaning its reservations, signature checks, fill accounting, and published prices, stays readable to anyone with chain access.
Integrate it
Everything the Console does runs on the versioned public API, with generated TypeScript SDK operations to match.
The venue and market reads list every venue and, under it, every market with its trading grid, fee schedule, price protection band, holding period, and status. Depth, trades, and candles hang off each market, and the streaming feed opens with a full depth snapshot and then sends numbered differences. Sequence numbers are per market, so two venues listing the same pair carry two independent streams; a gap in those numbers means reconnect for a fresh snapshot rather than render stale depth.
Order placement accepts the signed intent, runs the admission, desk-limit, and fee-cap checks, and answers with a status URL. Acceptance is not placement: an order becomes matchable only once its reservation confirms on chain, so read the outcome from the order's own state. An order reports one of nine statuses, four of them open and five terminal, and a closed order names the reason it closed.
A filled order is not a received leg. The trade carries its own delivery state, pending until the market's holding period ends and then delivered, or undone with the reason it was undone. Order cancellation queues the on-chain cancel, and a cancel-all covers every open order of one trader; a cancelled order can never fill, even if the engine matched it moments before the cancel arrived.
Compatibility
No migration is required, and nothing here changes an existing integration.
The venue is an optional addon. Its surface is additive v2 routes, contracts deployed by their own factory, and Console pages that appear only where a venue is deployed. The v1 API stays frozen, and every existing v2 route keeps its request and response shapes. The Console hides the venue selector while a tenant has one venue and shows it everywhere once there are two.
Three things stay with the operating institution: the broker or exchange legal role, the market-operation decisions, and the liquidity itself. The cash leg can be a platform token or a plain ERC-20 stablecoin, and money outside token form still needs its own rail.
Understand the venue → · Trade from the Console → · Operate venues, markets, and calendars →
DALP 3.2
Assets issued on the platform can now trade on its own permissioned order book, pay income to holders, and produce regulatory filings and audit records.
Primary offerings
A primary offering, the first sale of a new asset, now has both sides in the Console: a desk that runs the raise and a portal where investors subscribe.