What's the rationale for providing different contract id seeding modes in the sandbox?

And should I always use strong in a production setting? What are the implications of not doing so?

As described in a previous thread, we have a new contract ID scheme that generates pseudo-random contract IDs. Under the hood, we use a cryptographically secure pseudorandom number generator, to generate IDs that look like random.
For the scheme to be secure, we “seed” this pseudorandom number generator with a high entropy 64 bytes number. Here come into play the seeding modes of the sandbox. We have currently four modes:

  • the strong mode, which creates a high entropy seed using entropy gathered from the underlying operating system. In Linux, this uses /dev/random or /dev/urandom.
  • the testing-weak mode, which creates a low-entropy seed, using basically the system time.
  • the testing-static mode, which uses a fixed seed.
  • the no mode, which forces the sandbox to use the unsecured legacy scheme.

In production, you should consider only the strong or the no mode, depending on the scheme you want to use. Note that the next version of DAML-LF will require the new scheme. Also, be aware that the sandbox is the only DAML ledger supporting the legacy scheme.

Now let me clarify the purpose of the two other modes. As you can imagine from their name they are useful for testing.

Because the strong mode gathers entropy from the system, it may block on startup if not enough entropy is available. This is not an issue in production where only one (or at most few) sandbox will be started. However, in a testing context, one can start a lot of sandboxes in a short interval of time, hence depleting the entropy pool of the operating system. In this case, using the testing-weak guarantees the sandbox will never block on startup. The resulting contract IDs are not cryptographically secure but this is not an issue in most testing contexts.

The purpose of the testing-static mode is to provide a simple way to get reproducible run. I am sure you can foresee how handy this can be for testing. This mode is definitively not secure and should be used only on a fresh sandbox with empty database, if not this can lead to contract ID collisions.


I recall it mentioned earlier that this also made writing documentation/tutorials much easier, where you can refer to contract Id’s by number in vernacular, rather than using some long random number.

1 Like

The testing-static mode, will still produce contract IDs that look like long random numbers. We only guarantee that if you submit sequentially the same commands to two fresh sandboxes started with this option, you will end up with the exact same responses containing the exact same contract IDs. This may made a tutorial easier to follow, as the reader may be able to reproduce a sequence of steps by copy/pasting.

However, to get small vernacular IDs you need to use the legacy mode. I do not recommend to use this mode for documentation as the sandbox is the only ledger that supports this feature. Even the scenarios run in the IDE produce long random IDs.