Token liquidity is won or lost before launch

Aug 20, 2026

10 min read

Summarize with AI

Most tokenization projects treat liquidity as a later problem. Issue the token, get compliance right, then go find a venue and some market makers. I understand the sequencing, but it usually produces the same outcome: a technically correct token that trades once a month at a discount, if it trades at all.

The reason isn’t that nobody tried hard enough on the distribution side. It is that by the time anyone asks “where should this trade,” the answer has already been narrowed by decisions made months earlier, in legal structuring and token design sessions where nobody used the word “liquidity.” The end-to-end tokenization process covers those steps well. What I want to add here is the market-structure consequence of each one.

So the framing I would use with any issuer: liquidity isn’t a feature you add after launch. It is a set of constraints you either preserve or destroy while structuring the product.

Andrew Nalichaev

Blockchain Expert & DeFi Analyst

Andrew translates decentralized concepts into secure, functional financial tools. He navigates the volatile DeFi landscape to build scalable blockchain infrastructures that address real-world utility, moving past the buzzwords to deliver technical value.

View profile

Why "we will add liquidity later" rarely works

A secondary market needs someone willing to hold the asset between a buyer and a seller. That someone is a balance sheet, and balance sheets are rational. A market maker quoting your token is asking four questions before committing capital.

Can I price it? That depends on how often an authoritative valuation exists and whether it’s still meaningful outside the hours when it was struck.

Can I get out? That depends on whether redemption is available to me, in what size, and how quickly.

Can I hedge or finance the position? That depends on whether the token has a hedgeable underlying and whether anyone accepts it as collateral.

What happens when something changes? That depends on how distributions, valuation revisions, defaults, and eligibility changes are handled in the token contract and in the fund documents.

Notice that none of these are venue questions. Every one of them is answered by the structure of the product, and every one of them is answered before issuance. If the answers are bad, no amount of listing effort fixes them. A market maker doesn’t decline because your venue is unfashionable. It declines because the position is unpriceable, unhedgeable, or unexitable at a size that justifies the operational cost of being there.

That is also why compliance infrastructure alone never produces a market. Getting transfer restrictions enforced correctly is necessary, and it removes a barrier, but removing a barrier isn’t the same as creating a reason for capital to show up. I made that argument in more detail for permissioned AMM infrastructure in Uniswap v4 made regulated tokens AMM-compatible, it did not make them liquid, and the same logic applies to any compliance layer you build.

Five issuance decisions that set the liquidity ceiling

These are the decisions I would flag during structuring, before the token contract is written.

Decision 1: Valuation cadence

How often does an economically authoritative price exist, and where does it come from? A continuously observed external market, a daily NAV, a monthly NAV, a quarterly appraisal, or a model output.

This decision determines whether a continuously executable quote is defensible at all. If your NAV is struck quarterly, a market maker quoting continuously against a three-month-old number isn’t providing liquidity; it’s writing an option to whoever knows more than the last valuation. The rational response is a wide spread or no quote.

I have seen teams choose a quarterly cadence purely for administrative convenience, then be surprised that the token trades at a persistent discount. The discount is the market pricing valuation staleness. The decision was made during structuring, well before the asset reached the listing stage.

Decision 2: Redemption design

This is the single highest-leverage decision, and it’s almost always treated as a legal clause rather than as market infrastructure.

Redemption comes with a set of trading parameters, and each one has a direct impact on market structure:

Redemption parameter	What it decides	Market-structure consequence
Eligibility	Who may actually redeem	If only affiliates can redeem, price correction is administratively concentrated
Direction	One-way exit or two-way mint and redeem	One-way facilities produce asymmetric depth, deep on one side and thin on the other
Timing	Same-transaction, same-day, monthly, quarterly	Asynchronous redemption cannot support execution that must settle in one transaction
Size limits	Minimums, per-investor caps, aggregate daily caps	Correctable capacity equals the smallest remaining limit, not the fund's total assets
Price used	Current NAV or a prior period's NAV	Redeeming at a stale NAV gives an exit without giving a fresh arbitrage anchor
Settlement asset	What the investor actually receives, and its availability	Delivery liquidity is its own bottleneck, separate from the redemption right
Behavior under stress	Gates, suspensions, queue priority	A facility that closes when needed most isn't a correction path

The pattern worth internalizing: redemption is what lets a market maker convert inventory back into cash on demand. Its capacity, not its existence, is the number that bounds how much liquidity anyone can provide.

Two products can both say “redemption available” in the documentation and be completely different instruments. One offers instant two-way conversion for eligible investors within published daily limits. The other offers on-demand redemption at the previous quarter’s NAV. Both statements are true. Only the first supports a secondary market that stays near fair value.

Decision 3: The eligible participant set

Transfer restrictions are usually designed to satisfy a regulator. They also determine who is allowed to correct a mispricing, and that’s a market-structure decision hiding inside a compliance decision.

The questions I would ask at structuring: how many independent participants can be admitted, are they operationally independent or do they share a custodian and a hedging counterparty, do they have equal access to the primary facility, and can eligibility be changed while positions are open.

A permissioned market with several genuinely independent approved participants can be competitive. One where a single affiliate holds the inventory, controls the allowlist, and owns the redemption facility is something different, and it should be described honestly as an issuer-operated execution venue rather than as a market. That design often makes sense for a first product, but it also sets clear limits on what you can realistically promise investors about pricing.

Decision 4: Carry and collateral treatment

Two questions here. Does the asset generate income while held, and does that income actually reach whoever holds the token in inventory? And can the token be posted as collateral or financed?

Both affect whether holding inventory is economically survivable. A market maker holding a yield-bearing instrument is compensated for the time it sits on the book. A market maker holding a non-yielding token that can’t be financed is paying full carrying cost out of spread.

The technical detail that decides this is how income reaches holders: accumulating NAV, distributions, or a rebasing balance. Each interacts differently with wrapper contracts, pools, and custody arrangements. If distributions arrive at a contract that holds tokens on behalf of several parties, someone has to define how they are attributed. If that’s unspecified at design time, it becomes an integration problem later, and integration problems at this layer usually resolve by nobody providing liquidity.

Decision 5: Lifecycle and discontinuity handling

Valuation revisions, distributions, splits, defaults, workouts, eligibility revocation. The lifecycle management step covers the operational side. The market-structure side is narrower: what happens to trading while any of these are in progress?

The failure mode is specific. During a discontinuity, the last known price is wrong, and someone knows it before everyone else. If your design has no way to pause, widen, or move to a different execution mode, then the moment of maximum information asymmetry runs through a mechanism built for normal conditions. Whoever is providing liquidity absorbs the difference.

This is why I would define pause authority, reopening procedures, and the handling of unresolved corporate actions in the token design from the outset, well before the first dividend puts those rules to the test.

Structure your tokenized asset for secondary-market trading

What each decision does to your venue options

Once these five are fixed, the set of workable execution mechanisms is largely determined. The choice that feels like a decision later was mostly made earlier.

Structural profile	Realistic execution options
Frequent valuation, fast two-way redemption, broad eligible set, cash-like pair	Continuous mechanisms viable for smaller sizes; request-based quoting for blocks
Frequent valuation, capped or one-way redemption	Dealer quoting with asymmetric depth; continuous mechanisms only within tight bounds
Periodic NAV, redemption at prior period's price	Periodic auctions or negotiated transfers; continuous quoting invites adverse selection
Appraisal-based valuation, gated redemption, narrow eligibility	Issuer buyback windows, bulletin-board matching, negotiated transfers
Any profile with unhandled corporate actions	Nothing continuous until pause and reopening rules exist

I want to be precise about what this table is and is not. It doesn’t say a given asset class belongs on a given venue. Venue suitability isn’t a fixed property of a token. It depends on the instrument, the trading pair, the primary-market path, the eligible participants, the specific order, and the market state. I worked through that as a five-part diagnostic in AMM, RFQ, or order book? A market-structure test for tokenized assets. What the table above does say is that structuring decisions remove options from that diagnostic before anyone gets to run it.

The practical consequence for an issuer is that the same asset may need several execution paths at once. A small conversion, an institutional block, and a forced exit are three different problems even when the token is identical. Designing for one and assuming the others will follow is how projects end up with a venue that technically works and practically doesn’t.

Where the platform choice makes these decisions for you

This is the part I would flag hardest for teams evaluating build versus buy.

A ready-made tokenization platform isn’t neutral with respect to the five decisions above. It ships with an opinion about valuation feeds, a redemption workflow, a compliance and eligibility model, a distribution mechanism, and a set of venues it integrates with. Choosing the platform means inheriting those opinions, and some of them are difficult to change later without reissuing.

That isn’t an argument against platforms. For many issuers, a platform’s defaults are perfectly reasonable and the speed advantage is real. The comparison between ready-made platforms and custom solutions goes through the trade-offs properly. My addition is one question to add to the evaluation:

Which of the five structural decisions does this platform fix, and are its defaults compatible with the market structure we need?

Concretely, I would ask a vendor: can we run a two-way primary facility with configurable limits, or only a subscription-and-redemption request queue? Can eligibility be extended to multiple independent market makers, or is the model built around one distributor? How are distributions attributed when tokens sit in a pool or a custody contract? What is the pause mechanism during corporate actions, and who controls it?

If a platform can’t answer those, it isn’t necessarily the wrong platform. But you are accepting a liquidity ceiling without measuring it, and that ceiling will not be visible until you try to build a market.

Evaluate whether your tokenization stack supports the market you need

What I would check before signing off on the structure

Here is the checklist I would run at the end of structuring, before the token contract is finalized.

Check	What I would expect to see
Valuation cadence	A stated frequency, a named source, and a defined behavior when the price is stale or unavailable
Redemption capacity	Eligibility, direction, timing, minimums, caps, price basis, settlement asset, and stress behavior
Participant breadth	The number of independent participants who can hold inventory and access the primary facility
Carry attribution	How income reaches a holder, including when tokens sit in a pool or custody contract
Collateral treatment	Whether the token can be financed or posted, and with whom
Discontinuity policy	Pause authority, trigger conditions, and a defined reopening procedure
Venue implications	A written statement of which execution mechanisms remain viable given the four points above

The last row is the one most often missing. Teams document the legal structure and the technical architecture, but rarely write down what those choices imply for trading. I would make that an explicit artifact, because it’s the document that tells you whether the liquidity you plan to promise is achievable.

The honest version of this conversation with an issuer sounds like: we can tokenize this, and here is the market structure your chosen parameters allow. If that market structure isn’t what you had in mind, the time to change it is now, while it’s still a document rather than a deployed contract and a set of investor expectations.

Contact us

Book a call or fill out the form below and we’ll get back to you once we’ve processed your request.

Name

Company

Phone

Message

Send us a voice message

Attach documents

Upload file

You can attach 1 file up to 2MB. Valid file formats: pdf, jpg, jpeg, png.

By clicking Send, you consent to Innowise processing your personal data per our Privacy Policy to provide you with relevant information. By submitting your phone number, you agree that we may contact you via voice calls, SMS, and messaging apps. Calling, message, and data rates may apply.

You can also send us your request
to contact@innowise.com

What happens next?

Once we’ve received and processed your request, we’ll get back to you to detail your project needs and sign an NDA to ensure confidentiality.

After examining your wants, needs, and expectations, our team will devise a project proposal with the scope of work, team size, time, and cost estimates.

We’ll arrange a meeting with you to discuss the offer and nail down the details.

Finally, we’ll sign a contract and start working on your project right away.