We're happy to announce the latest open-source release v16 of Blockwatch's all-in-one zero-conf Tezos indexer TzIndex which is now fully compatible with the Tezos Mumbai protocol. This release includes support for all smart rollup operations and tickets along with significant performance improvements. Available on GitHub blockwatch-cc/tzindex.

Mumbai and Smart Rollup Support

With protocol Mumbai, Tezos' core engineering teams have laid the groundwork to a faster and more scalable Tezos network. In addition to 15 second block times, Mumbai introduced the next generation of highly scalable optimistic rollups called Smart Rollups that are enshrined directly into the Layer 1 protocol. This paves the way for anyone to develop and permissionlessly deploy an interoperable Layer 2 solution on top of Tezos. Rollups can be developed in various programming languages, not just OCaml like the Tezos core protocol itself. This enables the implementation of entire dapps as rollups (or app chains). This is particularly interesting for dapps that require much higher throughput than Tezos Layer 1 can sustain. All rollups can benefit from Tezos' security assurances and can share assets with Tezos L1 and other rollups based on tickets (relevant ticket bridges are under development). At the current state, rollups are not production ready because performance, tooling and standards are still missing. It's a bit early to assess when all pieces will be ready, but it's a great time to start experimenting and learning what may become possible.

Blockwatch TzIndex v16 offers initial indexing support for tz4 addresses (they use BLS keys and are supposed to be used in rollups and not L1) and sr1 addresses (smart rollups) as well as their many operations. Transaction rollups (TORU) have been deprecated, but they are still supported in TzIndex since they have been used on testnets. Like before, we wrap rollup operations into two generic transaction types rollup_origination and rollup_transaction (these do not exist in Tezos L1, just in the indexer). Rollup kind and name of the original L1 rollup operation are available as data fields along with the original data. This design is more lean and future proof than alternatives. It also means TzIndex API users can add support for Smart Rollups and upcoming zkRollups at their own convenience, while generic fields like tx fees, gas and sender/receiver are available as usual.

Besides raw operation data and the identity of rollups, TzIndex does not track rollup state (inbox, refutation games, etc.). We closely monitor the progress of tooling around rollups and may add additional features as necessary or when standards for bridging assets emerge.

Performance Improvements

We expect Tezos to grow significantly in the near future as new NFT projects, games, and rollup use cases launch. Hence we've been diligently working on improving indexing performance and overall indexer maintenance costs. We're pleased to report notable advancements in these areas, courtesy of our latest compression scheme that reduces the overall database size by 10-20%. Modifications in TzGo's internal representation of address and hash types have yielded an additional 50%+ reduction in heap memory used. The new address format now always stores 21 bytes per address instead of the earlier 21+24 bytes for an extra Go slice header (similar for hashes which are now 32 bytes instead of 56). The new formats make addresses and hashes directly comparable and on top of that save one out of two memory allocations per address/hash leading to a substantial boost in performance.

Full changelog

New Additions

  • Added Mumbai operations wrapped into rollup_origination and rollup_transaction
    • smart_rollup_add_messages
    • smart_rollup_cement
    • smart_rollup_originate
    • smart_rollup_execute_outbox_message
    • smart_rollup_publish
    • smart_rollup_recover_bond
    • smart_rollup_refute
    • smart_rollup_timeout
  • Added transfer_ticket op as explict operation (previously this was part of the rollup package
    and wrapped inside rollup_transaction)
  • Added op model fields
    • ticket_updates on eligible transactions between tz accounts (previously ticket transfer was
      limited to contracts)
    • staker, loser, winner as participants in smart rollup refutation games
  • Added block model NTickets
  • Added chain model TotalTicketTransfers
  • Extended list of metadata alias categories
  • Detect and track protocol activations independently of hard-coded block heights


  • Crash on broken call params
  • Micheline type compare for nested unions, this fixes detecting allocated bigmap types - Decoding bootstrap deposits on testnets
  • Exclude unknown fields from endorsement table query
  • Entrypoint detection, continue on data decode errors
  • Take delegation volume from flows instead of previous balance
  • Parsing block height
  • Micheline translate bugs
  • Some entrypoint param decoding
  • Nil response crash
  • Account n_tx_success column name
  • Gov vote index
  • Stake in post-Ithaca index 15 snapshots
  • Contract table lookup, limit to successful originations
  • Rollup call stats query
  • Handle storage burn on transfer ticket op
  • Use staking balance for gov snapshots
  • Handle internal results on rollup output message execution


  • List internal ops sent by a contract
  • Sanitize API requests to reject zero hashes and negative heights
  • Add virtual start|end_time columns to income API
  • Store height in rights and income tables
  • Process internal transaction after ticket transfer
  • Protect against high memory usage when loading from (zero) op hash - Prevent indexer stop on unexpected rollup data
  • Protect against unexpected rollup calls
  • Use spendable balance for audit
  • Skip internal tx when building traffic ranks
  • Add more verbose init errors
  • Add auto retries to RPC client
  • List factory created contracts
  • CLI: change log system config names
    • log.blockchain to log.etl
    • log.database to log.db
  • Upgrade to Go 1.20 and TzGo to v1.16


Blockwatch TzIndex is available under two licenses:

  1. open-source MIT license with community support/best-effort updates
  2. PRO license with professional support and scheduled updates. Learn more about licensing here or e-mail us at license at blockwatch dot cc.


For support, talk to us on our Discord developer support channel or DM us on Twitter. We appreciate your feedback, suggestions, and comments.