Entry requirements

Add up to ten requirement rows; entrants must satisfy all of them. Role rows are the exception: they merge into a single "any of these roles" group.

A blank form starts pre-filled with what your recent raffles usually ask for: any row that at least half of your last 20 raffles carried (the host NFT gate, a role, a follow on your own account, an email...) is added for you, and like / retweet rows come back with an empty link when they are a habit, so pasting the partner's post is the only typing left. Everything stays editable; Duplicate on an existing raffle uses that raffle's rows instead.

Requirement	Verified	How
Holds NFTs	At entry	Any collection: one of yours, another project's from the list, or a pasted contract. Live holdings read across the entrant's linked wallets. On your own collections with staking set up in Verification, pick what counts: held or staked (the default), wallet only, or staked only
Has Discord role	At entry	Rows marked Required gate entry (any of them qualifies); every row can add +N bonus entries, and a bonus-only row never gates. See Entries and odds
Joined this Discord	At entry	Membership check, so outsiders must join your server first
Follows on X	At draw	Checked winner-first against the live follow graph; failures are redrawn
Paid X subscriber	At draw	Only paid subscribers of the X account you name can win. Checked winner-first from each winner's public Subscriptions list on X; failures are redrawn. See Paid X subscribers
Retweets a post	At draw	One read of the post's retweeters disqualifies non-retweeters before the draw. Like + retweet on the same post show in Discord as one "Like and retweet this post" line
Likes a post	At draw	Any post works. Entrants like it through the Like button (raffle page or Discord). See How like tasks are verified
Joined Telegram	At entry AND at draw	Free membership checks against your Telegram channel or group; winners are re-checked at the draw and leavers are redrawn

What entrants see

Every task is done somewhere else (X, Discord, Telegram, a wallet), so both places an entrant works from keep up on their own:

The raffle page re-checks its checklist whenever the entrant comes back to the tab. Join your server, get the role or join the Telegram group, and the row turns Met without a reload; a tapped Like moves on to Checked at draw. Each task has a one-tap action: Follow on X, Retweet on X, Like, Join server, Join on Telegram. Anything missing (X, Discord, Telegram, a wallet that holds the NFTs) connects right there and brings them back to the raffle.
In Discord, a refused entry says what's missing, with a button to fix it (connect X, link a wallet, join the Telegram group) and Check again, which re-runs the entry in the same message. The "You're in" reply lists the follow and retweet tasks with one-tap buttons, and its like line updates as soon as the Like button is tapped. My entry on the post shows the same.

Telegram join tasks

Telegram does not expose channel member lists publicly, so verification runs through a bot:

You add the Fealty Telegram bot to your channel or group before creating the task. For channels the bot must be an admin (only admins can look up channel members); for groups a plain membership is enough. The task is validated when you create the raffle, with a clear error if the bot is missing.
Entrants link their Telegram account once, right on the raffle page or from their Account page (an explicit "Log in with Telegram" click; Fealty stores only the Telegram id and username, no tokens, no message access).
Fealty checks membership when they enter and re-checks winners at the draw. The checks are free: no engagement credit involved.

Reference the chat by public @username. Private chats work too: use the numeric -100… id and paste the invite link so entrants get a Join button.

Why X tasks verify at the draw

Someone can follow to enter and unfollow a minute later, so the check that matters is the one at closing time. Verifying then also keeps costs sane: follow checks run only against provisional winners (with automatic redraws for failures) instead of every entrant. Any X task on the raffle requires entrants to have their X account connected; the checklist shows this before they enter.

Paid X subscribers

For creators who run raffles for their paid X subscribers (X Creator Subscriptions). Add Paid X subscriber and type the creator's handle; it can be any X account, yours or a partner's.

Entering costs nothing. Nobody is checked at entry, so the community spends no credit on entrants.
Winners are checked at the draw, from the Subscriptions list on their X profile. A winner who doesn't subscribe is redrawn, and the next one is checked. Each check costs at most $0.01 of engagement credit (the official X API price of reading one account; the Usage tab shows today's price), so a raffle pays for its winners plus any redraws.
Hidden lists fail. X lets people hide who they subscribe to (Settings, Profile customization). A hidden list proves nothing, so that winner is redrawn: tell your subscribers to keep the list visible. The raffle page says so next to the task.
Entrants need their X account connected, like every X task.

How like tasks are verified

Entrants like the post through the Like button, on the raffle page or in the Discord entry reply: one tap opens X's like screen. Like every X task, likes are checked when winners are drawn, and entrants who didn't like the post are left out of the draw. Like tasks never spend engagement credit.

Email

Add an email requirement and every entry snapshots an email address for the host: auto-filled from the entrant's profile when Fealty knows it (Discord sign-in supplies one), typed in otherwise (both on the web page and via a modal on the Discord Enter button). It lands in the winners export's email column (offered in the column picker only on raffles with this requirement). The address is stored on the entry only; it never overwrites the account's profile email.

Mint wallet

Give the raffle a chain (say Solana) and entrants supply a wallet of that family at entry: either one of their signature-verified linked wallets, or a pasted address (validated for the chain, no wallet connection required). The choice is snapshotted as their mint wallet and that address is what the winners export delivers to your partner. Pasted addresses are marked self-declared in the export and the entries table; they never count toward NFT-hold requirements or holder roles, which always verify against linked wallets only.

Zcash

Zcash appears as two separate mint chains, and picking the right one matters: a shielded drop can only pay a shielded receiver, so a project collecting one kind cannot send to the other.

Zcash Shielded takes a unified address (u1...) or a Sapling address (zs1...). This is what privacy-pool mints ask for.
Zcash Transparent takes a t1... or t3... address, which is what transparent-pool inscription collections use.

Entrants always paste a Zcash address rather than connect a wallet: there is no browser signing standard for Zcash, and a shielded address is receive-only. Every pasted address is checksum-verified, so a truncated or mistyped paste is rejected at entry instead of surfacing as a failed mint later. Zcash addresses are always self-declared for that reason.

No indexer can attribute ownership on Zcash (the shielded pool hides the transaction graph by design, which is the whole point), so a Zcash collection cannot be indexed, and Zcash can never back an NFT-hold requirement or a holder role.

That limit is about the collection, not the raffle. A Zcash raffle still takes every requirement any other raffle does, NFT-hold rows included, as long as the collection being counted lives on a chain we can read. The usual collab shape works unchanged: gate entry on the host collection your members already hold (say Giraffies on Ethereum), and set the mint wallet to the partner's Zcash chain. Entrants keep their linked Ethereum wallet for the holdings check and paste a Zcash address for the mint.

On this page