Waitlist & referrals

The public registration flow records an email, wallet string, survey choices, social-attestation fields, referral code/linkage, and timestamp in Redis. This is separate from PostgreSQL-backed marketplace accounts and does not itself verify wallet ownership.

Social checkboxes are self-attested. They are not X OAuth verification and do not establish that a person followed an account or published a quote post. Duplicate-wallet handling is also not a general anti-bot or anti-Sybil system.

1. Registration receives an optional referral code from the link.
2. The code is attributed only if it matches an existing registered code.
3. The new entry records its referrer; later duplicate registration does not rewrite that attribution.
4. Referral counts are derived from persisted relationships.
5. Queue ranking prioritizes referral count, then earlier registration time.
6. The dashboard shows position, referral count, masked referred wallets, and a leaderboard.

Positions are dynamic. A referrer can move ahead when a signup is attributed, and other people's activity can change the relative order. Referral activity does not guarantee a particular future reward or access entitlement.

Marketplace accounts carry their own referral code (a w-prefixed default from the wallet address, or a custom code set in Profile). Sharing https://idleai.xyz/early?ref=YOUR_CODE attributes a new account to you at first sign-in; attribution is immutable afterwards.

The referrer earns 10% of every top-up the referred account makes and 10% of the platform fee on its usage, credited as spendable balance. Rewards are paid from the platform's own house:promo account — the depositor keeps 100% of their top-up and suppliers are always paid in full.

Production requires durable storage. A storage failure is reported rather than silently becoming an empty queue or a successful memory-only registration. The current same-wallet insertion uses an atomic insert-if-absent operation on the existing Redis hash, so concurrent requests do not overwrite the wallet's referral identity.

Tests cover multiple referrals, read/write failures, missing production configuration, duplicate/concurrent registration, and immutable attribution. They do not establish complete abuse resistance or prove that every signup is a unique human.

The current implementation includes a configured position offset of 204. That is presentation logic, not proof that 204 verified users exist. Use actual persisted registrations and clearly defined analytics for user metrics rather than treating a displayed queue number as an audited participant count.

Waitlist statistics are accessible by wallet lookup and include masked referral relationships. Emails and full survey records are not part of that public stats response. Administrative export access and retention need to remain separately controlled.

The teaser uses a shared deadline rather than resetting a fresh timer for each visitor. A timer reaching zero does not activate inference or payment infrastructure. Launch communications must match actual release readiness.

Early participation and referrals may inform future decisions, but no token allocation, yield, payout, or guaranteed reward has been implemented by the waitlist itself.