User Acquisition for Perp DEXs: The Campaign Playbook

Perp DEX user acquisition is unusual in one respect that shapes everything else: the thing you want — volume on your venue — is directly measurable, attributable to a wallet, and payable against. Almost no other consumer category can condition a reward on the exact outcome it is buying.

That advantage is routinely squandered by running campaigns that measure the wrong thing. This is the playbook: what to run, how to split a budget across campaign types, what to measure, and the specific mistakes that make a bad campaign look like a good one.

The campaign types, and what each one is for

Different structures buy different things. Choosing by what is fashionable rather than by what you need is the most common error at the top of the funnel.

Most venues over-invest in the first row and under-invest in the third and fourth. Fixed tiers make a great screenshot and acquire a small number of traders who were already competitive. Threshold and raffle structures are what convert first-time users, because they answer the question a new trader actually asks — "what do I get for showing up?" — with a number rather than a rank.

Sponsored entry-fee challenges are worth a mention as a distinct instrument. The creator seeds a pool up front, and every entrant's ticket then splits three ways between the creator, the platform and the prize pool. That makes an event that grows its own prize with turnout, which is a very different budget profile from a fixed pool — and a different anti-abuse profile, because a paid entry is itself a filter.

Allocating a budget

A useful default split for a venue running its first serious quarter of campaigns:

• ~50% to a recurring pro-rata or threshold campaign. This is the workhorse. It runs continuously, it converts new wallets at a predictable cost, and it produces the cohort data everything else is measured against.
• ~30% to periodic leaderboard events. These are the marketing artefact — a defined window, a podium, something to announce. Run them on top of the workhorse rather than instead of it.
• ~20% to retention mechanics. Raffles, streak structures, or a second-week multiplier. This is the budget line that is always cut first and is usually the one that changes the retention number.

Two allocation rules that matter more than the split:

Do not spend it all in one window. A single large campaign produces one spike and one cliff. The same budget across three sequential campaigns produces three chances to learn something and a much better retention read, because you can see whether cohort one is still trading during campaign three.

Reserve some for the markets you actually want promoted. A campaign scoped to specific markets moves flow where you need it — a new listing, a market with market-maker commitments to justify, a pair where depth is the bottleneck. An unscoped campaign moves flow to whatever is already busiest, which is the flow you already had.

Measuring it properly

Three numbers. Nothing else belongs on the report.

1. Cost per acquired trader. Pool divided by wallets that traded during the campaign and traded again after it settled. Not registrations. Not peak participants. Not unique wallets. The post-settlement trade is the entire definition — without it you are counting people who were paid to appear once.

2. Volume retention. The fraction of campaign-period volume still present two to four weeks after settlement. Some proportion of campaign volume is mercenary by construction and will leave with the pool; that is expected and not a scandal. The ratio that remains is the campaign's result. A campaign with a smaller peak and better retention beat the one with the bigger screenshot.

3. Cost per dollar of counted volume. Pool divided by the volume the rules actually counted — not raw traded volume. The gap between the two is your anti-abuse machinery doing its job, and it is worth reporting both so the gap is visible rather than buried.

All three require instrumentation from the start. You cannot reconstruct a retention cohort after the fact from a leaderboard screenshot, which is a practical argument for running campaigns on infrastructure that stores per-day, per-trader rows rather than a rolled-up total.

Common mistakes

Reporting peak volume. The most-quoted number and the least informative. Peak volume during a campaign measures the size of the pool and the aggressiveness of the field, not the value of either.

Counting registrations as acquisitions. Registration is free. It measures how easy your form is.

No anti-abuse until after the first campaign is farmed. A prize pool is a bounty on your scoring rules. Per-day counted-volume caps, a minimum qualifying volume, and pro-rata economics have to be designed in from the start — bolting them on afterwards means changing the rules mid-campaign, which is the single most damaging thing you can do to a competition's credibility.

Changing anything mid-campaign. Rules must be published and then frozen. If you have to change something, the campaign is over and a new one starts.

A leaderboard that disagrees with the payout. This is the reputational failure that outlasts everything else. It happens when scoring is computed in more than one place — the live leaderboard, the projected-rewards column, the settlement job — and the implementations drift. They must share one definition, including day boundaries. Anchoring day buckets to campaign start rather than midnight UTC is the kind of detail that quietly produces two different answers if only one of the three code paths knows about it.

Campaigning into thin depth. Induced volume against a shallow book produces terrible fills. The trader's takeaway is "this venue slips", which is worse than not having run the campaign.

Running only on your own surface. Covered below, because it is the biggest one.

The distribution argument

Here is the structural problem with running competitions only on your own site: a campaign on your own site reaches people who already use you.

That is not a user acquisition channel. It is a retention and reactivation channel — a valuable one, but it is not the thing the budget was approved for. Every trader who sees the campaign is already a trader you have.

An aggregator inverts the population. People browsing a list of live competitions are, by definition, actively looking for a competition to enter. They are the highest-intent possible audience for exactly the thing you are offering, and most of them are not your users yet. The same pool that reactivates your existing base on your own site acquires new wallets on a surface where competitions are the product.

There is a second-order effect worth naming. On an aggregator your campaign is displayed next to other venues' campaigns, which is uncomfortable and also honest: it prices your pool against the market. If your terms are weak you will find out immediately rather than after the quarter. Most growth teams discover their pool was mis-sized only in the retrospective.

What to own and what not to build

Your differentiators are the budget, the rules, the markets you want promoted, and the traders you are trying to reach. None of them live in the sync job.

The machinery underneath — wallet registration and sub-account aggregation, per-day volume tracking that is idempotent under retries, scoring that is identical in the leaderboard and in settlement, anti-abuse, and a payout rail — is a few weeks to build and forever to maintain, and the maintenance is where teams get hurt. Venue APIs drift, rate limits tighten, pagination semantics shift, and every one of those is a silent scoring bug until a trader who is owed money notices. Trading campaign infrastructure for perp DEXs is the full inventory of what that involves.

Voltrade runs that layer across venue integrations that already exist — perp DEXs, CEXs, on-chain EVM and Solana pools, options and predict markets — with the shapes those integrations come in already handled: full fill history where a venue exposes it, cumulative-counter deltas where it exposes only a running total, block-explorer replay where history is auth-gated per account. Traders keep trading on your venue with their own funds, so nothing about your product changes.

Where to start

If you run a venue, look at Voltrade for exchanges for the campaign side, browse live competitions to see how they present to traders, or read the partner API docs for rendering competitions and leaderboards inside your own product. Before you fund anything, read wash-trading resistance in volume campaigns — the rules you set on day one determine what your pool actually buys — and reward rails compared for how the money gets to winners.