We know you have all been waiting for this for quite some time. Finally we have finished implementing local snapshots, a feature that allows you to run your node without storing the full transaction history. This means faster synchronization, lower system resource requirements, and no more waiting for global snapshots to prune the database.

While Hans Moog implemented most of the logic behind this feature, reviewing and testing local snapshots has been a huge effort for the whole IRI team.

IRI 1.6.0 is not just about local snapshots. We have been working on many other improvements as well, which we believe will make running a node a much better experience from now on!

What do I need to do?

It’s simple. You just download the latest version and upgrade your node. Local snapshots are enabled by default, with what we believe are reasonable configuration values.

You can of course change things up as you like. For example, you can control how much data the node stores using the following two configuration options:


By default, nodes will store around 30 days worth of transaction data.

You can also change the interval at which synced nodes perform local snapshots using:


Unsynced nodes perform snapshots less frequently, so they can focus resources on getting up to speed first:


You can read more about using local snapshots in the documentation.

Operating public-facing nodes with local snapshots

By default, nodes with local snapshots enabled store around 1 month worth of transaction data.

If you are operating a public node and want to have LOCAL_SNAPSHOT_PRUNING enabled, please stick to at least the default value of LOCAL_SPAPSHOTS_PRUNING_DELAY (40000) or higher.

What else does IRI 1.6.0 contain?

A lot. Many of the improvements were already shared in version 1.5.6 right before Christmas, but it’s worth highlighting some of them here:

Greatly improved performance on a synchronizing node

Previously, the computational demands for a node that was not yet synchronized were very high. We have made significant improvements by removing redundant hashing and validation of replies in the gossip protocol.

Default remote API limit list

As a security measure for nodes, we are now limiting some remote API calls by default. This ensures your node doesn’t get spammed with request from outside parties that know its address. Calls limited by default are:

  • addNeighbors
  • getNeighbors
  • removeNeighbors
  • attachToTangle
  • interruptAttachToTangle

You can make these calls available remotely by defining a different REMOTE_LIMIT_API in the configuration file.

Retrieve a list of features enabled on the node

The getNodeInfo API call now returns a list of features that a node has enabled. This allows you to determine, for example, if the node supports remote proof of work!

Improved synchronization for TCP neighbors

The synchronization of nodes neighbored with TCP could get stuck in certain scenarios. This has now been fixed by our community member GJEEE!

PearlDiver threads are now configurable

Another contribution by our community member, CodeMonkeySteve allows you to control PearlDiver threads better. This is useful if you want to utilize as many cores as possible on a dedicated node server, for example.

Code cleanups, refactoring and documentation

Quite a bit of effort went into cleaning up some of the code base and adding documentation. Shout-out goes to our community member #ChEfKoCh (legacycode) for help with that!

What’s next?

We have quite a few things we want to focus on next:

  • Solidification improvements — simpler and more performant solidification logic.
  • Database layer refactoring
  • API redesign and refactoring
  • Configuration and other bug fixes

Release notes

The following list is truncated for brevity. See the release page for a full list.

Non-local snapshot changes that were also included in IRI 1.5.6 are listed under the 1.5.6 tag.

  • Feat: added config variables for local snapshots #981
  • Feat: Introducing the GarbageCollector of local snapshots #995
  • Feat: Fixes + Improvements for IRI that are required for local snapshots #1095
  • Feat: Introducing several executor services for IRI #1131
  • Activate Local Snapshots #1172
  • Introducing a repair mechanism for corruptions in the ledger database #1174
  • Introducing a parameter validation for the local snapshot config parameters #1175
  • Introducing a dedicated Transaction Requester Background Worker #1178
  • Feat: Added an option to fast forward the ledger state #1196
  • Perf: Massively improved the performance of the replayMilestones method #1197
  • Increase rescan performance of old milestones after IRI restart #1204
  • Refactor: made boolean parameters receive a value #1224
  • Feat: Disable snapshot logic completely if disabled in the config #1228
  • Fix: Node requested old transactions forever #1235
  • Feat: Write snapshot files to temp files first #1256
  • Spent addresses are updated on local snapshot nodes #1258#1263
  • Spent addresses are present on local snapshot nodes #1266
  • Report local snapshot node transaction history via getNodeInfo #1264
  • Change the minimum value for LOCAL_SNAPSHOTS_PRUNING_DELAY #1267


Big thanks go to our community for your patience while we finalized this feature and to all the RC testers who gave us feedback on the different builds. You made this huge milestone for IRI possible.

Another big thanks goes to the whole IRI team for their great efforts!

If you have feedback or questions, please join the discussion on the #iri channel of our Discord.

IRI 1.6.0 with local snapshots out now! was originally published on——2. The IOTA-News Community curates, examines, and summarizes news from external services while producing its own original material. Copyrights from external sources will be credited as they pertain to their corresponding owners. The purpose is to make use of 3rd party content or pictures as either allusion or promotional endorsement of mentioned sites. If you have a claim of copyright infringement with respect to material, please mail to support[at] is a community run website and is NOT affiliated with the IOTA Foundation in any way.