Key Points

1. service life cycle: definitions, design, plans, delivery, manage, operate, govern, support, maintain
2. service consumption life cycle for a consumer:  key questions, assumptions on consumer service capabilities
3. services have flexible mapping to containers and platforms
4. services are accessed from a service registry ( broker ) that provides meta management of services and governance by id, name etc
5. clients connect to a service through the broker and bind to the service with a configuration
6. clients connect with an identity that maps to a role and set of authorizations and receive a JWT for the client session
7. a good service broker can work with multiple service types ( API, data, message, http, ftp etc )

References

Key Concepts

G4 Pattern Summary

https://springframework.guru/gang-of-four-design-patterns/

Creational Design Patterns

• Abstract Factory. Allows the creation of objects without specifying their concrete type.
• Builder. Uses to create complex objects.
• Factory Method. Creates objects without specifying the exact class to create.
• Prototype. Creates a new object from an existing object.
• Singleton. Ensures only one instance of an object is created.

Structural Design Patterns

• Adapter. Allows for two incompatible classes to work together by wrapping an interface around one of the existing classes.
• Bridge. Decouples an abstraction so two classes can vary independently.
• Composite. Takes a group of objects into a single object.
• Decorator. Allows for an object’s behavior to be extended dynamically at run time.
• Facade. Provides a simple interface to a more complex underlying object.
• Flyweight. Reduces the cost of complex object models.
• Proxy. Provides a placeholder interface to an underlying object to control access, reduce cost, or reduce complexity.

Behavior Design Patterns

• Chain of Responsibility. Delegates commands to a chain of processing objects.
• Command. Creates objects which encapsulate actions and parameters.
• Interpreter. Implements a specialized language.
• Iterator. Accesses the elements of an object sequentially without exposing its underlying representation.
• Mediator. Allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
• Memento. Provides the ability to restore an object to its previous state.
• Observer. Is a publish/subscribe pattern which allows a number of observer objects to see an event.
• State. Allows an object to alter its behavior when its internal state changes.
• Strategy. Allows one of a family of algorithms to be selected on-the-fly at run-time.
• Template Method. Defines the skeleton of an algorithm as an abstract class, allowing its sub-classes to provide concrete behavior.
• Visitor. Separates an algorithm from an object structure by moving the hierarchy of methods into one object.

Microservices.io Pattern repository

https://microservices.io/patterns/index.html

text starts here

Microservices Application Pattern

Please see the example applications developed by Chris Richardson. These examples on Github illustrate various aspects of the microservice architecture.

for more see this link

Services Patterns SDP#MicroservicesApplicationPattern

Capability patterns for Microservices

There are many patterns related to the microservices pattern. The Monolithic architecture is an alternative to the microservice architecture. The other patterns address issues that you will encounter when applying the microservice architecture.

• Decomposition patterns
  • Decompose by business capability
  • Decompose by subdomain
• The Database per Service pattern describes how each service has its own database in order to ensure loose coupling.
• The API Gateway pattern defines how clients access the services in a microservice architecture.
• The Client-side Discovery and Server-side Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture.
• The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate.
• The Single Service per Host and Multiple Services per Host patterns are two different deployment strategies.
• Cross-cutting concerns patterns: Microservice chassis pattern and Externalized configuration
• Testing patterns: Service Component Test and Service Integration Contract Test
• Circuit Breaker
• Access Token
• Observability patterns:
  • Log aggregation
  • Application metrics
  • Audit logging
  • Distributed tracing
  • Exception tracking
  • Health check API
  • Log deployments and changes
• UI patterns:
  • Server-side page fragment composition
  • Client-side UI composition

Orchestration vs Choreography: 2 approaches to coordinate parties actions based on governing policies and rules

Given a set of policies and rules that members in a community are governed by, orchestration and choreography provide 2 different methods manage that governance.

Challenge is identifying the best governance model for a specific use case based on a variety of factors including the capabilities of members and the maturity of governance

Orchestration - a central party coordinates the actions of the members enforcing the governing rules and policies

An orchestra with a conductor

Choreography - the members use governance services to coordinate the actions of the members enforcing the governing rules and policies

An orchestra without a conductor following a governance rule set

Microservice Orchestration vs Choreography

https://www.softobiz.com/microservice-orchestration-vs-choreography/

Microservice Orchestration Vs Choreography-softobiz.com.pdf

How to stitch these service modules together?

Orchestration = central controller

In an orchestra, we have a central man called the “orchestrator”. Therefore, he is responsible for invoking all the sounds.

Orchestration Benefits

Easy to maintain and manage as we unify the business process at the center.
In synchronous processing, the flow of the application coordinates efficiently.

Limitations

Creating dependency due to coupled services. For example, if service A is down, service B will never be called.
The orchestrator has the sole responsibility. If it goes down, the processing stops and the application fails.
We lose visibility since we are not tracking business process.

Microservice Choreography

It is the other way to achieve microservice interaction.

We want to avoid dependencies in a microservice architecture. So, that each service can work independently. Choreography solves this issue which was the main challenge in orchestration approach.

You can imagine Microservice Choreography as a belle dance (as shown in the above picture). In it, every individual performs steps independently.

Similarly, in microservice Choreography, every microservice performs their actions independently. It does not require any instructions. It is like the decentralized way of broadcasting data known as events. The services which are interested in those events, will use it and perform actions. This is also known as reactive architecture. The services know what to react to, and how-to, which is more like an asynchronous approach.

Benefits

Enables fast processing. As no dependency on the central controller.
Easy to add and update. The services can be removed or added anytime from the event stream.
As the control is distributed, there is no single point failure.
Works well with the agile delivery model, as teams work on certain services rather than on entire application.
Several patterns can be used. For example, Event sourcing, where events are stored, and it enables event replay. Command-query responsibility segregation (CQRS) can separate read and write activities.

Limitations

Complexity is the concerning issue. Each service is independent to identify the logic and react based on the logic provided from the event stream.
The Business process is spread out, making it difficult to maintain and manage the overall process.
Mindset change is a must in the asynchronous approach.

Most of the times, these approaches don’t work well in architecture. So, what is the solution in these use cases?

Hybrid

That is to say, the hybrid approach can solve the problem. For example, if we have a mix of synchronous and asynchronous blocks of activity. So consequently, one or more hybrid pattern can add value to the projects.

Hybrid is the combination of the orchestration approach and choreography. In this approach, we use orchestration within the services whereas we use choreography in between the services.

A Hybrid approach like others is two-edged. Let’s discuss:

Benefits

• The Overall flow is distributed. Each service contains its flow logic.
• Services are decoupled (but to an extent).

Limitations

• The coordinator is coupled with the services.
• If the coordinator goes down, it impacts the entire system.

RDD - Responsibility Driven Design - Wirfs-Brock

Why RDD?

more flexible than reactive services design

doesn't force everything to an API service model - just what should be an API vs a service vs a library vs a function

more natural way to find events produced and consumed by starting with business or client use cases

provides an easier way for business users to drive requirements specifications using natural language ( vs powerpoint logic )

Reactive Microservices based on event listeners

https://sites.google.com/a/mammatustech.com/mammatusmain/reactive-microservices

event maps, event storming in the context of microservices

effective really for software engineers but not so much for others

Interoperable Blockchain ACID transaction pattern

Simple Crypto Payment Transaction Model - Bitcoin or Ethereum basics

https://crypto.com/university/how-does-bitcoin-work

https://crypto.com/university/how-do-bitcoin-transactions-work

payments-crypto.com-How Do Bitcoin Transactions Work.pdf link

payments-crypto.com-How Do Bitcoin Transactions Work.pdf file

https://ethereum.org/en/developers/docs/transactions/

The logic below ignores the Bitcoin POW process in favor of the Ethereum POS process

new coins are mined, they are minted ( or issued ) for example.

A simple example sending a payment from Bob to Alice on a crypto POS platform

Alice wants to send Bob a payment

Alice's wallet contains tokens that exceed the amount she wants to send Bob

Bob and Alice both have Bitcoin wallets

Wallets are files that provide access to multiple bitcoin addresses.

Each address can hold multiple tokens ( Bitcoin, Ether etc )

When Alice creates a new address, what he’s really doing is generating a ‘cryptographic key pair’, composed of a private key (which only you know) and a public key (which is known to anyone). If you sign a message with a private key, it can be verified by using the matching public key. Alice's new bitcoin address represents a unique public key, and the corresponding private key is stored in his wallet. The public key allows anyone to verify that a message signed with the private key is valid.

The process to send payment from Alice to Bob on a crypto POS platform

Bob creates a new wallet address for Alice to send her payment ( in crypto coins )

Alice initiates a transfer of crypto to Bob's wallet address that calls a smart contract method

Alice wallet signs the transaction

The transactions is

validated by validator nodes

hashed and ordered in a block

committed to the ledger nodes

blockchain interoperability on atomic transactions using escrow transactions for DvP

context

assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )

blockchains implement escrow transaction interface services in a smart contract

2 independent chains A and B can send messages using a common protocol ( gRPC or ??? )

party A wants to buy X from party B for Y currency amount

problems

how to ensure only authorized parties participate in the transactions for settlement of a trade agreement

how to ensure both parties will execute their transaction once and only once to complete the purchase transaction

how to ensure that the purchase is cancelled if either party fails to complete their part of the purchase transaction within the designated time limit

how to prevent either party from failing to deliver or accept delivery of assets or funds per the terms of the trade agreement

pre-requisites

network connectivity and interoperability across all related networks

blockchain directory services and access

identity, registration and access management services for all parties in a transaction

each party implements the escrow transaction interfaces as buyer, seller and their agents

each party communicates using one of the supported protocols: gRPC or REST api or ?

each party digital certificates to sign and execute transactions identifying the authorized party

gateway nodes connect 2 different logical blockchain networks directly or indirectly ( blockchain networks normally not physical but virtual overlay networks across multiple provider networks )

solution

use an escrow transaction with smart contracts that

records each parties performance of the obligation

This follows a saga pattern to implement the escrow transaction (eg a purchase ) as a set of linked transactions in smart contracts

Singe Use Tokens are used to guarantee that only this single reservation transaction can be executed once by the designated party

step 0 - party A agrees to buy X from party B for Y currency amount agreeing to a set of policies to execute the transaction for the buyer and the seller roles

step 1 - reservation for payment from A to B with a token,  reservation for delivery from B to A with a token

step 2 - when both reservations complete, the reservations are executable as smart contracts by each party

each party executes their reservation transaction via smart contract using the supplied single use token created for just this transaction

A executes B's reservation using the token from B

B executes A's reservation using the token from A

alternate scenarios

both reservations are not completed within the agreed time limit, all reservations and tokens are cancelled and resources revert to current owner control

the purchase policy agreed to may include automated contracts to execute actions to reverse one or both reservation executions or cancel the reservations updating the blockchain

step 3 - if both reservations are not executed as transactions within an agreed time limit, each party is notified to manage the purchase based on agreed policy

step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transaction

step 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )

issues with simple saga pattern above - why escrow manager adds value

IF the trade settlement is executed simple on 1 network, real-time using a synchronous model it may work well using simple HTLC 

AND both parties fulfill all their obligations to deliver and accept delivery of assets and funds

OTHERWISE 1 or both parties may fail to deliver or accept delivery of the assets or funds for settlement after the trade agreement is set

P2P Escrow Transaction Pattern

goals

1. 2 parties complete an atomic swap of asset 1 for asset 2 without risk
2. if swap can't meet completion criteria, swap transaction is reversed for all parties returning initial states for each
3. optionally, a 3rd party notary service may need to approve the transaction
4. optionally, a 3rd party observer service may record the transaction
5. optionally, the 2 parties may be on different networks

model

a cross chain atomic swap can be managed at the API level or the chain level if the chains are interoperable

a chain manager ( on a chain ) for other chain transactions ?? ( or a configurable chain model ? )

specific validators only for that transaction type and parties are active

1. multi-party contract with roles where config defines terms of the swap
2. each party is identified and claims a role ( eg buyer, seller etc )
3. define multi-step transaction types
4. create transaction instance using the shared transaction manager with workflow from the contract config for that transaction type
5. each transaction has a unique ID
6. set the parties who validate the transaction on each ledger
7. contract takes control over both assets from each party using locks and confirms locks ( if funds or asset limited, policy may allow partial transactions )
   1. obligation set for each asset in the contract locking a portion of the assets for a time period
   2. after lock done, the lock status for all assets in the contract is shared
   3. if all assets in the contract locked, next step executes ( normally the trade )
   4. funds transferred to new party,  assets transferred to new party
   5. after delivery completed, obligations removed
8. after each step, the contract instance is updated for both parties and confirmed
9. signatures and consents required by all parties for each step
10. state changes are validated  as complete on each ledger for the current step before moving to next step - 100% endorsement of each update by relevant parties
11. if completion criteria for a step not fulfilled by X time, the transaction is cancelled and all parties are restored to initial states
12. completion messages recorded and events published on success or failure of the transaction

context

assume 2 different orgs on 2 different blockchains on 2 different platforms want to execute a sale using an order (any type of asset )

a blockchain with 2 parties as nodes each running a ledger copy and a contract

assume direct payment ( no margin loan ) on purchase transaction

blockchains implement escrow transaction interface services in a smart contract

2 independent chains A and B can send messages using a common protocol ( gRPC or ??? )

party A wants to buy X from party B for Y currency amount

problems

how to ensure only authorized parties participate in the transaction

how to ensure both parties will execute their transaction once and only once to complete the purchase transaction

how to ensure each party will accept delivery of assets and funds

how to ensure that the purchase is cancelled if either party fails to complete their part of the purchase transaction within the designated time limit

pre-requisites

network connectivity

blockchain directory services and access

identity, registration and access management services for all parties in a transaction

each party implements the escrow transaction interfaces

each party communicates using one of the supported protocols: gRPC or ?

each party digital certificates to sign and execute transactions identifying the authorized party

gateway nodes connect 2 different logical blockchain networks directly or indirectly ( blockchain networks normally not physical but virtual overlay networks across multiple provider networks )

solution

use an escrow transaction with smart contracts that

records each parties performance of the obligation

This follows a saga pattern to implement the escrow transaction (eg a purchase ) as a set of linked transactions in smart contracts

Singe Use Tokens are used to guarantee that only this single reservation transaction can be executed once by the designated party

step 0 - party A agrees to buy X from party B for Y currency amount agreeing to a set of policies to execute the transaction for the buyer and the seller roles

step 1 - reservation for payment from A to B with a token,  reservation for delivery from B to A with a token

step 2 - when both reservations complete, the reservations are executable as smart contracts by each party

each party executes their reservation transaction via smart contract using the supplied single use token created for just this transaction

A executes B's reservation using the token from B

B executes A's reservation using the token from A

alternate scenarios

both reservations are not completed within the agreed time limit, all reservations and tokens are cancelled and resources revert to current owner control

the purchase policy agreed to may include automated contracts to execute actions to reverse one or both reservation executions or cancel the reservations updating the blockchain

step 3 - if both reservations are not executed as transactions within an agreed time limit, each party is notified to manage the purchase based on agreed policy

step 4 - when both reservations have been executed by each party, all parties are notified of the completion of the escrow transaction

step 5 - any dependent actors are notified of the completion of the purchase which may trigger additional transactions ( eg start an automatic purchase warranty etc )

Hashed Timelock Contract  |  Hashed Timelock Agreement

https://www.investopedia.com/terms/h/hashed-timelock-contract.asp

https://academy.binance.com/en/glossary/hashed-timelock-contract

https://docs.lightning.engineering/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc

https://www.minima.global/post/understanding-hashed-time-locked-contracts-htlcs

Atomic Swaps using HTLC

https://medium.com/@mchammond/atomic-swaps-eebd0fa8110d

 Hashed TimeLock Contracts (HTLCs) on two chains could allow users to trade one digital asset for another directly in a peer-to-peer transaction.

Hash Time Locked Contracts (HTLCs) Explained

https://medium.com/liquality/hash-time-locked-contracts-htlcs-explained-e88aa99cc824

Refund scenario for HTLC

 leverage HTLCs in Atomic Swaps, but also lead industry-wide efforts to standardize their implementation across different applications and blockchains.

Bitcoin UXTO model

https://river.com/learn/bitcoins-utxo-model/

• Bitcoin does not have accounts with balances. Instead, individual coins are owned by Bitcoin users.
• An Unspent Transaction Output (UTXO) is a discrete piece of bitcoin. UTXOs are used as the inputs of every Bitcoin transaction.
• The UTXO model makes Bitcoin more auditable, transparent, and efficient than traditional financial systems, which rely on accounts, balances, and third parties.

Sample Ethereum Solidity HTLC Sequence Diagram in Confluence using Plantuml

Plantuml examples#HTLCEthereumSmartContractsexampleswithPlantumlSequenceDiagrams

HashedTimelockERC20 contract: normal flow - receiver withdraws with preimage before the timelock expires

Firefly Hash Time Lock Example Explained

https://docs.kaleido.io/kaleido-services/token-swaps/

https://docs.kaleido.io/kaleido-services/token-swaps/usage/

https://docs.kaleido.io/kaleido-services/token-swaps/architecture/

https://docs.kaleido.io/kaleido-services/token-swaps/htlc/

https://github.com/kaleido-io/token-sample-htlc

Hashed Timelock Contracts (HTLCs) for Ethereum:

• HashedTimelock.sol - HTLC for native ETH token
• HashedTimelockERC20.sol - HTLC for ERC20 tokens
• HashedTimelockERC721.sol - HTLC for ERC721 tokens

Example of atomic token swap cross chain

https://github.com/chatch/xcat

•  Protocol API Scenario 1 (Stellar side initiated)
• Protocol API Scenario 2 (Ethereum side initiated)
• Built in communication channel (Telehash Links?)

Jim >> Hash Time Lock Contract Overview

cbdc-project-lessons-adds-v1.pptx file for download

sequencediagram.org 

file  >>   dvp-atomic-swap-htlc-v2.txt 

Slide for HTLC overview for DvP atomic swap

DvP-cross-net-payment-patterns-jmason-v2 link gslides

Hash time lock cross network example from EU Stella DeFi settlement report

https://www.ecb.europa.eu/pub/pdf/other/stella_project_report_march_2018.pdf

DvP Trade Settlement with HTLC, Escrow Orchestrator, Escrow Choreographer Scenarios

Hash Timelock Controls ( HTLC ) are effective to manage atomic trades on the Bitcoin network.

The Bitcoin network has a number of simplifications over real-world trading systems that make HTLC useful as a settlement control system with minimal risks

Looking to improve on larger challenges on multiple networks, regulations, scalability, lower risks, the other Escrow Service models improve on the basic HTLC pattern to ensure all parties fulfill their responsibilities during settlement.

DvP Trade Settlement Use Case, Context, Goals, Landscape

2 parties ( buyer and seller ) each have a custody bank and a settlement bank

assumes security trade place in US markets subject to US rules for settlement

buyer places trades on a cash or margin basis. Cash trades allocate the cash at the time the order executes.

Margin trades allow the buyer up to 3 days to provide the funds. If the funds are not available, an automatic margin loan is created based on the margin agreement.

goals include:

1. automated, atomic trade settlement of both asset delivery and payment delivery
2. minimization of settlement risks for all parties during settlement based on trade agreement, delivery and acceptance of assets and funds
3. support full and partial trade settlements based on availability of securities ( assets ) and funds for settlement based on buyer and seller account policies
4. regulatory compliance in the jurisdictions the trade and settlement are subject to
5. efficient, low-cost trade settlement that scales across multiple networks

The DvP operating landscape is a logical network of independently managed and governed networks

Many payment networks and CBDC networks are independently defined and operated

Many asset and services networks are independently defined and operated

Secure, Scalable Interoperability with Operational Governance and Standards across networks is required to execute DvP settlement for any trade between parties

A conceptual diagram showing a logical network for networks

m Messaging#EventStreamUseCaseonLogicalValueChain

Key Questions to Answer for the DvP Settlement Use Case

1. What is the use case?
2. What are the parties, roles and goals for each?
3. What is the use case context for trade settlement?
4. What are the key assumptions in the model?
5. What are the key dependencies in the model?
6. What are the scenarios for the use case?
7. What is the economic model and incentives for parties for the use case and scenarios?
8. What is the governance model for parties for the use case and scenarios?
9. What are the jurisdictions in effect for regulation and taxation?
10. What is the process model and related contracts between parties for each scenario?
11. What is the security model for each scenario given the process and parties?
12. What is the privacy model for each scenario given the process and parties?
13. What is the trust model and related proofs for each scenario given the process and parties?
14. What is the decision model for parties in each scenario?
15. What is the public and private data model for parties and transactions in each scenario?

Scenario 1 - Simple DvP Settlement

Context

1. 1 network only
2. RTGS can execute fine
3. Buyer and seller and their agents all fulfill responsibilities for settlement
4. No partial trades. Full trade settles

All 3 models for DvP can succeed well

Scenario 2 - DvP Settlement where Stock goes up before settlement

Context

1. multiple networks involved cross border
2. RTGS can not execute effectively, need N-RTGS ( near real-time settlement )
3. Seller or their agents not incentivized to fulfill responsibilities for settlement
4. Partial trade may occur due to lack of shares or funds

Given cross border, network delivery, RTGS is difficult

HTLC model doesn't handle allocations for partial trade in the pattern

Given settlement is not immediate, with stock price increase, seller or agent incentivized to minimize shares for sale or decline to accept payment tokens

Partial trade occurs.

Seller wins and buyer loses effectively based on share price increase and delivery below trade 

HTLC doesn't support partial trade directly.  Execution may fail on timeout if seller doesn't accept payment tokens

Under escrow models, neutral 3rd party determines the net trade and holds both shares and funds guaranteeing delivery without risk

Scenario 3 - DvP Settlement where Stock goes down before settlement

Context

1. multiple networks involved cross border
2. RTGS can not execute effectively, need N-RTGS ( near real-time settlement )
3. Buyer or their agents not incentivized to fulfill responsibilities for settlement
4. Partial trade may occur due to lack of shares or funds

Given cross border, network delivery, RTGS is difficult

HTLC model doesn't handle allocations for partial trade in the pattern

Given settlement is not immediate, with stock price increase, buyer or agent incentivized to minimize funds for sale

Partial trade occurs.

Buyer wins and seller loses effectively based on share price decrease and delivery below trade 

HTLC doesn't support partial trade directly.  Execution may fail on timeout if buyer doesn't provide funds

Under escrow models, neutral 3rd party determines the net trade and holds both shares and funds guaranteeing delivery without risk

Scenario 4 - DvP Settlement where Seller or Buyer are sanctioned

Trade will be halted for legal reasons

All 3 models will be equally impacted

Simple DvP Settlement Using HTLC controls

Hash Timelock Control Concept

Services Patterns SDP#HashedTimelockContract%7CHashedTimelockAgreement

Very Good Diagram > a relevant HTLC process flow for simple DvP on security trade settlement

Services Patterns SDP#HashtimelockcrossnetworkexamplefromEUStellaDeFisettlementreport

DvP Settlement with HTLC

it depends on ...

wallets
tokenized assets
tokenized currencies
RTGS
UXTO
parties that fulfill their obligations in the process for all scenarios

challenges to address ...

needs sync model
needs trusted parties to fulfill their roles regardless of state changes
by scale
by multi-network processing
wallet risks
has execution risks on some scenarios
has regulatory issues to manage not accounted for in simple HTLC
doesn't support partial trades on securities, funds correctly

Escrow DvP Settlement using Orchestration

In this model,  DSM.O - DTCC Settlement Manager Orchestration 

DSM.O automates coordination of settlement participants across networks using escrow and smart services

Smart services integrate DLT and related services across multiple, interoperable networks using defined standards

The connectivity model using DSM.O as a logically centralized service across multiple networks

a relevant Escrow Orchestration process flow for DvP on security trade settlement

OLD version without orchestrator services shown

DvP Settlement with DSM.O - Escrow using Orchestration

it depends on ...

wallets
tokenized assets
tokenized currencies
near-RTGS
account management
netting optimizations
parties that fulfill their obligations in the process for all scenarios

challenges addressed include:

wallet risks
account risks
supports async model with N-RTGS
with escrow, improves trusts by trusted parties to fulfill their roles
scales better with async ( throughput vs transaction latency, nettings optimizations )
by multi-network processing for centralized orchestration
has lower execution risks on some scenarios
has regulatory support accounted for in DSM.O
supports partial trades on securities, funds correctly

Escrow DvP Settlement using Choreography ( OLD - not updated here )

In this model,  DSM.C - DTCC Settlement Manager Choreography

DSM.C automates coordination of settlement participants across networks using escrow and smart services

Smart services integrate DLT and related services across multiple, interoperable networks using defined standards

The connectivity model uses event-driven workflows across multiple networks

a relevant Escrow Choreography process flow for DvP on security trade settlement

DvP Settlement with DSM.C - Escrow using Choreography

it depends on ...

wallets
tokenized assets
tokenized currencies
near-RTGS
account management
netting optimizations
parties that fulfill their obligations in the process for all scenarios

challenges addressed include:

wallet risks
account risks
supports async model with N-RTGS
with escrow, improves trusts by trusted parties to fulfill their roles
scales better with async ( throughput vs transaction latency, nettings optimizations )
by multi-network processing for decentralized choreography
has lower execution risks on some scenarios
has regulatory support accounted for in DSM.C
supports partial trades on securities, funds correctly

Article - Taprootized Atomic Swaps with ZKP - no traceability

Submitted the article about Taprootized Atomic Swaps; feel free to review it: https://lnkd.in/deDiGP_e

At the same time, we are working on creating a trustless oracle for all Bitcoin events that could be deployed to any smart contract platform.

Let me know if you want to be on the list of first reviewers of this concept

Potential Value Opportunities

Potential Challenges

Candidate Solutions

Step-by-step guide for Example

Related References ( not all are available online )

CBDC in Wholesale Markets  - 2022

https://www.linkedin.com/pulse/wholesale-cbdc-considerations-digital-assets-sristhi-assudani/

Trust Over IP - Trust Concepts and Related Digital Proofs

https://skywebteam.atlassian.net/wiki/spaces/KHUB/pages/481624152/m+TOIP+Trust+Over+IP#mTOIPTrustOverIP-Jim'sTrustConcepts-WhatifItoldyou..

Hash Time Locked Contracts (HTLCs) Explained

https://medium.com/liquality/hash-time-locked-contracts-htlcs-explained-e88aa99cc824

Hash time lock cross network example from EU Stella DeFi settlement report

https://www.ecb.europa.eu/pub/pdf/other/stella_project_report_march_2018.pdf

How Escrow Protects Parties in Financial Transactions

https://www.investopedia.com/terms/e/escrow.asp#:~:text=Escrow%20is%20a%20legal%20concept,process%20of%20completing%20a%20transaction.

Reactive Microservices based on event listeners

https://sites.google.com/a/mammatustech.com/mammatusmain/reactive-microservices

Microservice capability patterns

https://microservices.io/patterns/index.html

US Digital Currency Opportunities Challenges Strategies ( restricted access )

https://docs.google.com/presentation/d/1dE-87HWfGFIHlXtzzlgmg_JevaFAkngPbUdoWBoEnt4/edit#slide=id.g18ca60cdfeb_0_0

sample code block

Recommended Next Steps

Related articles