Resource · 2.7 in the design proposal

Query / Explorer

Transactions & Chain State — the read-side complement to every write operation in every other resource, and the one resource a workflow could use with no signing key at all.

8 operations 4 MVP candidates 4 Phase 2+

What this resource covers, and why it's the read-side baseline

Every resource-scoped history operation elsewhere in this node — ID06, TA08, DA06, KM09 — is the same underlying query-tx-history call as QX02, just typed and scoped to that resource's account. Query/Explorer is where the generic, resource-agnostic versions live: look up any transaction by ID (QX01), list any account's history (QX02), check settlement status (QX03), list what's under any acc:// URL (QX05), and — Phase 2 — inspect synthetic transactions, browse minor/major blocks, or check node status.

Per the design proposal's decision log, the Query/Explorer operations use the V2 method surface as the baseline, because V2 method names (query, query-tx, query-directory, etc.) were independently verified against the protocol's own Go source (pkg/client/api/v2/api_v2_sdk_gen.go in AccumulateNetwork/accumulate), while V3's exact method-name surface was not. That's a starting point, not a final call — see the open question below.

Operations

CodeOperationMaps toWhy a workflow author wants itPriority
QX01Query TransactionV2 query-tx Look up a transaction by ID — verification/monitoring, the read-side complement to every write op MVP ★
QX02Query Transaction HistoryV2 query-tx-history List an account's past transactions for reporting/reconciliation workflows MVP
QX03Query Pending TransactionV2 query-tx (pending state) Check whether a submitted transaction (or a multi-sig pending transaction) has settled MVP
QX05Query Directory (generic URL listing)V2 query-directory Generic "what's under this acc:// URL" — reusable beyond ID04's ADI-specific case MVP
QX04Query Synthetic TransactionV2 query-synth Inspect the protocol-generated synthetic transaction behind a cross-ADI effect — debugging/advanced use Phase 2
QX06Query Minor BlocksV2 query-minor-blocks Chain-explorer-style browsing, not a typical workflow step Phase 2
QX07Query Major BlocksV2 query-major-blocks Same tier as QX06 Phase 2
QX08Node Status / Version / DescribeV2 status / version / describe Operational diagnostics (network config, fee schedule) — arguably infra tooling, not workflow logic Phase 2

How it works — a reconciliation/monitoring workflow

Periodic watch: compare expected vs. actual chain state
flowchart TD
  CRON["Scheduled workflow run"] --> Q1["QX01/QX02
query specific transactions + history
for a set of watched accounts"]
  Q1 --> Q2["TA04 / CR02
check token & credit balances
against expected thresholds"]
  Q2 --> Q3["QX05 Query Directory
enumerate what exists under an acc:// URL"]
  Q3 --> CMP{"Matches expectations?"}
  CMP -->|no| ALERT["Raise alert / kick off follow-up workflow
(email, ticket, Slack)"]
  CMP -->|yes| DONE["No action needed"]

Business use case — reconciliation and monitoring, with no signing key

From 001.BusinessIdeas/README.md §2.6

Not every use case needs to write to the chain — a workflow can exist purely to watch it. A finance-ops workflow could periodically query transactions and balances, enumerate what exists under an acc:// URL to detect drift (e.g. an unexpected new sub-account), and raise an alert when something doesn't match expectations.

Called out as the lowest-friction use case in the whole list because it needs no signing key at all — see the read-only credential mode open question below. It's a genuine fit for any customer already running Accumulate accounts for other reasons (Token Account or Identity use cases), even if they have no interest in the write-side operations.

Open questions affecting this resource