Xlist

Whitelist contract, one per collection

One Xlist is deployed per collection alongside Xcollection. The Xpectrum platform operator manages it on behalf of creators.

Per-collection binding

Each Xlist is bound to exactly one Xcollection via init(). The is_whitelisted() function only responds to calls from its registered collection address. A single Xlist can’t be reused across unrelated drops.

Functions

add_batch(addresses[])

Adds up to 20 wallet addresses per transaction. Called by the platform operator when a creator updates their whitelist through the dashboard. The on-chain Xlist is the authoritative record. Supabase is a display mirror only.

remove(address)

Removes a single address.

is_whitelisted(address) (view)

Called by Xcollection at mint time. Returns true if the address is whitelisted. Only callable from the registered Xcollection address.

check(address) (view)

Public whitelist status check. No collection-binding restriction. Used by the frontend to show whitelist status to users.

Whitelist sync

Before deployment, whitelist edits are stored in Supabase only. Free and instant. After deployment, each update triggers an on-chain transaction signed by the operator’s edge function. Creators manage the list through the dashboard; the platform handles the signing.