@poa-box/core 0.1.0

package/dist/graph/documents/voting.js

@@ -0,0 +1,163 @@
+"use strict";
+/**
+ * Voting Queries
+ * Ported from frontend queries.js
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FETCH_VOTING_DATA_LEGACY = exports.FETCH_VOTING_DATA = exports.PROPOSAL_STATE_FOR_PREFLIGHT = exports.RECENT_PROPOSALS_FOR_RESOLVE = void 0;
+/**
+ * Fuzzy --proposal resolution: recent proposals for ONE voting contract,
+ * addressed directly by contract address (works for HybridVoting and
+ * DirectDemocracyVoting — whichever entity matches the address answers,
+ * the other root field returns null). Titles are stored decoded by the
+ * subgraph, so they can be scored with bestMatches directly.
+ */
+exports.RECENT_PROPOSALS_FOR_RESOLVE = `
+  query RecentProposalsForResolve($votingId: ID!, $first: Int!) {
+    hybridVotingContract(id: $votingId) {
+      id
+      proposals(orderBy: startTimestamp, orderDirection: desc, first: $first) {
+        proposalId
+        title
+        status
+        endTimestamp
+      }
+    }
+    directDemocracyVotingContract(id: $votingId) {
+      id
+      ddvProposals(orderBy: startTimestamp, orderDirection: desc, first: $first) {
+        proposalId
+        title
+        status
+        endTimestamp
+      }
+    }
+  }
+`;
+/**
+ * One proposal's voting-window state for the cast pre-flight
+ * ("not obviously ended"). Same dual-entity addressing as above.
+ */
+exports.PROPOSAL_STATE_FOR_PREFLIGHT = `
+  query ProposalStateForPreflight($votingId: ID!, $proposalId: BigInt!) {
+    hybridVotingContract(id: $votingId) {
+      proposals(where: { proposalId: $proposalId }, first: 1) {
+        proposalId
+        status
+        endTimestamp
+      }
+    }
+    directDemocracyVotingContract(id: $votingId) {
+      ddvProposals(where: { proposalId: $proposalId }, first: 1) {
+        proposalId
+        status
+        endTimestamp
+      }
+    }
+  }
+`;
+exports.FETCH_VOTING_DATA = `
+  query FetchVotingDataNew($orgId: Bytes!) {
+    organization(id: $orgId) {
+      id
+      hybridVoting {
+        id
+        thresholdPct
+        quorum
+        classVersion
+        votingClasses(where: { isActive: true }, orderBy: classIndex, orderDirection: asc) {
+          id
+          classIndex
+          version
+          strategy
+          slicePct
+          quadratic
+          minBalance
+          asset
+          hatIds
+          isActive
+        }
+        proposals(orderBy: startTimestamp, orderDirection: desc, first: 50) {
+          id
+          proposalId
+          title
+          descriptionHash
+          metadata {
+            id
+            description
+            optionNames
+          }
+          numOptions
+          startTimestamp
+          endTimestamp
+          status
+          winningOption
+          isValid
+          wasExecuted
+          executionFailed
+          executionError
+          isHatRestricted
+          restrictedHatIds
+          proposer
+          proposerUsername
+          creatorUsername
+          classesVersion
+          votes {
+            voter
+            voterUsername
+            optionIndexes
+            optionWeights
+            classRawPowers
+            votedAt
+          }
+        }
+      }
+      directDemocracyVoting {
+        id
+        thresholdPct
+        quorum
+        ddvProposals(orderBy: startTimestamp, orderDirection: desc, first: 50) {
+          id
+          proposalId
+          title
+          descriptionHash
+          metadata {
+            id
+            description
+            optionNames
+          }
+          numOptions
+          startTimestamp
+          endTimestamp
+          status
+          winningOption
+          isValid
+          executionFailed
+          executionError
+          isHatRestricted
+          restrictedHatIds
+          proposer
+          proposerUsername
+          votes {
+            voter
+            optionIndexes
+            optionWeights
+          }
+        }
+      }
+    }
+  }
+`;
+/**
+ * FETCH_VOTING_DATA without the subgraph #195 attribution fields.
+ *
+ * A GraphQL document is validated as a whole, so a single unknown field fails the entire
+ * query — not just that selection. `pop vote announce-all` (a WRITE that announces winners)
+ * shares this document, so against a subgraph pinned before #195 the org would lose the
+ * ability to announce ANY proposal. Derived from the full query by deletion so the two
+ * cannot drift apart.
+ */
+exports.FETCH_VOTING_DATA_LEGACY = exports.FETCH_VOTING_DATA
+    .split('\n')
+    .filter((line) => !/^\s*(proposer|proposerUsername|creatorUsername|classesVersion|classVersion)\s*$/.test(line))
+    .join('\n');

package/dist/graph/documents/vouch.d.ts

@@ -0,0 +1,79 @@
+/**
+ * Vouching Queries
+ * Ported from frontend queries.js
+ */
+/**
+ * Vouch config for one hat — the subgraph mirror of
+ * EligibilityModule.getVouchConfig(hatId) / vouchConfigs(hatId).
+ *
+ * Field population VERIFIED live (2026-07-30) on BOTH deployments:
+ *   poa-gnosis-v-1 → quorum=1, membershipHatId=2908…, enabled=true,
+ *                    combinesWithHierarchy=true/false (both values present)
+ *   poa-arb-v-1    → same fields, same shape
+ * so no field-fallback tier is required. Callers still degrade to the RPC
+ * getter on ANY error (including a hypothetical unknown-field validation
+ * failure on a self-hosted older deployment), which is the correct answer
+ * rather than a partially-filled one.
+ *
+ * A MISSING row is deliberately NOT treated as "vouching disabled": callers
+ * fall back to RPC, because absence is ambiguous between "no VouchConfigSet
+ * event was ever emitted" and "not indexed yet".
+ */
+export declare const FETCH_VOUCH_CONFIG = "\n  query FetchVouchConfig($eligibilityModuleId: Bytes!, $hatId: BigInt!) {\n    vouchConfigs(\n      where: { eligibilityModule: $eligibilityModuleId, hatId: $hatId }\n      first: 1\n    ) {\n      id\n      hatId\n      quorum\n      membershipHatId\n      enabled\n      combinesWithHierarchy\n    }\n  }\n";
+/**
+ * TIER 0 — vouch progress read off the subgraph's epoch mirror.
+ *
+ * EligibilityModule kills stale vouches by bumping an epoch counter rather than
+ * emitting a per-vouch invalidation:
+ *
+ *   configureVouching / batchConfigureVouching / resetVouches → vouchConfigEpoch[hatId]++
+ *   clearWearerVouches                                        → wearerVouchEpoch = 2^256-1
+ *
+ * and `currentVouchCount(hatId, wearer)` returns 0 whenever the two disagree. The
+ * subgraph mirrors both counters onto WearerVouchState, so this tier reproduces the
+ * getter EXACTLY:
+ *
+ *   currentCount = (state.epoch == config.epoch) ? state.count : 0
+ *
+ * No row counting, so no 1000-row page cap and no cross-epoch overcount.
+ *
+ * `effectiveCount` is the subgraph's own materialisation of that same expression. It
+ * is read only as a CONSISTENCY CHECK: the count+epoch comparison is self-correcting
+ * while effectiveCount depends on a sweep, so a disagreement means the deployment is
+ * buggy and the caller falls back to RPC rather than picking a winner.
+ *
+ * This tier fails GraphQL validation (unknown field `epoch`) on deployments predating
+ * the epoch indexing, which is what drops callers to FETCH_VOUCH_STATUS below.
+ */
+export declare const FETCH_VOUCH_STATUS_EPOCH_AWARE = "\n  query FetchVouchStatusEpochAware($eligibilityModuleId: Bytes!, $hatId: BigInt!, $wearer: Bytes!) {\n    vouchConfigs(\n      where: { eligibilityModule: $eligibilityModuleId, hatId: $hatId }\n      first: 1\n    ) {\n      id\n      hatId\n      quorum\n      membershipHatId\n      enabled\n      combinesWithHierarchy\n      epoch\n    }\n    wearerVouchStates(\n      where: {\n        eligibilityModule: $eligibilityModuleId\n        hatId: $hatId\n        wearer: $wearer\n      }\n      first: 1\n    ) {\n      id\n      count\n      effectiveCount\n      epoch\n      cleared\n    }\n  }\n";
+/**
+ * TIER 1 — legacy deployments with no epoch mirror.
+ *
+ * `vouches.length` approximates the on-chain currentVouchCount(hatId, wearer):
+ * EligibilityModule increments the counter in vouchFor (emits Vouched) and decrements
+ * it in revokeVouch (emits VouchRevoked), and the subgraph creates a Vouch on Vouched /
+ * flips isActive=false on VouchRevoked.
+ *
+ * VERIFIED live against Gnosis RPC on 5 real (hat, wearer) pairs, including three with
+ * a count of 2 — active-Vouch count matched currentVouchCount() exactly on all 5.
+ *
+ * It is only an APPROXIMATION: on these deployments an epoch bump leaves the superseded
+ * rows at isActive=true, so the count runs high after any reconfiguration. `updatedAtBlock`
+ * and `createdAtBlock` exist purely so the caller can detect that ambiguity (any vouch
+ * older than the config's last update) and refuse to derive.
+ *
+ * `first: 1000` is the Graph page cap; callers treat a full page as "cannot derive"
+ * and fall back to RPC rather than silently under-counting.
+ */
+export declare const FETCH_VOUCH_STATUS = "\n  query FetchVouchStatus($eligibilityModuleId: Bytes!, $hatId: BigInt!, $wearer: Bytes!) {\n    vouchConfigs(\n      where: { eligibilityModule: $eligibilityModuleId, hatId: $hatId }\n      first: 1\n    ) {\n      id\n      hatId\n      quorum\n      membershipHatId\n      enabled\n      combinesWithHierarchy\n      updatedAtBlock\n    }\n    vouches(\n      where: {\n        eligibilityModule: $eligibilityModuleId\n        hatId: $hatId\n        wearer: $wearer\n        isActive: true\n      }\n      first: 1000\n    ) {\n      id\n      createdAtBlock\n    }\n  }\n";
+/**
+ * Recent vouch activity for `pop vouch list` — display only, never a quorum decision.
+ *
+ * `isActive` IS THE EPOCH FILTER HERE. On deployments that index the epoch, the indexer
+ * flips isActive=false for every vouch a configureVouching/resetVouches/clearWearerVouches
+ * voided (recording invalidatedAt to keep that distinct from a voucher's own revokedAt),
+ * so this listing is epoch-correct with no extra field. On older deployments the
+ * superseded rows are still isActive and will be listed — stale rather than wrong, which
+ * is acceptable for a listing but NOT for the quorum maths in FETCH_VOUCH_STATUS above.
+ */
+export declare const FETCH_VOUCHES_FOR_ORG = "\n  query FetchVouchesForOrg($eligibilityModuleId: Bytes!) {\n    vouches(\n      where: { eligibilityModule: $eligibilityModuleId, isActive: true }\n      orderBy: createdAt\n      orderDirection: desc\n      first: 200\n    ) {\n      id\n      hatId\n      wearer\n      wearerUsername\n      voucher\n      voucherUsername\n      vouchCount\n      isActive\n      createdAt\n    }\n  }\n";

package/dist/graph/documents/vouch.js

@@ -0,0 +1,171 @@
+"use strict";
+/**
+ * Vouching Queries
+ * Ported from frontend queries.js
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FETCH_VOUCHES_FOR_ORG = exports.FETCH_VOUCH_STATUS = exports.FETCH_VOUCH_STATUS_EPOCH_AWARE = exports.FETCH_VOUCH_CONFIG = void 0;
+/**
+ * Vouch config for one hat — the subgraph mirror of
+ * EligibilityModule.getVouchConfig(hatId) / vouchConfigs(hatId).
+ *
+ * Field population VERIFIED live (2026-07-30) on BOTH deployments:
+ *   poa-gnosis-v-1 → quorum=1, membershipHatId=2908…, enabled=true,
+ *                    combinesWithHierarchy=true/false (both values present)
+ *   poa-arb-v-1    → same fields, same shape
+ * so no field-fallback tier is required. Callers still degrade to the RPC
+ * getter on ANY error (including a hypothetical unknown-field validation
+ * failure on a self-hosted older deployment), which is the correct answer
+ * rather than a partially-filled one.
+ *
+ * A MISSING row is deliberately NOT treated as "vouching disabled": callers
+ * fall back to RPC, because absence is ambiguous between "no VouchConfigSet
+ * event was ever emitted" and "not indexed yet".
+ */
+exports.FETCH_VOUCH_CONFIG = `
+  query FetchVouchConfig($eligibilityModuleId: Bytes!, $hatId: BigInt!) {
+    vouchConfigs(
+      where: { eligibilityModule: $eligibilityModuleId, hatId: $hatId }
+      first: 1
+    ) {
+      id
+      hatId
+      quorum
+      membershipHatId
+      enabled
+      combinesWithHierarchy
+    }
+  }
+`;
+/**
+ * TIER 0 — vouch progress read off the subgraph's epoch mirror.
+ *
+ * EligibilityModule kills stale vouches by bumping an epoch counter rather than
+ * emitting a per-vouch invalidation:
+ *
+ *   configureVouching / batchConfigureVouching / resetVouches → vouchConfigEpoch[hatId]++
+ *   clearWearerVouches                                        → wearerVouchEpoch = 2^256-1
+ *
+ * and `currentVouchCount(hatId, wearer)` returns 0 whenever the two disagree. The
+ * subgraph mirrors both counters onto WearerVouchState, so this tier reproduces the
+ * getter EXACTLY:
+ *
+ *   currentCount = (state.epoch == config.epoch) ? state.count : 0
+ *
+ * No row counting, so no 1000-row page cap and no cross-epoch overcount.
+ *
+ * `effectiveCount` is the subgraph's own materialisation of that same expression. It
+ * is read only as a CONSISTENCY CHECK: the count+epoch comparison is self-correcting
+ * while effectiveCount depends on a sweep, so a disagreement means the deployment is
+ * buggy and the caller falls back to RPC rather than picking a winner.
+ *
+ * This tier fails GraphQL validation (unknown field `epoch`) on deployments predating
+ * the epoch indexing, which is what drops callers to FETCH_VOUCH_STATUS below.
+ */
+exports.FETCH_VOUCH_STATUS_EPOCH_AWARE = `
+  query FetchVouchStatusEpochAware($eligibilityModuleId: Bytes!, $hatId: BigInt!, $wearer: Bytes!) {
+    vouchConfigs(
+      where: { eligibilityModule: $eligibilityModuleId, hatId: $hatId }
+      first: 1
+    ) {
+      id
+      hatId
+      quorum
+      membershipHatId
+      enabled
+      combinesWithHierarchy
+      epoch
+    }
+    wearerVouchStates(
+      where: {
+        eligibilityModule: $eligibilityModuleId
+        hatId: $hatId
+        wearer: $wearer
+      }
+      first: 1
+    ) {
+      id
+      count
+      effectiveCount
+      epoch
+      cleared
+    }
+  }
+`;
+/**
+ * TIER 1 — legacy deployments with no epoch mirror.
+ *
+ * `vouches.length` approximates the on-chain currentVouchCount(hatId, wearer):
+ * EligibilityModule increments the counter in vouchFor (emits Vouched) and decrements
+ * it in revokeVouch (emits VouchRevoked), and the subgraph creates a Vouch on Vouched /
+ * flips isActive=false on VouchRevoked.
+ *
+ * VERIFIED live against Gnosis RPC on 5 real (hat, wearer) pairs, including three with
+ * a count of 2 — active-Vouch count matched currentVouchCount() exactly on all 5.
+ *
+ * It is only an APPROXIMATION: on these deployments an epoch bump leaves the superseded
+ * rows at isActive=true, so the count runs high after any reconfiguration. `updatedAtBlock`
+ * and `createdAtBlock` exist purely so the caller can detect that ambiguity (any vouch
+ * older than the config's last update) and refuse to derive.
+ *
+ * `first: 1000` is the Graph page cap; callers treat a full page as "cannot derive"
+ * and fall back to RPC rather than silently under-counting.
+ */
+exports.FETCH_VOUCH_STATUS = `
+  query FetchVouchStatus($eligibilityModuleId: Bytes!, $hatId: BigInt!, $wearer: Bytes!) {
+    vouchConfigs(
+      where: { eligibilityModule: $eligibilityModuleId, hatId: $hatId }
+      first: 1
+    ) {
+      id
+      hatId
+      quorum
+      membershipHatId
+      enabled
+      combinesWithHierarchy
+      updatedAtBlock
+    }
+    vouches(
+      where: {
+        eligibilityModule: $eligibilityModuleId
+        hatId: $hatId
+        wearer: $wearer
+        isActive: true
+      }
+      first: 1000
+    ) {
+      id
+      createdAtBlock
+    }
+  }
+`;
+/**
+ * Recent vouch activity for `pop vouch list` — display only, never a quorum decision.
+ *
+ * `isActive` IS THE EPOCH FILTER HERE. On deployments that index the epoch, the indexer
+ * flips isActive=false for every vouch a configureVouching/resetVouches/clearWearerVouches
+ * voided (recording invalidatedAt to keep that distinct from a voucher's own revokedAt),
+ * so this listing is epoch-correct with no extra field. On older deployments the
+ * superseded rows are still isActive and will be listed — stale rather than wrong, which
+ * is acceptable for a listing but NOT for the quorum maths in FETCH_VOUCH_STATUS above.
+ */
+exports.FETCH_VOUCHES_FOR_ORG = `
+  query FetchVouchesForOrg($eligibilityModuleId: Bytes!) {
+    vouches(
+      where: { eligibilityModule: $eligibilityModuleId, isActive: true }
+      orderBy: createdAt
+      orderDirection: desc
+      first: 200
+    ) {
+      id
+      hatId
+      wearer
+      wearerUsername
+      voucher
+      voucherUsername
+      vouchCount
+      isActive
+      createdAt
+    }
+  }
+`;

package/dist/graph/documents/zkemail.d.ts

@@ -0,0 +1,63 @@
+/**
+ * ZkEmailInvites Queries
+ *
+ * The ZK Email role-invite module is optional per org: `organization.zkEmailInvites` is null
+ * for orgs deployed without it. A module with `activeRoot == null` is deployed but dormant —
+ * every claim reverts until governance sets an allowlist.
+ */
+/**
+ * Full module read, including the fields added by subgraph-pop #197: the module wiring
+ * (executor + verifiers + registries) and the DKIM keys the trusted registry holds.
+ *
+ * Every one of those replaces an RPC call the CLI used to make — six eth_calls for the wiring
+ * and a full-range eth_getLogs scan for the DKIM keys. Until #197 is deployed the whole
+ * document fails validation, so callers must go through FETCH_ZKEMAIL_MODULE_TIERS rather than
+ * issuing this directly.
+ */
+export declare const FETCH_ZKEMAIL_MODULE = "\n  query FetchZkEmailModule($orgId: Bytes!) {\n    organization(id: $orgId) {\n      id\n      name\n      zkEmailInvites {\n        id\n        activeRoot\n        activeAllowlistCid\n        executor\n        domainVerifier\n        emailVerifier\n        accountRegistry\n        universalFactory\n        claimCount\n        dkimRegistry {\n          id\n          owner\n          keys(first: 1000) {\n            id\n            domainHash\n            keyHash\n            valid\n            validUntil\n            revokedAt\n          }\n        }\n        activeAllowlist {\n          id\n          root\n          indexedAt\n          entries(orderBy: index, orderDirection: asc, first: 1000) {\n            id\n            index\n            entryType\n            identifier\n            identifierHash\n            hatIds\n            roleIndexes\n          }\n        }\n      }\n    }\n  }\n";
+/**
+ * The pre-#197 field set: allowlist only, no wiring and no DKIM registry.
+ *
+ * Derived from the modern query by deletion so the two cannot drift. A GraphQL document is
+ * validated as a whole, so a single unknown field fails the entire request — without this tier
+ * every `pop zkemail` command would break against a subgraph that has not been redeployed yet.
+ */
+export declare const FETCH_ZKEMAIL_MODULE_LEGACY: string;
+/** Modern tier first, pre-#197 tier as the fallback. */
+export declare const FETCH_ZKEMAIL_MODULE_TIERS: string[];
+/**
+ * Has this specific address already consumed its specific-address invite?
+ *
+ * Replaces an `isEmailRegistered` eth_call. Only meaningful post-#197; callers fall back to the
+ * contract when the entity is absent.
+ */
+export declare const FETCH_ZKEMAIL_REGISTERED_EMAIL = "\n  query FetchZkEmailRegisteredEmail($id: ID!) {\n    zkEmailRegisteredEmail(id: $id) {\n      id\n      registered\n      claimer\n      claimedAt\n      clearedAt\n    }\n  }\n";
+/**
+ * Resolve role hat IDs to human names so an allowlist can be shown as
+ * "gmail.com -> Member" instead of a raw uint256.
+ */
+export declare const FETCH_ORG_ROLE_NAMES = "\n  query FetchOrgRoleNames($orgId: Bytes!) {\n    organization(id: $orgId) {\n      id\n      roles {\n        id\n        hatId\n        name\n        isUserRole\n        canVote\n      }\n    }\n  }\n";
+/**
+ * Claim history for a module (subgraph-pop #197).
+ *
+ * Two things to know when rendering these:
+ *   - `nullifier` is null for the passkey onboarding variants (RegisteredAndClaimed*), which do
+ *     not emit it. On the live Gnosis module that is most claims, so absence is normal.
+ *   - `identifierHash` is the allowlist leaf id the claim used, which may belong to a SUPERSEDED
+ *     allowlist. Resolve it against the active entries opportunistically, never assume it hits.
+ */
+export declare const FETCH_ZKEMAIL_CLAIMS = "\n  query FetchZkEmailClaims($module: String!, $first: Int!) {\n    zkEmailClaims(\n      where: { module: $module }\n      orderBy: claimedAt\n      orderDirection: desc\n      first: $first\n    ) {\n      id\n      kind\n      claimer\n      claimerUsername\n      identifierHash\n      hatIds\n      nullifier\n      registeredUsername\n      claimedAt\n      claimedAtBlock\n      transactionHash\n    }\n  }\n";
+/**
+ * Just the committed allowlist pointer for an org's module.
+ *
+ * `activeRoot`/`activeAllowlistCid` are the two fields that exist on BOTH deployed schemas —
+ * Gnosis (post-#197) and Arbitrum (pre-#197, where ZkEmailInvites is only
+ * {id, organization, activeRoot, activeAllowlistCid, activeAllowlist, createdAt, lastUpdatedAt})
+ * — so this needs no queryWithFieldFallback tier. Verified populated on live Gnosis:
+ * activeRoot = 0x1d5d75df3ee05a0a90c42f0fe423f3c063dedf3466378e45a8343bfef18ebc46.
+ *
+ * A null `activeRoot` on a module row that EXISTS means dormant (no allowlist committed yet),
+ * which is the same thing the contract reports as merkleRoot() == 0. A missing row means "not
+ * indexed" and callers must fall back to the contract.
+ */
+export declare const FETCH_ZKEMAIL_ACTIVE_ROOT = "\n  query FetchZkEmailActiveRoot($orgId: Bytes!) {\n    organization(id: $orgId) {\n      id\n      zkEmailInvites {\n        id\n        activeRoot\n        activeAllowlistCid\n      }\n    }\n  }\n";

package/dist/graph/documents/zkemail.js

@@ -0,0 +1,188 @@
+"use strict";
+/**
+ * ZkEmailInvites Queries
+ *
+ * The ZK Email role-invite module is optional per org: `organization.zkEmailInvites` is null
+ * for orgs deployed without it. A module with `activeRoot == null` is deployed but dormant —
+ * every claim reverts until governance sets an allowlist.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FETCH_ZKEMAIL_ACTIVE_ROOT = exports.FETCH_ZKEMAIL_CLAIMS = exports.FETCH_ORG_ROLE_NAMES = exports.FETCH_ZKEMAIL_REGISTERED_EMAIL = exports.FETCH_ZKEMAIL_MODULE_TIERS = exports.FETCH_ZKEMAIL_MODULE_LEGACY = exports.FETCH_ZKEMAIL_MODULE = void 0;
+/**
+ * Full module read, including the fields added by subgraph-pop #197: the module wiring
+ * (executor + verifiers + registries) and the DKIM keys the trusted registry holds.
+ *
+ * Every one of those replaces an RPC call the CLI used to make — six eth_calls for the wiring
+ * and a full-range eth_getLogs scan for the DKIM keys. Until #197 is deployed the whole
+ * document fails validation, so callers must go through FETCH_ZKEMAIL_MODULE_TIERS rather than
+ * issuing this directly.
+ */
+exports.FETCH_ZKEMAIL_MODULE = `
+  query FetchZkEmailModule($orgId: Bytes!) {
+    organization(id: $orgId) {
+      id
+      name
+      zkEmailInvites {
+        id
+        activeRoot
+        activeAllowlistCid
+        executor
+        domainVerifier
+        emailVerifier
+        accountRegistry
+        universalFactory
+        claimCount
+        dkimRegistry {
+          id
+          owner
+          keys(first: 1000) {
+            id
+            domainHash
+            keyHash
+            valid
+            validUntil
+            revokedAt
+          }
+        }
+        activeAllowlist {
+          id
+          root
+          indexedAt
+          entries(orderBy: index, orderDirection: asc, first: 1000) {
+            id
+            index
+            entryType
+            identifier
+            identifierHash
+            hatIds
+            roleIndexes
+          }
+        }
+      }
+    }
+  }
+`;
+/**
+ * The pre-#197 field set: allowlist only, no wiring and no DKIM registry.
+ *
+ * Derived from the modern query by deletion so the two cannot drift. A GraphQL document is
+ * validated as a whole, so a single unknown field fails the entire request — without this tier
+ * every `pop zkemail` command would break against a subgraph that has not been redeployed yet.
+ */
+exports.FETCH_ZKEMAIL_MODULE_LEGACY = (() => {
+    const lines = exports.FETCH_ZKEMAIL_MODULE.split('\n');
+    const out = [];
+    let skipDepth = 0;
+    for (const line of lines) {
+        const t = line.trim();
+        if (skipDepth > 0) {
+            // Inside the dkimRegistry block: track braces until it closes.
+            if (t.endsWith('{'))
+                skipDepth++;
+            else if (t === '}')
+                skipDepth--;
+            continue;
+        }
+        if (t === 'dkimRegistry {') {
+            skipDepth = 1;
+            continue;
+        }
+        if (/^(executor|domainVerifier|emailVerifier|accountRegistry|universalFactory|claimCount)$/.test(t))
+            continue;
+        out.push(line);
+    }
+    return out.join('\n');
+})();
+/** Modern tier first, pre-#197 tier as the fallback. */
+exports.FETCH_ZKEMAIL_MODULE_TIERS = [exports.FETCH_ZKEMAIL_MODULE, exports.FETCH_ZKEMAIL_MODULE_LEGACY];
+/**
+ * Has this specific address already consumed its specific-address invite?
+ *
+ * Replaces an `isEmailRegistered` eth_call. Only meaningful post-#197; callers fall back to the
+ * contract when the entity is absent.
+ */
+exports.FETCH_ZKEMAIL_REGISTERED_EMAIL = `
+  query FetchZkEmailRegisteredEmail($id: ID!) {
+    zkEmailRegisteredEmail(id: $id) {
+      id
+      registered
+      claimer
+      claimedAt
+      clearedAt
+    }
+  }
+`;
+/**
+ * Resolve role hat IDs to human names so an allowlist can be shown as
+ * "gmail.com -> Member" instead of a raw uint256.
+ */
+exports.FETCH_ORG_ROLE_NAMES = `
+  query FetchOrgRoleNames($orgId: Bytes!) {
+    organization(id: $orgId) {
+      id
+      roles {
+        id
+        hatId
+        name
+        isUserRole
+        canVote
+      }
+    }
+  }
+`;
+/**
+ * Claim history for a module (subgraph-pop #197).
+ *
+ * Two things to know when rendering these:
+ *   - `nullifier` is null for the passkey onboarding variants (RegisteredAndClaimed*), which do
+ *     not emit it. On the live Gnosis module that is most claims, so absence is normal.
+ *   - `identifierHash` is the allowlist leaf id the claim used, which may belong to a SUPERSEDED
+ *     allowlist. Resolve it against the active entries opportunistically, never assume it hits.
+ */
+exports.FETCH_ZKEMAIL_CLAIMS = `
+  query FetchZkEmailClaims($module: String!, $first: Int!) {
+    zkEmailClaims(
+      where: { module: $module }
+      orderBy: claimedAt
+      orderDirection: desc
+      first: $first
+    ) {
+      id
+      kind
+      claimer
+      claimerUsername
+      identifierHash
+      hatIds
+      nullifier
+      registeredUsername
+      claimedAt
+      claimedAtBlock
+      transactionHash
+    }
+  }
+`;
+/**
+ * Just the committed allowlist pointer for an org's module.
+ *
+ * `activeRoot`/`activeAllowlistCid` are the two fields that exist on BOTH deployed schemas —
+ * Gnosis (post-#197) and Arbitrum (pre-#197, where ZkEmailInvites is only
+ * {id, organization, activeRoot, activeAllowlistCid, activeAllowlist, createdAt, lastUpdatedAt})
+ * — so this needs no queryWithFieldFallback tier. Verified populated on live Gnosis:
+ * activeRoot = 0x1d5d75df3ee05a0a90c42f0fe423f3c063dedf3466378e45a8343bfef18ebc46.
+ *
+ * A null `activeRoot` on a module row that EXISTS means dormant (no allowlist committed yet),
+ * which is the same thing the contract reports as merkleRoot() == 0. A missing row means "not
+ * indexed" and callers must fall back to the contract.
+ */
+exports.FETCH_ZKEMAIL_ACTIVE_ROOT = `
+  query FetchZkEmailActiveRoot($orgId: Bytes!) {
+    organization(id: $orgId) {
+      id
+      zkEmailInvites {
+        id
+        activeRoot
+        activeAllowlistCid
+      }
+    }
+  }
+`;

package/dist/graph/index.d.ts

@@ -0,0 +1,2 @@
+export * from './client';
+export * as documents from './documents';