Session Date/Time: 05 Dec 2023 15:00

SATP

Summary

The SATP working group session focused on two primary technical discussions: a proposed architecture for Asset Schemas and an update on network identification, particularly addressing the integration of Layer 2 (L2) networks. Dennis presented a conceptual framework for asset registries and the roles of Schema Definition Authorities to standardize asset definitions and ensure their legal validity. Thomas provided an overview of an approach to identify L2 networks by associating them with their parent Layer 1 networks through metadata, discussing implications for transaction finality and party identification.

Key Discussion Points

Asset Schema Architecture (Presented by Dennis)

Introduction of Registries and Schemas: The concept of a "Registry" service was introduced. This service stores "Asset Schemas," which are formal definitions of asset types (also referred to as asset profiles). Gateways will access these registries to retrieve schemas, allowing them to verify that asset instances comply with their defined types before transfer.
Registry Management and Trust: A discussion addressed the management, synchronization, and trust models for registries. It was clarified that registries are services, and their trust considerations are analogous to those for Gateways. The architecture explicitly separates asset schemas from asset instances.
Schema Definition Authority (SDA): The concept of a Schema Definition Authority was presented as a legal entity responsible for cryptographically signing asset schemas within a registry. This signature confers legal authority to the schema within a specific jurisdiction. Asset Providers must obtain issuance authorization from the relevant SDA to issue asset instances conforming to a specific schema.
Asset Issuance Process: The process for issuing an asset instance involves a provider fetching the asset schema, requesting authorization from the SDA, and then, upon receiving approval, issuing the instance on the network. This workflow ensures the legal validity and compliance of the asset instance with its defined schema.
Governance Principles: The proposed governance model is open and permissive, allowing SDAs and Providers to freely register. No central organization dictates write access to registries. Trust is based on mutual agreement between parties. Asset schemas are designed to be append-only, with new versions added while previous versions are retained for backward compatibility, ensuring an immutable history. Semantic versioning is anticipated.
Defining Asset Schemas: Asset schemas aim to define the essence or type of an asset (analogous to a class in object-oriented programming), including its attributes, associated capabilities (e.g., taxability, transferability constraints), and relevant legal jurisdiction. This goes beyond merely defining the interface for manipulating an asset (e.g., ERC-20 or ERC-721 tokens). Industry-specific subclasses of schemas are envisioned to promote global consistency.
Registry Implementation: Registries could be implemented using a hybrid approach, incorporating both on-chain and off-chain components to manage storage costs, with on-chain elements providing core identity and consistency guarantees.
Decentralized Access: It was clarified that the proposed system is not centralized. While SDAs provide legal backing for specific jurisdictions, any party can define schemas. Private parties can mutually agree to use a schema without requiring SDA involvement if legal context or jurisdiction-specific compliance is not a primary concern.

Network Identification (Presented by Thomas)

Network Identification Fundamentals: Gateways require precise identification of originating/beneficiary addresses, network identifiers, and Gateway endpoint identifiers to facilitate transfers and compute critical application-level (context ID) and network-level (session ID) identifiers, which are vital for managing concurrent transfers.
Addressing Layer 2 (L2) Networks: Previous architectural assumptions had primarily focused on Layer 1 (L1) networks. The discussion explored whether a Gateway needs to distinguish between L1 and L2 remote networks, particularly if a signed assertion from the remote Gateway adequately guarantees the asset's state. The initial sense was that, at a fundamental level, the Gateway should not need to care if the assertion is trustworthy.
Proposed L2 Identification Scheme: A proposal was discussed to identify L2 networks using the standard 32-byte network ID format (specifically bytes 2-30 for the L2 identifier). Critically, the metadata section of this identifier must include the identifier of the parent L1 network. This allows a Gateway receiving such an identifier to infer that it is interacting with an L2 network that rolls up to a specified L1.
Rationale for L2 Identification Approach: L2 networks are inherently dependent on L1 networks for verifiability and exhibit diverse implementations (e.g., ZK-rollups, optimistic rollups). Therefore, it was suggested that L2s should not be treated as a distinct "type" in the identification scheme. Instead, they are identified similarly to L1s, with their L1 dependency explicitly signaled via metadata. The L1 network should not enumerate its associated L2s, as L2s can be independently developed on an L1.
Finality and Consistency in L2 Transfers: Concerns were raised regarding transaction finality, particularly with optimistic rollups, which may have extended settlement periods on L1. Rama's "views" draft was suggested as a potential mechanism for an originating Gateway to independently verify transaction finality on the target L1.
Cross-Layer Party Identification: The challenge of identifying parties (e.g., wallet addresses) that may exist with the same address across both L1 and L2 networks was highlighted. It was agreed that a party's address alone is insufficient; the network identifier must be explicitly included to resolve such ambiguities.
Legacy System Identification: An open question remains regarding the standardized identification of monolithic legacy systems (e.g., Swift) within the network identification framework. This would likely involve an IETF-defined prefix followed by industry-specific identifiers.

Decisions and Action Items

Action Item: Network Identification Draft Update: Thomas and Wurh will update the network identification draft to incorporate the proposed solution for L2 and L1 network identification. Target completion: before the end of the year.
Action Item: Asset Schema RFC: The team working on Asset Schemas intends to issue an RFC soon, encompassing both the asset schema definition and architecture concepts.

Next Steps

Further Elaboration on Asset Schemas: The concepts for the Asset Schema architecture will be further developed and shared with the working group mailing list.
Input on Legacy System Identification: The working group will seek input from experts regarding standard approaches to describe and identify monolithic legacy systems (Type 3 identifiers). Claire's team (Quant), Luke, and Martin were specifically mentioned as potential contributors, along with experts in NABA and European financial systems.
Wes's Comments: Wes will be sharing his comments on the core documents via the mailing list.
Next Meeting Planning: The chairs will poll the group for availability and potential agenda topics for the first meeting in the new year.