Trackers

A tracker watches for activity outside Domino and keeps a record of it, so your quests can reward it. For example:

• Posts on X that mention your launch hashtag.
• Messages and reactions in your Discord server.
• Messages and reactions in your Telegram group.
• YouTube Shorts your members post on their own channels.
• TikTok videos your members post on their own accounts.
• Token balances in the wallets your members linked, sampled once a day.
• On-chain events or game results your own server sends in.

Collecting is the tracker's only job. It keeps what it finds in a dataset for one project and environment, separate from members, quests and rewards. A quest then decides what counts and who earns what.

What members see

Members don't interact with a tracker directly. They link their X, Discord or Telegram account, their YouTube channel or TikTok account, or their wallet, and take part as usual: post, react, play. When a quest rewards that activity, they see the quest complete. When it doesn't, your app can show them why, such as "No member has linked this X account", and for some quests they can claim activity from before they linked.

Domino only ever matches activity to a member through an account they proved they own. A username or a verification badge is never enough.

Words on this page

Sources

Collecting is not qualifying

• Every match is kept. An X or custom tracker keeps unverified authors and people who have not joined your project. Apply filters, such as verified or member, when you read. Discord, Telegram, YouTube, TikTok and wallet balance trackers are the exception: they keep only activity that involves a member's linked account.
• A tracker has no reward policy. Collecting never awards anything. A quest that declares a tracker trigger evaluates the record observations it selects for the member behind one of the record's accounts.
• Each rule decides. Quests and engagement rules read the dataset, and each can qualify the same post differently.
• Quests read a fixed moment. When a quest checks a tracker, it sees the records as of when the activity happened, and a retry sees the same answer. See maintained tracker datasets for how those reads are captured.

Attribution

Each record says who took part, in roles: who wrote the post, who it replied to, who reacted. Domino pays the member behind one of those accounts, and only when that member has linked and verified the account. The tables below list the roles and account kinds each source has.

Tracker triggers

A quest can turn each new record into a chance to earn: every new post with your hashtag, every reaction to your announcement, every game your server reports. You choose which records count, who gets paid, whether members must join the quest first, and what happens to activity from before a member linked their account.

In code, a quest with automatic({ tracker }) turns tracker records into attempts. These choices compose it:

• Firing and filtering are not decisions. An observation the mode or filter does not select records nothing and costs no attempt. Older observations only add history.
• Every decision is recorded. Each selected observation gets exactly one trigger outcome: an admission, or a skip with a stable code, such as unlinked-account, and a reason for people, such as "No member has linked this X account". A once() quest the member already completed records already-completed. Operators see outcomes in Console and through the management API; members read their own with relay.quests.outcomes().
• A record never pays its author's member through another role. When the beneficiary account is the record's author account, such as a reply to one's own post or a reaction to one's own message, or both accounts belong to the same member, the observation is skipped.
• A skip waits for the event that clears it. Domino decides a skip again, under the quest's current rules, only when the member event that clears its code happens: linking the account clears unlinked-account, removing a conflicting link clears ambiguous-account, joining the project clears not-joined, and enrolling in the quest, or in its campaign, clears not-enrolled. Every other skip is final unless staff with review permission retry it. A banned member's records are skipped with member-banned, which is never decided again: an unban counts only what they do afterwards, and Console's trigger outcomes say there is nothing to do.
• Activity is never backfilled by publishing. With the default since, observations that occurred before the quest was published are skipped.
• X posts pay approved creators. X does not allow apps that reward users for posting, so a quest that pays an X post's author, with automatic({ tracker }) or content({ tracker }), needs an inGroup(group) prerequisite naming a group of creators the operator approves. Posts by anyone else are skipped with prerequisites-incomplete. A deployment that publishes such a quest without the prerequisite warns with x-post-rewards-ungated.
• The attempt keeps what it saw. Once a record starts an attempt, later updates or the member unlinking the account don't change it. Quest code cannot redirect who it pays. See tracker triggers for what the evaluator receives.

Historical activity

Activity from before a member joined in is historical: by default it doesn't pay automatically, so linking an old account can't sweep up months of past posts.

Activity is historical when it occurred before the member linked the account it pays, or before the member enrolled. A link time Domino does not know, such as a Discord connection made before selections existed, counts as later than the activity. Accounts of kind member are never historical: the server that ingests the record vouches for the member.

A linked account or an enrollment decides earlier skips again, and historical activity then becomes a historical skip that names the member. The quest's historical policy says who releases it:

A retry or claim releases only historical activity: every other rule still applies. Activity that occurred before the member completed a prerequisite never counts.

Revisions and observations

Domino keeps history rather than overwriting a record. An edit to a post's body creates a new content revision. A refreshed like count or author profile creates a new observation with the same revision. Returning to an earlier body reuses that body's revision.

Trackers in the same project and environment that collect the same X post share its latest facts. Each tracker keeps its own matches and first-seen times, so another tracker's discovery never adds a match to yours.

Coverage and changes

• Complete coverage is not a census. It means a collection cycle exhausted the provider's results and refreshed known posts. It does not prove the dataset holds every matching post.
• Changes do not backfill. Changing a query or window keeps collected records and discovers new posts from publication time. Use a new tracker key for a deliberate historical collection: its first publish searches from window.start, even when that is in the past, as far as the provider's history reaches.
• Each cycle searches the whole window. An X tracker searches from its discovery start to now, or to window.end once that has passed, on every cycle, up to maxPages search pages. A long, busy window can reach that limit every cycle and report partial coverage with a page-limit warning.
• Removal keeps data and collection. Removing a definition from the manifest does not delete its dataset, and it does not stop collection: a deployment publishes only the trackers it lists and leaves the others as they are. Pause or archive a tracker to stop collecting. Pausing stops collection without freezing shared post facts.
• Code or data owns each key. A tracker is code, published by a deployment from defineTracker, or data: a tracker of a source Domino collects itself, such as an X search or Discord reactions, created in Console or with management.trackers.create. Only its owner changes the definition, and a deployment never changes or removes a data tracker. Data trackers are created and changed in test, and a promotion carries them to live, still owned by data. A promotion never copies the Discord server or Telegram chats a tracker reads; live connects its own. See Create a tracker without a deployment.
• Test first. The CLI publishes trackers to test only. A promotion carries them to live once a person with publish permission approves it in Console.

Where next

Tracker-scoped ingestion keys

A personal ingestion key can carry a list of allowed custom tracker IDs. It still belongs to one project and environment, and its owner must still hold ingestion permission. The restriction applies to writes, not reads or other permissions on the same key. Choose only Ingest for an indexer that should not read project data. Existing keys without a tracker restriction keep project-wide ingestion. Operators can inspect, edit or revoke their own keys in Console Settings → API keys. See custom source ingestion.

Read and feed trackers from the CLI

domino trackers list and domino trackers get TRACKER show each tracker's collection status (see Collection status), domino trackers records TRACKER pages its records newest first with the same filters as management.trackers.records, domino trackers summary TRACKER counts them, and domino trackers outcomes TRACKER lists its trigger outcomes. Reads need read.

domino trackers ingest TRACKER records.json stores up to 100 records in a custom tracker with ingest permission, and domino trackers retry-outcome TRACKER --quest QUEST --record RECORD --observed-at MS runs admission again for one skipped record. Both are saved before they are sent, so an uncertain answer resumes with the error's operation.resume command. See CLI automation.

Collection status

domino trackers get and management.trackers.get return the published definition, paused, archivedAt for an archived tracker, and these collection fields:

Archive a tracker

Archive a tracker with Archive tracker on its page in Trackers, or in Settings → Resources, to stop collecting: scheduled X searches, Discord activity, and records your server sends. Everything already collected stays readable. Choose Unarchive tracker in either place to collect within its window again; a separate pause stays until you resume it. Quest checks that already read the tracker keep what they saw. See resource lifecycle.

Withdraw and restore quest enrollment

Your team can take a member out of a quest that requires enrollment with Withdraw enrollment in Console member details, giving a reason. New activity stops counting for them; their existing attempts, completions and rewards stay. Re-enroll brings them back after confirming consent and starts a new enrollment time. Repeating an active enrollment keeps its current time. This differs from campaign enrollment, which keeps its original time through withdrawal.

Relink retained identities

If a member's account was unlinked, a reviewer can restore it with Relink, under the member's Identities or Wallets in Console. Activity Domino skipped because nobody had linked the account is then looked at again.