Wallet: history & unspent

Reference for the wallet history and unspent-output methods: listtransactions, z_listtransactions, listsinceblock, gettransaction, and listunspent. All five are read-only: they run on short-lived SQLite connections and never block on the sync loop.

Shared conventions

These apply to every method on this page.

• Categories. Only send and receive are emitted. A self-transfer (a payment to one of the wallet's own external addresses) appears as Bitcoin Core's send + receive pair. True change (internal key scope) is hidden from history but still counted in balances and listunspent. Core's coinbase categories (generate/immature/orphan) never appear.

• Confirmations are anchored to the wallet's fully-scanned height, the same height getblockcount reports, so getblockcount() - blockheight + 1 agrees with the field. An expired unmined transaction reports -1 (it can never confirm; Core's "conflicted" signal, so pollers terminate).

• time / timereceived are the block time once mined. For an unmined transaction they are the wall-clock time the wallet first saw it in the mempool, held in a transient in-memory map (never persisted; see statelessness), falling back to the creation time for wallet-authored sends. After a restart, an unmined foreign transaction reports 0 until the mempool stream re-observes it or it mines. The two fields are always equal.

• memo / memoStr are extension fields beyond Bitcoin Core's set, using zcashd's z_viewtransaction names: memo is the raw stored memo bytes in hex, memoStr the decoded text when the memo is a valid ZIP-302 text memo. An output carrying no memo, or the canonical empty memo every memoless shielded output carries, adds neither field.

  memo is emitted from the stored bytes and does not depend on the ZIP-302 parse succeeding; only memoStr does. The two are different questions: a memo whose lead byte is at or below 0xF4 is declared to be UTF-8 text, but nothing on the consensus side enforces that, so a protocol embedding arbitrary bytes in that lead-byte space produces a memo that fails the parse while still being perfectly good data. Through 0.6.3 the hex field was gated on that parse, so such a memo came back with no memo, no memoStr and no error, which is indistinguishable from an output that carried none. Fixed in 0.6.4: an absent memo field now means "no memo", never "unparseable memo". If you built a workaround that fetches the raw transaction to recover memos this dropped, you can retire it.

• Outgoing address is the single receiver actually paid, not the full Unified Address the caller typed. A multi-receiver UA is sender-side metadata that never reaches the chain, so history reduces each outgoing output to the paid receiver (a bare t/zs address, or a single-receiver UA for Orchard). This makes history identical on the authoring instance and after a restore-from-seed. Since 0.8.0 received entries follow the same rule, so a payer and a payee print the same string for one output (byte-identical to the issued address under the default Orchard-only receivers). See statelessness.

• diversifier_index (new in 0.8.0, zecd extension) is on receive entries in listtransactions, listsinceblock, z_listtransactions and gettransaction.details: the index of the wallet's own address the output landed on. Every encoding of an address shares it, and the scanner recovers it from the note, so it is identical after a from-seed restore. Store the index at issuance (z_getaddressforaccount returns it, getaddressinfo reads it back) and match receipts by integer. Send entries, including the send half of a self-transfer, never carry it: a recipient's index is theirs. A shielded index can reach 2^88, so parse it as an arbitrary-precision integer.

• With [sync] fetch_memos = false (0.8.0), memo and memoStr are omitted everywhere, not only where a fetch was skipped. See configuration.

• label is always "" and walletconflicts always []: zecd keeps no address labels and tracks no conflict set. bip125-replaceable is always "no" (Zcash has no RBF).

• Amounts are bare JSON numbers in decimal ZEC, 8 places.

• History ordering is total, and is a contract. For the four history methods (listtransactions, z_listtransactions, listsinceblock, gettransaction, but not listunspent, which builds its list from the note and UTXO sets and promises no order), results are ordered by height, then transaction id, then output pool, then output index. Height alone is not injective, since a block holds many wallet transactions, so through 0.6.3 two transactions mined at the same height came back in whatever order SQLite happened to produce. That was stable enough within one call and not stable across calls, which meant a count/from page boundary landing inside a same-height tie could show a transaction twice or skip it entirely between adjacent pages. Fixed in 0.6.4. A consumer replaying history as a log therefore gets a stable (height, txid, pool, outindex) sequence and can resume from the last entry it processed. The transaction-id comparison is over the stored internal byte order, which is an arbitrary but stable permutation of display order; do not read it as alphabetical by displayed txid. Reversing the order (newest-first) reverses the height and txid keys together, leaving the within-transaction output order unchanged.

listtransactions

listtransactions ( "label" count skip include_watchonly )

The most recent wallet history entries, one entry per non-change output, oldest-to-newest. Covers shielded notes and (when enabled) transparent outputs in one list.

Parameters

Result

[
  {
    "address": "u1a7pqnnzcdev3ka5jyv2q0kag0k8qvyw2s0z1erdhfmwzmp8dip5rk5632cxutlyf6jz062cu5qnkcs2857vy0mnhxen8993rvxmqedqu",
    "category": "receive",
    "amount": 1.25000000,
    "label": "",
    "vout": 0,
    "confirmations": 12,
    "txid": "8ab1c74952e723459d5e18b975bff21af07a90ba1eec368bcb2d3d6d7b0e0c17",
    "bip125-replaceable": "no",
    "memo": "696e766f6963652034322070616964",
    "memoStr": "invoice 42 paid",
    "blockhash": "0000000001d4f81c8494ba9cd02c0ea936f1ba52e6a186a538d3c3e2ab5b91f7",
    "blockheight": 2914301,
    "blockindex": 1,
    "blocktime": 1751581200,
    "walletconflicts": [],
    "time": 1751581200,
    "timereceived": 1751581200
  },
  {
    "address": "u1v40svyy8lqhy4gyq5vysyz39yqwf4ypw9zvhqjmwlqk9vqvyfrgc6yz6e2spwwrjxpwyfwjt3u4nrpydp0hnzqge0ptr9y8yavgvpr7ux",
    "category": "send",
    "amount": -0.50000000,
    "label": "",
    "vout": 0,
    "confirmations": 3,
    "txid": "e37b006aa754e982f2c19152fbd80f26e6a3fe9c418b1ce3f5aab3ad4d7e9b52",
    "bip125-replaceable": "no",
    "abandoned": false,
    "fee": -0.00015000,
    "blockhash": "00000000023a1b6d81c62f1c22f0a3e9a83f6de960e60d357ce09b3c73ef14a8",
    "blockheight": 2914310,
    "blockindex": 2,
    "blocktime": 1751583450,
    "walletconflicts": [],
    "time": 1751583450,
    "timereceived": 1751583450
  }
]

• Sends are negative (Core's sign convention); fee (negative) and abandoned appear on send entries only. abandoned is true for an expired unmined send.
• Mined entries carry blockhash/blockheight/blockindex/blocktime; unmined entries carry trusted instead (true iff the wallet authored the transaction and it can still be mined).

Errors

vs Bitcoin Core: same arguments and paging (count most recent after skipping skip from the newest end, returned oldest-first). Entries omit wtxid and parent_descs; abandoned appears only on send entries (Core master also puts it on receives); categories are limited to send/receive; memo/memoStr are extensions.

vs zcashd: zcashd's listtransactions covers transparent activity only (shielded receipts need per-address z_listreceivedbyaddress) and adds amountZat, status, and expiryheight to each entry. zecd lists shielded and transparent activity in one Core-shaped list; use z_listtransactions for the zcashd vocabulary.

z_listtransactions

z_listtransactions ( count from includeWatchonly )

A zecd extension (no such method exists in zcashd or Bitcoin Core): per-output wallet history in zcashd's z_* vocabulary. Same content as listtransactions, different field names, plus the value pool and zatoshi amounts. Pagination is identical (newest-first cursor, oldest-first output).

Parameters

There is no account or address argument: results span the wallet's single account.

Result

[
  {
    "txid": "e37b006aa754e982f2c19152fbd80f26e6a3fe9c418b1ce3f5aab3ad4d7e9b52",
    "status": "mined",
    "confirmations": 3,
    "time": 1751583450,
    "walletconflicts": [],
    "pool": "orchard",
    "category": "send",
    "amount": -0.50000000,
    "amountZat": -50000000,
    "address": "u1v40svyy8lqhy4gyq5vysyz39yqwf4ypw9zvhqjmwlqk9vqvyfrgc6yz6e2spwwrjxpwyfwjt3u4nrpydp0hnzqge0ptr9y8yavgvpr7ux",
    "outindex": 0,
    "change": false,
    "outgoing": true,
    "blockhash": "00000000023a1b6d81c62f1c22f0a3e9a83f6de960e60d357ce09b3c73ef14a8",
    "blockheight": 2914310,
    "blockindex": 2,
    "blocktime": 1751583450,
    "expiryheight": 2914350,
    "fee": -0.00015000,
    "feeZat": -15000
  }
]

• pool is transparent, sapling, orchard, or ironwood. ironwood appears once NU6.3 activates (testnet). Those notes arrive at ordinary Orchard addresses, so pool labels the note's bundle, not a distinct receiver. See Addresses & shielded pools.
• status is mined, waiting, or expired. zcashd's fourth value expiringsoon is never emitted.
• amountZat is an integer (zatoshis), negative on sends; outgoing is true on the send side of a self-transfer pair.
• change is always false (change outputs are filtered before this point; the key is kept for shape compatibility with zcashd's walletInternal/change convention).
• expiryheight appears when the transaction has a non-zero expiry; fee/feeZat (negative) on send entries only; memo/memoStr on shielded outputs as elsewhere.

Errors

vs Bitcoin Core: no equivalent; this is the zcashd-vocabulary view of the same history listtransactions serves.

vs zcashd: zcashd has no z_listtransactions. The entry shape borrows from z_listreceivedbyaddress (pool/amount/amountZat/memo/memoStr/outindex/change/ block fields), z_viewtransaction (outgoing), and zcashd's per-transaction status/expiryheight. Unlike z_listreceivedbyaddress it is not per-address and includes sends; unlike z_viewtransaction it is a flat paged list, not a per-transaction spends/outputs breakdown.

listsinceblock

listsinceblock ( "blockhash" target_confirmations include_watchonly include_removed )

The restart-safe payment poller: every wallet transaction in blocks after blockhash (plus all unmined transactions), and a lastblock cursor to feed into the next call.

Parameters

Result

{
  "transactions": [],
  "removed": [],
  "lastblock": "0000000001d4f81c8494ba9cd02c0ea936f1ba52e6a186a538d3c3e2ab5b91f7"
}

transactions entries have exactly the listtransactions shape (no label filter applies). removed is always empty: reorged-away transactions are rescanned and re-reported by the sync engine rather than tracked separately. lastblock is the hash of the block that currently has target_confirmations confirmations, anchored to the fully-scanned height; when the requested depth predates the wallet's scan range it falls back to the earliest scanned block, and a wallet with nothing scanned returns the all-zero hash.

Cursor semantics after a reorg. zecd keeps only the current chain's scanned blocks, so it cannot walk a stale cursor back to the fork point the way Bitcoin Core's findCommonAncestor does. Instead, a well-formed 64-hex hash that is not among the wallet's scanned blocks (a reorged-away cursor, or one below the wallet birthday) is treated as "since the earliest scanned block": everything is listed. A lower cursor only ever re-reports, never misses, so the poller self-heals instead of wedging. Only a malformed hash, which can never be a cursor zecd handed out, is a -5 Block not found. Consequence for integrators: process listsinceblock output idempotently, keyed by txid. A target_confirmations of, say, 6 keeps re-reporting transactions until they reach 6 confirmations, which is the intended Core usage pattern and absorbs the re-baseline case for free.

Errors

vs Bitcoin Core: same cursor pattern and lastblock semantics. Core walks a stale hash back to the fork point and can populate removed; zecd re-baselines to the earliest scanned block and keeps removed always []. Core master's two extra positional arguments (include_change, label) exceed zecd's four-argument arity and are rejected with -1.

vs zcashd: zcashd's listsinceblock is the inherited transparent-only Bitcoin method; zecd's covers shielded activity too and adds the reorg re-baseline behavior above.

gettransaction

gettransaction "txid" ( include_watchonly verbose )

Detailed information on one wallet transaction: net amount, per-output details, and the raw hex.

Parameters

Result

{
  "amount": -0.50000000,
  "fee": -0.00015000,
  "confirmations": 3,
  "txid": "e37b006aa754e982f2c19152fbd80f26e6a3fe9c418b1ce3f5aab3ad4d7e9b52",
  "bip125-replaceable": "no",
  "details": [
    {
      "address": "u1v40svyy8lqhy4gyq5vysyz39yqwf4ypw9zvhqjmwlqk9vqvyfrgc6yz6e2spwwrjxpwyfwjt3u4nrpydp0hnzqge0ptr9y8yavgvpr7ux",
      "category": "send",
      "amount": -0.50000000,
      "vout": 0,
      "pool": "ironwood",
      "label": "",
      "abandoned": false,
      "fee": -0.00015000
    }
  ],
  "hex": "050000800a27a726b4d0d6c2...",
  "blockhash": "00000000023a1b6d81c62f1c22f0a3e9a83f6de960e60d357ce09b3c73ef14a8",
  "blockheight": 2914310,
  "blockindex": 2,
  "blocktime": 1751583450,
  "walletconflicts": [],
  "time": 1751583450,
  "timereceived": 1751583450
}

• amount is fee-exclusive, per Core: for a wallet-funded transaction it is the negated sum of payments (the balance delta with the fee added back); for a pure receive it is the received amount; a self-transfer nets to 0.
• fee (negative) appears only when the wallet funded the transaction. librustzcash records a derived fee even on pure receives, but zecd gates the field on the balance-delta signal so a deposit is never reported with a fee the wallet did not pay.
• details has one entry per non-change output and category, with the listtransactions entry shape minus the per-transaction fields (confirmations, txid, times), which sit at the top level. memo/memoStr appear per detail entry.
• details[].pool (extension, 0.7.0): "transparent", "sapling", "orchard" or "ironwood". vout is the output index within its own pool's bundle, not a transparent outpoint index, so on a transaction with outputs in more than one pool (txid, vout) does not identify an output. (txid, pool, vout) does, which is the key a consumer following listsinceblock as an incremental cursor reaches for. History entries already carried pool; this brings details into line with them.
• hex is the stored raw transaction when the wallet has it (wallet-authored sends, and receives stored via the mempool stream or the enhancement pass). For a transaction the wallet only ever saw as a compact block, the bytes are fetched on demand from the chain backend. The fetch is best-effort: an unreachable upstream yields "", not an error.
• Mined/unmined block fields and trusted follow the shared conventions above.

Errors

vs Bitcoin Core: same top-level shape; omits wtxid, parent_descs, generated, comment, and (since verbose is ignored) decoded. fee appears only on wallet-funded transactions, as in Core. details entries add memo/memoStr and pool.

vs zcashd: zcashd's gettransaction reports the transparent parts and defers shielded detail to z_viewtransaction. zecd's details cover shielded outputs (with memos) directly; there is no separate z_viewtransaction.

listunspent

listunspent ( minconf maxconf ["address",...] include_unsafe query_options )

The wallet's unspent funds in Bitcoin Core's UTXO shape: every unspent shielded note (all enabled pools) plus, for transparent-enabled wallets, every unspent transparent UTXO.

Parameters

Result

[
  {
    "txid": "8ab1c74952e723459d5e18b975bff21af07a90ba1eec368bcb2d3d6d7b0e0c17",
    "vout": 0,
    "address": "u1a7pqnnzcdev3ka5jyv2q0kag0k8qvyw2s0z1erdhfmwzmp8dip5rk5632cxutlyf6jz062cu5qnkcs2857vy0mnhxen8993rvxmqedqu",
    "amount": 1.25000000,
    "confirmations": 12,
    "spendable": true,
    "solvable": true,
    "safe": true
  }
]

• Synthesized outpoints for notes. Shielded notes are not bitcoin-style outpoints, so (txid, vout) is synthesized: vout is the note's index within its pool's bundle (the Sapling output index or the Orchard action index). It identifies the note stably but cannot be fed to raw-transaction spending. Transparent UTXOs carry their real (txid, vout) and a bare t-address.
• address is the receiving diversified address when the wallet recorded one. Change and internal notes report "", which an addresses filter never matches, so a filtered call naturally excludes change.
• generated rides on transparent entries, carrying zcashd's meaning: true when the output came from a coinbase transaction, false otherwise. Shielded notes have no such field. Immature coinbase is not listed at all: a coinbase UTXO with fewer than 100 confirmations is excluded from listunspent entirely, matching Bitcoin Core's AvailableCoins, and its value is reported in getwalletinfo.immature_balance until it matures. A mature coinbase entry does appear, but consensus forbids spending it into any transparent output, so the only way to spend it is z_shieldcoinbase; the ordinary send paths never select it. See Transparent support.
• safe is true for confirmed outputs and for unconfirmed outputs whose creating transaction the wallet itself authored (its own change or self-send); a foreign output surfaced at 0-conf by the mempool stream is safe: false. include_unsafe: false hides those.
• spendable and solvable are always true. They are nominal: whether a send can actually select an output is governed by the wallet's confirmations policy ([spend] trusted_confirmations/untrusted_confirmations, ZIP-315 defaults 3/10), so an entry with 1 confirmation can appear here while a send still returns -6 until it reaches policy depth (see Sending). A transparent UTXO is additionally spendable only under the AllowFullyTransparent privacy policy; under the default policy it is receive-only (see Transparent support).

Errors

vs Bitcoin Core: same arguments and filtering; entries omit label, scriptPubKey, redeemScript, desc, and parent_descs (shielded notes have no script form). query_options is accepted but has no effect, where Core applies minimumAmount and friends. generated is an addition (Core carries it on gettransaction, not here), but the immature-coinbase exclusion follows Core's AvailableCoins exactly. The synthesized note outpoints are the largest semantic difference; see Compatibility boundary.

vs zcashd: zcashd splits this surface into listunspent (transparent) and z_listunspent (shielded, with pool/outindex/memo/change per note). zecd merges both into one Core-shaped list; for pool and memo detail use z_listtransactions. The generated flag on transparent entries is zcashd's, with zcashd's meaning.