@domino-sdk/relay 1.56.0 → 1.59.0

package/CHANGELOG.md

@@ -1,5 +1,79 @@
 # @domino-sdk/relay
 
+## 1.59.0
+
+### Minor Changes
+
+- 1d5a195: `management.attempts.acceptAnyway({ attempt, reason })` (`POST /attempts/<id>/accept-anyway`, `review` permission) accepts a rejected attempt anyway, for any member, reversing a reviewer's or an evaluator's rejection. The acceptance pays as a reviewer's approval would, with the normal `completion.created` webhook; the rejection stays in the attempt's events beside a `staff-decision` with `decision: "accept-anyway"` and the reason, and the retry cooldown ends. Only the member's latest attempt on a quest that isn't archived qualifies (409 `attempt-superseded`, `quest-archived`), and a cap the acceptance would break refuses it instead of rejecting it again (409 `completion-cooldown`, `budget-exhausted`, `completion-revoked`, `already-completed`). `management.attempts.get` answers `supersededBy`, the member's newer attempt on the quest, or null. The CLI adds `domino attempts accept-anyway ATTEMPT --reason TEXT`.
+- a0c77e4: Archiving or unarchiving a group, pausing or resuming a tracker, and changing the project's schedule state take an optional reason, which the audit log records: `management.groups.archive(group, { reason })` and `unarchive(group, { reason })`, `management.trackers.pause(reference, { actionId, reason })` and `resume`, and `management.schedules.setState(state, { reason })`. A reason is a trimmed string of 1–500 characters, like the other lifecycle reasons; leaving it out works as before. The CLI adds `--reason TEXT` to `domino groups archive|unarchive`, `domino trackers pause|resume` and `domino schedules pause|archive|resume`. Console asks for a reason in a dialog for each of these, and the project schedule menu no longer applies a state as soon as you pick it.
+- 424863f: Operators can restore an entitlement they voided. `management.entitlements.restore(entitlement, { revision, reason })` (`POST /management/v1/entitlements/<id>/restore`, `review` permission) and `domino entitlements restore <id> --revision <n> --reason <text>` make a `void` entitlement `available` again at the tier an accepted completion still earns, and bring back any referral review the void settled. Restoring is refused with 409 `entitlement-status` when a completion revocation voided the entitlement or no accepted completion still earns it (the body names the `completion` to restore instead), when canceling an offer redemption voided it, or when a referral reward was voided before voids kept their reviews. Console Rewards and member detail offer **Restore reward** on a voided reward, and Audit history lists each restore with its reason.
+- 790aa5d: Operators can restore a completion they revoked by mistake. `management.completions.restore({ completion, reason })` (`POST /management/v1/completions/<id>/restore`, `review` permission) and `domino completions restore <completion> --reason <text>` re-apply what the revocation recorded, not a fresh reward evaluation: the points it reversed are awarded again (points it could not reverse are not), its badges, group memberships, tiered rewards, Discord role grants, referral qualifications and streak milestone come back, and budgets stay spent. The result (`CompletionRestoration`) lists what came back. Restoring is refused with 409 `completion-not-revoked` when the completion isn't revoked, and with 409 `occurrence-taken` (naming the `completion` that holds it) when the revocation freed the occurrence and the member completed it again. `members.get(id).revokedCompletions` lists up to 25 revoked completions, each with its revoke's reason and result. Console member detail and attempt detail offer **Restore completion**, and the attempt history and Audit history show the restore beside the revoke.
+- 850a252: `settlementPayoutCsv(exported)` turns the result of `management.leaderboards.settlementExport(id)` into the payout list as CSV, with the columns `member,score,rank,share,amount,unit,wallets`. `domino leaderboard-settlements export` now prints it through this helper, unchanged, and Console's prize settlement panel offers **Download payout list (CSV)** for any pool that is not points, with the same content.
+- 7ac13ef: Solana transactions from `ctx.wallet.transactions()` now carry `signer`: whether the linked wallet signed the transaction. It is `false` for a transfer someone else sent into the wallet, and for results captured before it existed. Check it before rewarding an action. The new `solana-action` snippet completes a quest once per transaction a linked wallet signed that called your program, optionally receiving at least an amount of a token.
+- 5b94440: Anchor instruction decoding for `ctx.wallet.transactions()`. Saving a `settings.solanaProgram()` setting now stores the program's Anchor IDL (legacy or 0.30+), read from its on-chain IDL account, in the published release's new optional `solanaIdls` (`SolanaProgramIdl`: `{ program, source, idl }`, by setting key). For a program without an on-chain IDL, an operator pastes one in Console or sends the new optional `solanaIdls: { [settingKey]: idl | null }` with `quests.updateSettings()` (`anchorIdlSchema`, `AnchorIdl`). With an IDL, each transaction gains optional `instructions`: the program's top-level and inner instructions in call order, decoded as `{ name, args, accounts }` (`WalletInstruction`). An instruction the IDL does not describe is skipped. The new `instruction(tx, name)` helper in `@domino-sdk/relay/authoring` returns the first matching instruction's args, or `null`. The testing kit's `facts.wallet.transactions` accepts `instructions`.
+- 95cb8d8: On-chain action checks on Solana. `ctx.wallet.transactions({ program, since, afterActivation?, mint?, address? })` reads the successful, finalized transactions of the member's linked Solana wallets since `since` that invoked `program` in a top-level or inner instruction, oldest first. It returns `{ program, chain, mint, since, at, complete, transactions: [{ wallet, signature, slot, timestamp, programs, balanceChanges: [{ mint, delta }] }], observedAt }` (`WalletTransactions`, `WalletTransaction`, `WalletBalanceChange`, `walletTransactionsSchema`), with `mint` `"SOL"` for lamports (rent included, the fee the wallet paid left out) and `delta` a signed integer string, or null when the member has no linked Solana wallet, and follows `ctx.wallet.balance()`'s capture, `author-error` and `provider-unavailable` rules. With `mint`, only each wallet's associated token account for that mint is read. `since` may be at most 30 days before the evaluation (`maxWalletTransactionLookback`); each wallet's read fetches at most 1,000 transactions (`maxWalletTransactions`), and a wallet with more returns its newest ones with `complete: false` instead of throwing. `WalletReader.transactions` is optional in the type so that existing test doubles compile; Relay supplies it to every evaluation.
+
+  The program comes from the new `settings.solanaProgram({ label, default })` setting, a base58 address (`SolanaProgram`, `isSolanaProgram`) stored as a text setting with `picker: "solana-program"`. Publication, Console settings edits and unarchiving check that the account exists on Solana mainnet and is executable.
+
+  New pure helpers in `@domino-sdk/relay/authoring` read one transaction: `received(tx, mint)` and `spent(tx, mint)` return the wallet's gain or loss as an integer string, or `"0"`; `swapped(tx, { into?, from? })` checks that one mint went down and a different one went up; `invoked(tx, program)`. The testing kit answers `ctx.wallet.transactions()` from `facts.wallet.transactions`.
+
+### Patch Changes
+
+- aaa07ad: The SDK and CLI depend on Zod 4.6.5, whose schemas keep their methods on a shared prototype instead of binding about 7 KB of them to every schema instance. Importing the SDK takes far less memory: a Relay backend process that loads the server entry starts with about half the heap. Quest `settings.datetime()` values, member-import times and X post `createdAt` values (including hand-written testing fixtures) still accept minute-precision instants such as `2026-11-01T00:00Z`, which Zod 4.6 alone rejects. An X post read without a `media` field still gives an empty list.
+
+  One tracker data schema change after a rebuild: a field declared as `z.number().min(0).int()` now stores `minimum: 0`, so Relay refuses negative values at ingestion that the app's own schema already refused. Zod 4.3 stored the safe-integer minimum for that order of checks.
+
+## 1.58.0
+
+### Minor Changes
+
+- 321763b: `management.discordRoles.list()` lists every Discord role the project's reward deliveries have granted in the environment, with the quests that requested it and its deliveries counted by status (`pending`, `delivered`, `failed`). It reads the whole delivery history, so a role granted only before the newest page of `management.rewardDeliveries` still appears. The response schema is `discordRoleRewardsSchema`.
+
+### Patch Changes
+
+- a2318dd: `stagingPathSchema` refuses paths with control characters and accepts only a path that resolves on the staging host. Browsers drop tab and newline from a URL, so a path such as `/<tab>/example.com` used to pass and open another site after a staging sign-in.
+
+## 1.57.0
+
+### Minor Changes
+
+- 7012d1c: Contract state and Cosmos staking reads in quest evaluators.
+
+  `ctx.wallet.call({ call, args?, address? })` calls one `view` or `pure` EVM contract function once per linked EVM wallet, every call at one block, through dRPC on the chains `management.walletBalanceChains()` lists: state a contract keeps per address, such as `stakedOf(address)`, `getVotes(address)` or `userInfo(uint256, address)`. `{ wallet: true }` in `args` stands for each wallet's address. It returns `{ call, chain, contract, returns, total, wallets: [{ address, value }], at, observedAt }` (`WalletCall`, `walletCallSchema`), with integers as decimal strings and `total` their sum (null for `bool` and `address` returns), or null when the member has no linked EVM wallet. A revert is an `author-error` carrying the contract's reason. The call comes from the new `settings.contractCall({ label, default })` setting (`picker: "contract-call"`): the contract's CAIP-10 ID and a human-readable signature, such as `eip155:8453:0x… function stakedOf(address) view returns (uint256)` (`ContractCall`, `isContractCall`, `parseContractCall`, `parseContractFunction`). Only `view` or `pure` functions with elementary parameters that return one `uint`, `int`, `bool` or `address` are accepted; publication, Console settings edits and unarchiving also check the chain.
+
+  `ctx.wallet.delegations({ chain, validator?, address? })` reads the native staking delegations of the member's wallets linked on a Cosmos SDK chain Relay lists, at one block, in base units of the chain's staking denomination: `{ chain, denom, validator, total, wallets, validators, at, observedAt }` (`WalletDelegations`, `walletDelegationsSchema`), optionally only to one validator, or null when the member has no wallet on that chain.
+
+  Both follow `ctx.wallet.balance()`'s capture, `author-error` and `provider-unavailable` rules. `WalletReader.call` and `WalletReader.delegations` are optional in the type so that existing test doubles compile; Relay supplies them to every evaluation, and the testing kit answers them from `facts.wallet.call` and `facts.wallet.delegations`. New `contract-state` and `cosmos-staker` snippets accept members whose view call reaches a minimum, or who delegate at least a minimum, optionally to a configured validator.
+
+- 59a01d8: On-chain action checks on EVM chains. `ctx.wallet.events({ event, account, since, afterActivation?, where?, address? })` reads the events of one contract whose indexed address argument `account` is one of the member's linked EVM wallets, from `since` to the chain's finalized block (its safe block on a chain without finality), through dRPC `eth_getLogs` on the chains `management.walletBalanceChains()` lists. It returns `{ event, chain, contract, since, at, finality, logs: [{ wallet, block, timestamp, tx, logIndex, args }], observedAt }` (`WalletEvents`, `walletEventsSchema`) with decoded arguments, or null when the member has no linked EVM wallet, and follows `ctx.wallet.balance()`'s capture, `author-error` and `provider-unavailable` rules. `where` holds equality or `{ gte }` conditions on other arguments (`WalletEventCondition`); `afterActivation` skips events before the quest's activation. `since` may be at most 30 days before the evaluation (`maxWalletEventLookback`), and a read over more than 3,000,000 blocks or 1,000 logs (`maxWalletEventLogs`) throws `author-error`. `WalletReader.events` is optional in the type so that existing test doubles compile; Relay supplies it to every evaluation.
+
+  The event comes from the new `settings.contractEvent({ label, default })` setting: a CAIP-10 contract, a space and the event's Solidity signature with argument names and `indexed` markers, such as `eip155:8453:0x… Transfer(address indexed from, address indexed to, uint256 value)` (`ContractEvent`, `isContractEvent`, `parseContractEvent`, `ContractEventParts`), stored as a text setting with `picker: "contract-event"`. An event without an indexed address argument is refused. Publication, Console settings edits and unarchiving also check that the chain reports a finalized or safe block and that the address holds a contract.
+
+  The testing kit answers `ctx.wallet.events()` from `facts.wallet.events`. A new `onchain-action` snippet rewards each new matching event since the later of the quest's activation and the wallet's link, with an optional minimum amount, keyed on `chain:tx:logIndex`.
+
+- 956b721: NFT holding checks on EVM chains and Solana. `ctx.wallet.nfts({ collection, address? })` counts the NFTs of one collection the member's linked wallets of its family hold: on EVM, an ERC-721 contract's `balanceOf(owner)`, or one ERC-1155 token ID's `balanceOf(owner, id)`, through dRPC on the chains `management.walletBalanceChains()` lists; on Solana mainnet, the NFTs whose Metaplex metadata names the collection with `verified: true` (SPL Token and Token-2022 accounts holding exactly 1 of a 0-decimal, supply-1 mint; compressed NFTs and Metaplex Core assets are not counted). It returns `{ collection, chain, standard, total, wallets: [{ address, count }], at, observedAt }` (`WalletNfts`, `walletNftsSchema`; `standard` is `"erc721"`, `"erc1155"` or `"metaplex"`), or null when the member has no linked wallet of that family, and follows `ctx.wallet.balance()`'s capture, `author-error` and `provider-unavailable` rules. `WalletReader.nfts` is optional in the type so that existing test doubles compile; Relay supplies it to every evaluation.
+
+  The collection comes from the new `settings.nft({ label, default })` setting, a CAIP-19 asset type such as `eip155:1/erc721:0x…`, `eip155:8453/erc1155:0x…/1` or `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/nft:<collection mint>` (`NftCollection`, `isNftCollection`, `parseNftCollection`, `NftCollectionParts`), stored as a text setting with `picker: "nft"`. Publication and Console settings edits check it: an EVM chain and that the contract reports the standard through ERC-165 `supportsInterface`, so a token contract or the wrong standard is refused when it is set; a Solana mint must be a Metaplex collection NFT, so a fungible mint, a mint without Metaplex metadata, a print edition or a member NFT is refused. Unarchiving checks it too, and a platform without its dRPC key refuses every EVM collection. `ctx.wallet.balance()` pointed at an ERC-721 or ERC-1155 contract now throws `author-error` naming `ctx.wallet.nfts()` instead of reading a token count; it asks ERC-165 alongside `decimals()` on every token read.
+
+  The testing kit answers `ctx.wallet.nfts()` from `facts.wallet.nfts`. A new `nft-holder` snippet accepts members whose linked wallets hold at least one NFT from the configured collection, on EVM or Solana.
+
+- 1770ada: A seventh starter, `loyalty`: members join a campaign, earn points from its steps, join a members' group through a quest's group membership reward, and spend points on offers, one of them limited to the group with `inGroup`. Console offers it and `domino create --template loyalty` creates it.
+
+  Starters are now an open list, so adding one no longer changes the SDK's types. `starters` lists every starter as a `Starter` with a plain string `id`, `offeredStarterSchema` checks an ID against it, and `projectCreateInputSchema` and `repositoryCreateSchema` accept any offered starter; `management.createProject` uses the first. `starterTemplates`, `StarterTemplate`, `StarterId`, `starterIdSchema`, `projectInputSchema` and `createRepositorySchema` are deprecated: they keep the first six starters and are removed in 2.0.0. To upgrade, replace `starterTemplates` with `starters` and `starterIdSchema` with `offeredStarterSchema`, and type a starter ID as `string`.
+
+- cec850f: Create and change a tracker of every managed source without a deployment, not only X search. `management.trackers.create` and `management.trackers.update` (`POST /trackers`, `POST /trackers/:tracker/update`) take a `source`: `{ kind: "x-search", query }`, `{ kind: "discord-messages", text? }`, `{ kind: "discord-reactions" }`, `{ kind: "telegram-messages" }`, `{ kind: "telegram-reactions" }`, `{ kind: "youtube-shorts" }` or `{ kind: "tiktok-videos" }`. Each is stored as the source its builder makes, such as `telegram.reactions()`, so quests read a data tracker as they read the same tracker in code. `query` alone still creates an X search tracker; create takes exactly one of `query` or `source`. An update's `source` replaces the source's settings but never its kind, which is refused with 422 `validation-failed`. Turning Discord message text off erases the text already stored. `managedTrackerCreateSchema` validates the new input, while `trackerCreateSchema` keeps its X-only shape. `managedTrackerSource(source)` reads a published source by these names, and `managedTrackerSourceKinds` lists them.
+
+  `domino trackers create KEY --source <kind>` creates one from the CLI, with `--text on` for Discord messages; `domino trackers update TRACKER --text on|off` turns message text on or off. Console **Trackers → New tracker** offers every source.
+
+- 94726d8: Organization automation keys (`dak_`): a credential for CI and headless coding agents that no person owns. An organization administrator creates one in Console Settings → API keys for every project or a chosen list, with chosen permissions and an optional permission to create projects. It works as `RELAY_MANAGEMENT_TOKEN`, with `domino login --token-stdin` and the Git credential helper, in the test environment only: live writes, administration and minting other credentials are refused.
+
+  The management client adds `automationKeys` (`list`, `create`, `addSecret`, `revokeSecret`, `revoke`) with `automationKeyInputSchema`, `automationKeySchema`, `issuedAutomationKeySchema` and `automationKeyPermissionSchema`. `accessSchema` gains an optional `credential` that `/access` and `domino whoami --json` fill for an automation key with its kind and scope.
+
+- 6d9f0de: `telegram.messages()` is a tracker source of the messages members post in the project's connected Telegram groups and supergroups, one record per message with the poster's Telegram account as `author`. `data` is `TelegramMessageData`: `chatId`, `chatType`, `messageId`, `replyToMessageId` and `threadId`, never the text. Bots', service and channel messages are not recorded. In SDK 1.x it is a custom source on the reserved namespace `telegram-messages`, which Relay alone writes. The new `telegram-contribution` snippet rewards posting once per member per day.
+- 8d11f64: `wallet.balances({ chain, token })` is a tracker source of daily balance samples that Relay writes itself. Once per project-calendar day, at a time members can't predict, Relay reads one token's balance in every wallet linked by a member who joined the project, every wallet of a run at one pinned EVM block or Cosmos height (on Solana, every read must reach the run's pinned slot). `chain` and `token` are those of `ctx.wallet.balance()`. Each record is one wallet, keyed by its CAIP-10 account on the sampled chain, which is also its `author`; each sample is a new observation whose `occurredAt` is the sample time and whose `data` is `WalletBalanceSample` (`amount` in base units, `decimals`, `block`). A provider outage retries the same block later that day and never writes a zero, so a day with no successful sample breaks a `streak({ days })`. Reward holding for days with `automatic({ tracker, where: { path: "amount", gte: { setting: "threshold" } } })` and `streak({ days })`. In SDK 1.x it is a custom source on the reserved namespace `wallet-balances`, with the chain and token in the new optional `balance` field of custom sources (`walletBalanceSourceSchema`); ingestion refuses the namespace, and a project and environment can have at most 5 such trackers (`limit-reached`).
+
+  `management.trackers.create` and Console **New tracker** take `{ kind: "wallet-balances", chain, token }` (`managedTrackerSourceSchema`), and `domino trackers create --source wallet-balances` takes `--chain` and `--token`. The new `token-hold-streak` snippet rewards holding a token for 7 days in a row.
+
 ## 1.56.0
 
 ### Minor Changes

package/dist/{accounts-DRPENuZe.d.ts → accounts-CVonEkdb.d.ts}

@@ -18,7 +18,6 @@ type DiscordMessage = z.infer<typeof discordMessageSchema>;
  */
 declare const discordMessagesSourceSchema: z.ZodObject<{
     kind: z.ZodLiteral<"discord-messages">;
-    /** Store each message's text in `data.text`. Off unless set. */
     text: z.ZodOptional<z.ZodBoolean>;
 }, z.core.$strict>;
 /**
@@ -206,11 +205,7 @@ interface TelegramReader {
         chat: string;
     }): Promise<TelegramChatMember | null>;
 }
-/**
- * The namespace of the tracker source `telegram.reactions()` makes. Relay alone writes its
- * records; ingestion into it is refused.
- */
-declare const telegramReactionsNamespace = "telegram-reactions";
+
 /**
  * One reaction a Telegram user added to a message, as a `telegram.reactions()` record's `data`.
  * Every field is a scalar, so a trigger's `where` can select on it.
@@ -229,6 +224,22 @@ declare const telegramReactionDataSchema: z.ZodObject<{
 }, z.core.$strip>;
 type TelegramReactionData = z.infer<typeof telegramReactionDataSchema>;
 
+/**
+ * One message a Telegram user posted in a connected group, as a `telegram.messages()` record's
+ * `data`. It names the message and never holds its text. Every field is a scalar, so a trigger's
+ * `where` can select on it.
+ *
+ * @compat output
+ */
+declare const telegramMessageDataSchema: z.ZodObject<{
+    chatId: z.ZodString;
+    chatType: z.ZodString;
+    messageId: z.ZodNumber;
+    replyToMessageId: z.ZodNullable<z.ZodNumber>;
+    threadId: z.ZodNullable<z.ZodNumber>;
+}, z.core.$strip>;
+type TelegramMessageData = z.infer<typeof telegramMessageDataSchema>;
+
 declare const authProviderSchema: z.ZodEnum<{
     discord: "discord";
     google: "google";
@@ -289,4 +300,4 @@ interface DiscordReader {
     }): Promise<DiscordMessage | null>;
 }
 
-export { type AccountConnection as A, discordRewardSchema as B, telegramAccountConnectionSchema as C, type DiscordMessageData as D, telegramChatConnectionSchema as E, telegramChatIdSchema as F, telegramChatMemberSchema as G, telegramChatSchema as H, telegramChatsSchema as I, telegramInitDataSchema as J, telegramMemberInputSchema as K, telegramMiniAppSignInSchema as L, telegramReactionDataSchema as M, telegramReactionsNamespace as N, telegramSignInMethodsSchema as O, type TelegramAccountConnection as T, type AuthProvider as a, type TelegramSignInMethods as b, type DiscordMessageTextData as c, discordMessagesSourceSchema as d, discordReactionsSourceSchema as e, type DiscordReactionData as f, type TelegramReader as g, type DiscordReader as h, type TelegramChatMember as i, type TelegramChatMemberStatus as j, type TelegramReactionData as k, type DiscordMember as l, type DiscordMessage as m, type TelegramChat as n, type TelegramChatConnection as o, type TelegramChats as p, accountConnectionSchema as q, authProviderSchema as r, discordMemberInputSchema as s, discordMemberSchema as t, discordMessageDataSchema as u, discordMessageInputSchema as v, discordMessageSchema as w, discordMessageTextDataSchema as x, discordReactionDataSchema as y, discordResourceSourceSchema as z };
+export { type AccountConnection as A, discordResourceSourceSchema as B, discordRewardSchema as C, type DiscordMessageData as D, telegramAccountConnectionSchema as E, telegramChatConnectionSchema as F, telegramChatIdSchema as G, telegramChatMemberSchema as H, telegramChatSchema as I, telegramChatsSchema as J, telegramInitDataSchema as K, telegramMemberInputSchema as L, telegramMessageDataSchema as M, telegramMiniAppSignInSchema as N, telegramReactionDataSchema as O, telegramSignInMethodsSchema as P, type TelegramAccountConnection as T, type AuthProvider as a, type TelegramSignInMethods as b, type DiscordMessageTextData as c, discordMessagesSourceSchema as d, discordReactionsSourceSchema as e, type DiscordReactionData as f, type TelegramReader as g, type DiscordReader as h, type TelegramChatMember as i, type TelegramChatMemberStatus as j, type TelegramMessageData as k, type TelegramReactionData as l, type DiscordMember as m, type DiscordMessage as n, type TelegramChat as o, type TelegramChatConnection as p, type TelegramChats as q, accountConnectionSchema as r, authProviderSchema as s, discordMemberInputSchema as t, discordMemberSchema as u, discordMessageDataSchema as v, discordMessageInputSchema as w, discordMessageSchema as x, discordMessageTextDataSchema as y, discordReactionDataSchema as z };

package/dist/{attempt-captures-CxxO7DeD.d.ts → attempt-captures-DBj-rxak.d.ts}

@@ -1,4 +1,4 @@
-import { O as OpenIdentityKind } from './schema-C4m9RhCR.js';
+import { O as OpenIdentityKind } from './schema-BA0nRRlt.js';
 import * as z from 'zod';
 
 /** One capability call of the captured evaluation run, as Relay stored it. */

package/dist/authoring.d.ts

@@ -1,24 +1,23 @@
-import { x as xContentBodySchema, I as IdentityKind, y as customSourceSchema, W as WithRecordData, z as WithContent, B as WithAccountRoles, C as ResourceHandle, D as QuestHandle, L as LedgerReference, G as GroupHandle, F as pointLedgerDeclarationSchema, H as TrackerSource, J as trackerDefinitionSchema, N as Tracker, U as TrackerData, V as SourceRoles, X as LedgerHandle, Y as TrackerDataSchema, Z as xSearchSourceSchema, _ as XTweet, $ as XContentMetric, a0 as TrackerTriggerPolicy, a1 as Where, a2 as MemberIdentity, P as PointBalance, a3 as ReferralHandle, a4 as TrackerTriggerContext, a5 as TrackerReader, a6 as TextReviewInput, a7 as TextResult, a8 as PhotoResult, a9 as Decision, aa as rewardSchema, ab as TrackerTriggerMode, ac as RoleOf, ad as WhereSetting, ae as ContentBody, af as BadgeHandle, ag as ContentMetricName, ah as triggerSchema, k as QuestPresentation, l as QuestProfile, m as QuizEvidence, ai as TieredRewardDefinition } from './schema-C4m9RhCR.js';
-export { aj as LedgerSetting, ak as TrackerPage, al as TrackerReadQuery, am as trackerDataSchema, an as trackerTriggerContextSchema } from './schema-C4m9RhCR.js';
-import { M as MemberCompletion, B as Budget } from './capability-error-DSd8EMQC.js';
-export { C as CapabilityError, a as CapabilityErrorCode, c as capabilityErrorCodes } from './capability-error-DSd8EMQC.js';
-import { d as ProfileReferral } from './profiles-BoOK03cR.js';
+import { B as xContentBodySchema, I as IdentityKind, C as customSourceSchema, W as WithRecordData, D as WithContent, F as WithAccountRoles, y as ResourceHandle, x as QuestHandle, L as LedgerReference, G as GroupHandle, H as pointLedgerDeclarationSchema, J as TrackerSource, N as trackerDefinitionSchema, U as Tracker, V as TrackerData, X as SourceRoles, Y as LedgerHandle, Z as TrackerDataSchema, _ as xSearchSourceSchema, $ as XTweet, a0 as XContentMetric, a1 as TrackerTriggerPolicy, a2 as Where, a3 as MemberIdentity, P as PointBalance, a4 as ReferralHandle, a5 as TrackerTriggerContext, a6 as TrackerReader, a7 as TextReviewInput, a8 as TextResult, z as PhotoResult, a9 as Decision, aa as rewardSchema, ab as TrackerTriggerMode, ac as RoleOf, ad as WhereSetting, ae as ContentBody, af as BadgeHandle, ag as ContentMetricName, ah as triggerSchema, k as QuestPresentation, l as QuestProfile, m as QuizEvidence, ai as TieredRewardDefinition } from './schema-BA0nRRlt.js';
+export { aj as LedgerSetting, ak as TrackerPage, al as TrackerReadQuery, am as trackerDataSchema, an as trackerTriggerContextSchema } from './schema-BA0nRRlt.js';
+import { M as MemberCompletion, B as Budget } from './capability-error-DDJl0LY-.js';
+export { C as CapabilityError, a as CapabilityErrorCode, c as capabilityErrorCodes } from './capability-error-DDJl0LY-.js';
+import { N as NftCollection, o as ContractCall, p as ContractEvent, S as SolanaProgram, q as WalletBalanceSourceQuery, r as WalletTransaction, s as WalletInstruction, e as ProfileReferral, t as WalletReader } from './wallet-B06zvDXp.js';
+export { u as ContractCallParts, v as ContractCallReturnType, w as ContractEventInput, x as ContractEventParts, y as ContractFunction, z as CosmosDenom, a as CosmosNetwork, E as EvmChainId, B as NftCollectionParts, D as NftStandard, F as WalletBalance, G as WalletBalanceChange, H as WalletBalanceQuery, I as WalletBalanceSample, J as WalletCall, K as WalletCallArgument, M as WalletCallQuery, Q as WalletDelegations, R as WalletDelegationsQuery, T as WalletEventCondition, U as WalletEventValue, V as WalletEvents, X as WalletEventsQuery, Y as WalletNfts, Z as WalletNftsQuery, _ as WalletTransactions, $ as WalletTransactionsQuery, a0 as cosmosDenomSchema, a1 as cosmosNetworkSchema, a2 as isContractCall, a3 as isContractEvent, a4 as isEvmChainId, a5 as isNftCollection, a6 as isSolanaProgram, a7 as maxWalletEventLogs, a8 as maxWalletEventLookback, a9 as maxWalletTransactionLookback, aa as maxWalletTransactions, ab as parseContractCall, ac as parseContractEvent, ad as parseContractFunction, ae as parseNftCollection } from './wallet-B06zvDXp.js';
 import * as z from 'zod';
 export { z } from 'zod';
-import { f as badgeDeclarationSchema, B as Badge } from './offers-CtzMeB7O.js';
-export { g as defineOffer } from './offers-CtzMeB7O.js';
-import { E as EngagementBudget, l as leaderboardDefinitionSchema, m as AuthoringIdentity, r as referralAuthoringSchema, C as CampaignDefinition, A as AvailabilityWindow } from './groups-DPE004_V.js';
-export { n as defineCampaign, o as defineGroup } from './groups-DPE004_V.js';
-import { d as discordMessagesSourceSchema, D as DiscordMessageData, c as DiscordMessageTextData, e as discordReactionsSourceSchema, f as DiscordReactionData, g as TelegramReader, h as DiscordReader } from './accounts-DRPENuZe.js';
-export { i as TelegramChatMember, j as TelegramChatMemberStatus, k as TelegramReactionData } from './accounts-DRPENuZe.js';
+import { f as badgeDeclarationSchema, B as Badge } from './offers-DAfe1O3_.js';
+export { g as defineOffer } from './offers-DAfe1O3_.js';
+import { E as EngagementBudget, m as leaderboardDefinitionSchema, l as AuthoringIdentity, r as referralAuthoringSchema, C as CampaignDefinition, A as AvailabilityWindow } from './groups-CFuTfFqG.js';
+export { n as defineCampaign, o as defineGroup } from './groups-CFuTfFqG.js';
+import { d as discordMessagesSourceSchema, D as DiscordMessageData, c as DiscordMessageTextData, e as discordReactionsSourceSchema, f as DiscordReactionData, g as TelegramReader, h as DiscordReader } from './accounts-CVonEkdb.js';
+export { i as TelegramChatMember, j as TelegramChatMemberStatus, k as TelegramMessageData, l as TelegramReactionData } from './accounts-CVonEkdb.js';
 import { a as StreakPolicy, Q as QuizContent } from './streaks-0YuipsUQ.js';
-import { R as ResourceSource, S as Setting, A as AmountSetting, B as BalanceChain, I as IntegrationModule, a as BoundSettings } from './integrations-CcD5NPEA.js';
-export { D as DashboardInput, b as DashboardPanelInput, T as TikTokVideoBody, c as TikTokVideoMetric, Y as YouTubeShortBody, d as YouTubeShortMetric, e as defineDashboard } from './integrations-CcD5NPEA.js';
-import { P as Prerequisite, T as TextEvidence, U as UrlEvidence, a as TextOptions, b as UrlOptions } from './submission-input-wTiYGdgA.js';
-export { c as balanceAtLeast, d as completed, i as inGroup } from './submission-input-wTiYGdgA.js';
-import { I as ImageReader, X as XReader } from './x-1czZFVUW.js';
-import { h as WalletReader } from './wallet-Ac7OFpOr.js';
-export { i as CosmosDenom, a as CosmosNetwork, E as EvmChainId, j as WalletBalance, k as WalletBalanceQuery, l as cosmosDenomSchema, m as cosmosNetworkSchema, n as isEvmChainId } from './wallet-Ac7OFpOr.js';
+import { R as ResourceSource, S as Setting, A as AmountSetting, B as BalanceChain, I as IntegrationModule, a as BoundSettings } from './integrations-DrbKQSTD.js';
+export { D as DashboardInput, b as DashboardPanelInput, T as TikTokVideoBody, c as TikTokVideoMetric, Y as YouTubeShortBody, d as YouTubeShortMetric, e as defineDashboard } from './integrations-DrbKQSTD.js';
+import { P as Prerequisite, T as TextEvidence, U as UrlEvidence, a as TextOptions, b as UrlOptions } from './submission-input-DxQ6RnKo.js';
+export { c as balanceAtLeast, d as completed, i as inGroup } from './submission-input-DxQ6RnKo.js';
+import { I as ImageReader, X as XReader } from './x-C28SNifw.js';
 export { f as formatUnits, p as parseUnits } from './units-CwgsPB_r.js';
 import './analytics-URV-mxjH.js';
 
@@ -459,6 +458,11 @@ declare const discord: {
 /**
  * Telegram, through Domino's bot in the chats a project connects in Console.
  *
+ * - `telegram.messages()`: a tracker source of the messages members post in those groups and
+ *   supergroups. Each record is one message, keyed by chat and message ID: its `author` is the
+ *   poster's Telegram account. `data` is `TelegramMessageData`, which names the chat, the message,
+ *   and the reply target and topic thread, never the text. Bots', service and channel messages
+ *   are not recorded, and an edit is the same message.
  * - `telegram.reactions()`: a tracker source of the reactions members add to messages in those
  *   groups and supergroups. Each record is one added reaction: its `author` is the reactor and
  *   its `messageAuthor` account is the message's author, both Telegram accounts. `data` is
@@ -467,19 +471,43 @@ declare const discord: {
  * - Quests read membership with `ctx.telegram.member({ chat })`, naming the chat with
  *   `settings.telegramChat()`.
  *
- * In SDK 1.x the reactions source is a custom source whose namespace Relay reserves: only Relay
- * writes its records, and the accounts on them are Telegram accounts whatever `identities` says.
+ * In SDK 1.x both sources are custom sources whose namespaces Relay reserves: only Relay writes
+ * their records, and the accounts on them are Telegram accounts whatever `identities` says.
  */
 declare const telegram: {
+    messages(): {
+        kind: "custom";
+        namespace: string;
+        identities?: ("discord" | "member" | "wallet" | "x" | `app:${string}`)[] | undefined;
+        accounts?: string[] | undefined;
+        data?: TrackerDataSchema | undefined;
+        content?: {
+            metrics: string[];
+        } | undefined;
+        balance?: {
+            chain: string;
+            token: string | null;
+        } | undefined;
+    } & WithRecordData<{
+        chatId: string;
+        chatType: string;
+        messageId: number;
+        replyToMessageId: number | null;
+        threadId: number | null;
+    }> & WithAccountRoles<"author">;
     reactions(): {
         kind: "custom";
         namespace: string;
-        identities?: ("x" | "discord" | "member" | "wallet" | `app:${string}`)[] | undefined;
+        identities?: ("discord" | "member" | "wallet" | "x" | `app:${string}`)[] | undefined;
         accounts?: string[] | undefined;
         data?: TrackerDataSchema | undefined;
         content?: {
             metrics: string[];
         } | undefined;
+        balance?: {
+            chain: string;
+            token: string | null;
+        } | undefined;
     } & WithRecordData<{
         chatId: string;
         chatType: string;
@@ -509,12 +537,16 @@ declare const youtube: {
     shorts(): {
         kind: "custom";
         namespace: string;
-        identities?: ("x" | "discord" | "member" | "wallet" | `app:${string}`)[] | undefined;
+        identities?: ("discord" | "member" | "wallet" | "x" | `app:${string}`)[] | undefined;
         accounts?: string[] | undefined;
         data?: TrackerDataSchema | undefined;
         content?: {
             metrics: string[];
         } | undefined;
+        balance?: {
+            chain: string;
+            token: string | null;
+        } | undefined;
     } & WithRecordData<ContentData<{
         title: string;
         description: string;
@@ -547,12 +579,16 @@ declare const tiktok: {
     videos(): {
         kind: "custom";
         namespace: string;
-        identities?: ("x" | "discord" | "member" | "wallet" | `app:${string}`)[] | undefined;
+        identities?: ("discord" | "member" | "wallet" | "x" | `app:${string}`)[] | undefined;
         accounts?: string[] | undefined;
         data?: TrackerDataSchema | undefined;
         content?: {
             metrics: string[];
         } | undefined;
+        balance?: {
+            chain: string;
+            token: string | null;
+        } | undefined;
     } & WithRecordData<ContentData<{
         title: string;
         description: string;
@@ -573,6 +609,49 @@ declare const tiktok: {
         isAigc: boolean;
     }, "likes" | "views" | "comments" | "shares"> & WithAccountRoles<"author">;
 };
+/**
+ * Members' linked wallets, sampled by Relay.
+ *
+ * - `wallet.balances({ chain, token })`: a tracker source of daily balance samples. Once per
+ *   project-calendar day, at a time members can't predict, Relay reads the balance of every
+ *   wallet of that chain's family linked by a member who joined the project, every wallet at one
+ *   pinned EVM block or Cosmos height (Solana can't read a past slot: each read reaches at least
+ *   the pinned slot). Each record is one wallet, keyed by its CAIP-10 account on `chain`, which is also
+ *   its `author`; each sample is a new observation whose `occurredAt` is the sample time and whose
+ *   `data` is `WalletBalanceSample`. `chain` and `token` are those of `ctx.wallet.balance()`: an
+ *   EVM chain with its native coin or an ERC-20, Solana with SOL or an SPL or Token-2022 mint, or a
+ *   Cosmos chain with a bank denomination. A day whose reads all fail has no sample: Relay never
+ *   writes a balance it didn't read. Reward holding for days with
+ *   `automatic({ tracker, where: { path: "amount", gte: ... } })` and `streak({ days })`.
+ *
+ * In SDK 1.x the source is a custom source whose namespace Relay reserves: only Relay writes its
+ * records. A project and environment can have at most 5 of them.
+ */
+declare const wallet: {
+    balances(query: WalletBalanceSourceQuery): ({
+        kind: "custom";
+        namespace: string;
+        identities?: ("discord" | "member" | "wallet" | "x" | `app:${string}`)[] | undefined;
+        accounts?: string[] | undefined;
+        data?: TrackerDataSchema | undefined;
+        content?: {
+            metrics: string[];
+        } | undefined;
+        balance?: {
+            chain: string;
+            token: string | null;
+        } | undefined;
+    } & WithRecordData<{
+        amount: string;
+        decimals: number | null;
+        block: string;
+    }> & WithAccountRoles<"author">) & {
+        balance: {
+            chain: string;
+            token: string | null;
+        };
+    };
+};
 declare const pointLedgers: () => ResourceSource;
 type Label = {
     label: string;
@@ -630,6 +709,50 @@ declare const settings: {
     chain(options: Label & {
         default: BalanceChain;
     }): Setting<"text", z.ZodDefault<z.ZodPipe<z.ZodString, z.ZodTransform<"solana" | "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp" | `eip155:${number}`, string>>>>;
+    /**
+     * An NFT collection `ctx.wallet.nfts()` reads, as a CAIP-19 asset type: an EVM chain, the
+     * standard and the contract, such as `"eip155:1/erc721:0x…"`, or `"eip155:8453/erc1155:0x…/1"` for
+     * one ERC-1155 token ID; or a Metaplex collection NFT's mint on Solana mainnet,
+     * `"solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/nft:<mint>"`. Relay checks it when the collection is
+     * published or edited: an EVM chain must be one `ctx.wallet.balance()` reads and the contract
+     * must report the standard through ERC-165 `supportsInterface`; a Solana mint must be a Metaplex
+     * collection NFT. Typed as the query's collection, so it passes to
+     * `ctx.wallet.nfts({ collection })` as it is.
+     */
+    nft(options: Label & {
+        default: NftCollection;
+    }): Setting<"text", z.ZodDefault<z.ZodPipe<z.ZodString, z.ZodTransform<`eip155:${number}/erc721:0x${string}` | `eip155:${number}/erc1155:0x${string}/${string}` | `solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/nft:${string}`, string>>>>;
+    /**
+     * A contract function `ctx.wallet.call()` reads: the contract's CAIP-10 account ID on an EVM
+     * chain, a space, and the function's human-readable signature, such as
+     * `"eip155:8453:0x… function stakedOf(address) view returns (uint256)"`. Only `view` and `pure`
+     * functions with elementary parameters that return one `uint`, `int`, `bool` or `address` are
+     * accepted; publication and Console edits also check that Relay reads the chain. Typed as the
+     * query's call, so it passes to `ctx.wallet.call({ call })` as it is.
+     */
+    contractCall(options: Label & {
+        default: ContractCall;
+    }): Setting<"text", z.ZodDefault<z.ZodPipe<z.ZodString, z.ZodTransform<`eip155:${number}:0x${string} function ${string}`, string>>>>;
+    /**
+     * An EVM contract event `ctx.wallet.events()` reads: the contract as a CAIP-10 account ID and
+     * the event's Solidity signature, with argument names and `indexed` markers, such as
+     * `"eip155:8453:0x… Transfer(address indexed from, address indexed to, uint256 value)"`. The event
+     * needs an indexed `address` argument, the one matched against the member's wallets. Relay checks
+     * it when the event is published or edited: the chain must be one `ctx.wallet.balance()` reads
+     * and report a finalized or safe block, and the address must hold a contract. Typed as the query's
+     * event, so it passes to `ctx.wallet.events({ event })` as it is.
+     */
+    contractEvent(options: Label & {
+        default: ContractEvent;
+    }): Setting<"text", z.ZodDefault<z.ZodPipe<z.ZodString, z.ZodTransform<`eip155:${number}:0x${string} ${string}`, string>>>>;
+    /**
+     * A Solana mainnet program `ctx.wallet.transactions()` reads: its base58 address, such as
+     * Jupiter's `"JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4"`. Relay checks it when it is published
+     * or edited: the account must exist and be an executable program.
+     */
+    solanaProgram(options: Label & {
+        default: SolanaProgram;
+    }): Setting<"text", z.ZodDefault<z.ZodPipe<z.ZodString, z.ZodTransform<string, string>>>>;
     integer(options: Label & {
         default: number;
         min: number;
@@ -646,6 +769,35 @@ declare const settings: {
     object<T extends Record<string, Setting>>(shape: T): z.ZodObject<{ -readonly [P in keyof T]: T[P]; }, z.core.$strict>;
 };
 
+/**
+ * How much of `mint` (`"SOL"` for lamports) the wallet gained in `tx`, in base units, or `"0"`
+ * when it gained none.
+ */
+declare function received(tx: WalletTransaction, mint: string): string;
+/**
+ * How much of `mint` (`"SOL"` for lamports, rent included, the fee not) the wallet gave up in `tx`, in base
+ * units, or `"0"` when it gave up none.
+ */
+declare function spent(tx: WalletTransaction, mint: string): string;
+/**
+ * Whether the wallet swapped in `tx`: one mint went down and a different one went up. `into` names
+ * the mint that must have gone up, `from` the one that must have gone down; `"SOL"` stands for
+ * lamports. The fee is left out of SOL, but rent is not: a transaction that opens a token account
+ * for the wallet lowers its SOL by the rent, so check a swap out of SOL with `spent(tx, "SOL")`
+ * against a minimum above it.
+ */
+declare function swapped(tx: WalletTransaction, options?: {
+    into?: string;
+    from?: string;
+}): boolean;
+/** Whether `tx` invoked `program`, in a top-level or inner instruction. */
+declare function invoked(tx: WalletTransaction, program: string): boolean;
+/**
+ * The arguments of the first instruction of the program in `tx` named `name`, as the program's
+ * Anchor IDL spells it, or `null` when there is none, or the program's setting has no IDL.
+ */
+declare function instruction(tx: WalletTransaction, name: string): WalletInstruction["args"] | null;
+
 declare const badge: (definition: BadgeHandle & Pick<Badge, "name">) => {
     reward: {
         badge: string;
@@ -1402,7 +1554,7 @@ declare const defineQuest: <T extends Record<string, Setting>, const G extends T
             imageAlt?: string | undefined;
             requirements?: ({
                 kind: "account";
-                provider: "x" | "discord" | "google" | "apple";
+                provider: "discord" | "x" | "google" | "apple";
             } | {
                 kind: "wallet";
                 chain?: "solana" | "eip155" | "cosmos" | undefined;
@@ -1426,7 +1578,7 @@ declare const defineQuest: <T extends Record<string, Setting>, const G extends T
                 } | undefined;
             } | undefined;
         };
-        integrations: ("x" | "discord")[];
+        integrations: ("discord" | "x")[];
         fields: Record<string, {
             kind: "point-ledger";
             default: string;
@@ -1852,7 +2004,7 @@ declare const defineQuestType: <T extends Record<string, Setting>, const G exten
             imageAlt?: string | undefined;
             requirements?: ({
                 kind: "account";
-                provider: "x" | "discord" | "google" | "apple";
+                provider: "discord" | "x" | "google" | "apple";
             } | {
                 kind: "wallet";
                 chain?: "solana" | "eip155" | "cosmos" | undefined;
@@ -1876,7 +2028,7 @@ declare const defineQuestType: <T extends Record<string, Setting>, const G exten
                 } | undefined;
             } | undefined;
         };
-        integrations: ("x" | "discord")[];
+        integrations: ("discord" | "x")[];
         fields: Record<string, {
             kind: "point-ledger";
             default: string;
@@ -2192,4 +2344,4 @@ declare const defineQuestType: <T extends Record<string, Setting>, const G exten
     }): Promise<Decision>;
 } & ResourceHandle<"quest">;
 
-export { AmountSetting, BalanceChain, ContentBody, type ContentData, ContentMetricName, type ContentTrigger, type ContentTriggerInput, DiscordMessageData, DiscordMessageTextData, DiscordReactionData, DiscordReader, type EvaluationCalendar, type EvaluationCalendarDay, type EvaluationContext, type EvaluationMember, GroupHandle, IdentityKind, ImageReader, IntegrationModule, type KeyedContext, LedgerHandle, LedgerReference, MemberCompletion, type MemberCompletionQuery, MemberIdentity, type Outcome, type PerformanceContext, type PerformanceOutcome, PointBalance, ProfileReferral, QuestHandle, type QuestKeyedContext, ReferralHandle, RoleOf, Setting, TelegramReader, Tracker, TrackerData, TrackerDataSchema, TrackerReader, type TrackerTrigger, TrackerTriggerContext, type TrackerTriggerInput, type TriggerAdmission, WalletReader, Where, type XContentBody, XReader, automatic, automaticFulfillment, badge, budget, calendar, content, count, customSource, decision, defineBadge, defineEngagementReward, defineLeaderboard, defineLedger, defineQuest, defineQuestType, defineReferral, defineTieredReward, defineTracker, discord, earned, evaluators, evidence, groupMembership, keyed, manual, once, pointLedgers, points, progress, questCompleted, rolling, settings, staffHandover, streak, telegram, tiktok, untracked, x, youtube };
+export { AmountSetting, BalanceChain, ContentBody, type ContentData, ContentMetricName, type ContentTrigger, type ContentTriggerInput, ContractCall, ContractEvent, DiscordMessageData, DiscordMessageTextData, DiscordReactionData, DiscordReader, type EvaluationCalendar, type EvaluationCalendarDay, type EvaluationContext, type EvaluationMember, GroupHandle, IdentityKind, ImageReader, IntegrationModule, type KeyedContext, LedgerHandle, LedgerReference, MemberCompletion, type MemberCompletionQuery, MemberIdentity, NftCollection, type Outcome, type PerformanceContext, type PerformanceOutcome, PointBalance, ProfileReferral, QuestHandle, type QuestKeyedContext, ReferralHandle, RoleOf, Setting, SolanaProgram, TelegramReader, Tracker, TrackerData, TrackerDataSchema, TrackerReader, type TrackerTrigger, TrackerTriggerContext, type TrackerTriggerInput, type TriggerAdmission, WalletBalanceSourceQuery, WalletInstruction, WalletReader, WalletTransaction, Where, type XContentBody, XReader, automatic, automaticFulfillment, badge, budget, calendar, content, count, customSource, decision, defineBadge, defineEngagementReward, defineLeaderboard, defineLedger, defineQuest, defineQuestType, defineReferral, defineTieredReward, defineTracker, discord, earned, evaluators, evidence, groupMembership, instruction, invoked, keyed, manual, once, pointLedgers, points, progress, questCompleted, received, rolling, settings, spent, staffHandover, streak, swapped, telegram, tiktok, untracked, wallet, x, youtube };