Trading Campaign Infrastructure for Perp DEXs

Every perp DEX eventually runs a trading competition. It is the most reliable way to convert a marketing budget into measurable usage, and it is one of the few campaigns whose success criterion is the same as the business's: volume on the venue.

The competition itself is easy to describe and unpleasant to build. This is what the machinery consists of, so you can decide honestly whether to build it.

The five pieces

1. Identity and registration. You need to know which wallets are competing, from when. Sounds trivial; is not. Wallet-first registration means signature verification and session handling. Sub-accounts have to be aggregated to a single competitor. Late entrants need a defined start point, because counting volume from before someone registered is retroactive and unfair, while counting from the campaign start is exploitable.

2. Volume tracking. The part that consumes the engineering time. Whatever your API exposes, you need per-trader volume bucketed by day, reconciled, and idempotent under retries. Every venue integration is bespoke: some expose complete fill history, some expose only a cumulative counter you have to difference between snapshots, some gate history behind per-account auth so you reconstruct state from a block explorer instead. Each shape has its own failure modes — a missed snapshot silently zeroes a day, a paginated endpoint re-serves rows you must dedupe, a counter that resets destroys your baseline.

3. Scoring. Volume becomes points under rules that have to be identical everywhere they are computed: the leaderboard, the projected-rewards column, the settlement job. Day boundaries must be anchored consistently — Voltrade anchors them to the campaign start time rather than midnight UTC, so a comp beginning at 14:00 rolls its day at 14:00 across every venue. Getting this subtly wrong is how a leaderboard and a payout end up disagreeing, which is the single most damaging thing a campaign can do to your reputation.

4. Anti-abuse. A prize pool is a bounty on your scoring rules. Per-trader per-day counted-volume caps, minimum qualifying thresholds, pro-rata structures that make self-trading pay fees for a slice of your own money, and separating raw volume from counted volume in the display so the mechanism is legible. This has to be designed in, not bolted on after the first campaign is farmed.

5. Distribution. Ranking, tie handling, and getting money to winners — manual transfers, an on-chain claim rail like Merkl, or your own payout system. Plus the unglamorous surface: proof that the pool exists, a public rule that does not change mid-campaign, and a settlement that can be audited after the fact.

The costs nobody scopes

The build is maybe a few weeks. The maintenance is forever, and it is where teams get hurt:

• API drift. Venue endpoints change, rate limits tighten, pagination semantics shift. Every change is a silent scoring bug until someone notices their volume is missing.
• Rate limits. Public endpoints are metered per IP. A campaign with a thousand participants makes thousands of calls per sync, and the naive implementation gets throttled into producing wrong numbers rather than failing loudly.
• Disputes. Somebody will insist their volume was not counted. Without per-day audit rows you cannot answer, and "trust us" does not survive contact with a trader who is owed money.
• Support during, not after. Campaigns generate their support load while they run, when your team is busy.

What you actually want to own

The campaign, not the plumbing. Your differentiators are the budget, the rules, the markets you want to promote, and the traders you are trying to reach. None of those live in the sync job.

Voltrade is that layer: registration, tracking, scoring, leaderboards, anti-abuse and reward distribution, across venue integrations that already exist — perp DEXs, CEXs, on-chain EVM and Solana pools, and newer surfaces like predict markets. You define the campaign; the stack runs it. Traders keep trading on your venue with their own funds, so nothing about your product changes.

There is also a distribution effect that is easy to underrate. A campaign on your own site reaches people who already use you. A campaign on an aggregator reaches traders who are actively looking for competitions to enter — which is the population you are trying to acquire in the first place.

Measuring it properly

Two numbers determine whether a campaign worked:

• Cost per acquired trader — pool divided by new wallets that traded and then traded again after settlement. Not registrations. Not peak participants.
• Volume retention — the fraction of campaign-period volume still present two to four weeks later. This separates a campaign that bought users from one that rented mercenaries.

Both require data you only have if the campaign was instrumented from the start, which is another argument for not building it hastily yourself.

Where to start

If you run a venue and want to see the mechanism end to end, read Voltrade for exchanges, browse live competitions for how they present to traders, or look at the partner API docs for rendering competitions and leaderboards inside your own product.