Members

A member is one person in your community program. Domino keeps everything they do with you in one place: the quests they finish, their points, their rewards, and the accounts they've proved are theirs, such as their X handle, their Discord account, or their wallet.

• A member who signs in with X can earn points for posting about you.
• A member who links their wallet can take part in a holders-only quest.
• A member you bring over from another platform keeps the points they had there.

A member belongs to one project. Someone who joins two of your projects, even in the same organization, is a separate member in each, with their own accounts and progress. Test and live members are separate too.

Verified identities

Members prove which accounts are theirs: an email address, an X, Discord, Google or Apple account, a Telegram account, or a wallet. Domino signs members in with them, and quests only credit a member's X, Discord, Telegram and wallet activity through accounts they proved. A name, a handle or a profile picture is never enough.

A few paths take your organization's word instead of the member's proof:

• Imported members. A member import attaches the X, Telegram and Discord accounts and wallets you vouch for.
• Accounts your app vouches for. With an existing app login, your server can attach those accounts each time it signs a member in, once an admin with Publish permission allows it for the key.
• Your own login. With an existing app login, your app server vouches for its user. It also links that user as an app:<name> identity when the integration has an identity kind.
• Your server's records. A custom tracker record that names a Domino member ID is taken on the word of the server that sends it.
• Test members. In test, an operator can give a test member wallets and X or Discord accounts.

Sign-in

Your app signs members in one of two ways. See app login.

When a member first signs in with an email code, Domino reuses the member of an OAuth account with the same verified email, provided that account is enabled for sign-in. Accounts connected only to check activity can't link the two. If several members match, email sign-in stops instead of choosing one. An existing email identity keeps its current member; this does not repair accounts already split.

Domino recovers older Google and Apple sign-in profiles before matching a new email identity. If an older sign-in grant cannot be recovered, the attempt stops: the member signs in with their original method to refresh the account, or contacts you. Existing email identities can still sign in.

Connected accounts

A signed-in member adds accounts by connecting them, so Domino can check their activity with a provider such as Discord. Connecting a member's Discord account and connecting your Discord server to the project are separate steps:

Rewarding Discord messages and reactions needs both. An organization administrator installs Domino's bot into a server once, or sends a one-time link to whoever manages the server; other projects of the organization then connect the same server without installing it again. The integration names the server Domino listens to, and Domino keeps a message or reaction only when its Discord account is linked to a member of the project. Activity from before the link is not kept. See Discord messages and reactions and project integrations.

A quest's announcements mention the member through the Telegram or Discord account they connected, with their Telegram @username when their sign-in profile has one. A member who connected none there is named by their display name instead. A test-linked account is someone else's, so announcements never mention it.

Quests that need Discord fail while the project's integration is missing or needs attention, whatever the member linked. Once it's ready again, Domino retries the failed attempts of automatic quests without a tracker on its own. See recover a configuration failure.

Accounts Domino reads in the background

Some providers let Domino keep reading a member's own account after they link it, with their permission, for example to follow their posts. Linking such an account also asks for the permissions those reads need. If the member later revokes access, or the access lapses, the account needs reconnecting: Console shows Needs reconnect and the reason on the member, and the member fixes it by linking the same account again. A temporary provider outage doesn't count; Domino just tries again later.

Creator accounts

A creator account is the account a member publishes from: their YouTube channel or their TikTok account. Domino reads it in the background, so trackers like YouTube Shorts and TikTok videos can credit the member for what they post there.

• Linked, never used to sign in. A member signs in some other way first, then links the account. On Google's consent screen they pick the YouTube channel; Domino identifies it by its channel ID, not by the Google account. On TikTok's consent screen they approve Domino reading their profile and public videos; Domino identifies the account by the ID TikTok gives Domino for it, not by the @username.
• One per platform. Linking another channel or TikTok account replaces the current one. Content the earlier account posted stays where it is.
• Only where Domino configures it. Until then, members aren't offered that platform at all.

Creator accounts are read in the background, so an account whose access stopped working shows Needs reconnect until the member links it again. TikTok shares a member's videos only with their own permission, so while a TikTok account needs reconnecting Domino reads nothing from it. In Console, open a member: Creator accounts lists their linked accounts, and a reviewer can Unlink one with a reason. Domino then stops reading the account; the records it already collected stay.

Operator identity changes

Sometimes an account needs to stop counting for a member, such as a shared wallet or a hijacked X account. Your team can unlink it, and relink it later. Each account has three separate facts:

In Console, open a member. Identities lists their X, Discord and Telegram accounts and app identities; Wallets lists their wallets. A reviewer chooses Unlink or Relink and enters a reason, which is recorded. Unlinking stops new quest checks and tracker records from crediting activity through that account in the project and environment. Activity already accepted and rewards already earned stay.

Each kind keeps its own rules:

• Wallets and accounts keep their sign-in when unlinked. A wallet's sign-in has its own command.
• App identities sign in only while linked: unlinking one also ends the sessions your app started for it.
• X, Discord and Telegram select one account per provider. To relink another account the member proved, unlink the selected one first.

Another member cannot claim an unlinked account, and the original member can link it again.

An account or wallet the member holds only on your organization's word is different: a member import or your app login vouched for it, and Console marks it Imported or Vouched by. If the member never signed in with it or proved it, Unlink releases it. It leaves the member with nothing to relink, its owner can link it and sign in with it, and no import or app can attach it to that member again. Use it when the organization vouched for the wrong account.

If an account changed while you were looking at it, Console reports a conflict: refresh the member and review the current state before trying again.

Wallets

A member links Solana, EVM and Cosmos SDK wallets to a project by signing a message in each wallet; a Cosmos wallet links on a chain the app names by its chain ID. Quests can then check which wallets the member controls and the token balances they hold, for a holders-only quest or reward, on Solana, EVM and the Cosmos SDK chains Domino lists (see token balances), how many NFTs of an EVM collection or a Solana Metaplex verified collection they hold (see NFT holdings), their staking: a view function's value on an EVM contract, or Cosmos native delegations (see staking and contract state), and whether a wallet took part in an event of an EVM contract, such as a swap, mint or vote, in the last 30 days (see on-chain actions), and whether a Solana wallet's transaction called a program, with how its balances changed (see on-chain actions on Solana). See wallets.

Linking and signing in are separate:

Imported members

Moving from another platform? A member import brings your members over, keyed by the account each will sign in with: your app's user ID, a wallet, or an X account. When that person signs in, they are the imported member, with their opening balances, quest progress and referral: who invited them, and the friends they invited. An import never merges two members, and refuses an account another member holds. A row names an inviter who already signs in by the account they sign in with, the same way. Console shows who invited a member under the member's summary in Members, marked Imported when an import recorded it.

An import can also attach X, Telegram and Discord accounts and wallets on your organization's word. Quests, trackers and wallet checks trust these vouched accounts like proved ones, and Console marks them Imported. The one exception is a leaderboard's payout list: it lists only wallets a member proved, so an off-platform payout never goes to an address you vouched for. When the member links an account of that kind themselves, by connecting X, Telegram or Discord, signing in with the X account, or signing with the wallet, their own link replaces the vouched one. A vouched Telegram or Discord account never signs in.

Your app's server can vouch for accounts the same way when it signs a member in, so members who join after an import arrive with their accounts too. Console marks those Vouched by and the app login key's name. See vouch for your members' accounts.

A wrong import can be reverted: its opening balances, imported quest completions, and the accounts it attached that nobody signed in with since are taken back. The members it brought over stay.

Profiles

A profile is the name and picture other members see in one project and environment, for example next to their score on a leaderboard. The member chooses a display name, and a picture they upload, take from a connected X, Discord or Google account, or have generated. A member's profile in one project never changes their profile in another.

Where profiles are visible, leaderboard rows show the profile's name and picture. A profile page can also show the member's place on a leaderboard, their completions of quests that opt in to profiles, and their progress in a referral program, but only what the viewer could read anyway. Emails, wallet addresses, member IDs and account IDs are never shown. Google and Apple accounts never supply a default name or picture. See participant profiles.

Ownership of progress

• Completions are recorded for the member who did the quest.
• Quest rewards belong to the member who completed the quest.
• Referral rewards go to both sides: a referral program connects an inviter and an invited member so each can receive their own rewards.

Your app shows progress, and Domino checks activity and records the result on its server:

Erased members

When a person asks you to delete their data, you erase their member. Their profile, accounts, sign-in, consent and submitted evidence are deleted, and the member stays as an anonymous ID with the points, completions and rewards it earned, so leaderboards and other members' referral rewards don't change. Nothing new reaches an erased member, and the same person signing in again becomes a new member. Erasing needs the Publish permission and can't be undone.

Banned members

You can ban a member who farms or abuses your program. A banned member can still sign in, but can't take part: Domino refuses their attempts, completions and invitations, skips tracker records that would count for them, leaves them off every leaderboard and settlement, and stops referral payouts to and from them. When you ban, you can also take back their completions, the referral payouts they received and their manual awards, after a preview of what that reverses. Banning needs the Review permission, and you can unban later. A ban covers one member: the same person signing in with another account is a different member.

Test members

A test member is a pretend member you create in the test environment to try your quests end to end before launch. It has a display name, no sign-in, and a Test badge in Console. Someone with publish permission in test can act for it:

• Submit a quest on its behalf. The submission is checked, reviewed and rewarded like a real member's, and the history names who did it.
• Pass a quest, or accept a rejected try anyway. Completion rules, budgets and rewards still apply. See Pass a quest or accept an attempt anyway.
• Accept a referral invitation, with the same refusals, qualification and rewards as a member's own acceptance.
• Redeem an offer, with the same price, stock, limits and refusals as a member's own redemption.
• Move its clock forward, by days, hours or minutes or to a later instant, to try streaks, weekly limits and time-of-day rules without waiting.
• Give it a wallet to try balance and holding quests. See Give the member a wallet.
• Link a real X or Discord account to try follower, repost and role checks. See Link an X or Discord account.
• Send X posts, Discord messages and reactions as the member. See Send X and Discord activity.
• Reset it to start again.

These actions work from Console, a personal API key, or a domino login CLI session. Hosted app keys and service keys can't create, list, act as, accept referrals or redeem offers as, pass quests for, advance, give wallets or accounts to, send records for, reset or purge test members. Management credentials still can't issue member sessions.

The one exception is the project's staging app. An operator who signed in to it through Console and holds publish can sign that app in as a test member. The member gets an ordinary 8-hour member session, so the app runs as that member, and the history records the operator. Signing out or resetting the member ends the session. Staging opened with the project password cannot do this, and live never issues one.

Active members

Domino counts a project's active members each calendar month, in UTC. A member is active in a month when, on a UTC day of it after the UTC day they joined the project, they sent a signed-in request to the participant API. Their attempts and redemptions are such requests, and so is every call your app makes with their session.

These never make a member active:

• the day they joined, so a member who signs up and never comes back is not counted;
• a member import or a tracker record your server reports, on its own;
• anything in the test environment, so test members never count.

Each member counts once a month, however often they come back. A member's active days stay in the months they happened, and move with the project when it moves to another organization.

Read the count with management.usage.activeMembers() or domino usage active-members (GET /management/v1/usage/active-members, read permission). It returns this month's activeMembers, the project's plan and its limit of live active members a month (null when the plan has none), and the six earlier months in history, newest first. The count is the same whichever environment you select. In Console, Settings → Plan & usage shows this month's count against the limit, with last month's beside it.

Going over the limit refuses nothing. Where plans apply, a project over its limit in two calendar months in a row moves up:

Real people in test

Where plans apply, a project's test environment admits a limited number of real people: members who joined test, by signing in or through a member import. The limit is the plan's: 100 on Free and Launch, 250 on Growth, 1,000 on Scale, and what Domino agreed on Enterprise. Test members never count.

Once test holds that many, a person who never joined test cannot sign in to it: sign-in fails with limit-reached (403, limit: "real-people-in-test") and a message that the test version is full. Nothing else changes:

• people who already joined test keep signing in, even over the limit;
• live sign-in is not limited this way;
• staff and operator sessions are not counted.

A bigger plan raises the limit. While the limit is enforced, Console shows a notice on project pages from 80% of it. Read the count with management.usage.realPeopleInTest() or domino usage real-people-in-test (GET /management/v1/usage/real-people-in-test, read permission). It returns realPeople, the project's plan, its limit, and whether the limit is enforced, whichever environment you select.

Recover saved submissions

If a member's saved answer refers to a submission Domino has permanently closed, the member reviews the current quest and chooses to discard the saved answer before sending again.

Restore quest identity attribution

When a reviewer relinks an account from the member's page in Console, Domino looks again at that member's activity from while it was unlinked, under the quest's current rules.