Reward Rails Compared: Manual, Merkl and Partner-Direct

The campaign ends, the leaderboard freezes, and someone has to move money to a few hundred wallets. This part gets scoped last and causes the most damage when it goes wrong, because a payout dispute is the campaign failure traders talk about publicly for months.

Three rails are in use on Voltrade, and a campaign or offer declares which one it is on. Each trades a different thing away.

The three rails at a glance

Manual: the operator pays out

The default. Voltrade distributes the prize pool off-platform after settlement, against the published rule and the frozen leaderboard.

Why it is the default: it works everywhere. No chain requirement, no token whitelist, no contract to fund, no claim for the winner to perform. A Solana-tracked competition and one on a chain nothing else supports are handled the same way. Winners with no gas, no bridging and no patience still get paid — the money simply arrives.

What you give up: every property of the other two rails is replaced by trust in the operator, and auditability is only as good as what gets published afterwards. Settlement is operationally linear — a field of five hundred is five hundred transfers, and someone is checking them.

When it fits: small to medium fields, new or unusual chains, non-EVM winner sets, and one-off campaigns where standing up a distribution is more work than the payout itself.

Merkl: fund once, winners claim

The Merkl rail uses a JSON-airdrop model. The mechanism, concretely:

1. Settlement produces a recipient list — an explicit map of checksummed address to raw token amount, built from the campaign's finalised reward rows.
2. That list is submitted and the campaign funded.
3. Merkl publishes a Merkle root committing to the whole list.
4. Winners claim against the Distributor contract, from a claim button on the competition page.

What this buys you:

• One funding transaction instead of N transfers. Cost and operational effort stop scaling with the winner list, which is what makes large fields viable.
• Settlement becomes verifiable. The root commits to the full allocation. Anyone can check their own entry is in it and that nobody's amount changed afterwards — the strongest auditability of the three, and the reason to reach for this rail when the payout will be scrutinised.
• Claims are pull, not push. No payout job that half-completes and leaves a spreadsheet of "did this one go out?".

What it costs you:

• Winners pay gas and have to show up. A pull model means unclaimed rewards, and the smallest cheques are the likeliest to be left on the table because the claim costs more than the prize. A long tail of tiny payouts quietly does not get paid.
• EVM only, in practice. The recipient list is built from EVM addresses; non-EVM or invalid addresses are skipped rather than paid. A campaign whose winners are Solana wallets is not a Merkl campaign.
• There is a fee. Merkl takes a small top-up on airdrop distributions — 50 basis points at the time of writing. Decide up front whether it comes out of the pool or your budget, and say so in the rules.
• Token and chain support is not universal. USDC on the major EVM chains — Base, Ethereum, Arbitrum, Optimism, Polygon — is the well-trodden path, Base by default. Other tokens or chains may need a one-off whitelist before you can fund: a lead-time item, not a launch-day discovery. Confirm distributor addresses per chain before funding a new one.
• You still fund up front. The trust window moves from "will they pay?" to "is the campaign funded?" — better, not zero.

When it fits: large EVM fields, campaigns where public verifiability is part of the pitch, and any programme you intend to run repeatedly — the setup cost amortises.

Partner-direct: the venue pays its own winners

Some rewards never touch Voltrade's treasury at all. The venue or partner distributes them through their own system — an exchange crediting balances, a protocol running its own distribution, a project sending tokens from its own multisig.

In this mode Voltrade tracks, ranks and settles, and the competition page states plainly that rewards are distributed directly by the partner rather than claimed on Voltrade, with proof links attached where the partner publishes them.

What this buys:

• The partner keeps custody. No prize pool leaves their control, which for a regulated or treasury-constrained venue is often the only workable arrangement.
• Rewards can be things Voltrade cannot send. Fee credits, account-level rebates, tier upgrades, off-chain perks. A rail that only moves ERC-20s cannot express those.
• Existing distribution reused. If the venue already pays out points or rebates weekly, the campaign becomes one more input to a machine that works.

What it costs:

• Trust concentrates entirely on the partner, and the platform cannot compensate a winner the partner did not pay. This is the rail where the reputational risk is least controllable.
• Auditability depends on the partner publishing proof. Proof links are supported and displayed; they are not enforceable.
• Timing is theirs. Campaign end and payout date can drift apart, and traders will ask you about it.

When it fits: venue-native reward programmes, fee rebates and non-transferable rewards, and any campaign where the sponsor cannot hand over the pool.

How to choose

Four questions get you there.

Who is allowed to hold the money? If the answer is "only the venue", it is partner-direct and the rest is academic.

How many winners, and how small is the smallest cheque? Under a few dozen, manual is simpler than anything you would build. Over a few hundred, per-recipient transfers stop being reasonable and a claim rail earns its complexity — unless the tail cheques are so small that gas eats them, in which case pay the tail manually and claim the head.

What chain are the winners on? Non-EVM winner sets rule out the Merkl rail today. A hard constraint, not a preference.

Does the payout need to be provable to strangers? If outsiders verifying the settlement is part of the campaign's value, the Merkle root is worth its gas and its fee. If the audience is your own users and they already trust you, it is overhead.

The parts that are the same either way

Whichever rail you pick, three things do not change, and they cause more disputes than the rail does:

• The rule must be published before the campaign starts and frozen after. A distribution rule discovered at settlement is not a rule.
• Scoring must agree with itself. The live leaderboard, the projected-rewards column, and the settlement job must compute the same thing from the same day boundaries. A leaderboard that disagrees with a payout is the single most damaging outcome a campaign can produce, and no payout rail can repair it.
• Ended campaigns need a settlement window. The last day's volume has to finalise before anything is paid, so campaigns stay in sync for a period after their end time rather than freezing the instant the clock hits zero.

The competition detail endpoint exposes the payout rail alongside the reward rules, so an integrator rendering competitions inside their own product can show traders how they will be paid before they enter — see the API docs.

Next

If you are planning a campaign, user acquisition for perp DEXs covers structure and measurement, wash-trading resistance covers the rules that decide who ends up on the payout list, and Voltrade for exchanges is the operator's entry point. To see rails in practice, open any live competition or challenge.