Click here to expand a Glossary of Key Contract Terms
Active Contract Set (ACS)
— The current set of Active Contracts for a party or parties hosted on a Node. This excludes contracts that have been archived.
— Authentication is the process of confirming an identity.
— Authorisation is the process of checking permissions to access a resource.
— An available action on an active DAML contract.
— A command is the exercise of a choice on the Participant’s Master Contract. For example, a command to open an account at CSP.
— DAML contracts encode the rights, obligations and choices of the parties and the choices on the CSP that they can exercise.
— A DAML library is a collection of DAML contract templates. DAML contracts encode the rights of the parties as choices that they can exercise.
— A party is an entity that has rights and obligations under DAML contracts.
Each node is authorised to act on behalf of one or more DAML parties, therefore it is possible to have a single node with multiple DAML parties, which may be required when a parent organisation requires access for their related entities.
DAML Software Development Kit (SDK)
— Comprises of components that allow developers to create DAML Libraries and ledger user applications to submit DAML commands to exercise Choices and listen to ledger events.
— An event occurs as the result of the creation of a DAML contract or as a result of a contract being exercised (which may result in a contract being archived).
Exercising a Choice
— The act of selecting one of the available actions on an Active Contract. A Choice can be consuming or non-consuming, as defined by the DAML model describing the contract. When a consuming Choice is made the original contract becomes archived and no further Choices are possible (i.e. cannot double spend). When a non-consuming Choice is made it is still possible to make additional Choices on the same original contract.
— An API that allows user applications to submit DAML commands that exercise Choices on entitled DAML contracts and listen to entitled DAML contract events from the ledger event stream in near real time.
Ledger API Integration
— Ledger API is a new model of connectivity where users transact directly with the ledger via the DA Ledger API. This allows the user to take advantage of the mutualisation of data and workflow between authorised parties whilst retaining data privacy and integrity.
— An instance of the DA Platform software authorised to join a network of other nodes to form a distributed ledger. A node supports the Ledger API which allows user applications to access the ledger.
Private Contract Store (PCS)
— Each node in the network will have its own privately segregated PCS, which contains all contracts to which the user is a party.
— A token (or access token) is a tamper-proof piece of data that contains security information, such as the user identity or its privileges.
— A token issuer is a service that generates tokens. Also known as “authentication server” or “Identity and Access Management (IAM) system”.
Developers using the Ledger API Contracts should be aware that published API Contracts may change as part of subsequent CDE releases.
At its core, the CSP consists of a distributed ledger, which is analogous to a database. The distributed ledger acts as a repository of data stored in the CSP sub-register. DAML based contract workflows are used to communicate and transact with the CSP. The results of such transactions are stored as DAML contracts on the CHESS Replacement distributed ledger.
DAML contracts encode the rights, obligations and choices of the parties and the choices on the CSP that they can exercise. They represent an agreement between multiple parties, but unlike a traditional contract, DAML contracts also contain the application code to execute behaviour based on the terms of the contract. For more detailed information about DAML Contracts, refer to the DAML SDK.
ASX supports multiple methods of communication with the ledger. The method of communication does not change the behaviour of the CSP, which triggers business workflows resulting in the creation of contracts on the ledger. These contracts contain the data related to the completed transaction and is analogous to a row in a database table. For further information on the methods of communicating with the CSP, refer to the Connectivity section.
For example, submitting a schema valid Account Creation Request (acct_001) ingress message results in the creation of an Account (HIN), an Account contract and one or more Holder contracts on the ledger for each account holder referenced on the message and subsequently responds with an Account Notification (acct_002) egress message. This process is identical for Ledger API connectivity with the exception of the usage of a DAML command requesting account creation. Participants can view newly created Account and Holder contracts by inspecting the ledger event stream. For further information on the Account and Holder Creation process, refer to the Account and Holder Creation Overview.
A choice is an available action on an active DAML contract. Similar to a method call in a programming language, a choice accepts parameters, which allow additional terms to be specified in the executed behaviour.
Given, this contract
I, the controller, of it
Choose, to exercise some behaviour on it
Exercising a Choice
To update an active DAML contract on the ledger, a party must exercise an ingress choice on the ingress master contract. This results in the existing contract being archived and a new contract being created. Since all exercised choices are recorded as events, the ledger maintains a complete and auditable history of all the changes that have led to the current Active Contract Set.
An event occurs as the result of the creation of a DAML contract or as a result of a contract being exercised (which may result in a contract being archived). When a choice is exercised, the choice and metadata such as the exercising time and exercising party, as well as the choice parameters, are recorded in the resultant event on the ledger.
primary DAML Contract Types exist within the CSP. These include:
- Master Contracts
A Master Contract is an instance of DAML contract that allows users to exercise a choice at the CSP. It is unique and specific to the participant and sets out all the choices that can be exercised on the ledger.
Master Ingress Contract
The Master Ingress Contract is a non-consuming DAML contract that allows CHESS Users to issue a command to the CSP to start the associated workflow.
Each DAML party in the system is permissioned to execute specific commands and business workflows as set out in the party’s master ingress contract. Each command, is a combination of choice with a parameter, which when exercised, sends an instruction to the CSP. A party can initiate a workflow by exercising a choice on the master ingress contract, which triggers a piece of code, representing a workflow, and results in one or more contracts being created or archived on the ledger.
An example master ingress contract for a participant is illustrated below. For further information refer to Identify the Master Ingress Contract.
Each choice on the master ingress contract maps to a specific ISO20022 message and takes the message payload as a parameter. This ensures parity between messages and commands sent to the CSP via Messaging or Ledger API access modes.
Master Egress Contract
The master egress contract is a mirror of the master ingress contract. It specifies the egress choices that the Operator (ASX) can exercise in response to an ingress choice made by a DAML party.
As is the case with the ingress master contract, each choice on the master egress contract maps to a specific ISO20022 egress message and takes the message payload as a parameter.
API Contracts expose permitted contract details to contract parties based on their access privileges. This information represents the current state of the ledger and is available to I connectivity participants.
Participants can access active API Contracts via the and obtain real-time updates to fact contracts via the Transaction Service. Those permitted to access API Contract information are known as .
For further information on API Contracts, refer to the below pages:
Public Contracts are a result of the creation, modification, or deletion of Securities, Corporate Action data, Issuers, and certain types of Reference Data. They are API Contracts with a 'public' party associated to them, allowing the disclosure of information to all appropriately permisssioned market participants.
Public Parties are observers created and on-boarded by ASX that have permission to access active public contracts available to all ledger API users such as Calendars, Securities and Issuers. Both ASX and CHESS Users can connect to the Ledger as the public Party to access active public contracts. Refer to Reference Data API Contracts for further information.