Private Challenges for Your Community

Every challenge has a visibility setting with two values. Public means anyone can join until the seats run out. Private means you review each person who asks, and nobody pays until you have said yes.

That one flag changes the challenge from an open contest into a room you control, and it is the setting most community operators actually want. Here is exactly what it does.

What "private" changes

Three things:

It leaves the public listing. Private challenges do not appear on the challenges page. The page for the challenge still exists and still renders a proper link preview when you share it — that is the point, it is meant to be shared — but it is marked as not-for-indexing, so search engines are told to leave it alone.

It gates entry behind you. A stranger who has the link can register interest, but they cannot pay. Their participation is created in a pending-approval state, and the entry payment step is simply not offered until you accept them.

It changes when the challenge publishes. A public ticket-mode challenge goes live the moment you pay your own ticket. A private one requires an explicit publish, and it will refuse while any approved entrant still owes their ticket.

The join flow, step by step

1. You create the challenge and set visibility to private. It exists as a draft. Creating is free.
2. You share the link — a Discord channel, a Telegram group, a DM, a post to a paid community.
3. Someone asks to join. Their participation is created pending your approval. No money moves, and — importantly — no seat is occupied. If interest registrations held seats, anyone with the link could fill your challenge with unpaid requests and lock everyone else out.
4. You accept or reject. Accepting moves them to awaiting-payment. Capacity is enforced here, at approval, not at request time: if the challenge is already full of accepted entrants, the approval is refused rather than overbooking the room.
5. They pay. USDC on Base, the ticket price you set. The transaction hash is recorded before it is verified, so a closed browser or a slow confirmation does not lose the payment — a background job reconciles it and credits the pool when it settles.
6. You publish. Once every approved entrant has paid and at least one payment has landed, the challenge goes live.

That last gate is the one people ask about. It exists because a private challenge that starts with an approved-but-unpaid seat starts with an empty chair somebody was promised. Better to chase the one straggler than to run a contest with a phantom entrant on the board.

Rejecting people, and the limits on it

Reject answers a join request. It also removes an approved entrant who never paid — which is your only escape from a private draft that cannot publish because one person went quiet.

There are three things reject deliberately will not do:

• It cannot remove a paid participant. Once someone's entry is credited to the pool, they are in. If you could eject a paid entrant, you could reshape the field after seeing who joined.
• It cannot reject someone mid-payment. If an entrant has a payment confirming on-chain, rejecting now would strand their funds — the row would be invisible to both the reconcile job and the refund queue. The rejection is refused with a "wait a minute or two" until the transaction settles or the hash is old enough to be treated as dead. That expiry matters: without it, an approved entrant could veto your challenge permanently by submitting a transaction that never lands.
• It cannot reject a re-buy line. Extra lines belong to a wallet that already paid; rejecting one would lock a fully-paid entrant out of their own challenge.

Rejection is also available to platform admins, not just you, but the ordinary path is the creator's.

What it is actually good for

Discord and Telegram trading groups. The single most natural fit. You already have the room; a private challenge turns it into a weekly event with a leaderboard, and the approval step means only members compete. Nobody hands over custody of anything: every entrant trades their own account on Hyperliquid or Lighter, and Voltrade reads public venue activity for the wallets that entered.

Paid communities and alumni groups. Approval is a membership check you were already performing. Ask for the handle, match it against your member list, accept. The challenge becomes a perk with a visible outcome rather than another channel.

Small, high-ticket rooms. A Whale Pit-style challenge with a $250 ticket is a hard sell to strangers and an easy one to twenty people who know each other. Private plus a small seat count is how you run that without an open room full of people who will never clear the volume floor.

Vetting for a format you are testing. If you are trying a new bracket, duration or payout curve, running it privately first means the first version is seen by people who will tell you it was wrong rather than by everyone.

The trade-offs, stated plainly

Private challenges are more work and fill more slowly. You are the bottleneck: every entrant waits on you, and a challenge with a start time you set can arrive with half the room still pending. Two habits fix most of it — approve in batches on a schedule you announce, and set the start far enough out that approvals and payments both have room.

They also lose the discovery you get for free. A public challenge is listed, shareable and findable; a private one is only as big as your distribution. If your goal is to reach traders you do not already have, private is the wrong setting — run it public and use the volume bracket to shape who it is for.

And there is one asymmetry to be honest about: you decide who is in the field. That is the feature, and it is also a responsibility. If you are also playing, an approval queue means you chose your own opponents. Communities that care about this usually solve it by accepting everyone who asks and using private purely as a "members only" gate, which is what most of them wanted anyway.

Setting one up

Pick a template, set visibility to private, and decide two more things:

• Max participants (optional, minimum 2) caps the room. With private visibility it is a soft target rather than a race, since you control the queue.
• Minimum participants to start (optional, minimum 2) auto-cancels and refunds if the challenge is short at the start time. Useful when you have promised a real contest and would rather refund than run a two-person version of a twenty-person plan.

Everything else works identically to a public challenge: same volume brackets, same flat-start rule, same payout options, same settlement.

Create a challenge and flip visibility to private, or read how to run a crypto PnL challenge for the full set of settings first. If you would rather bankroll the room than play in it, sponsoring a challenge covers the economics from the other side.