Before entries open
A SHA-256 commitment is published on the post. It binds the server seed and the parameters named in it — the code, the declared closing time, the price and the seat count — so those cannot be quietly changed afterwards.
Ordered by how uncomfortable the answer is.
No. Payment details are exchanged in a private message to the bot between that entrant and you. The group sees the banner and the running count of paid seats, never a name attached to a payment, a Venmo handle, a transaction reference or a screenshot.
No, and that is deliberate. Entrants pay you directly through your own Venmo, Cash App, PayPal, Zelle, bank or crypto address. The only money that touches us is your subscription or day pass, charged by Stripe. We cannot refund an entrant because we never received it — which is also why a raffle you cancel means you refund the entrants yourself.
Sales stop, held seats are released, and the draw does not run. Everything is recorded: the status, who cancelled it, when, and the reason. Entrants who had already paid are shown to you with their reference codes so you can send that money back — we do not take a cut of it, so we cannot hand it back for you.
Check it. The public verification page for every finished raffle recomputes the winner list from the published commitment, entry-list hash, entrant contributions and revealed seed, and shows PASS or FAIL for each stage. It does not read our answer. The same page prints the commands you can run yourself with openssl. There is a live example at /verify/demo.
Here is the honest limit. The commitment stops a seed from being changed after the entries are in: the hash is published before anyone joins, and the revealed seed has to match it. It does not stop a host from closing early or cancelling before the reveal, and we cannot cryptographically force a draw to happen. What reduces that risk is automatic closing at the published time, the entry-list hash everyone can see first, and the audit trail that keeps a re-draw as a new record rather than an edit. If a host cancels a raffle that was about to pay out, that shows up in their history.
We are software. We do not take stakes, set odds, or hold prize funds, and we do not give legal advice. Rules for prize draws differ by country and state, and paid entry raffles are the kind of thing regulators look at. Many operators keep a free entry route open for exactly that reason; the bot supports a free-entry path and a no-purchase-needed note. Get your own advice before you charge for a number.
An entrant says they paid and shows you a reference and a screenshot; a person (you or a staff member you allow) confirms it and the seat becomes paid. It is manual on purpose for Venmo, Cash App, PayPal and Zelle: those rails have no API we could check a payment against, so an automated “verified” badge would be a claim about someone else's system we cannot honour. Crypto payments keep the transaction hash on file and can be checked against the chain by you at any time.
Entries are never deleted. Rejecting, cancelling or voiding an entry writes a row with the reason, who did it and when, and keeps the seat's history. That record is what a dispute is settled with, and it is the reason a re-draw creates a new draw instead of editing the winner.
Whatever your plan says, and you can see the number on your dashboard as “3 of 5 groups”. Going over does not delete anything: new raffles stop being created until you are under the limit again, and existing ones keep running. Upgrading takes effect immediately.
No. A failed payment opens a grace period with the date shown on your dashboard, and the bot tells you in Telegram. Only after grace does the bot stop taking new entries; a raffle that was already open is completed rather than abandoned, because your entrants are not responsible for your billing.
Yes. Any raffle's entry list exports as CSV — ticket number, Telegram id or username, entry status, amount, reference code, review timestamps. It is your member data; we keep it only to run the raffle and settle disputes.
Payment screenshots are kept for the dispute window and then deleted; a raffle banner is deleted a few days after the winner post that referenced it. The retention clock is set when the file is created, not by a sweep that guesses.
A SHA-256 commitment is published on the post. It binds the server seed and the parameters named in it — the code, the declared closing time, the price and the seat count — so those cannot be quietly changed afterwards.
The eligible list is frozen and its canonical hash is published, so the exact set of entries the draw will use is visible before the seed is revealed. This is a second, separate publication — not part of the commitment.
The seed is revealed, the pick-by-pick log is published, and every winner index can be recomputed from the hash — with or without our software.