QX Interoperability - v.0.7
  • πŸ’‘ABOUT
    • License
    • How to Give Attribution For Usage of QX Interoperability
  • πŸ‘¬Industry Initiatives
    • ISO Interoperability Framework
    • EEA Crosschain Interoperability Specification Suite
    • IEEE Standards for Blockchain Interoperability
    • ICMA Bond Data Taxonomy
    • IETF Secure Asset Transfer Protocol
    • SODA MIT Crosschain Interop WG
    • Decentralized ID for Tokenization
    • Cross-chain Interoperability Alliance
    • SWIFT Coalition
    • BIS Projects
    • MAS Projects
    • Regulated Liability Network
      • UK Finance - Regulated Liability Network
      • US - Regulated Liability Network
    • Hyperledger Projects
    • EEA-OASIS L2 WG
    • RollColl WG
    • ITU Digital Currency Global Initiative
    • EIP-5164: Cross-Chain Execution
    • EIP-3220: Crosschain Identifier Specification
    • EIP-7281: Sovereign Bridged Token
    • ERC-7092: Financial Bonds
    • ERC-3643: Permissioned Tokens
    • ERC1400: Universal Token for Assets and Payments
    • ERC6960: Dual Layer Token
    • CASA CAIPs
    • COSMOS IBC
    • Polkadot XCM
    • IEEE Crosschain Workshop
  • 🏦Use Cases
    • Payments/Digital Asset Transactions
      • Enable transfers of digital payment tokens
      • Conduct Compliant Cross-VASP Digital Asset Transaction
      • Swap NFT for Tokenized Bank Deposits
      • Enable Intra-Group Payments with Tokenised Deposits
    • Wholesale CBDC (wCBDC)
      • Enable Settlement with Simultaneous Delivery versus Payment
      • Facilitate Cross-Border Payments with wCBDC
      • Enable FX transactions to facilitate cross-border payments
      • Settle Crypto Derivatives using wCBDC
      • Access Liquidity via wCBDC
      • Settle Interbank Payments with wCBDC
      • Settle Interbank Payments with wCBDC (Acquirer-Merchant Settlement)
      • Make Property Payments with Tokenized Deposits
      • Provide FX Liquidity using wCBDC
      • Enable Payment versus Payment (PvP)
      • Crosschain digital bonds trades
    • Decentralized Finance (DeFi)
      • Aggregate Yields across Blockchains for Corporate Treasuries
    • Retail CBDC (rCBDC)
      • Provide Targeted Government Transfers (Government Vouchers)
      • Streamline Home Equity Lending
      • Provide Corporate Vouchers and Rewards
      • Make Milestone-Based Property Purchase Payments
      • Enable Traceable and Targeted Donations
      • Consumer Prepayments to Corporations
      • Enable Asset Transactions
      • Enable Cross-Border Remittances
      • Government Payouts
      • Managing Learning Accounts
    • Private Markets/Asset Tokenization and Trading
      • Tokenize and Trade Private Equity Fund Shares
      • Distribute and Settle Private Corporate Debt Issuance
      • Trade Employee Stock Grants as Digital Securities
      • Enable Secondary Trading for Non-Listed Assets and Private Markets
      • Automated Discretionary Portfolio Management with Tokenized Assets
    • Trade & Commerce
      • Support Tokenized Electronic Bills of Lading for Global Trade
      • Commercial Vouchers
      • Online Commerce
      • Programmable Rewards
    • DAOs
  • πŸ› οΈSolutions Providers
    • Swift
    • Mastercard
    • Fnality
    • Quant Network
    • Ownera
    • Fujitsu
    • Deutsche Bank/Standard Chartered Ventures
    • Kaleido
    • Onyx/JP Morgan
    • Canton Network
    • Universal Digital Payments Network Alliance
    • Li.Fi
    • Visa
    • Partior
    • CLSNet
    • Impel
    • Adhara
    • Datachain
    • Ant Group
    • CitiGroup
    • WeBank
    • IMF ?
    • BIS ?
    • Progmat ?
    • GroundX ?
  • πŸ““Requirements
    • Legal & Regulatory Layer
    • Governance and Policies Layer
      • Audit and Compliance sub-layer
      • Operations sub-layer
    • Application Layer
    • Integration and Middleware Layer
      • Oracle sub-layer
    • Semantic Layer
    • Syntactic Layer
    • Foundational Layer
      • Discovery sub-layer
      • Smart contract sub-layer
      • Function call sub-layer
      • Messaging sub-layer
      • Transaction sub-layer
      • Consensus sub-layer
      • Data transfer sub-layer
      • Security sub-layer
        • Identity and Authentication
        • Data Privacy
    • -
  • Protocol Providers
    • Chainlink
    • Axelar
    • Connext
    • Across
    • Toposware
    • IBC
    • Hyperlane
    • Sovereign Labs
    • Polymer Labs
    • Orb Labs
    • Zetachain
    • Sygma
    • deBridge
    • Wormhole
    • Routeur Protocol
    • Synapse
    • Wanchain
    • Gnosis
    • LayerZero
    • Comparison
  • Bridging Approaches
    • Bridges
    • Native Bridge
    • Third Party bridge
    • Multi-bridge
    • Oracle
    • Shared Sequencer
    • Mechanisms
      • Hash Locking
      • Notary Schemes
      • Proof Aggregation
    • zk-rollup ecosystems
    • Intent-centric
    • Function Calls
    • Relayers
      • Multisig
      • MPC
      • Light Client
      • ZKP Stark
      • ZKP Snark
      • Hybrid method
Powered by GitBook
On this page

Was this helpful?

  1. Requirements

Foundational Layer

Focus: Underlying mechanisms, protocols, and infrastructure that support crosschain operations.

Objective: Provide the foundational technical components and services that enable and support crosschain interactions, ensuring reliable, secure, and efficient operations.

Description: Encompasses a wide range of sub-layers and components. This layer ensures that messages are securely transmitted, transactions are correctly processed. It provides the tools, services, and protocols that other layers rely on to function in a crosschain environment.

Layer owner: Developers, infrastructure providers, security experts, standards organizations and consortiums that set technical standards for crosschain interoperability.

-------------------------------------

From existing documentation (unorganized)

  • There must be settlement finality. Probabilistic finality is not acceptable

  • Nonce management is critical for avoiding replay attacks.

  • Proof constructs must be based on rule book/legal requirements.

  • An abstraction layer is necessary to manage the complexity of blockchains.

Having the ability to keep internal systems updated about the progress of blockchain transactions across multiple chains will remove risk and ease integration

Most institutions have indicated they are not inclined to build new infrastructure and technology stacks entirely from scratch. Firms prefer to leverage their existing infrastructure, message implementations, and proven business processes to connect to blockchain ledgers, where tokens are recorded in a way that is both compliant and secure. This could help firms simplify their architecture and operations, minimise investment costs and reduce the risk of technology obsolescence.

include public blockchains as an underlying settlement layer. As such, there was strong interest within the community in collectively exploring open questions around interacting with public permissionless blockchains, as well as appetite for understanding how this can be supported in a secure and compliant manner.

  • It must be possible to clearly demonstrate that the technical solution aligns with with business considerations, including but not limited to behaving predictably and in accordance with prevailing conventions in the case of bankrupty by one or other party.

  • Integrating and enriching data for blockchain transactions

  • Integrating with blockchain wallets

  • Approaches commonly used in public blockchains (hash timelocks – HTLCs – in particular) are not necessarily well suited to financial transactions as the time lock can lock up assets for extended periods and are prone to race conditions across the two networks at the timeout. Therefore, we prefer plain hash locks to hash timelocks.

  • No (new) intermediate networks or third-party bridges, unless owned and controlled by the participants of the two networks or provided by a trusted party who already facilitates activity in the relevant market. The protocol should not mandate the usage/introduction of a new party solely for the purpose of the swap. There is a preference to solve the problem without forcing a change to the market structure

  • Approaches should be standards-based (including having a default towards adopting existing standards such as the EEA Interop standard, with some modifications if necessary, for the cross-chain communication layer)

To initiate the process of blockchain message creation within the financial institution’s infrastructure, it is essential to gather a set of information in dedicated fields of the MT 543 Deliver Against Payment

Message standards: MT 543 – Quantity of the tokens which will be transferred – This data can be captured in the message with a dedicated field option :36D::SETT//DITU/ – From: Wallet address the tokens will be sent from – This data can be captured in the message with a dedicated field option :97D::BCAW// – Receiver: Wallet address the tokens will be sent to – This data can be captured in the message with a dedicated field option :97D::BCAW// – Target: Address of the tokens which will be transferred – The message can currently formally handle the DTI identifier. This data can be captured in the message in :70E: Processing Instruction as ADDR/ – Target name: Name of the tokens which will be transferred – This data can be captured in the message with the /NM/ tag for :35B: identification of the financial instrument – Target version: Version of the tokens which will be transferred – This data can be captured in the message with a /VRSN/ tag for :35B: identification of the financial instrument – Chain ID: ID of the blockchain from which the tokens will be sent – This data can be captured in the message with a structure for :70E: Processing Instruction – Destination chain ID: ID of the blockchain to which the tokens will be sent – This data can be captured in the message with a structure for :95Q::PSET – Valid until time: Timestamp after which the transfer would no longer be valid – This data can be captured in the message with a structure for :70E: Processing Instruction – Nonce: Random value (non-sequential) stored on chain to avoid replay attacks – This data can be captured in the message with a structure for :70E: Processing Instruction – Signature: EIP-712 signature of the blockchain message – This data can be captured in the message with a structure for :70E: Processing Instruction

  • APIs compliance with financial-grade API (FAPI) standards

  • FAPI authentication, with attributes in ISO20022 format

  • API compliance with transport layer security (TLS) authentication for secure communication.

  • APIs use OpenAPI specifications to define the structure and syntax, and JavaScript Object Notation (JSON) for data format.

  • Technology standardisation: technical coordination vs technical infrastructure and implementation

  • FinP2P

Interoperability standardization needs:

  • common APIs

    • APIs compliance with financial-grade API (FAPI) standards

    • use OpenAPI specifications

  • data formats

    • ISO 20022

  • messaging formats

    • ISO 20022

Existing doc source: swift, mastercard.

  • Atomic settlement vs precision settlement

  • Precision settlement: is the collateral/asset available to settle immediately ? i.e. collateral would no longer be managed behind the scene by operations team ?

PreviousSyntactic LayerNextDiscovery sub-layer

Last updated 1 year ago

Was this helpful?

EIP-712 standard:

ISO 15022:

ISO 20022:

https://eips.ethereum.org/EIPS/eip-712
https://www.iso20022.org/welcome-iso-15022
https://www.iso20022.org/
πŸ““
Page cover image