What is Daml's transaction execution model?

I can’t find any useful info about how DAML architecture support smart-contracts.
For example on fabric chain code is executed on few peers (depend on endorsement policy), and if all validation are successful(on every peer) the transaction can be written to ledger (in very big simplification). But how is this achieved using DAML drivers? Or maybe it is not at all?

I found similar topic here -Transaction validity model on HLF
But if above is true (maybe i misunderstand it) it would mean that DAML doesn’t support smart-contracts at all.

1 Like

Hi Michal,

You can look at these two links to find out more about the underlying architectures we support.

A daml ‘driver’ is what abstracts away the underlying ledger/blockchain, so the underlying implementation will vary. Here are some examples:


And for some more detail on the abstraction model:


I know this documents, but I still can’t understand how to use it in different blockchains through drivers.

  1. The first way that it could be achieved that come to my head is that daml .dar files are transpiled to for example chaincode then install it in infrastructure node and then this chaincode get executed.

  2. The second way is that every infrastructure node(HLF) has to have its own participant node(daml). But this solution to be adopted to existing infrastructure would need to install a participant node for each existing infrastructure node.

1 Like

I think one of my colleagues will be able to elaborate on this, but basically it’s the second case you’ve outlined.

The link you included in your original post gives evidence to that fact, so e.g. when you look at the underlying Fabric node, DAML contracts are serialized as a binary strings; it’s an encoding of DAML-LF, our low level ‘bytecode’ for lack of a better analogy.

But this solution to be adopted to existing infrastructure would need to install a participant node for each existing infrastructure node.

I can’t really speak to this - let’s see if someone else can shed some light on this.


Hi @Michal_Konopka, the second option that you outlined is what we use in our drivers, each Fabric node also has the Daml Ledger API server (and a few other components) deployed alongside it.

To go a bit more in depth, there are a few different architectures for Daml Drivers, depending on the underlying ledgers and their properties. For Fabric we have two different architectures.

The first one is very roughly:

Where the Fabric peer node has a custom chaincode deployed which is part of the Daml Driver for Fabric. It’s essential that we deploy the Ledger API Server alongside each node for a few reasons. One of them is local validation of all Daml logic, another one is to ensure that all Daml ledgers have a unified Daml API so users can port and/or migrate applications from one ledger to another (a bit more background on this here and here)

The second architecture is based on https://www.canton.io/ and is a two-layer network. In that architecture there are two types of nodes: a domain node and a participant node. The domain node can be thought of as the first layer (L1) and includes the Fabric node and a Daml Driver for Fabric, and the L2 contains the Ledger API server.

So to summarize, Daml itself is a smart contract language but it doesn’t transpile to Chaincode (in theory we could do that but it would have many limitations). Conceptually we do something similar to Fabric but instead of validating the smart contract directly in chaincode, we deploy a chaincode onto the Fabric peer which communicates over an RPC with a local Daml engine which runs the validation.

Hope this helps


Hi Shaul,
Thank you for your response.
For now, I would like to focus on the first example.

  • If I understand correctly only nodes which want to participate in DAML application have to use DAML ledger nodes. Other nodes may still participate in chain-code based smart-contrancts?
  • Is this correct? Or rather what is incorrect.

    Editable link

I’m really glad that you are here guys :slight_smile:

PS I found another project: GitHub - hyperledger/fabric-chaincode-evm, which in my understood works similar as DAML on fabric.


Yes, that’s correct.

From the Fabric network’s perspective the Daml ledger is just another Chaincode running on the ledger, and only those who want to participate in the Daml ledger need to run Daml ledger nodes.

An interesting way to think of it is:

  • From the perspective of a Daml application, it is communicating with a Daml ledger and the fact that there’s a Fabric network storing and coordinating data behind the scenes is just an implementation detail
  • From the perspective of a Fabric network participant, the Daml legder is just another smart contract running on the network, and the Daml ledger is embedded in the network’s data

I’ll mention one more thing, while my last answer implies no application level connection between Daml and other Chaincodes running on the network, it’s simple enough to build a bridge between the two - for an example on Ethereum see GitHub - liakakos/hemera: DAML library for integration with Ethereum (driven using DAML's Java bindings, web3j, ethereumj and Infura) which allows for application level interaction between ERC20 tokens on the native Solidity ledgder and ERC20 on the Daml ledger