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)

EIP-712 standard: https://eips.ethereum.org/EIPS/eip-712

ISO 15022: https://www.iso20022.org/welcome-iso-15022

ISO 20022: https://www.iso20022.org/

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 ?