In CEX vs DEX marketing, centralised and decentralised exchanges compete for the same trader and market to two different people. A CEX sells trust and convenience to someone who wants an account. A DEX sells self-custody and access to someone who already has a wallet and does not want an account. Running the same campaign for both is the most common waste in exchange marketing, because the second audience is repelled by exactly the message that converts the first.
The measurable consequence is where the funnel breaks. A CEX loses people at identity verification. A DEX loses them at the wallet connect step, and the two failures need opposite fixes: one is a friction problem you can only smooth, the other is a trust problem you can only answer.
CEX vs DEX marketing: two funnels, two failure points
| CEX | DEX | |
|---|---|---|
| What is being sold | Custody, liquidity, fiat access | Self-custody, access to new assets, no gatekeeping |
| Conversion event | Verified account, then first deposit | Wallet connect, then first swap |
| Where users drop | Identity verification and funding | Wallet connect and the first transaction fee |
| Trust question | Will you hold my money safely | Can this contract drain my wallet |
| Acquisition channel that works | Paid media, comparison content, referrals | Communities, aggregators, token listings, developer channels |
| What kills it | A withdrawal freeze | A contract exploit |
Why CEX marketing looks like fintech and DEX marketing does not
A centralised exchange can run recognisable performance marketing because it has an account, an email address and a funnel that behaves like a financial product. Cost per funded account is the honest metric, and the gap between registration and funding is where budgets are quietly lost, because campaigns optimised to signups reliably buy people who never deposit.
A decentralised exchange has none of that. The user arrives as a browser session and converts as a wallet, and nothing joins those identities for you. Attribution is partial by design, so campaign planning has to define the on-chain event that counts before launch rather than reconstructing it afterwards.
Where each actually finds users
- CEX: comparison and fee content. People choosing an exchange compare fees, supported assets and withdrawal limits, and those queries convert.
- CEX: referral mechanics. The account model makes referral tracking trivial, which is why it works here and barely functions for a DEX.
- DEX: aggregators and trackers. Being routable and findable matters more than being advertised.
- DEX: the communities around the assets you list. Traders arrive for a specific token, not for the venue.
- Both: block explorer placement. The visitor already has a wallet open and is inspecting a transaction.
The metric each side of CEX vs DEX marketing should report
For a centralised exchange, cost per funded account and thirty-day active traders. For a decentralised one, wallets that completed a first swap and returned within thirty days. Both are unflattering next to registration and visit counts, which is precisely why they are the figures that predict whether the venue survives its own launch spike.
The acquisition work behind either sits in the same place: how we acquire traders for exchanges.
Instrumenting both funnels before launch
Decide which event counts before any money is spent, and write it down where the media team and the product team can both see it. On a centralised exchange the useful chain is registration, verification started, verification passed, first deposit cleared. On a decentralised one it is wallet connect, first swap confirmed on chain, and a second swap inside thirty days. Campaigns that define the event afterwards end up optimising towards whatever happened to be tracked.
On the account side, send the conversion events from the server rather than the page. A deposit that is counted when it is initiated instead of when it clears inflates every cost figure in the report, and the gap is largest exactly where the traffic is worst. Agree the attribution window before launch too, because a first deposit often lands days after the click, and a window chosen after the results arrive is a window chosen to flatter them.
Agree a campaign naming convention on day one and let one person own it. Channel, geo, audience and creative in fixed positions sounds trivial until three agencies and two in-house teams are buying at once and nothing can be grouped. The report an exchange needs is cost per funded account by channel and geo, and that report is impossible to assemble from parameters that were invented per campaign.
Fix the day the numbers are cut as well as the definitions. Thirty-day active traders and wallets that came back for a second swap are both cohort measures, and a cohort recalculated whenever someone asks produces a different answer every time. Run the same query on the same weekday, keep the output, and compare cohorts against each other rather than against a running total that grows with the account base.
What breaks in wallet attribution
The link between a session and a wallet is where decentralised campaigns lose their data. A mobile user taps an ad, the site opens in an in-app browser, the wallet redirect starts a fresh session and the campaign parameter is gone before the connect happens. Persist the parameter in storage at first landing, restore it after the redirect, and pass it into the swap itself where the router accepts a referral tag, so the record survives the handover.
Then clean what arrives. One person often connects several wallets, contract addresses appear in the data as if they were users, and a share of connects never sign anything at all. Exclude team and test wallets by address, cohort by the date of the connect rather than the date of the swap, and treat a wallet that connects without swapping as a separate group. It usually points at a broken chain or a missing balance rather than at weak creative.
Keep the two reports apart. Cost per funded account and cost per first swap are not comparable numbers, and putting them in one table produces a decision to move budget on the basis of an arithmetic artefact. Reconcile weekly against the on-chain record and the exchange back end rather than against the ad platform, because the platform reports what it can see, and on the decentralised side that is almost nothing.
Media buying, referrals and partner contracts
Paid acquisition for a centralised exchange runs inside a financial advertising category, which means account approval, creative review and country restrictions before anything goes live. Build that lead time into the plan instead of discovering it in launch week. The rejections that repeat are earnings language, anything read as a guaranteed return, and landing pages whose terms do not match the offer in the ad. Prepare a compliant page per market rather than one page with a language switcher.
On search, split brand terms from comparison and fee terms, because they behave differently and one will quietly consume the other’s budget. Comparison queries convert, so give them their own campaigns and their own landing pages. Add negatives for support and complaint phrasing, where the searcher wants a withdrawal fixed rather than an account opened. Hold a bid on your own brand terms as well, since the alternative is a phishing clone occupying that result.
Creative cannot be shared across the two models even when the product looks similar. The account side answers the question about whether the money is safe, so proof of custody arrangements, funding options and support response beat any promise of returns. The wallet side answers a different question about whether a contract can drain the wallet, and audits, contract addresses and a verifiable front end URL are what the audience checks before connecting.
Build the landing page per market rather than per campaign. The funding methods, the verification requirements and the supported assets differ by country, and a page that lists options the visitor cannot use loses them before the form. Route by the market the campaign targeted rather than by browser language, and keep a page that states plainly which countries are not served, because that answer given early costs far less than a rejection after verification.
Referral and affiliate terms that survive
Referral works for an account model because attribution is trivial, and that is exactly why the terms need to be strict. Pay on a funded account rather than a registration, set a hold period before payout, and write a clawback window covering reversed deposits and self-referrals. Check for duplicate devices and shared payment instruments before releasing payment, cap the monthly payout per partner until a partner has a record, and reconcile the partner report against your own every month.
Without accounts the same mechanic has to be rebuilt on chain, and it pays on routed volume rather than on clicks. Where the router supports a referral tag, give each partner their own and settle from the on-chain record, which nobody can dispute afterwards. Creator deals need the deliverable, the disclosure, the live window, and what happens if a post is deleted early written into the contract, with part of the fee paid after the agreed window has passed.
The same discipline applies to agencies. Ad accounts, pixels and the event data belong to the exchange rather than to the buyer, and that has to be in the contract before the accounts are created, not after a relationship ends. Fix the reporting format and the reporting day as well. A partner who reports in their own template every month is a partner whose numbers cannot be compared with anything you hold.
CEX vs DEX marketing when the funnel breaks
Both models have a failure that stops acquisition being defensible: a withdrawal problem on one side, a contract exploit on the other. Decide now who is allowed to pause spend, and give that person access rather than a request queue. The rule should be written as a trigger rather than a judgement call, so that a support backlog beyond an agreed threshold or any unexplained contract behaviour pauses acquisition automatically while the question is answered.
During an incident, say what is known, say what is not known yet, and publish the time of the next update. Meeting that time matters more than the content of the update. Do not promise a resolution hour that depends on a third party, and make sure the community channel, the status page and support replies carry the same wording, because screenshots of two different answers are what turns an incident into a longer story.
Staff the support queue before the campaign rather than during the incident, and watch the queue as a marketing number. Verification times stretch under a traffic spike, and a spike is what a campaign is for. An exchange that buys traffic into a queue it cannot clear is paying for registrations that expire at exactly the step the money was meant to get them through.
Write the playbook before launch, while nothing is on fire. One page is enough: the triggers that pause spend, who holds the access, where the first statement is published, who writes it, who approves it and how often updates follow. Incidents are handled badly not because teams lack judgement but because the first hour is spent deciding who decides, and that hour is the one the audience remembers.
Restarting spend after an incident
Restart when the step the campaign pushes people into is measurably working again, not when the thread has gone quiet. Check the verification queue length or the swap success rate first, bring retention and brand campaigns back before acquisition, and expect a worse cost per funded account for a period while the search results still carry the incident. Budget for that instead of reading it as a media problem and moving spend between channels.
Paused budget does not have to sit idle. Support content, documentation, proof of reserves or audit material and answers to the questions the incident generated are all worth producing in that window, and they are what the next acquisition campaign lands on. Coming back with the same creative and the same landing page that ran the week before an incident is the most expensive option available.
The everyday breakages are less dramatic and cost more in total. A verification backlog after a spike, a geo block quietly rejecting a market you are buying, RPC errors at connect, a failed first swap because the estimate was short, and a gas spike that makes the first transaction look expensive all present as a fall in conversion with no change in the ads. Alert on the conversion event itself and the cause is usually obvious within an hour.
Brand protection belongs in the same plan. Cloned front ends buy the same search terms and imitate the same wallet prompts, and a user who loses funds to one of them attributes the loss to the venue rather than to the clone. Publish the single official URL in every campaign and in the community pinned message, keep a bid on the brand term, and file takedowns as routine work rather than as an emergency each time.
Frequently Asked Questions
Should a CEX and a DEX use the same marketing?
No. A CEX sells custody and convenience to someone who wants an account; a DEX sells self-custody to someone who already has a wallet and does not. The message that converts one repels the other.
Where do users drop off?
On a centralised exchange, at identity verification and funding. On a decentralised one, at wallet connect and the first transaction. One is friction, the other is trust, and they need different fixes.
What should an exchange measure?
For a CEX, cost per funded account and thirty-day active traders. For a DEX, wallets completing a first swap and returning within thirty days. Registrations and visits are the figures budgets inflate.
Why does referral marketing work better for a CEX?
Because the account model makes attribution trivial. A DEX has no account to attach a referral to, so the same mechanic delivers far less.