Secure Asset Transfer (SAT) Use Cases

Introduction Business networks, built on both centralized and decentralized models, have emerged to manage cross-organization assets and workflows. The scope of such workflows and the assets they govern, as well as the set of participating organizations within a network, have been quite limited, partly for security, privacy, and scalability reasons, and partly because organizations have been reticent to moving large portions of their pre existing workflows to such networks. This is especially observable in the areas of trade, finance, supply chain logistics, and property management. Yet the workflows managed by these networks are naturally interlinked in the real world, and therefore cannot afford to remain isolated from each other technologically, which would diminish the value of their assets. At the same time, a network, once built, has institutional staying power, and it is therefore impractical to assume that they will expand or merge. Interoperability is therefore an imperative in this fragmented business network ecosystem. This comes in different flavors, namely the ability to move an asset from one network to another, interlinking workflows to share asset state with proof of authenticity from one network to another, and swapping assets in different networks as part of a business transaction, as listed in the SAT Architecture Specification . The purpose of this document is to describe prominent examples of these modes that have been encountered by enterprises and business consortiums and identified as challenges to be overcome. In particular, this document describes scenarios where the Secure Asset Transfer Protocol (SATP) can be directly applied to solve the problem of moving digital assets across networks, for which no other canonical protocol exists in the literature.

Terminology The following are some terminology used in the current document, with some borrowed from and , and new terms introduced only when needed:

Asset network (system): The network or system where a digital asset is utilized.
Distributed ledger technology (DLT): Software to maintain a shared and/or replicated ledger (or system-of-record) of digital assets across multiple nodes through distributed consensus, and an SDK and technical stack to develop applications over the ledger. Asset networks can be built on DLTs.
Secure Asset Transfer Protocol (SATP): The protocol used to transfer (move) a digital asset from one network to another using gateways.
Origin network: The current network where the digital asset is located.
Destination network: The network to which a digital asset is to be transferred.
Data sharing: The process, using the Asset Transfer Protocol, by which one or more units of verifiably authentic data are communicated from an Origin network to a Destination network, either voluntarily or upon request.
Asset Transfer: A fail-safe process of moving an asset from one network to another, with the destruction of the asset in the Origin network and its recreation in the Destination network occurring as a single atomic action.
Asset Exchange: A fail-safe process of exchanging (or swapping) assets held by a pair of owners, each asset being maintained in a different network, with the two in-network transfers occurring as a single atomic action.

International Trade and Supply Chains

Trade Finance and Logistics Several real-world examples of consortium networks have been created to manage different aspects of international trade. Some networks manage trade finance workflows by connecting exporters, importers, and financial institutions (primarily banks) . Other networks manage shipping and documentation logistics involved in trade, by connecting exporters and shipping carriers . These networks are typically built as asset networks on prominent open source DLTs . As an example, consider a system of two networks as illustrated in Figure 1: (a) a trade finance network managing letters of credit business lifecycles from application to fulfilment, and (b) a trade logistics network managing shipping consignment creation and dispatch documents like bills of lading.

An exporter who belongs to both systems must produce a valid bill of lading in the trade finance network to enforce a payment from the buyer to fulfil the terms of the letter of credit. But this bill, which serves as evidence of a shipping consignment's dispatch via a carrier, lies in the other, i.e., trade logistics, network. The two networks must therefore be interoperable in such a way that the logistics network can share a bill with the finance network along with independently verifiable proof of authenticity. Otherwise, the trade finance network's workflow must trust that the exporter is acting in good faith and supplying genuine bills of lading, which adds insecurity. This interoperation, which involves sharing of network data, can be extrapolated to other scenarios involving the two networks. The trade logistics network can require an exporter to produce a valid letter of credit from the trade finance network before permitting a consignment record creation. Both these cross-network data sharing instances are illustrated in Figure 2.

| Importer | +----------+ Purchase Order +----------+ +------------+ | Exporter's | +----------+ +---------------------+ | Bank | | Exporter | | Exporter | +------------+ +----------+ +---------------------+ | | | | | 4 | | 12 5 | | 7 | 9 Approve | | Request Book | | Create | Accept L/C | | L/C Consignment | | Consignment | B/L | | | | | | | ___________________ | | | | | | | | | | | | | 11 Share B/L | | | | V V V | V V V +-------------------------------+ +-------------------------------+ | Trade Finance Network | | Trade Logistics Network | +-------------------------------+ +-------------------------------+ ^ ^ | ^ ^ ^ | | | 6 Share L/C | | | | | |_______________| | | | | | | 3 | | 2 10 | | 8 Propose | | Request Dispatch | | Upload L/C | | L/C Consignment | | B/L | | | | +------------+ +----------+ +-------------+ | Importer's | | Importer | | Carrier | | Bank | +----------+ +-------------+ +------------+ ]]> Asset transfers among trade networks: In the preceding example, letters of credit and bills of lading represent portions of state of the larger export-import workflow. But these documents are also digital assets in their own rights. A bill of lading can serve as title to the consignment of goods being shipped, and hence can be traded as a security or used as collateral against debt obligations in the financial market. Hence, Step 11 in Figure 2 may well be embodied by the transfer rather than the sharing of state of a bill so that it ceases to remain on the Trade Logistics Network ledger and instead belongs to the Seller's Bank on the Trade Finance Network's ledger. A letter of credit may also assume the properties of a digital asset in certain situations. Consider the case of an importer who wishes to move their business to a different trade finance network and maintain their records on that network's ledger. The banks and the exporter can be assumed to participate in the second trade finance network as well, which exists to serve a different clientele. The importer needs to be able to move its letter of credit state to the other network and resume the trade workflow after migration. This requires the ability to transfer the letter in the form of a digital asset from one trade finance network to another.

Tracking Food Shipments The use case linking a trade finance network with a trade logistics network can be augmented by adding a food tracking network to the mix. Such a network, also built as an asset network on a DLT, connects producers, suppliers, manufactures, and retailers, who participate in food supply chains . Purchase orders, like those negotiated between producers and retailers, and which are illustrated as negotiated between exporter and importers in Figure 2, are recorded in this network's ledger. For quality control, its business workflow will track at periodic intervals the state (e.g., temperature and humidity) of containers carrying, for example, produce from farm to source port and from destination port to warehouse. The trade logistics network handles documentation and dispatch but does not track the location or condition of a consignment outside of a carrier's purview. Clearly, these networks play complementary roles in a supply chain. The logistics network should be able to get the state and history of a container before dispatch from the food tracking network, as should the latter from the former after the carrier has delivered a consignment. End-to-end supply chain visibility and effectiveness relies on the interoperability of these two networks, or to be precise, their ability to share verifiably authentic data with each other . Further, such interoperation also enables the trade finance network to allow the creation of a letter of credit only after verifying the existence of a valid purchase order in the food tracking network. Figure 3 illustrates the links between these networks.

Supply Chain Management To complete the picture, a payment network can be added to the mix. This payment network maintains currency accounts for clients in different countries and enables cross-border payments . After goods have been dispatched, and optionally after verification of the delivery and proper condition of a shipment, payment is due from an importer to an exporter. The trade finance network can record a payment obligation on its ledger but it will rely on the payment network to process and confirm the actual transfer of funds. The former shares data about the obligation to the latter, which shares data about a successful (or otherwise) payment in return, as illustrated in Figure 4.

Addendum: yet another network, one that manages regulatory compliance, can be added to the mix. (E.g., proof-of-concept systems have been built to bring banks and corporations on a single distributed ledger and smart contract platform to share KYC information in privacy-preserving ways .) Now issuances of letters of credit in the trade finance system will be dependent on valid KYC records being maintained as assets in the regulatory compliance system.

Currency and Finance The emerging paradigm of Decentralized Finance (DeFi) and the emerging application of Central Bank Digital Currency (CBDC) have opened up a spectrum of scenarios that require management of financial digital assets across multiple systems, typically built on distributed ledgers. DeFi is a "new financial paradigm that leverages distributed ledger technologies to offer services such as lending, investing, or exchanging cryptoassets without relying on a traditional centralized intermediary" . Following the Web3 philosophy , scoped for the world of finance, DeFi offers architecture and protocols built on smart contracts deployed on blockchain or other distributed ledger technology. It thereby obviates the need for centralized management and orchestration of financial processes (e.g., currency transfers, exchanges, securities settlements) by trusted authorities who can gain undue leverage. CBDC is a form of tokenized cryptocurrency that various central banks around the world are experimenting with as the digital equivalent of traditional central bank-issued money used by banks and other financial institutions as well as end users for commercial transactions and settlements. Central banks possess exclusive authority to mint and issue money in physical cash form and in the form of electronic reserves. They also support commercial bank money used in retail transactions by banks and other users in their private capacities. Central banks have traditionally used their control over these different forms of money to enforce monetary policy in a way that promotes financial stability and provides broad access to safe and efficient payments . CBDCs would form a new, or alternative, type of central bank money, typically (but not always) built on blockchain or other distributed ledger technology. They have recently garnered significant interest in government circles by promising increased access and inclusion, better resilience, and increased scale and efficiency of currency transfers, compared to traditional forms of central bank-issued or central bank-backed currency. CBDCs can broadly be classified into "wholesale" and "retail". Wholesale CBDC, which facilitates inter-bank and cross-border settlements, is currency that is available only to banks and other financial institutions. Retail CBDC is available to the public and can be used as a digital form of cash, enabling fast transparent payments for goods and services at high scale and volume; in effect, it can be used as a substitute for legacy payment mechanisms. Different system architectures exist to manage CBDC for banks and end users, from issuance to transfers to redemptions. A 2-tier model as illustrated in Figure 5 has recently gained popularity, where wholesale CBDC networks manage interactions between central and commercial banks, and retail CBDC networks manage interactions between commercial banks and end users. If the role of the central bank is treated as the defining characteristic of a system architecture, this model can be referred to as "indirect", because commercial banks mediate claims between the central bank and end users and also facilitate payments. Other architectures also exist, including "direct CBDC", where the central bank issues CBDC directly to end users and facilitates payments, and "hybrid CBDC", which provides users the facility to make direct claims on the central bank while allowing intermediaries to facilitate payments .

Currency Transfers The 2-tier "indirect CBDC" model illustrated in Figure 5 presents unique interoperability challenges that require protocols for asset transfers and which SATP is well-suited to handle. In the higher tier lie wholesale CBDC networks, bringing together central or reserve banks and various commercial banks. Following the DeFi logic, these networks are typically built on distributed ledger and smart contract technologies. Commercial banks hold reserve currency deposits with the reserve bank, which has the special power to mint currency and issue CBDC and also enforce regulatory compliance. In the lower tier lie retail CBDC networks for commercial banks and their customers, built on similar technologies, enabling seamless, efficient, and transparent payments using CBDCs. A retail CBDC network may involve a single commercial bank or multiple commercial banks, depending on the market caps of those banks and their purposes for joining such a network.

In scenarios described subsequently, a given commercial bank maintains digital currency accounts in a wholesale CBDC network as well as one or more retail CBDC networks. To inject liquidity into a retail CBDC network, this bank will need to transfer currency from its reserve account in the wholesale CBDC network. Or it may need to approve (or at least audit) the transfer of currency from one retail CBDC network to another bank in another retail CBDC network. In the world of decentralized finance, or DeFi for short, currency cannot afford to remain siloed in any single CBDC network. Hence, these networks must be interoperable in order to facilitate secure transfers of currency among themselves, as illustrated in Figure 5. Two specific instances of currency transfer across networks can be observed in this example: one from a wholesale CBDC network to a retail CBDC network, and another from one retail CBDC network to another. Since currency in tokenized form is a digital asset, these scenarios require the direct application of a secure protocol for asset transfer. SATP fits the bill, is agnostic of the types of distributed ledger technologies on which the respective networks are built, and simply requires the networks to use SATP gateways. This is not just a theoretical proposition; a candidate design for a bridge between Hyperledger Fabric and Hyperledger Besu networks using SATP and the Hyperledger Cacti interoperability platform has been proposed by distributed ledger researchers .

Multi-CBDC Economy Several governments, banks and financial communities have explored the use of a shared ledger containing multiple CBDCs as way to potentially obtain an economy of scale in the development and maintenance of their own respective CBDCs. Such a Multi-CBDC approach has the potential benefit to improve cross-border payments and protect monetary sovereignty, without necessarily becoming a monetary union . However, even within a Multi-CBDC configuration, there must be a mechanism to interconnect each respective national (sovereign) bank network with the shared Multi-CBDC network. Gateways appear to be an attractive means to permit the transfer of a CBDC from one national network/ledger into the shared Multi-CBDC ledger, and vice versa. One major requirement is the assurance that consistency is maintained between the CBDC counts on the national network with that on the Multi-CBDC network (i.e. no counterfeiting; no double-spend). With or without a Multi-CBDC ledger, the existence of different national networks managing different wholesale CBDC assets will necessitate inter-network transfers for cross-border payments and settlements . Whether directly between two wholesale CBDC networks or between a wholesale CBDC network and the Multi-CBDC network, transfer of currency assets is a problem for which SATP appears to be the most suitable solution.

Delivery vs Payment (DvP) of Securities In Decentralized Finance, or DeFi for short, investors and financial institutions will form networks to manage the creation and purchase of securities. As a simple example, consider a network to which the Treasury, which issues bonds, and commercial banks, which purchase and trade bonds, belong. Also consider a payment network of the kind seen in Section 3.3 (or a retail CBDC network of the kind seen in Section 4.1), which allows CBDC transfers between commercial banks' accounts. In the securities network, banks may wish to transfer bonds to each other but only in exchange for compensation. But such compensation can be made only on a payment network where the two maintain currency accounts (e.g., in CBDC). Therefore, the securities and payment networks must be able to interoperate in such a way that two banks can carry out a delivery-vs-payment transaction spanning these two independent networks. Such a transaction must be atomic, i.e., either both bond and CBDC tokens get transferred in their respective networks or neither gets transferred. Figure 6 illustrates this exchange.

Stock Options Contract Fulfilment Stock options are financial instruments that allow holders to buy or sell stock at predetermined prices until specific expiration dates . Exercising an option, i.e., buying or selling a stock by paying a "strike price", involves a more complex cross-network financial transaction than the securities DvP use case. Option contracts can be managed and enforced in a specific business network (which can be labeled a "stock network") to which entities like a clearing organization (CO), stock exchanges , and brokerage firms, belong. In this example, the CO is the issuer and guarantor for all options and futures contracts traded on a country's exchanges . It provides secured back-end clearing services, while exchanges provide front-end trading markets. Transfer and settlement of payments, just like in the DvP scenario, will typically occur in a dedicated payment network in which buyers and sellers of stock have currency accounts. Options contract fulfilment requires the stock and payment networks to work in concert, and hence need SATP to coordinate transactions across them. Figure 7 illustrates a simplified flow for the exercising of a "call" option, where a buyer acquires stock from a seller by paying it a strike price. First, the buyer informs its brokerage, which then notifies its exchange about the buyer's intent to exercise the option. The exchange in turn notifies the CO in the Stock Network. (All these notifications typically occur via a smart contract). Steps 1-2 illustrate these notifications. The CO then verifies the contract's validity and the buyer's right to exercise the option. If this is successful, the CO triggers a payment request to the buyer through a contract-to-contract communication from the Stock Network to the Payment Network (step 3). (Alternatively, the buyer may trigger a payment request in the Payment Network, which then requests the Stock Network for proof of the contract's validity from the CO before approving the payment.) The buyer then pays the strike price to the seller (step 4). The payment receipt is now sent to the Stock Network for the CO's verification (or alternatively, the buyer can request the CO to fetch and verify the receipt from the Payment Network) and fulfilment of the contract (step 5). The CO, via the exchange, requests the brokerage to transfer stock from the seller's to the buyer's account (steps 6-7). This cross-network transactions require SATP using gateways, either to communicate information of a contract's validity (step 3) or a payment receipt (step 5) with authenticity proof (i.e., data sharing), or by ensuring that strike price payment (step 4) and contract fulfilment (step 6-7) occur atomically as an exchange using a coordinated set of commitments .

| |-|----------|>| | | | | | | Account | | | | Options | | | | Options | | | | | +---------+ | | | Contract | | | | Contract | | | | | | | | (Copy) | | | | | | | | | +---------+ | | | | | | | | | | | | | Seller |<|----------|-| |<|----------|-| | | | | | | Equity | | 7 | +----------+ | 6 | +----------+ | | | | | Account | | Fulfil & | | Fulfil & | | | | | +---------+ | Transfer | | Transfer | | | | | | Stock | | Stock | | | | +-------------+ +--------------+ +--------------+ | | | +---------------------------------------------------------------------+ | ^ 3 Request to Pay | | Strike Price | | 5 Send Payment Receipt | | V | +---------------------------------------------------------------------+ | Payment Network | | | | +--------------+ +--------------+ | | | Buyer | 4 Pay Strike Price | Seller | | | | Payment |-------------------------->| Payment | | | | Account | | Account | | | +--------------+ +--------------+ | | | +---------------------------------------------------------------------+ ]]>

Decentralized Commerce: Payments for Goods and Services In the emerging Web3 world, undergirded by blockchain and DLT, goods and services are increasingly available on decentralized networks, either as purely digital objects or proxies of physical objects. The networks typically manage these assets in the form of non-fungible tokens (NFTs) using smart contracts and decentralized applications (DApps for short). DeFi in a Web3 ecosystem can create thriving online marketplaces where goods and services can be bought and sold across network boundaries if those networks are interoperable (i.e., assets and data can be moved or managed seamlessly across networks). SATP is a necessary requirement to enable and secure such a decentralized form of commerce.

Transferal of Digital Art and Payments across National Borders There is currently growing interest within many artist communities of developing and selling digital-only artwork, in which the artwork consists of a file in a well-known (e.g., JPEG , MPEG ) format that is created by an artist. The artists seek to sell copies of the digital-only artwork on the global marketplace, allowing anyone in the world to purchase a copy and consume (e.g., display offline) the artwork at the buyer's discretion. Currently, the most popular technological vehicle to achieve this goal is through the tokenization of the copies of the artwork coupled with digital encryption/signature technologies to transfer control (and thereby legal ownership) of the digital-only artwork to the buyer. Although there are a number of technical and legal challenges (e.g., copyright enforcement) to completing such a sale, one key issue pertains to the sale and payment for digital-only artwork across national borders. Many nations enforce taxation upon the sale of any asset, including that of artwork generally both domestically and internationally. Thus, when the control/ownership of a tokenized digital-only artwork is transferred to a new owner in a foreign nation and payment is received, taxation must be obtained at the point-of-sale (which could be an online platform) and proof of delivery must be traceable to ensure that no taxation-avoidance occurs. A secure asset transfer protocol between systems that can be built on distributed or shared ledgers via gateways with designated legal authority is necessary to enforce governmental regulations and provide accountability.

Payment for Streaming Services Several services exist to stream content over the World Wide Web to users' (or customers') nodes . Such services can tap into the cryptocurrency and DeFi user markets by offering content on distributed ledger networks using smart contracts. Instead of monthly subscriptions, they can offer pay-as-you-go streaming of arbitrarily low amounts to large numbers of users on such networks. Content transfer can be backed by NFTs, which users can redeem on any video or audio playback application. Because here already exist several payment networks for unregulated (e.g., Bitcoin ) and regulated (e.g., CBDC) currencies, the content networks are likely to remain independent and not involve any monetary transactions on their own ledgers, as that would create safety and regulatory issues. Content transfer in a content network can be backed by a corresponding payment in a payment network if there is a facility to transfer payment receipts from the latter to the former. This can be fulfilled through the data sharing mode of SATP, whereby knowledge of payment along with authenticity proof can be communicated across networks. Alternatively, an atomic swap of the content and the payment can occur across both networks using the asset exchange mode of SATP. In a related example, if users wish to obtain content that is not available currently with the streaming service provider, that provider may seek and purchase that content from another distributer that is offering it on a different content network. The copyright to that content can be backed by NFTs and the secure transfer of those NFTs from one network to another will require SATP. Though these examples show what is possible, ongoing initiatives in Europe and China are aimed at facilitating data and asset transfers. Since 2022, China has issued a series of policies and guidelines to promote the development of a nationwide data market that supports data elements' assetization, capitalization, and circulation . A multi-layered national data infrastructure is slated be built by the end of 2029 to support transaction, transmission, and utilization, of data; telecom operators like China Mobile and China Unicom are building large- scale networks to enable data transmission . Design and implementation of this infrastructure will be guided by the newly established National Data Standardization Technical Committee (TC609), which will coordinate with existing data circulation standards organizations like ISO/IEC JTC 1/SC 32 and ISO/IEC JTC 1/SC 42, and reuse existing standards. In Europe, several projects like Gaia-X and Catena-X aim to create secure, decentralized, and interoperable data infrastructures. Catena-X specifically targets data exchanges in automotive industry operations while Gaia-X is a more generic, EU-wide data infrastructure. The International Data Spaces Association (IDSA) produces several ISO standards like ISO/IEC AWI 20151 and ISO/IEC 23751:2022 for exchanges across data spaces . The IDSA also partners with the Eclipse Foundation to implement open-source solutions and jointly develop the Dataspace Protocol (DSP), using which data usage policies, usage contracts, and schemas can be negotiated (in the so-called "control plane") between two data-exchange gateway peers . The actual post-negotiation data transfer (in the so-called "data plane") is out of scope of DSP, and here SATP can fill the gap.

Trustworthy DNS Resource Record Migrations using an Augmented EPP Several examples have been presented in this document where SATP is indispensable for enabling cross-network asset and data transfer and transaction settlement. But SATP can also be used to augment an existing protocol by making it more secure, trustworthy, and efficient rather than creating an altogether new feature that preexisting technology was unable to provide. Conventional Internet architecture offers scope for such augmentation. Though highly decentralized, the Internet consists of nodes (or actors) that play critical roles in various protocols. Such protocols would benefit if the actions of these actors can be recorded and tracked on blockchain or other decentralized ledger networks. (It must be noted that the performance implications of these augmentations ought to be studied before firm recommendations are made.) In the canonical DNS architecture , multiple registries and registrars may co-exist, managing DNS records for domain administrators (registrants). The Extensible Provisioning Protocol (EPP) allows registrars to communicate with registries for DNS resource record updates . Consider an example where R acts as a TLD (top-level domain) registry for the ".example" namespace, and entities S1 and S2 are registrars that can issue SLDs (second-level domains) to users. In one scenario, user Alice, who administers an SLD (say alice.example) issued by S1, wishes to transfer that SLD to S2. She can submit a request to S2 for this purpose, following which the respective registrars (S1 and S2) can communicate with the registry (R) using EPP to transfer the SLD from S1 to S2. S2 will then reissue the domain to Alice. In another scenario, Alice can transfer administration of her S1-issued domain to user Bob, a registrant who relies on S2 for registrations. Though EPP facilitates these resource updates and transfers, and reputed registrars offer users these features in a usable manner, such scenarios face safety issues as they require trust and proper coordination among the participants. These issues can be mitigated by distributed ledger networks, smart contracts, and NFTs, which collectively provide a platform for safe and transparent DNS resource transfers with easy detection of non-compliance. In such a scheme, domains (or domain names) can be monetized as NFTs or digital assets, e.g., in the form of ERC-721 tokens, a popular NFT standard in the Ethereum ecosystem . The creation of a domain is represented by minting of an NFT and the deletion of a domain by the burning of the NFT using smart contracts whose transactions are tracked on a distributed ledger maintained by a network of entities. Registrants Alice and Bob also participate in the smart contracts and hold wallet identities, allowing them to trade assets by submitting transactions to the ledger. Registrants, registrars, and registries can engage in commercial transactions using contracts governing tokenized (and monetized) domains for the purposes of issuing and transferring domains (among users and registrars). This setup provides more safety when registrars are not reputed, and also allows new registrar services to emerge and build reputations. It also enables users like Alice and Bob to transfer domains to each other safely and seamlessly. SATP is crucial to enabling this scheme where registrars belong to, and issue, NFT-backed domains in different ledgers maintained by different networks. Ensuring that tokens are securely and atomically transferred between the ledgers will be a necessary prerequisite for an EPP resource record update operation. Further, non-compliance, or non-fulfilment of EPP, by either registrar, can be easily detected by examining the SATP logs from the respective networks' gateways, thereby safeguarding the process. In future, reputed registrars may require their counterparties to comply with SATP-based transfers across ledgers as a prerequisite to engaging in a domain transfer with them. This scenario additionally illustrates an example of what typically occurs in Stage 0 of a SATP instance , which is where negotiation and agreement-building occurs between gateways. EPP instances among registrars and registries will occur in this stage, both prior to the start of an SATP instance and after its conclusion. EPP will aid in the generation of transaction contexts, which gateways need to transfer an asset (in this case, a tokenized domain) using SATP. Many other applications of SATP for asset transfers may similarly augment or bolster pre-existing business workflows, which (like EPP here) will produce transactions contexts for SATP instances.

Interoperation Protocol Considerations The use cases provided as examples serve to illustrate instances of general phenomena that the Secure Asset Transfer Protocol , with a limited number of variations, is designed to handle. The data sharing examples in Section 3 can be extrapolated to any kinds of data that need to be shared between networks running arbitrary workflows. The asset transfer example in Section 4.1 and the asset exchange example in Section 4.3 similarly can be extrapolated to any kinds of digital assets lying within any kind of network. Considerations for the interoperability protocol, or SATP, can therefore be limited to standard distributed systems issues like integrity, fault tolerance, and liveness, while completely disregarding the nature of the assets, networks, and workflows, which can all remain opaque to the protocol.

Security Considerations This specification inherits the security considerations of and . It describes exemplifying use cases for the interoperability of asset networks and identifies suitable applications of SATP to overcome challenges in these use cases. When any of these use cases is implemented using SATP, the security considerations described in the SATP architecture and SATP core protocol specifications will apply. Since this specification does not describe any system components, there are no additional security considerations to list here.

IANA Considerations This document has no IANA actions.

Contributors The authors would like to thank André Augusto of INESC-ID and Técnico Lisboa (Portugal), Zainan Victor Zhou of Namefi by D3Serve Labs, and Hyojin Song of Seoul National University (South Korea) for reviewing this draft, helping us improve its quality, and inspiring use cases in the areas of CBDC and DNS record maintenance, which augmented the existing use cases to show more applications for the interoperability modes listed in the SATP Architecture document.