 Hello, my name is Alex Putkov. I'm a developer advocate at Digital Asset, leading provider of enterprise distributed ledger technology, a company that's changing how businesses and markets interact. Today I'm going to talk about how to build a global economic network for Web3 by enabling composable applications. Building composable applications is a key requirement for any ecosystem to thrive and grow organically. Do smart contracts and blockchains have a role to play in building composable applications and architecture to form the building blocks of the next generation of global economic network where transactions and assets flow seamlessly across organizational and national boundaries? In this presentation, you'll see real-world examples of how this is happening today with DEML, Digital Asset's core technology that is used by numerous institutions, including Goldman Sachs, that's utilizing DEML to develop its end-to-end asset tokenization infrastructure. Hong Kong is changed. That's using DEML to build the next generation security settlement platform connecting Hong Kong and Western markets to mainland China. Expensive, the global marketplace for transacting data-driven commodity products that recently got a $400 million investment from Blackstone and that is creating the ESG or environmental social and governance-inclusive commodities markets of the future with DEML. Composability has numerous facets. For most people, when they hear the word composability, they think modularity, the architecture that consists of reusable building blocks. The concept of modular software dates back to the dawn of the software era. It's always been there. Today, it can be applied to applications which historically involved from monoliths, the services, to microservices. Open Source has been a great facilitator of modularity encouraging developers to work on shared projects which are then used by many more developers as building blocks for their projects. It can be applied to infrastructure which evolved from centralized client server architecture in the 80s and 90s to distributed application server in 0s and 10s to decentralized serverless and containers architecture in the 10s and 20s, and which is now heading towards adding virtual shared system of record based on DLT. When the modular architecture gives rise to new applications that doesn't require a foundation to be upgraded or changed, then we have a truly composable architecture. Gartner published a white paper where they introduced the term packaged business capabilities. Their research suggests that the winning organizations of the future will be the ones that are organized around producing packaged business capabilities, which can be composed to create desired business outcomes. What would allow these packaged business capabilities to be composable? Since businesses cannot live in isolation, the whole economy is a complex interaction of countless business entities. The composability of packaged business capabilities requires architecture that can support multi-party applications. The next evolution of composability is making applications multi-party ready and extensible. Multi-party applications are apps that require sharing data across organizational boundaries. An example is any app that facilitates B2B financial transactions. The current stock of multi-party apps is typically built as bespoke workflows with various entities having different data models and their own silos for their system of records. This results in massive reconciliation problem between organizations. There's also the competing issues of trust, transparency, privacy, and scalability or throughput to deal with when building or operating such systems. For single-party composable applications, microservices is the choice of technology today. The microservices architecture on a public network is optimized for composable and distributed reading. It works great for apps that need to read data from multiple sources. Microservices architecture is, unfortunately, not optimized for composable and distributed writing. For apps that need to write and share data across organizational boundaries, microservices architecture is of little help. The requirement to share data across organizational boundaries raises the issues of trust and privacy, neither of which is addressed by microservices architecture. Today, applications that facilitate workflows spanning multiple organizations are typically built on some sort of messaging infrastructure. Each party maintains its own records of transaction and state. These records are synchronized using some kind of messaging scheme. Since this approach is inherently not fail-safe, it results in disputes between the parties and necessitates expensive reconciliation of mismatched records. According to a Pricewaterhouse-Cooper's report from 2017, 25% of a typical finance team's time is spent on non-value-add reconciliation activities. And this number is much higher for industries with large back office operations such as financial services. For instance, Broderage estimates that 30% to 40% of total back office labor costs is spent on reconciliation. There are further challenges with messaging-based synchronization. It's hard to maintain atomicity of transaction, which is essential for DVP or delivery versus payment workflows. This leads to increased counterparty business risks that are expensive to mitigate. Many of the problems I mentioned could be addressed if there was a single source of truth between organizations, thus eliminating the need for reconciliation. However, having a centralized storage of business transaction records is not a realistic option in most cases. This is not a technical or technological challenge. It's a challenge of decentralized markets, which in most cases cannot be centralized. This is where distributed ledger technologies hold promise in addressing the significant issue of multiparty workflows trust and reconciliation of records. Blockchains allow for decentralized and trustless interactions. Using applications running on decentralized and synchronized ledger, organizations can stay in sync with each other without having to maintain individual silos or a single centralized data store. There are numerous challenges which have been affecting the enterprise adoption of DLT. The one that we don't think has been sufficiently addressed yet is data security and privacy, which means that only the part is required to see the data, should be able to see it. In countless business workflows, a mission critical requirement is to distribute data on a strict need-to-know basis. Consider, for example, a very simple financial transaction where a seller sells to the buyer 100 shares affecting me. The settlement of this transaction requires the transfer of ownership of stocks from the seller to the buyer, and the cash transfer from the buyer to the seller. Apart from the buyer and the seller that are privy to all the details of this transaction, other parties involved in the settlement are, at the very minimum, the securities depository and a bank. In this business transaction, the share and the cash transfers should be processed atomically so that the entire transaction could either succeed as a whole or fail as a whole. The state where the shares have been transferred and the cash hasn't or vice versa should never be possible. In other words, this operation should be committed to the ledger as a single transaction. However, the bank should only be able to see that the buyer transfers to the seller $12,000, and the depository should only know that the seller transfers to the buyer 100 shares affecting me. The depository in the bank should not be privy to any other details of this business transaction. This example illustrates the need to have privacy enabled on a sub-transaction level. A system where all transaction details are revealed to all parties in the transaction cannot facilitate this essential business workflow. This is also a hugely simplified example. In real world, there are many more parties representing layers and layers of intermediaries involved in such a transaction. And unless privacy is built into the core semantics of the system, ensuring the correct functioning of privacy restrictions in such a system is incredibly difficult, I'd say, bordering on impossible. Once the issue of privacy is addressed, DLT has enormous potential for multi-party applications as it provides the single source of truth in a trustless environment, eliminating the need for reconciliation. Now, what about building composable applications and workflows on such an infrastructure? What are the requirements that we need to consider for enabling composable workflows for multi-party business applications? The primary requirements for composability are the ability to share data across organizational boundaries, preserve privacy and authorization rules, maintain trusted immutable ledger of records so that the history of committed transactions is preserved to avoid any conflicts or disagreements when multiple parties are engaged in business, and applications that can interact with the ledger and build on each other's capabilities without upgrading or re-architecting the underlying layers. We can accomplish this by introducing the concept of networks of participants nodes and domains that constitute the network and smart contracts that implement the business logic of transactions between the parties. This is where technology such as Damol and Canton can play a leading role. Damol is a programming language for building smart contract applications focused on business transactions workflows, and Canton is a privacy-enabled distributed ledger protocol for distributing data, trust, and execution order that can operate independently or with blockchains. Using Damol and Canton, you can build multi-party back-end Damol applications running with different storages. You can create front-end applications for each participant integrated with participants other applications and systems. Adding new applications and participants makes the applications composable. Adding new Canton domains makes the network composable. Now let's look a little closer at Damol and Canton. Damol is an open-source, domain-specific programming language which is purposely built to create and operate smart contracts. It's a functional programming language which bodes well for implementing atomic transactions that facilitate workflows like DVP or delivery versus payment and PVP payment versus payment. It's based on Haskell, which is a tried and tested functional programming language that's been around for decades. Damol adds primitives that define and enforce the schema, semantics, and execution of transactions between parties. It allows to codify programmatically enforced contractual rights and obligations between parties. Damol privacy model, which extends to the sub-transaction level on the ledger, mathematically guarantees that parties are only private to the date on the ledger that has been shared with them. For every smart contract on the ledger, Damol calculates the precise list of parties allowed to view this contract. Canton is a Damol ledger interoperability and synchronization protocol. Different Damol-based ledger instances can interoperate using the Canton synchronization protocol. They can be merged and transformed. Never is can afford or locking, as they're always part of one virtual global ledger. Digital assets and workflows can flow freely between the ledgers. And Canton synchronization protocol ensures that the ledger is always in a valid state. And corrupted state never occurs even in the presence of malicious actors. Canton is built around the principle of data minimization and the right to forget. As a result, Canton is always GDPR compliant. Canton has no upper bound on how many transactions per second it can process. It can be scaled to achieve any transaction process in speed. And Canton's topology can be extended without friction with new parties, ledgers, and applications, building on other applications without requiring a central managing entity or global consensus within the network. In Canton, parties can create or participate distributed workflows written in demo. A party can be a legal entity, a physical person, or just one of many accounts for a person or an entity. Parties register with one or more participant nodes. And nodes can host multiple parties and facilitate party access to the ledger. Every node can connect through Canton to multiple demo ledgers. And each demo ledger instance is called a domain in Canton. A domain can be implemented in different ways, depending on the trust requirements. For low trust requirements, it can be implemented on a distributed ledger or on enclaves. Or it can be implemented in a centralized way if a trusted operator exists. All transactions data transferred between participant nodes is end-to-end encrypted and only selectively shared with other participant nodes on a strict need-to-node basis. The domains do not learn the transaction's content. And also, Canton guarantees the integrity of ledgers even in the presence of malicious participants. Furthermore, any party can extend the ledger at any time without adversely impacting others. Participant nodes can at any point choose to connect to multiple domains and transfer workflows between those domains. Therefore, domains do not impose hard boundaries. And participant nodes effectively participate in a virtual global ledger, which is composed of all existing domains. The virtual global ledger is the underlying concept. It doesn't exist physically, but it is the result of the Canton synchronization protocol that provides the integrity, privacy, auditability, and transparency guarantees. Demo and Canton digital assets core technologies enable the interface across networks. They provide a platform for building multiparty applications that can run seamlessly across infrastructures with different trust properties, backed by databases, private or public blockchains. It is the first system to fulfill the key requirement of a network of networks for transfer of value in global commerce, which leads to our vision, the global economic network of seamlessly interconnected businesses. Sounds too good to be true? Well, our vision is not a pie in the sky. It is happening today. One example of the evolution in composable applications for global economic network is the Australian stock exchange and their newest DLT as a service platform, Symphony. Modern exchange operators position themselves as infrastructure providers for financial markets. ASX is replacing its aging system known as chess, which provides clearing and settlement for the entire Australian exchange traded securities market with a new system built with Demo. While this alone will hugely improve the efficiency of ASX operations, with Symphony platform built on Demo, ASX achieved a foray into numerous potential new lines of business that are not available to any other exchange operator in the world today. Other vendors can develop customized and composable applications that run on Symphony, offering service to other participants and parties who are part of this network. For example, KPMG is using Symphony to help create and operate new South Wales government's building assurance solution that provides a trustworthy index for buildings based on the source and the quality of materials and contractors used in its construction. This will enable interested parties to distinguish between compliant resilient buildings and non-compliant problematic buildings. Other solutions being built on Symphony include an application that automates off-market transfers in the equities market by Broadridge, an ownership register for private companies by Boulevard, and Drawbridge, a RageTech application that helps companies reduce employee and directors securities trading risks by automating the approval process developed by DigitalX. This allows us to take a glimpse into the future. Digital asset were delivering value today by providing virtual shared system of record that eliminate the needs, eliminate core problems caused by data and process silos, and allow creating multi-party applications where parties can rely on a single source of truth for business transaction records where sensitive data is distributed on a strict need-to-know basis. And our vision for the future is a global economic network of seamlessly interconnected businesses, a network that not only builds economic value, but it also enables it to flow freely, securely, and with strict privacy across interconnected systems. Thank you very much for your attention. I encourage you to visit our booth upstairs. I'll be up there and my colleagues as well. So come and talk to us. Thank you.