Daml + Forma: Automatically Deploy and Operate Synchronized DLT Workflows

WorldSibu collaborates with Digital Asset to bring a multi-cloud automated infrastructure experience to Daml-driven solutions.

WorldSibu continues to expand the reach of Forma, the blockchain infrastructure automation platform, with the recent partnership with Digital Asset, the creators of the open source smart contract language, Daml.

This partnership will bring a wider adoption to Daml as now companies will be able to, with just 3 clicks, quickly wrap-up a cost-efficient development environment to build and collaborate. After that, leveraging the existing and future compute-environment and blockchain framework integrations in Forma, automatically deploy and operate multi-cloud infrastructure in minutes (Hyperledger Fabric in Microsoft Azure, IBM Cloud, Google Cloud, AWS, Digital Ocean, and bare-metal Kubernetes).

Daml is a pluggable smart contracting language and runtime that helps to abstract and automate synchronized complex workflows between multiple parties. It integrates with multiple ledger technologies such as VMware Blockchain, Hyperledger Fabric, Hyperledger Sawtooth, R3 Corda, AWS Aurora, and others.

“Daml has become the smart contract language of choice for developing multi-party applications without lock-in to a single platform. Now, with the addition of support from WorldSibu’s Forma, clients will be able to quickly deploy Daml applications to multiple clouds, further increasing portability,” said Dan O’Prey, CMO and Head of Community Growth at Digital Asset.

Daml integrates with multiple ledger technologies, Forma deploys it to any ledger technology in any infrastructure available.

unnamed2With this recent move, WorldSibu reinforces its vision to help the world adopt Distributed Ledger Technologies in the enterprise. Convector continues to have all the support from WorldSibu and will soon welcome Daml as a new option for companies all around the world.

“Digital Asset and Daml share our vision of more efficient and productive industries. Distributed Ledger Technologies are the natural evolution of silo-based systems, and partnerships like this one send a clear message to the market,” said Walter Montes, co-founder and CEO of WorldSibu.

Taking advantage of the best from Forma and Daml, an extensive roadmap of powerful integrations is on its way.

  • The first stage will bring Daml + PostgreSQL to the cloud for enterprises to evaluate the technology, create POCs, and design the business without worrying about which ledger technology to use.
  • In the future, Forma will enable software engineers to easily deploy to Hyperledger Fabric in all the cloud providers it supports already. And then to Hyperledger SawtoothCorda, and others. This will turn the decision of which ledger to use for your Daml-driven application into a matter of a click of a button.

Are you interested? We want to talk to companies interested in Daml that want to shape how these integrations look like or that want to know as soon as we release them. 👉 Sign up here to get a limited early access!

Release of Daml SDK v0.13.15

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.




Diamonds are Forever – Creating Asset Backed Tokens in Daml

Guest post by Brad Buck, co-founder and VP of Strategy & Development Solutions, OpenCrowd, a custom blockchain and Fintech technology solution firm and Digital Asset Partner.

Asset backed tokens are a great way to provide users with ownership rights in both physical and intangible form. However, we also need solutions that can guarantee the security, fungibility, and availability of the underlying physical asset. Developing such solutions leads to a wider set of architectural and technology integration challenges than just tokenization.

OpenCrowd has developed a Daml implementation based on our ongoing work with Diamond Standard Co. to create fungible asset tokens that are backed by real physical assets (diamonds). Diamond Standard is creating a novel, new commodity asset class that is a store of value, like gold. This has never been done before.

Our solution consists of an underlying master registry of diamond assets and a fungible token (a BitCarbon). The diamond assets are stored offline in secure units called “bars”. The contents of each bar are algorithmically selected to ensure each has the same gemological value of underlying physical diamonds, thus enabling the fungibility of the coins that are issued against these bars.

The implementation includes key operational workflows such as the registration and verification of assets, creation/minting of fungible tokens, and custody management. Minting of fungible tokens is done by approved minters that create new coins. The approval of minters is also developed as a Daml workflow.

Components of the solution

The asset backed tokenization solution has several key components listed here:


The contract that registers diamonds.


An invite contract for a Diamond Registrant to register diamond properties.


Manages Minters and issues out invite to mint diamonds.


An invite that would mint diamond pucks upon acceptance.


A contract would check if diamond IDs are valid and would generate fungible tokens that are tied to minted diamond pucks.


Option to create a lien for a minted puck with a lien expiration date.


An invite to enter into a lien agreement with the lien expiration date specified.


Why did we choose Daml?

As blockchain technology continues to gain traction, companies have quickly realized they will utilize multiple distributed ledgers. Until recently, if a company wanted to have a smart contract run on multiple blockchains, they would write smart contracts for each separate blockchain, in a different language for each blockchain. This is expensive, laborious, and time-consuming for a business. Enterprises using multiple blockchains are better off standardizing on technologies to achieve efficiency, but this has not been possible to date. 

With Daml we were now able to create concise and secure smart contracts that can be executed by the privacy aware Daml runtime on different distributed ledgers. Thus, different parts of a solution can potentially be deployed on multiple ledgers and even databases, while still enjoying a common business process integrated through Daml. This capability is enabled by the DA Ledger model that outlines the privacy and integrity properties of Daml. These properties are physically implemented by the individual ledger platforms to varying levels. However, the logical conformance to these properties is still enforced by the Daml runtime that works with each underlying persistent layer at each node.

For this use case, we use the Multiple Party Agreement design pattern. This pattern uses pending contracts as wrapper agreements before the final agreement contract so that any one of the counterparties to the contract can initiate the workflow by creating a pending contract. The final contract agreement is not created on the ledger until all the counterparties involved in the pending contract sign all pending contracts.

A very positive outcome of using Daml was the increase in productivity while developing this solution. Since Daml is designed to focus only on the business functionality while abstracting away the underlying ledger level complexities, it simplified our smart contract and workflow development, allowing developers to focus on implementing the behavior and logic of how asset backed tokens would work.

The effect of this focus becomes apparent when comparing the amount of code needed for a contract: equivalent smart contracts we developed before were 710 lines of code, while the Daml smart contracts are only 200 lines, a very significant difference, further amplified by the clarity of business function, ease of maintenance, and ability to collaborate better with business and operations counterparts.

Creating a blockchain solution that spans physical-virtual worlds presents its own challenges. The Daml stack provided us a simple way to manage that through ledger APIs that can be invoked by designated parties who are stakeholders to the contracts. The contracts themselves can have granular visibility defined thus providing confidentiality at a sub-transaction level. This layered design provided us a lot of flexibility in defining the logical architecture of our solution as IoT messages are received from the storage units, while maintaining various security criteria.

Finally, our Daml solution can also run on a traditional database such as AWS Aurora, in addition to running on DLT platforms. This capability of Daml, and full portability of the code, provides for an excellent development environment, and also a target deployment model for high trust scenarios (e.g. when all parties are within a single enterprise). Over time, this can lead to interoperability between Daml smart contracts across both high-trust and low-trust environments, a huge advantage.

Asset Based Dapp in Action

If you would like to see the demo Dapp in action, here is a link to a full annotated walkthrough video on the OpenCrowd YouTube channel:

The universality of Daml smart contracts has beneficial implications for any use case with multi-step processes involving multiple party interactions. Developers only need to focus on implementing the core logic when building smart contracts, as opposed to creating unique signatures, key structures, and other fundamental blockchain transaction components from scratch. 

We hope this blog provided some insights into the future of how physical assets can be tokenized using a mutualized business process across all parties involved. A common business process such as the one we described in this blog is a powerful capability. It is very different from many different applications sharing a conceptual business process but still exchanging, maintaining and reconciling data in their own different silos.

Enterprises should take note of Daml’s many benefits and consider its use for multi-party workflows and permissioned blockchain solutions. Please feel free to get in touch with me if you need assistance with use case analysis, benefits modeling, process design, and implementation.

About the Author

OpenCrowd is a blockchain fintech solutions firm that creates custom solutions for startups and investment banks since 2005. Our blockchain work spans from the ledger layer to the Dapp layer and our expertise in blockchains including Daml, Ethereum, EoS, Hedera HashGraph, R3 Corda, GoChain, and Stellar

Release of Daml SDK v0.13.14

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Release of Daml SDK v0.13.0

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.




Release of Daml SDK v0.13.13

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Blockchain’s Immutability Could Hold-up in Bankruptcy

Blockchain image 2-1

Committed settlement, a patent-pending methodology introduced by  Digital Asset , could present a way to make financial transactions immutable

By Charlie Yeh, Assistant General Counsel, Digital Asset

When Blockchain Immutability Meets Bankruptcy

“Immutable” is a term that is frequently used when people talk about blockchain and the benefit of using this technology for record-keeping.

Blockchain is designed to provide an immutable, indelible, unalterable, and untamperable source of truth. Many other benefits associated with blockchain technology, such as, data integrity, security, and transparency are built upon this fundamental quality. The application of this technology to record financial transactions seems like a panacea — imagine a crowd-sourced golden record of all transactions of value between two or more participants that’s mutual, immutable, indisputable and permanent.

But, the reality is that financial transactions are not immutable. Why? 


In addition to instances where one party may simply intentionally or unintentionally default on a transaction, bankruptcies may create forced defaults on agreed-upon but pending transactions.  Once a party files for bankruptcy or is declared insolvent, a bankruptcy stay prevents most pending transaction from moving forward. Even previously settled transactions may be voidable as a result of bankruptcy and may be clawed back. We witnessed how devastating bankruptcy and default can be on the financial system when Lehman Brothers collapsed in 2008: the current financial system is not immutable.

The havoc created by a bankruptcy judge and the bankruptcy trustee in stopping, unwinding, or clawing back transactions on an immutable blockchain would be even more devastating.

What if We Could Make Financial Transactions Immutable?

Instead of questioning what happens when an immovable object meets an unstoppable force, what if blockchains and smart contracts were utilized to make transactions bankruptcy remote, using existing bankruptcy laws and safe harbor statutes to structure transactions in ways to protect them from bankruptcy that are not currently feasible or efficient with existing technology?

If this can be done, blockchain can in fact provide an immutable record of financial transactions, and financial transactions could benefit from all of the efficiencies of blockchain.

How? Committed Settlement.

A first step in this process towards true immutability is Committed Settlement, a smart contract method conceived by Digital Asset.

Committed Settlement enables users to replicate control accounts (accounts used for over a century to hold collateral pledged by a pledgor to protect the secured party against a default or bankruptcy of the pledgor), by locking digitized assets to a specific purpose. While control accounts are commonly used to shield pledged collateral from bankruptcy, they are slow (taking several months to set up), costly (thousands of dollars in maintenance fees), and inefficient (placing onerous reporting, reconciliation, and maintenance obligations on all of the parties involved).  

In contrast, by using Daml, an open source programming language created by Digital Asset, Committed Settlement could be accomplished by writing a few lines of code into a smart contract (the digital representation of a physical contract) between counterparties. By using smart contracts, Committed Settlement also utilizes the built in reporting and maintenance routines and avoids reconciliation burdens.

While there are additional steps from control accounts to true bankruptcy protection, this is a large and important first step towards the ability to use blockchain for immutable record-keeping of financial transactions.

To substantiate our patent-pending Committed Settlement methodology, we’ve collaborated with trusted law firms to analyze the local legal frameworks in a variety of jurisdictions.  The first of our collaborations is with King & Wood Mallesons, one of the world’s most innovative law firms. The following thought piece looks at whether Digital Asset’s implementation of Committed Settlement would work under the legal framework of Hong Kong and Australia.

Click here to read our thought piece with KWM, Committed Settlement in Hong Kong and Australia.

Charlie Yeh is an assistant general counsel at Digital Asset where he helps clients understand how distributed ledger and smart contract technology align with prevailing legal frameworks.  Previously Charlie served as legal counsel to JPMorgan’s prime custody, clearing and collateral management businesses. He helped JPMorgan reduce its trillion dollar intraday exposure to clearing repurchase agreements and establish segregated IM control accounts on behalf of it clients.

ACH Payments on Smart Contracts — A Daml & Dwolla Example

This is a guest post from Dimitri Liakakos. The original article was posted on Medium and is republished here with permission.
1_XlqlNKomDvMqxcILbGJtVw (1)

Smart contracts are great tools for storing value in digital form as well as defining the behavior of how that value can be transferred, split, locked or simply destroyed. However, describing smart contract state transitions without specifying who is allowed to perform them and when, is like playing a game of chess where each player can move any piece on the board regardless of their turn. In this regard Daml, the platform-agnostic smart contract programming language developed by Digital Asset, shines.

Daml provides a higher level abstraction of the business logic from the nitty-gritty details of the data persistence layer implementation, be it a relational database or a blockchain. Its smart contracts also offer fine-grained permissions that hide all of the public address and transaction signing cryptography (should there be any) under the concept of a Party, a primitive type of the Daml language.

In this post I’ll try to demonstrate how to use Daml and its permissions in order to transfer value between parties in the form of ACH Payments. For this we will use Drachma — a library of Daml modules with a Python app that wrap the powerful Dwolla APIs for interfacing with the ACH Network. To set the stage, let’s use a scenario similar to the one in Settling a Daml Payment Obligation on Ethereum.

This time, Alice is looking to mow the lawn of her freshly painted house. She gets an offer from (you guessed it..) Bob the Gardener in exchange for $59.99. Bob, being a Drachma user, can set up a Daml agreement with Alice and receive payment in the form of an ACH transfer that will deposit the funds directly to his savings bank account. Daml will handle all the workflow and permissions between the two parties and Dwolla will power the ACH transaction.

Bootstrapping Alice to the ledger

Alice would like to accept Bob’s offer but unfortunately is not a Drachma user yet. She decides to get onboard and asks the Drachma operator to extend her a UserInvitation. (In Drachma, the “operator” is a trusted third party responsible for on-boarding users and servicing their requests):

Alice accepting the Operator’s invitation

Now that Alice is a Drachma user and has a User role contract, she will need to register herself as a Dwolla personal verified customer and attach her checking bank account from which she will send the funds. To kick off the registration process she exercises the User_VerifiedCustomerRequest choice on her role contract and provides the necessary fields for the Dwolla API

Alice requesting from the Operator to become a verified customer

The operator forwards the request to Dwolla and a successful response leads to the creation of a personal verified customer resource for Alice as well as an equivalent Daml Customer contract for Alice.

Alice as a Dwolla personal verified customer

Adding Alice’s bank account

The next step for Alice is to attach her bank account as a Dwolla Customer funding source. To accomplish that, she will exercise the Customer_UnverifiedFundingSourceRequest choice on her Customer contract:

Alice requesting a new unverified funding source

The request is once again forwarded to Dwolla which creates a funding source resource for Alice and the corresponding Daml FundingSource contract.

Unverified Dwolla funding sources however may only receive funds. In order for Alice to be able to send funds, she will need to verify her bank account. Dwolla offers a number of options for verification of a funding source — among them is the Micro-deposit verification process.

In this workflow, Alice will instruct Dwolla through the operator to transfer two deposits of less than $0.10 to her bank account. After the two random amounts post, she can fetch them from her statement and use them to verify her account. Let’s see how this unfolds in Drachma:

Verifying Alice’s bank account

Alice navigates to her FundingSource contract and exercises the FundingSource_InitiateMicroDeposits choice. This initiates the two random micro deposits and creates a micro-deposits resource on Dwolla’s side and a MicroDeposits contract in Daml. According to Dwolla, it will take 1–2 business days until the status of the deposits changes from pending to processed.

Alice’s MicroDeposits contract

Thankfully we are on a sandboxed environment so we don’t have to wait! Alice’s micro deposits have already posted and she is ready to proceed with verification. She exercises the MicroDeposits_Verify choice on the MicroDeposits contract and passes the two amounts as arguments.

1_uIMIVQfPs5xL6eY3ModMug (1)
Alice verifying her checking account with micro-deposits

The amounts make their way to the Dwolla API and if they match the ones sent, the bank account gets verified! Alice is now a verified customer with a verified bank account and is ready to make a deal with Bob.

Bob makes an offer Alice can refuse

Daml does a heck of a job modeling a party’s rights and obligations. Therefore Alice can never get into an obligable position against her will.

Bob goes ahead and drafts a GardeningOffer contract. He becomes the signatory of that contract and offers Alice the choice to accept it or refuse it. In his offer, Bob mentions the amount of money he is to receive for his work, an id for the payment (should Alice accept it) and finally a list of his trusted Drachma operator parties that Alice can use for the ACH payment.

The GardeningOffer Daml template and mowTheLawn scenario

Notice that if Alice (the beneficiary) chooses the AcceptOffer happy path, a GardeningContract and a ReceiveFundsRequest contract will be created. The GardeningContract will be the official agreement between Alice and Bob and the ReceiveFundsRequest will be a contract addressed to Bob in order to receive payment.

Let’s take a closer look at the body of the AcceptOffer choice. It requires Alice to pass her Customer contract id as well as the id of her bank account that she just verified. Daml will fetch the Customer contract and assert that it belongs to Alice and that the operator is one that Bob also trusts. It will then create two Metadata records that will piggyback on the ACH payment and help identify it later. Finally it will exercise the Customer_SendFunds choice on behalf of Alice and create the GardeningContract agreement between the two parties.

It’s official. Per the GardeningContract Bob must mow Alice’s lawn and Alice must reimburse Bob with $59.99 in the form of an ACH transfer. Bob may start mowing, but he also needs to respond to the ReceiveFundsRequest and specify where he would like the funds to be deposited.

1_kud3y24qQrG4iW-NHLUQEg (1)
Bob accepting funds from Alice

For that he exercises the ReceiveFundsRequest_AcceptFunds choice and passes his bank account id and optionally any clearing instructions addressed to his bank. This creates a TransferAgreement that is validated by the operator and converted into a TransferRequest which once again hits the Dwolla API. The request will create a transfer resource in Dwolla’s side and a Transfer Daml contract containing the details of the ACH transfer.

Bob viewing the Transfer Daml contract

Settling the deal

Being a top professional, Bob has done an awesome job mowing Alice’s lawn. The ACH Network has also processed the fund transfer between Alice and Bob’s bank accounts. What is left is to settle the GardeningContract. Before we do that let’s take a look at it:

The GardeningContract Daml template

The contract is signed by both Alice and Bob (gardener and beneficiary are both signatories). Recall that neither party was forced into this obligation, as Bob created a GardeningOffer and Alice accepted. Daml would refuse to create this contract outright, should either Alice or Bob attempt it, since it would be missing the consent (signature) of the other party.

To settle it, Alice can exercise the SettleTransfer choice and pass the Transfer contract id as proof of payment. Daml will first assert that the contract has not already been settled and then fetch the details of the transfer in order to validate them against the contract terms. The sender, receiver, amount, status of transfer and invoice id are checked. Finally the contract is updated with a populated optAchId field containing the id of the ACH transfer.

Alice viewing the settled GardeningContract

Wrapping up

We have used the power of Daml and Dwolla to create a multi-party workflow that triggers an ACH transfer and settles an agreement. I would encourage you to further explore the Drachma GitHub project and submit any valuable feedback or contributions! I am leaving you with a snapshot of the final Daml ledger active contract set. Cheers!

The final Daml Active Contract Set

Release of Daml SDK v0.13.12

Daml Studio

  • Scenario links no longer disappear if the current file does not compile. The location is adjusted but this is done one a best effort basis and can fail if the scenario itself is modified.

Daml Compiler

  • Support reading of Daml-LF 1.5 again.

Ledger API

  • BREAKING: Drop support for legacy identifier. The previously deprecated field name in Identifier message is not supported anymore. Use module_name and entity_name instead.

Ledger API



Bringing decentralized identity to the enterprise with Daml and NuID

User trust is harder than ever to earn and even easier to lose. Data breaches are commonplace and user privacy is threatened as a result. 

How can we put the ownership of users’ digital identities back in their own hands and reduce the risks businesses currently face from centrally managing identities and authentication?

In this post I will outline how we are addressing this problem for the enterprise by integrating our trustless authentication solution, NuLogin, with Daml, the smart contract language created by Digital Asset that will run on multiple blockchain platforms and cloud-native databases.

The “shared secret” problem

Authentication today is stuck in the “shared secret” paradigm: users are forced to share their authentication secrets (usually passwords, secret questions, and other information) with the services they use, and those services, in turn, take on the responsibility and liability of keeping those secrets safe. Unfortunately, because password databases are a prime target for cybercriminals, those secrets often don’t stay secret for long.

In addition, there is no way to ensure that security best practices are being implemented in the right way by these services. Nearly 40% of breaches compromise passwords, and over 80% of attacks involve the use of stolen or weak credentials.

This centralized model of password storage also leads to a frustratingly fragmented user experience. With their identities locked in proprietary silos, users end up with dozens of login credentials and tend to make things easier for themselves by choosing easy-to-remember (weak) passwords, or storing them in easy to reach locations such as text files.

Trustless authentication and decentralized identity

At NuID, we are working to solve the shared secret problem by giving enterprises a way to authenticate their users without having to store their passwords, but critically, in a way that places ownership of digital identities with users. Moreover, we want to provide the authentication foundation for a broader identity framework in which user consent and privacy are at the core of our digital economy.

The NuLogin authentication service leverages zero knowledge cryptography to enable users to prove they know their authentication secret (such as a password or a token unlocked by mobile biometrics) without ever sharing it with anyone. By removing the need for users to trust enterprises or any 3rd party to secure their credentials, this “trustless” authentication protocol allows us to break down the siloed identity model.

NuLogin takes advantage of distributed ledger technology (DLT) to anchor the public zero-knowledge proofs derived from authentication secrets. DLT takes the place of centralized silos and eliminates the need for a central authority to store and manage users’ authentication data. This decentralized identity model opens up a whole world of user-centric processes and services such as efficient, reusable KYC or privacy-preserving e-commerce.

Our work with Digital Asset will be key to bringing decentralized identity and trustless authentication to the enterprise world.

Daml + NuID

Digital Asset helps enterprises leverage the power of DLT through a business logic-driven contract language, Daml, that abstracts the persistence layer allowing it to run on platforms such as R3’s Corda, Hyperledger Fabric and Sawtooth, VMware Blockchain and AWS Aurora.

As we began to model our processes with Daml, one of the biggest benefits we realized was that we could focus on writing our workflows without having to figure out the specifics of how the business logic of the use case interacts mechanically with the underlying distributed ledger. By avoiding the tinkering with persistence layer specifics, we are able to actualize a much cleaner architecture that pushes the DLT interaction to the Daml runtime. 

We look at Daml as the perfect tool for expressing our extensible zero knowledge model generically. Daml is like LLVM for smart contracts—a target-independent intermediate representation—and equally powerful in nature. We will be able to write and maintain NuID’s authentication data model once, in Daml, and target environments across the use-case spectrum.

To drive adoption of our service, one of our key goals is to make as few changes as possible to the enterprise and user experience. For example, in a typical single sign-on (SSO) workflow, a user registering through one service of an enterprise can leverage the same authentication for other services configured for SSO. Daml inherently allows us to define the parties that can view and access information on the ledger to achieve the cross-domain functionality of SSO. An authentication architecture like this allows us to achieve the same functionality of single sign-on between multiple Daml parties without the traditional prerequisites of coordination and trust between them.

Additional requirements for the NuLogin service to be enterprise-ready are auditability and traceability. We found that Daml provides this capability at both the logical (language) and physical (immutable DLT) layers to our clients. By specifying parties who can be signatories, participants, or observers on Daml contracts, our clients can easily meet their audit requirements without having to engage in expensive and time-consuming customizations for storage and reporting.

Finally, technology change management is a significant factor that influences and often slows down enterprise adoption of new technology. Adopting Daml enables NuLogin to be very flexible when it comes to aligning with the existing technology infrastructures of our clients. The new Daml deployment options coming up with VMware, Hyperledger Sawtooth, R3 Corda, Hyperledger Fabric, and even Amazon Aurora, will allow our service to fully respect and integrate with our client’s underlying technology choices. 

These enterprise-focused design decisions made Daml an ideal tool for NuID to extend its reach into industries such as financial services, healthcare, manufacturing, and retail. 

Forging ahead 

As part of this integration, NuID will release open source Clojure bindings to Daml libraries that will make producing Daml-enabled Clojure applications more convenient. This will allow for seamless interoperability between NuID’s service, Daml’s platform, and user-facing applications.

The synergies between Digital Asset and NuID are best summed up in DA’s first intro series blog post: “Digital Asset’s vision is for value transfer to be simple, efficient and secure, driven by a new distributed ledger paradigm that unleashes web-pace innovation unrestrained by data silos.”  

NuLogin’s integration with Daml will extend that silo-wrecking mission to digital identity. 

Ibrahim Pataudi – VP Business Development at NuID

About NuID

NuID is a pioneer in trustless authentication and decentralized digital identity. The NuID platform leverages zero-knowledge cryptography and blockchain technology to eliminate the need for businesses to store passwords and other authentication credentials. NuID’s unified protocol for strong authentication supports passwords, tokens, and biometrics—enabling businesses to reduce security risks and streamline user experience. Our mission is to end mass credential breaches by returning data ownership to the individual.