Xlist

One Xlist is deployed per collection alongside Xcollection. It holds the GTD and FCFS whitelists for that collection and is the authoritative, on-chain record of who can mint in the gated phases.

​

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 Xlist operator. The on-chain Xlist is the authoritative record.

​

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.

​

Who manages the list

Each whitelist update is an on-chain transaction. Because a large whitelist means many batched transactions of 20 addresses each, the Xlist operator role decides who signs them:

• Platform-managed (default): Xpectrum is the operator and signs whitelist updates for you, so you manage the list from the dashboard without signing a long run of transactions yourself. This is a convenience, not a requirement.
• Self-managed: transfer the Xlist operator role to your own wallet and sign updates directly. Choose this if you would rather not have anyone else able to write your list.

Either way, the on-chain Xlist is the source of truth at mint time. Before deployment, whitelist edits are kept off-chain and cost nothing; they are written on-chain when the collection goes live.