All Versions
Latest Version
Avg Release Cycle
15 days
Latest Release
869 days ago

Changelog History
Page 1

  • v1.7.0 Changes

    November 11, 2020

    ๐Ÿš€ You can find the release notes at

  • v1.6.0 Changes

    October 15, 2020

    ๐Ÿš€ See for the release notes.

  • v1.5.0 Changes

    September 16, 2020

    ๐Ÿš€ Take a look at the release notes for details.

  • v1.4.0 Changes

    August 12, 2020


    • DAML on SQL is available as an Early Access standalone JAR, you can
      ๐Ÿš€ find it on the GH Release
      ๐Ÿš€ page
    • ๐Ÿ‘Œ Improvements to Ledger API and documentation for client application
      • This involves changes in the Ledger API in corner cases, but
        unless you are dealing with application failover, you are
        unlikely to be affected.
    • DAML REPL is stable and has gained new features, including the
      ability to run without being connected to a ledger
      • Module imports now need to be made explicit when starting DAML
    • daml codegen js is significantly faster when generating
      Javascript/TypeScript code
    • ๐Ÿ†• New Previous/Next buttons on
      ๐Ÿ“„ Thanks to Alex Mason for
      ๐Ÿ“š suggestion

    Impact and Migration

    Migration from SDK 1.3 to 1.4 should require no action for almost all
    ๐Ÿ‘‰ users.

    • If you were using the Early Access version of DAML REPL, you need to
      ๐Ÿ‘‰ make a minor adjustment to the CLI parameters to start it.
    • If you are working on application failover, you need to incorporate
      some API improvements.

    ๐Ÿš€ Standalone Early Access release of DAML on SQL


    The DAML Sandbox's primary purpose is to serve as an in-memory
    ๐Ÿ‘ development tool, but has had support for SQL backing for a long time.
    โœ… This made it a popular choice as a prototyping ledger and test tool, but
    lacking a separate distribution, required an entire SDK installation to
    ๐Ÿš€ run. To add clarity and ease deployment, the developer tool "Sandbox",
    and the Ledger "DAML on SQL" are now being separated. As a first step,
    DAML on SQL is now available as a standalone JAR file on GitHub
    ๐Ÿš€ releases. Some minor changes to functionality and CLI are planned for
    ๐Ÿš€ upcoming releases to further differentiate developer tooling and actual
    Ledger. The standalone JAR will remain in Early Access until those
    ๐Ÿ”„ changes have been made.

    Specific Changes

    ๐Ÿš€ DAML on SQL is now available with every release from the GitHub
    ๐Ÿš€ Releases page

    Impact and Migration

    For now, this is a purely additive change, but at the same time DAML on
    ๐Ÿ—„ SQL will become stable,, persistence mode in Sandbox will be deprecated,
    ๐Ÿ‘ and after a transition period, both support for persistence in Sandbox,
    ๐Ÿšš and the already deprecated Sandbox-classic will be removed from the SDK.
    ๐Ÿ‘‰ Users of Sandbox-classic or Sandbox with SQL backing are advised to
    start migrating over to the new DAML on SQL distribution.

    Client Application Failover


    Client applications have to be able to deal with the possibility that
    participant nodes become unavailable, for example due to network or
    hardware failure. For such cases, some DAML Ledgers offer the
    possibility to run hot (or cold) standbys of participant nodes. When a
    failover from a primary to a standby node occurs, the client application
    ๐Ÿšค has to handle the possibility that due to latency or initialization, the
    standby is not yet fully caught up with the Ledger. Improvements to
    ๐Ÿ“š Ledger API and documentation makes this significantly easier.

    Specific Changes

    • The error code for requesting a transaction stream with an offset
      beyond the ledger end changed from INVALID_ARGUMENT to
    • The command completion service now validates the offset and returns
      the OUT_OF_RANGE error if the request offset is beyond the ledger
    • โž• Added a documentation
      ๐Ÿ“„ section

      on how to write DAML applications that can fail over between
      eventually consistent Ledger API endpoints.

    Impact and Migration

    The behaviour of the transaction and command completion services have
    ๐Ÿ”„ changed in cases where an offset beyond ledger end are given. This
    should only happen if a client application re-connects to a different
    node which is not fully caught up, so you are only likely to be affected
    if your application fails over.

    If you were relying on the old behaviors (returning INVALID_ARGUMENT,
    or accepting the argument, respectively), you now need to handle the
    OUT_OF_RANGE error and implement retry logic.

    REPL is now Stable


    DAML REPL, a developer tool to interactively evaluate DAML and interact
    with DAML Ledgers has been in Early Access since SDK 0.13.55. With this
    ๐Ÿš€ release, it becomes stable, meaning its developer facing APIs are final
    and won't break outside of major SDK versions. In addition, it has
    gained a number of new useful features including the ability to run
    โœ… without being connected to a DAML Ledger, allowing interactive testing
    of pure functions, for example.

    Specific Changes

    • โš™ Run DAML REPL without connecting to a ledger by omitting the
      --ledger-host and --ledger-port parameters.
    • List the currently imported modules using the REPL command
      :show imports.
    • ๐Ÿ‘€ Type :help at the REPL prompt to see a list of possible REPL
    • โž• Add and remove module imports using :module [+-] Some.Module.
    • ๐Ÿ‘‰ Use let bindings to bind pure expressions
    • The list of DARs passed to DAML REPL can now be empty.
    • ๐Ÿ‘ The REPL now supports loading multiple DARs specified at the command
      line. The DARs are loaded as data-dependencies.
    • 0๏ธโƒฃ The REPL no longer loads modules by default to avoid collisions when
      multiple DARs are loaded.

    Impact and Migration

    You now need to either explicitly import all modules of your DAR file
    using the --import flag, or use :module + โ€ฆ inside the REPL. For
    example, if you previously started the REPL with

    daml repl .daml/dist/script-example-0.0.1.dar``

    you now need to either run

    daml repl .daml/dist/script-example-0.0.1.dar --import script-example``

    or import modules individually with

    :module + ScriptExample

    Faster JavaScript codegen


    The TypeScript/JavaScript codegen daml codegen js used to generate
    TypeScript files and then use yarn to compile these to JavaScript and
    declaration files. The codegen now generates JavaScript and declarations
    directly, significantly improving speed, and removing the dependency on

    Specific Changes

    • daml codegen js no longer requires yarn and is significantly

    Impact and Migration

    No action is required to consume this improvement.

    Minor Improvements

    • The DAML compiler will now compile type synonyms (type X = Y) into
      the DAR,whenever possible, and will expose these synonyms via
      0๏ธโƒฃ data-dependencies. This works for DAML-LF 1.8 (the current default)
      and upwards.
    • ๐Ÿ–จ DAML Ledgers now print detailed log messages whenever a request was
      rejected due to a failed JWT authentication/authorization, allowing
      for easier debugging.
    • You can now use daml new project-name --template=template-name
      instead of daml new project-name template-name. The positional
      arguments led to confusion so the named version is now preferred,
      but both continue to work.
    • ๐Ÿ“ฆ Successful package uploads to the Sandbox are now logged on the
      ๐Ÿ‘€ server. See #6144.
    • Sandbox now allows the user to specify the participant ID with the
      --participant-id switch.
    • โฑ The daml ledger commands now accept a --timeout option which can
      0๏ธโƒฃ be used to change the timeout for API requests from the default of
    • You can now specify the version of Sandbox and the JSON API
      independently of your SDK version by setting platform-version in
      ๐Ÿš€ your daml.yaml. This is useful if you are deploying to a ledger
      ๐Ÿ‘€ that is running components from a different SDK version. See
      for details.
    • daml new foobar --template=create-daml-app now properly respects
      the project name and creates a project called foobar in
      ๐Ÿ“ฆ daml.yaml and package.json instead of hardcoding the name to
    • ๐Ÿ‘€ Scala codegen has gained support for exercise-by-key commands. See
      Issue #6466.

    ๐Ÿ› Bug and Security fixes

    • ๐Ÿ›  Fix an issue in the JavaScript Client Libraries where some recursive
      types resulted in a stack overflow.
    • The ActiveContractService now only sets the offset in the last
      response, as intended, instead of in every response element.
    • A bug relating to how Fetch nodes are validated in some DAML ledgers
      ๐Ÿ›  was fixed.

    Integration Kit

    • ๐ŸŽ The performance test names have been changed. To learn more about
      ๐Ÿ“š the available tests, consult the documentation for the Ledger API
      โœ… Test Tool and run it with --list. Docs:
    • ๐Ÿ›  Fixed a bug in the Ledger API test tool that caused the full
      ๐ŸŽ conformance test suite to be run when trying to run performance
      ๐Ÿ‘€ tests but using a wrong name. See
    • Truncate GRPC error messages at 4 KB. This ensures that we won't
      trigger a protocol error when sending errors to the client.
    • ๐Ÿ”„ Change the callback for contract keys from
      GlobalKey => Option[ContractId] to
      GlobalKeyWithMaintainers => Option[ContractId] in DAML Engine
    • โœ‚ Removed Sandbox specific code from the API intended to be used by
      ledger integrations. Use the maven coordinates
      com.daml:participant-integration-api:VERSION instead of
      com.daml:ledger-api-server or com.daml:sandbox.
    • StandaloneApiServer can now be run in a read-only mode
      • The type of the constructor parameter writeService of
        StandaloneApiServer changed to Option[WriteService]. Passing
        None will not start any of the admin services, the command
        service, and the command submission service.
      • The constructor parameter readService of StandaloneApiServer
        ๐Ÿšš has been removed.
      • A new constructor parameter ledgerId has been added to
        StandaloneApiServer. It is used to verify that
        StandaloneApiServer is run against an index storage for the
        same ledgerId. Initialization is aborted if this is not the
    • ๐Ÿ”ง The LedgerConfigurationService now properly streams configuration
      ๐Ÿ”„ changes.
    • 0๏ธโƒฃ Default new Engine constructor to Engine.StableConfig so it does
      not need to be overridden unless you specifically want to run in
      Engine.DevConfig mode
    • โœ… The LotsOfPartiesIT and TransactionScaleIT test suite have been
      ๐Ÿšฆ deemed not providing relevant signal to DAML ledger implementers and
      โœ… have been retired. The tests will be nominally kept in but will be
      ๐Ÿ—„ skipped while they are in a deprecation period. You are advised to
      โœ‚ remove explicit references to those tests before they are fully
      โœ‚ removed.
    • โœ… All tests are now run by default. The --all-tests option is now
      ๐Ÿšš ineffective and deprecated. You are advised to remove its usages
      ๐Ÿ— from your build scripts. Non-isolated tests that could affect the
      โœ… global state of the ledger and interfere with other tests are now
      โฑ automatically scheduled by the test tool to run sequentially at the
      end of the run.
    • ๐Ÿ—„ The --load-scale-factor option is now unused and deprecated. You
      ๐Ÿ— are advised to remove its usages from your build scripts.
  • v1.3.0 Changes

    July 16, 2020


    • The Websocket query and fetch APIs are now stable.
    • ๐Ÿš€ The JSON API Server is now released as a standalone JAR file to
      ๐Ÿš€ GitHub Releases.
    • DAML Script and REPL now work in Static Time mode and can query
    • DAML Studio exposes more details on how contracts were disclosed.
    • The Trigger Service, a solution to host and manage DAML Triggers is
      now available in Early Access.

    Known Issues

    The DAML Studio VSCode extension is affected by a known and recently
    ๐Ÿ›  fixed bug in recent VSCode versions:

    For some users this may lead to the Scenario View in VSCode not
    โฌ†๏ธ rendering correctly. If you are affected by this issue upgrading to
    VSCode 1.47 should resolve it.

    What's New

    Websocket API is stable


    The JSON API Server exposes several Websocket endpoints which allow
    clients to maintain a live view of contract data without polling. These
    endpoints have been available since before SDK 1.0 in early access, and
    are now considered stable.

    Specific Changes

    • The API specification for the /v1/stream/query and
      /v1/stream/fetch endpoints are finalized and fully implemented. 

    Impact and Migration

    The final version of these endpoints is backwards compatible with SDK
    1.0 in the sense that clients of these endpoints from SDK 1.0 work with
    SDK 1.3. Thus no action needs to be taken.

    Standalone JSON API Server


    The JSON API Server is a component intended to be run in production
    environments to supplement the lower level Ledger API with an
    easy-to-use queryable ledger state consumable by any HTTP 1.1 client,
    ๐Ÿ’ป including web browsers. Despite this intended use case, the JSON API
    Server was only distributed as part of the SDK, which meant that the
    DAML SDK had to be installed on production servers in order to run the
    JSON API Server. Providing a stand-alone JAR distribution gives
    ๐Ÿš€ application operators a much leaner deployment option.

    Specific Changes

    Impact and Migration

    This is purely additive to the distribution via the SDK so no action is
    โœ… needed. However, if you do run the JSON API Server in a test or
    production environment, this gives you a leaner and more portable way of
    doing so.

    More functionality in DAML Script and REPL


    โœ… DAML Script and REPL had some limitations in key test and production use
    cases. Firstly, neither exposed the Time Service, which made them hard
    to use in static time mode. Secondly, they only exposed functions to
    allocate parties, not to query existing parties, which required existing
    parties to be passed in via a file, or to be obtained using unsafe
    functions like partyFromText. By exposing the relevant functions of
    the Ledger API in DAML Script and REPL, Ledger Time can now be queried
    and set in Static Time mode, and existing parties can be queried.

    In addition, it is now possible to use DAML Script and REPL with
    multiple JWTs, which in particular, means they can be used with multiple
    parties on DABL.

    Specific Changes

    • DAML Script and REPL's getTime now correctly handles time changes
      in static time mode and returns the current time by querying the
      0๏ธโƒฃ time service rather than defaulting to the Unix epoch. This only
      works in static time mode and via gRPC. In wallclock mode, getTime
      continues to return the system time in UTC. When run against the
      JSON API in static time mode, it continues returning Unix epoch.
    • โž• Add setTime to DAML Script and REPL which sets the ledger time via
      the Ledger API time service. This only works in static time mode and
      via gRPC.
    • โž• Add listKnownParties and listKnownPartiesOn to query the
      corresponding ListKnownParties endpoint in the Party Management
    • The time mode for DAML REPL can now be specified using
      the--static-time and --wall-clock-time flags.
    • You can now use DAML Script with multiple auth tokens. This is
      particularly useful if you are working with the JSON API where you
      can only have one party per token or with an IAM that only provides
      single-party tokens. The tokens are specified in the participant
      ๐Ÿ”ง configuration passed via --participant-config in a new
      access_token field. The existing --access-token-file flag is
      ๐Ÿ‘ still supported if you want to use the same token for all
      connections. Take a look at the
      ๐Ÿ“š documentation
      for more details.

    Impact and Migration

    This functionality is purely additive so no action needs to be taken.

    More Privacy Information in DAML Studio


    DAML Studio's Scenario view allows developers to explore the
    transactions resulting from their DAML models in real time. One of the
    main uses of doing so is to verify that privacy is preserved as
    expected. Until now, the available views only gave information on who
    ๐Ÿ‘€ got to see a contract and through which transaction. SDK 1.3 adds
    information on the mechanism through which a party learned about a
    contract. This saves the developer the work of inferring this from the
    detailed transaction view.

    Specific Changes

    • When displaying scenario results in table view in DAML Studio,
      there's now a new checkbox "Show Detailed Disclosure" which shows
      indications why a party knows about the existence of a contract:
      • S means the party is a signatory.
      • O means the party is an observer.
      • W means the party has witnessed the creation of the contract.
      • D means the party has learned about the contract via

    Impact and Migration

    This functionality is purely additive so no action needs to be taken.

    Early Access Trigger Service


    DAML Triggers give developers the ability to write automation of DAML
    ๐Ÿ’… applications in the style of database triggers using the DAML language
    itself, aiding code reuse and allowing contract definitions and basic
    ๐Ÿ“ฆ automation to be packaged and shipped together. These triggers need to
    be managed at runtime, which until now required developers to manage
    ๐Ÿš€ individual JVM processes, raising the bar to actually deploying DAML
    Triggers in production. The Trigger Service provides a way to manage
    DAML Triggers via a simple REST API.

    The Trigger Service is currently in Alpha, meaning API changes are still
    ๐Ÿ‘ likely, and it notably doesn't support authentication yet.

    Specific Changes

    • โž• Added the daml trigger-service command to the SDK to start the
      Trigger Service. More information in the
      ๐Ÿ“š documentation.

    Impact and Migration

    This functionality is purely additive so no action needs to be taken. If
    you are already evaluating Triggers for your application, we highly
    recommend trying out the Trigger Service as it should ease their use
    considerably. We welcome your feedback.

    Minor Improvements

    • The Java Binding's Bot.wire and Bot.wireSimple now return a
      Disposable, which can be used to shut down the flows. You are
      encouraged to call .dispose() before terminating the client.
    • โž• Added a CLI option for specifying the initial skew parameter for the
      time model. You can control the allowed difference between the
      Ledger Effective Time and the Record time using the
      --max-ledger-time-skew flag.
    • When run with persistence, the Sandbox used to crash if the database
      wasn't running during startup. It now instead waits for the database
      to start up.
    • โž• Additional CLI options to configure the write pipeline in Sandbox,
      ๐Ÿ‘ allowing operators to determine at what point back pressure is
      ๐Ÿ‘€ applied. See daml sandbox --help for details.
    • ๐ŸŽ‰ Initialize the loading indicators in @daml/react of useQuery,
      useFetchByKey and their streaming variants with true. This
      โœ‚ removes a glitch where the loading indicator was false for a very
      brief moment when components using these hooks were mounted although
      no data had been loaded yet. Code using these hooks does not need to
      be adapted in response to this change.
    • The create-daml-app example can now be run against a HTTP JSON API
      port specified in the environment variable
    • ๐Ÿ‘Œ Improved error messages on unsuccessful key lookups.

    ๐Ÿ› Bug and Security Fixes

    • โœ… damlc test --project-root now works with relative paths as well.
    • ๐Ÿ“ฆ The Package Management Service's ListKnownParties response's
      PartyDetails now properly reflects where a party is non-local on
      distributed, multi-participant ledgers that expose parties to remote
    • The application identifier in a command submission request is now
      ๐Ÿ‘€ checked against the authorization token. See
    • In scenarios, fetches and exercises of contract keys associated with
      contracts not visible to the submitter are now handled properly
      instead of showing a low-level error.
    • โšก๏ธ Some libraries in the DAML Studio VS Code Extension were updated to
      ๐Ÿ›  fix security issues. DAML Studio now requires VSCode 1.39 or newer.
    • ๐Ÿ›  Fix an issue in DAML Script where the port was ignored for
      non-empty paths in the url when running DAML Script over the JSON
    • ๐Ÿ›  Fix an issue in the Ledger API indexer that could have caused a
      crash in the presence of divulged contracts. Exclusively affects
      DAML ledger implementations where distributed participants each only
      ๐Ÿ‘€ see a portion of the ledger. The sandbox is not affected. See

    Ledger Integration Kit

    • โœ… The Ledger API Test Tool --exclude and --include flags now match
      โœ… the full test name as a prefix, rather than just suite names. Test
      โœ… name is built by combining the suite name with a test identifier, so
      this change should be fully backwards compatible. Run with
      โœ… --list-all to list all tests (as opposed to just the test suites
      with --list).
    • ๐ŸŒ LfValueTranslation.Cache now requires separate configuration of
      ๐ŸŒ lfValueTranslationEventCache and lfValueTranslationContractCache
    • โฌ†๏ธ Upgrade auth0 jwks-rsa version to 0.11.0
    • KVUtils does not commit output keys whose value is identical to
      input anymore
    • The Ledger API Server + Sandbox now accepts a new time model if none
      is set. Previously, it would erroneously be rejected because the
      generation number submitted to was incorrectly set to 2 rather
      than 1. This would not affect most users of Sandbox or other
      ๐Ÿ”ง kvutils-based ledgers, as if a configuration is set automatically on
      startup when creating a new ledger. This affects users who
      ๐Ÿ”ง explicitly override the initial ledger configuration submit delay to
      something longer than a few milliseconds.
    • โž• Add 8 new  timer metrics to track database performance when storing
      transactions. The overall time is measured by
      • Timer daml.index.db.store_ledger_entry.prepare_batches:
        measures the time for preparing batch insert/delete statements
      • Timer daml.index.db.store_ledger_entry.events_batch: measures
        the time for inserting events
      • Timer
        measures the time for deleting contract witnesses
      • Timer daml.index.db.store_ledger_entry.delete_contracts_batch:
        measures the time for deleting contracts
      • Timer daml.index.db.store_ledger_entry.insert_contracts_batch:
        measures the time for inserting contracts
      • Timer
        measures the time for inserting contract witnesses
      • Timer daml.index.db.store_ledger_entry.insert_completion:
        measures the time for inserting the completion
      • Timer daml.index.db.store_ledger_entry.update_ledger_end:
        โšก๏ธ measures the time for updating the ledger end
    • โž• Added 4 new timer metrics to track DAML execution performance The
      overall time is measured by
      • Timer daml.execution.lookup_active_contract_per_execution:
        measures the accumulated time spent for looking up active
        contracts per execution
      • Histogram
        measures the number of active contract lookups per execution
      • Timer daml.execution.lookup_contract_key_per_execution:
        measures the accumulated time spent for looking up contract keys
        per execution
      • Histogram
        measures the number of contract key lookups per execution
  • v1.2.0 Changes

    June 11, 2020


    • ๐Ÿ›  Module prefixes can now be stored in daml.yaml. This means that
      you can use multiple versions of libraries in the same project by
      specifying them in daml.yaml instead of with
      ๐Ÿ“ฆ the --package command line flag.
    • ๐ŸŒ A new flag, --max-lf-value-translation-cache-entries, allows you
      to set a number of events for which DAML-LF values will be cached.
      ๐Ÿšค This can help reduce latency when serving transactions.

    What's New

    ๐Ÿ›  Module Prefixes


    โฌ†๏ธ When upgrading a package using a DAML upgrade workflow, one has to
    ๐Ÿ“ฆ import both the old and new version of the package as dependencies. If
    ๐Ÿ“ฆ both the package and module names are the same, this used to require
    ๐Ÿ›  setting compiler flags. The new Module Prefixes feature gives an easier
    ๐Ÿ“ฆ means of disambiguating the packages and modules.

    Specific Changes

    ๐Ÿ›  The compiler picks up a new block module-prefixes specified
    ๐Ÿ›  in daml.yamlmodule-prefixes takes entries of the form 
    ๐Ÿ“ฆ package: Prefix, and modules from the package are then accessible
    using that prefix. For example, the below makes
    module X from foo-1.0.0 available as Foo1.X,
    and X from foo-2.0.0 as Foo2.X.

    ย ย foo-1.0.0: Foo1
    ย ย foo-2.0.0: Foo2

    Refer to
    ๐Ÿ“š the documentation for
    detailed information.

    Impact and Migration

    This is a purely additive feature, so no migration is necessary. If your
    ๐Ÿ“ฆ project uses the old --package compiler flag to disambiguate packages,
    you can switch to this simpler method.

    Minor Improvements

    • ๐ŸŒ The Sandbox's --max-lf-value-translation-cache-entries option
      ๐Ÿ‘ allows you to set a number of events for which DAML-LF values are
      ๐Ÿšค cached. This can reduce latency in serving transactions.
    • daml damlc inspect-dar now has a --json flag to produce
      ๐Ÿ‘€ machine-readable output. See
      ๐Ÿ“š the documentation
      for more information.
    • The Scala bindings have gained a method, LedgerClient#close, which
      will shut down the channel and await termination. This is optional;
      the channel will still be shut down on JVM exit if this method is
      not called.
    • Record dot syntax like rec.field1.field2 is now handled in
      expressions entered into the REPL.
    • ๐Ÿ‘ daml trigger, daml script and daml repl now all support
      ๐Ÿ”ง the --max-inbound-message-size command line flag, which configures
      the maximum size of transactions that can be handled.
    • The createAndExerciseCmd command has been added to DAML Triggers.

    ๐Ÿ›  Security and Bugfixes

    • โฌ†๏ธ Dependencies have been upgraded to newer versions to avoid exposure
      ๐Ÿ”’ to reported security vulnerabilities.
      • Upgrade jackson version to 2.11.0 from
      • Upgrade io.grpc:grpc-xxxxx and io.netty:netty-xxx version
        โœ… to latest
      • Upgrade protobuf and protobuf-java to 3.11.0
    • A Sandbox Classic migration issue when used with postgres has been
      ๐Ÿ›  fixed.
      ๐Ÿ‘€ See #6017
    • A bug where large multi-command transactions would cause a stack
      ๐Ÿ›  overflow in DAML Script was fixed.
    • The Standard Library's DA.Text.splitOn function will now correctly
      ๐Ÿ– handle the case where the separator appears at the end but should
      not be matched, as in splitOn "aa" "aaa" == ["", "a"].
      ๐Ÿ‘€ See #5786 for
      more details.
    • ๐Ÿ‘• The DAML linter, dlint, has been improved by removing some
      Haskell-based rules not currently applicable to DAML and by changing
      some function references.

    Ledger Integration Kit

    • The Ledger API Server emits new metrics for the LF Value Cache. If
      the --max-state-value-cache-size is greater than zero, the
      following additional metrics will be recorded under the
      daml.kvutils.submission.validator.state_value_cache namespace: 
      • hits
      • misses
      • load_successes
      • load_failures
      • load_total_time
      • evictions
      • evicted_weight
    • โž• Added new Ledger API Server metrics
      ๐ŸŒ for daml.index.db.*.translation to measure the time spent
      translating to and from the serialized DAML-LF values when fetched
      from the participant index.
    • โž• Added new Ledger API Server metrics
      for daml.index.db.*.deserialization to measure the duration of the
      ๐ŸŒ translation of the serialized DAML-LF values when fetched from the
      participant index.
    • โœ… The Ledger API Test Tool has gained
      ๐ŸŽ the TransactionSize performance benchmark test.
  • v1.1.1 Changes

    May 13, 2020


    • ๐Ÿ†• New package management endpoints on the JSON API
    • ๐Ÿ‘ Better TLS Support for the JSON API
      • Action required if you start the JSON API using daml json-api
        and do not run it behind a reverse proxy.

    What's New

    ๐Ÿ†• New Package Management Endpoints on the JSON API


    ๐Ÿ“ฆ The Ledger API's package management service allows uploading,
    ๐Ÿ“ฆ downloading and listing of DAML packages available on a DAML Ledger. For
    situations where connecting to the Ledger API is not possible or is
    inconvenient, these services are now available through the JSON API as

    Specific Changes

    The JSON API has three new endpoints

    • ๐Ÿ“ฆ GET /v1/packages -- returns all package IDs
    • ๐Ÿ“ฆ GET /v1/packages/<package ID> -- downloads a given DALF package
    • ๐Ÿ“ฆ POST /v1/packages -- uploads a DAR file to the ledger

    Impact and Migration

    This is a purely additive change. Users who connect to gRPC from their
    ๐Ÿ“ฆ applications for the sole purpose of managing DAML packages may switch
    over to the new endpoints to eliminate dependencies on gRPC or Ledger
    API language bindings.

    ๐Ÿ‘ Better TLS Support for the JSON API


    In addition to the numerous new TLS options introduced in SDK 1.0.0, the
    JSON API can now also connect to the Ledger API via TLS. To protect
    against insecure connections which may leak access tokens, it also adds
    โš  a warning if not run behind a reverse proxy that terminates TLS
    ๐Ÿš€ connections. This warning will become an error in a future release.

    Specific Changes

    • ๐Ÿ’ป The JSON API accepts new command line parameters --pem, --crt,
      ๐Ÿ”ง --cacrt, and --tls, which configure it to connect to the Ledger
      API using TLS.
    • 0๏ธโƒฃ By default, the JSON API now checks that connections are made
      through a reverse-proxy providing HTTPS, ensuring that JWT tokens
      don't leak. To disable this check, such as for development, pass
      --allow-insecure-tokens. A failed check currently results in a
      โš  warning.

    Impact and Migration

    daml start automatically sets this flag so there is no migration
    needed. If you are starting the JSON API manually, we advise you to add
    the flag --allow-insecure-tokens for development environments, and to
    โš™ run the JSON API behind a TLS-enabled reverse proxy in production.

    Minor Improvements

    • Faster Sandbox reset via the ResetService.
    • 0๏ธโƒฃ daml trigger and  daml script now default to wall clock time if 
      neither --wall-clock-time or --static-time is passed.
    • daml script now has an --output-file option that can be used to
      specify a file the result of the script should be  written to.
      Similar to --input-file the result will be output in the DAML-LF
      JSON encoding.
    • You can now disable implicit party allocation of the Sandbox by
      passing the flag --implicit-party-allocation=false. This makes it
      โœ… easier to test as you would against another ledger which does not
      ๐Ÿ‘Œ support this feature.
    • The daml ledger commands no longer require the Bearer prefix in
      the access token file. This matches the behavior of DAML Script and
      other SDK tools.
    • โž• Added --max-commands-in-flight to Sandbox CLI configs. This limits
      the maximum number of unconfirmed commands in flight in

    ๐Ÿ‘Œ Improvements to Early Access Features

    • daml damlc visual now works properly in projects consisting of
      ๐Ÿ“ฆ multiple packages.
    • ๐Ÿ›  Fix a bug where exerciseByKey was not properly recognized by daml
      damlc visual.
    • ๐Ÿ‘ DAML REPL now produces better error messages on calls to error and

    ๐Ÿ› Bug Fixes

    • ๐Ÿ›  Fix a bug where scenarios with names containing special characters
      resulted in a crash in the scenario service.
    • ๐ŸŒฒ The Sandbox properly respects the --log-level CLI parameter
    • The sandbox now properly delays command submissions using
      ๐Ÿ‘€ minLedgerTimeAbs or minLedgerTimeRel. See issue
    • Migrating from Sandbox 0.13.55 to Sandbox Classic 1.0.0 could have
      introduced contracts falsely reported as active when in fact they
      ๐Ÿ‘€ are not. Migrating to Sandbox Classic 1.1.0 will fix the issue. See
      issue #5659.

    ๐Ÿ”„ Changes to Ledger Integration Kit

    These changes only affect ledger integrators and operators that consume
    the metrics emitted by the DAML Integration Kit. We have introduced new
    metrics and adjusted the naming of existing metrics to be consolidated.
    If you have built a dashboard for a ledger built using the integration
    kit, then you will need to adapt that dashboard. The changes are as

    We have introduced these new metrics:

    • a timing metric for the commit at daml.kvutils.writer.commit.
    • a metric for command validation upon submission,
    • daml.commands.submissions is a new timer that measures all
    • daml.commands.valid_submissions is a new meter that counts valid
      (unique, interpretable) submissions.
    • โšก๏ธ daml.kvutils.reader.parse_updates is a new timer that measures the
      โšก๏ธ translation time of ledger log entries when serving state updates to
      the indexer.
    • daml.kvutils.reader.open_envelope is a new timer that measures the
      ๐ŸŒฒ deserialization time of ledger log entries when serving state
      โšก๏ธ updates to the indexer.
    • ๐ŸŒฒ daml.ledger.log.append is a new timer that measures the time for
      ๐ŸŒฒ writing new log entries.
    • is a new timer that measures reading from
      the ledger state.
    • daml.ledger.state.write is a new timer that measures writing to
      the ledger state.
    • We have renamed these metrics:
      • daml.lapi.command_submission_service.failed_command_interpretations
        has been renamed to
      • daml.lapi.command_submission_service.deduplicated_commands has
        been renamed to daml.commands.deduplicated_commands.
      • daml.lapi.command_submission_service.delayed_submissions has
        been renamed to daml.commands.delayed_submissions.
      • daml.lapi.command_submission_service.submitted_transactions
        has been renamed to
    • The metrics registry should now be passed using the new
      com.daml.metrics.Metrics type, which wraps/replaces
    • ๐Ÿ”ง maxDeduplicationTime configuration (the maximum time window during
      ๐Ÿšš which commands can be deduplicated) has moved from
      ๐Ÿ”ง SubmissionConfiguration to the Configuration class.
    • Engine is now mandatory in several  participant api server related
      constructors to avoid running multiple interpretation engines.
  • v1.1.0

    April 30, 2020
  • v1.0.1 Changes

    April 27, 2020

    ๐Ÿ›  This is a bugfix release for SDK 1.0.0. All users of SDK 1.0.0 are
    ๐Ÿš€ encouraged to upgrade at their earliest convenience. This release fixes
    3 issues:

    ๐Ÿ›  Fix an issue with false negative contract key lookups by
    ๐Ÿ‘€ non-stakeholders (see
    #5562 for details).

    This issue affected the new Sandbox introduced in SDK 1.0.0 (but not
    sandbox-classic) as well as the scenario service. Both Sandbox and
    ๐Ÿ›  the scenario service are fixed.

    ๐Ÿ›  Fix a crash in the scenario service.

    SDK 1.0 introduced a bug where the scenario service would crash if a
    failing transaction contained transient contracts. In DAML Studio
    this was shown as the following error:

    BErrorClient (ClientIOError (GRPCIOBadStatusCode StatusUnknown (StatusDetails {unStatusDetails = \โ€œ\โ€})))
    1. Fix an issue where Sandbox incorrectly rejected certain commands
      ๐Ÿ‘€ relying on getTime during validation (see
      #5662 for details).
      This was only an issue if you set either min_ledger_time_rel or
  • v1.0.0 Changes

    April 15, 2020


    • ๐Ÿ†• New JavaScript/TypeScript client-side tooling is now stable and the
      ๐Ÿ— recommended way to build DAML applications. A new Getting Started
      ๐Ÿ“„ Guide
      on these tools has replaced the Quickstart guide.
    • The Time Model has been improved so that it works seamlessly without
      โšก๏ธ user input to the Ledger API. Action needed when you update to the
      โœ… latest version of API bindings or recompile gRPC clients.
    • ๐Ÿ”ง More TLS configuration options for DAML Ledgers.
    • 0๏ธโƒฃ The next generation Sandbox is now the default, bringing an
      experience closer to a distributed ledger. Immediate action is
      needed if your project is relying on scenarios for ledger
      ๐ŸŽ‰ initialization.
    • ๐Ÿ—„ Cleanup of names, deprecated features and language versions.
      Immediate action needed if you use any Java dependencies with
      ๐Ÿ“ฆ com.digitalasset packages or Maven coordinates.

    Known issues

    • The new Sandbox has a known issue where some false negative contract
      key lookups are only correctly validated on the read path, not on
      the write path. The net effect is that with carefully constructed
      DAML models, non-conformant transactions can be recorded in the
      underlying storage, which may lead to data continuity issues when
      ๐Ÿ›  this issue is fixed. Full details can be found on GitHub issue

    What's New

    ๐Ÿ†• New Client Tooling


    Distributed applications are much more than smart contracts running on a
    distributed ledger, and in 2019 we set out to make it significantly
    ๐Ÿ— easier to build that part of applications which lives off-ledger:
    Automations, Integrations, and UIs. The new tooling is focused on giving
    application developers an easy-to-consume, real-time ledger state, which
    ๐Ÿšš moves the development experience away from event sourcing and makes it
    similar to working with a database.

    • The HTTP JSON API: giving a queryable view of the ledger state and
      endpoints to submit transactions, all using an easy-to-consume JSON
    • ๐Ÿ“ฆ A JavaScript/TypeScript code generator: turning a DAML package into
      a (typed) library to interact with the HTTP JSON API.
    • A set of JavaScript/TypeScript client libraries: working hand in
      hand with the code generator to interact with the HTTP JSON API, and
      bind ledger data to React components.
    • A new Getting Started Guide shows how all these pieces fit together
      ๐Ÿ— to build a complete distributed end-to-end application with a custom
      ๐Ÿ’ป UI.

    The HTTP JSON API is designed to be consumable from any language
    ecosystem. The choice of JavaScript (and React) for the rest of the
    tooling was driven by the desire to aid application development all the
    way up to UIs, using the most widely adopted technologies.

    Specific Changes

    • ๐Ÿ“š The documentation has a new Getting Started
      ๐Ÿ“„ Guide
      . The
      ๐Ÿšš previous Quickstart guide has moved under the Java Bindings section.
    • There is a new SDK template with a skeleton for an end-to-end
      application using the new tooling. It's documented and used in the
      ๐Ÿ†• new Getting Started Guide. Use
      daml new create-daml-app create-daml-app to get started.
    • The /v1 endpoints of the HTTP JSON API and the JavaScript Code
      ๐Ÿ‘ Generator and Support Libraries are now stable.
      • The JSON API has gained an endpoint to allocate parties:
    • ๐Ÿ‘Œ Support for maps and lists has been removed from the query language.
    • Note that the WebSockets streaming endpoint of the HTTP JSON API is
      still under development.

    Impact and Migration

    The new client tooling is almost purely additive so for most, no action
    is needed. For new applications, we recommend this tooling as it makes a
    lot of things quicker and easier. However, direct use of the Ledger API
    and HTTP JSON API continues to be a good option for anyone needing
    lower-level control or wanting to use a different language for their

    The only non-backwards compatible change compared to previous versions
    is the removal of queries on lists and maps in the HTTP JSON API. There
    is no trivial migration for this. If you were relying on these
    capabilities please get in touch with us via [email protected] or on
    Slack. We'd like to hear how you were making use of the feature so that
    ๐Ÿ‘ we can replace it with something better, and we will make some
    โ†ช suggestions to work around the removal.

    ๐Ÿ‘Œ Improved Time Model


    ๐Ÿš€ SDK Release 0.13.55 introduced a new method for command deduplication
    and deprecated the command field maximum_record_time. SDK Release 1.0
    further improves the Ledger Time model so that users no longer need to
    pass in any time related information to the Ledger API. The new time
    model is designed to work under almost all circumstances without user
    intervention, making developing applications against DAML Ledgers easier
    in practice.

    Specific Changes

    • The Sandbox no longer emits Checkpoints at regular intervals in wall
      clock mode.
    • The ledger_effective_time and maximum_record_time fields have
      ๐Ÿšš been removed from the Ledger API, and corresponding fields have been
      โœ‚ removed from the  HTTP JSON API and Ledger API language bindings.
    • 0๏ธโƒฃ The --default-ttl command line argument of the HTTP JSON API is
    • Ledger Time is no longer strictly monotonically increasing, but only
      follows causal monotonicity: Ledger Time of transactions is greater
      than or equal to the Ledger Time of any input contract.
    • The Command Service is no longer idempotent with respect to
      duplicate submissions. Duplicate submissions now instead return an
      ALREADY_EXISTS error, consistent with the new deduplication
      mechanism of the Command Submission Service.

    Impact and Migration

    Old applications will continue running against new ledgers, but ledger
    effective time and maximum record time set on submissions will be
    ignored. As soon as the client-side language bindings or compiled gRPC
    โšก๏ธ services are updated, the fields will need to be removed as they are no
    longer part of the API specification.

    ๐Ÿ‘ Better TLS Support


    ๐Ÿ‘ DAML Ledgers have always supported exposing the Ledger API via TLS, but
    ๐Ÿ‘Œ support on consuming applications was inconsistent and often required
    ๐Ÿš€ client certificates. From this release onward, more client components
    ๐Ÿ‘Œ support consuming the Ledger API via TLS without client authentication.

    Specific Changes

    • ๐Ÿ”ง When Sandbox is run with TLS enabled, you can now configure the
      ๐Ÿ‘€ requirement for client authentication via  --client-auth. See the
      ๐Ÿ“š documentation
      for more information.
    • ๐Ÿš€ The daml deploy and daml ledger commands now support connecting
      ๐Ÿ‘€ to the Ledger API via TLS. See their
      ๐Ÿ“š documentation
      for more information.
    • ๐Ÿ‘ DAML Script and DAML Triggers now support TLS by passing the --tls
      flag. You can set certificates for client authentication via --pem
      and --crt and a custom root CA for validating the server
      certificate via --cacrt.
    • Navigator, DAML Script, DAML REPL, DAML Triggers, and Extractor can
      now run against a TLS-enabled ledger without client authentication.
      You can enable TLS without any special certificates by passing
    • ๐Ÿ”ง DAML Script and DAML Triggers have the option to configure
      certificates for client authentication via --pem and --crt and a
      custom root CA for validating the server certificate via --cacrt.

    Impact and Migration

    This is a new capability, so no action is needed. These new features are
    ๐Ÿ‘‰ useful in production environments where client to ledger connections may
    need to be secured.

    Next Generation Sandbox


    The DAML Sandbox has had a major architectural overhaul to bring it and
    its user experience even closer in line with other DAML Ledgers. The new
    0๏ธโƒฃ Sandbox is now the default, but the "classic" Sandbox is included as a
    ๐Ÿš€ deprecated version in this release. The classic Sandbox will be removed
    ๐Ÿš€ from the SDK in a future release and will not be actively developed

    Specific Changes

    • daml sandbox and daml start start the new Sandbox. The classic
      sandbox can be invoked via daml sandbox-classic and
      daml start --sandbox-classic.
    • 0๏ธโƒฃ Wall Clock Time mode (--wall-clock-time) is now the default.
    • ๐Ÿ‘ Scenarios are no longer supported for ledger initialization.
    • Contract identifiers are hashes instead of longer sequence numbers.
      • A new static contract identifier seeding scheme has been added
        to enable reproducible contract identifiers in combination with
        ๐Ÿ‘€ --static-time. Set flag --contract-id-seeding=static to use
    • Ledger API Offsets are no longer guaranteed to be a parsable number.
      They are an opaque string that can be compared lexicographically.
    • ๐Ÿ’ป The command line flags --auth-jwt-ec256-crt and
      --auth-jwt-ec512-crt were renamed to --auth-jwt-es256-crt and
      --auth-jwt-es512-crt, respectively, to align them with the
      cryptographic algorithms used.

    Impact and Migration

    The impact is primarily on demo applications running in static time mode
    and/or using scenarios for ledger initialization. Since both the
    classic  and new Sandbox are compliant DAML Ledgers, there is no
    difference in behavior apart from these fringes.

    If you rely on static time mode, set it explicitly using

    • If you rely on reproducible contract identifiers, also set
      ๐Ÿ‘€ --contract-id-seeding=static.

    If you use a scenario for ledger initialization, migrate to DAML
    ๐Ÿ“„ Script
    ๐Ÿ“œ If you were parsing ledger offsets, you need to find a way to stop doing
    so. This is not guaranteed to be possible on DAML Ledgers other than the
    classic Sandbox. If you were relying on doing so, get in touch with us
    on [email protected]. We'd like to help with migration and want to
    ๐Ÿ‘ understand how you were using this so we can better support your use
    case. If you were using ES256 or ES512 signing for authentication,
    ๐Ÿ’ป adjust your command line flags. If you were running the now classic
    sandbox with persistence in a SQL database, you need to recreate
    contracts in the ledger run with the new sandbox. There is no automatic
    โช data migration available. To ease transition, you can revert back to the
    classic Sandbox using daml sandbox-classic and
    daml start --sandbox-classic=yes. Note that the classic Sandbox is
    ๐Ÿš€ deprecated and will be removed in a future release.

    Cleanup for DAML SDK 1.0


    ๐Ÿš€ As we are moving into the 1.0 release line, we have done some cleanup
    ๐Ÿ—„ work, aligning names of artifacts, removing deprecated language
    ๐Ÿ”– versions, streamlining the release process, and finishing a few language
    โš  tweaks by turning select warnings into errors. 

    Specific Changes

    ๐Ÿ“ฆ All Java and Scala packages starting with com.digitalasset.daml
    and com.digitalasset are now consolidated under com.daml

    • Impact: Changing the version of some artifacts to 1.0 will
      cause a resolution error.
    • Migration: Changing Maven coordinates and imports using a
      find and replace should be enough to migrate your code.

    ๐Ÿ“ฆ Ledger API services are now under the com.daml package. A
    compatibility layer has been added to also expose the services under
    ๐Ÿ“ฆ the com.digitalasset package.

    • Impact: grpcurl does not work with the compatibility layer.
    • Migration: Scripts using grpcurl need to change the service
      name from com.digitalasset to com.daml.

    < DAML SDK 1.0: com.digitalasset.ledger.api.v1.TransactionService

    โ‰ฅ DAML SDK 1.0: com.daml.ledger.api.v1.TransactionService)

    0๏ธโƒฃ The default DAML-LF target version is now 1.8.

    • Impact: Projects will not run against old DAML Ledgers that
      ๐Ÿ‘ do not support DAML-LF 1.8.
    • Migration: You can target 1.7 by specifying --target=1.7
      ๐Ÿ— in the build-options field in your daml.yaml.

    ๐Ÿ—„ All DAML-LF versions <1.6 are deprecated and will not be supported
    on DAML Ledgers.

    • Impact: The new Sandbox will not run DAML code compiled to
      DAML-LF 1.5 or earlier.

    - Migration : Use classic Sandbox to run older DAML models.

    ๐Ÿš€ We no longer release the SDK to Bintray.

    • Impact: If you were relying on artifacts on Bintray, you
      โšก๏ธ will not be able to update to version 1.0 without changing the
    • Migration: The new locations are as follows:
      • SDK Releases and Protobuf files are released to GitHub
        ๐Ÿš€ Releases.
      • Java/Scala artifacts are on Maven Central.

      - JavaScript artifacts are on NPM.

    File names must now match up with module names. This already
    ๐Ÿš€ produced a warning in previous releases

    • Impact: Projects in which there are mismatches will no
      ๐Ÿ— longer build.
    • Migration: Change your .daml filenames to match module

    It is now an error to define a record with a single constructor
    where the constructor does not match the type name. This restriction
    only applies to single-constructor records. Variants and enums are
    โš  not affected. This already produced a warning in SDK 0.13.55.

    • Impact: Projects with now illegal type declarations will no
      ๐Ÿ— longer build.
    • Migration: In declarations of the type data X = Y with ..,
      you have to change the type name (X) to match data constructor
      name (Y) or vice versa.

    The compiler name collision check has been extended to also count
    the case as a collision where you have a type B in module A and
    a module A.B.C (but no module A.B).

    • Impact: Projects with such module names will produce
      ๐Ÿš€ warnings and stop compiling in a future release. The JavaScript
      ๐Ÿ“ฆ Code Generator is not usable on packages that don't uphold this
    • Migration: You have to rename your modules to avoid such
      name clashes.

    Impact and Migration

    Impacts and migrations are covered item by item in Specific Changes

    Progress on Features Under Development


    Work is progressing on two features that are currently under active

    1. The DAML REPL, introduced with SDK 0.13.55 is becoming richer in its
      abilities, getting ever closer in capabilities to DAML Script.
    2. Work on a Websockets streaming version of the HTTP JSON API's
      querying endpoints is progressing. The aim with this streaming
      service is to combine the ease of consumption of the HTTP JSON API
      with the liveness provided by a streaming API.

    Specific Changes

      • You can now use import declarations at the REPL prompt to bring
        โž• additional modules into scope.
      • You can now use more complex patterns in statements, e.g.,
        (x,y) <- pure (1,2).
      • You can now connect to a ledger with authentication using
        daml repl --access-token-file=path/to/tokenfile option.
    • Websockets on the HTTP JSON API
      • The error format has changed to match the synchronous API:
        {"status": <400 \| 401 \| 404 \| 500>, "errors": <JSON array of strings> }.
      • The streaming version of the query and fetch-by-key endpoints
        ๐Ÿ‘€ now emit the last seen ledger offset. These offsets can be fed
        back to new requests to start the stream at said offset. Such
        offset messages are also used for heartbeating instead of the
        previous explicit heartbeat messages.

    Impact and Migration

    The only impacts are on consumers of the Websocket streaming APIs. Those
    consumers will have to make some minor adjustments to include the API
    ๐Ÿ”„ changes around error handling and ledger offsets.

    ๐Ÿ›  Minor Changes and Fixes

    • ๐Ÿš€  Better support for snapshot releases in the DAML Assistant.
      • daml version can now list the available snapshot versions by
        passing the flag --snapshots=yes.
      • daml install latest can now include the latest snapshot
        ๐Ÿ”– version by passing the flag --snapshots=yes.
      • DAML Script can now be run over the HTTP JSON API, which means
        it now runs against project:DABL. Take a look at the
        ๐Ÿ“š documentation
        for instructions and limitations.
    • Party strings are now restricted to 255 characters.
      • Impact: If you used the Sandbox with very long Party strings
        they'll be rejected by the new Sandbox and other DAML Ledgers.
      • Migration: Shorten your Party strings. Note that in ledgers
        other than Sandbox, you may not be able to choose them entirely
        freely anyway.
    • You can now disable starting Navigator as part of daml start in
      your daml.yaml file by adding start-navigator: false.
    • Calls to the GetParties API function with an empty list of parties
      no longer results in an error, but in an empty response.