> For the complete documentation index, see [llms.txt](https://qualitax.gitbook.io/interop/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://qualitax.gitbook.io/interop/requirements/undefined.md). # - ## From existing documentation (unorganized) * **Any solution should be designed to support multiple token handling mechanisms. Token handling mechanisms may vary by use case.** Participants expressed contrasting views about the suitability of various token handling mechanisms (see our glossary here), e.g. burn-mint versus lock-mint. Some participants thought the lock-mint mechanism to be more favourable for cross-chain visibility of total issuance – however, questions remain about the legal basis of wrapped tokens and the vulnerabilities of collateral locked in bridging solutions. Other participants suggested that the burn-mint mechanism may provide greater levels of control, but potentially at the expense of higher operational complexity. Another model to consider involves leaving the issued token on its native network and orchestrating ownership changes within each chain. In any case, participants generally agreed that token handling mechanisms are likely to depend on specific use cases. * **Institutions need to be able to send and receive existing MT formatted messages.** * **Blockchain wallet private keys to remain in the possession of the asset owners or their custodians.** * **Standardised channels** * **Market guidelines** * **Orchestration of flows across networks.** DvP orchestration across the spectrum of payment leg types, including existing off- chain payments (e.g. correspondent banking and RTGS payment rails) on-chain payment methods (such as CBDCs and deposit tokens) to facilitate instant atomic settlement, as these channels become commercially available in the market. ## Interop Principles (source: ) The following interoperability principles were put together by a banking working group who are involved in a number of new digital platforms, both cash and securities. The intention of these principles is to guide the discussion around the technical implementation. 1. **Anchored in Production implementation**\ Standards need to be driven by actual implementations across production targeting business platforms, not only theory. This ensures that the practical implementation, performance and maintenance of the standards are well grounded. 2. **Minimum (Wholesale) business flow scope** Standards need to cover, at a minimum, the patterns of interop that enables intraday XvP for Repos, FX Swaps and Equity/Bond Settlements. This is therefore focused on the regulated wholesale capital markets segment, it does not intend to cover public network interop or bridges. It is assumed that for regulatory purposes the assets do not leave the originating network/chain. 3. **Minimum protocol scope** Standards need to cover, at a minimum, interop patterns across R3 Corda and EVM (e.g. HL BESU) driven by the majority of business platforms coming to market and testing via the TestNet. \[Corda 4/5 to Corda 4/5, Corda 4/5 to EVM, EVM to EVM] 4. **Aligned to relevant standards body** Standards need to be seeded to the relevant standards body where it can be credibly supported. This standard is cross protocol (i.e. not EVM or Corda specific) and across capital markets business lines. \[Note: One for the community to steer, options provided by working group]. 5. **Maintains community incentive alignment**\ Standards & reference implementations drive aligned incentives for both those developing/maintaining the standards as well as not locking in a piece of 3rd party software / tech required that can be monetised by one party only. 6. **Reference implementations accelerate adoption**\ Standards require reference implementations to accelerate the adoption within their protocols, these reference implementations should be open source. 7. **Patterns anchored around Wallet/Asset holders not bridges in the first instance**\ New DLT business platforms are natively designed to operate without message brokers and their standard patterns will revolve around the banks (wallet/asset holders) deploying the required interop orchestration (based on reference implementations). * **Open to all regulated institutions** * **Multi-vendor** * **Ledger agnostic** * **Open Interfaces** ## wCBDC requirements Each central bank is the sole issuer of its wCBDC. Each central bank grants wCBDC access to selected commercial banks, with the ability to apply different eligibility criteria to the domestic platforms and to the international network. Each central bank may block specific or all commercial banks from receiving or transferring wCBDCs. Each central bank may retrieve wCBDC from blocked commercial banks. Each central bank may monitor transactions involving its wCBDC intraday. ## Bridge requirements Source: Each bridge enables the transfer of wCBDC between the respective domestic platform and the international network. Each domestic platform is connected to the international network with one bridge. Each central bank manages access to the respective bridge and the transfer of wCBDC. Each central bank’s balance sheet remains unaffected by the transfer of wCBDC between the respective domestic platform and the international network. wCBDCs on the respective domestic platforms and the network are fungible. Authorised commercial banks can convert wCBDC between the domestic platform and the international network 24/7. ## AMM Requirements The AMM aims to provide a reference price for FX transactions. FX rates are transparent to all market participants (GXGC Principle 12). The mechanism determining the FX rate minimises the impact from large transactions (FXGC Principle 9). Access to the AMM is transparent to participating commercial banks (FXGC Principle 37). Disproportionate liquidity provision to the AMM is possible, ie commercial banks can provide and remove liquidity in just one currency. Liquidity providing commercial banks may query their current holdings in the liquidity pool at any time (FXGC Principles 27 and 31). The AMM does not incentivise undesirable trading practices (FXGC Principle 9). **Domestic vs crossborder interoperability** Potential trade-offs might arise between promoting international interoperability of CBDCs using commonly implemented standards and achieving domestic interoperability with existing forms of money **From public Mainnet to private chain:** * Wallet screening must be implemented to analyze wallet histories and screen against known risks or sanctions. This is required to prevent prohibited/sanctioned entities from being whitelisted and onboarded. * Checking against OFAC and other authority sanctions lists needs to be part of the wallet screening process. * Transaction monitoring is required for any inbound asset bridge transactions to the private chain. * Transaction monitoring needs to enable detection of high-risk transactions. * Transaction monitoring must trace the source and destination of incoming bridged funds. * Whitelisting and onboarding new entities/accounts to the private chain can only happen after the required wallet screening is completed. * No prohibited or sanctioned entities should be granted access to the private chain after wallet screening. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://qualitax.gitbook.io/interop/requirements/undefined.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.