**Session Date/Time:** 09 Feb 2026 14:00

# [SATP](../wg/satp.html)

## Summary

The SATP Working Group held an interim meeting to discuss the status of its initial documents and to review a proposed recharter. The three core documents (SATP Core, Usage, and Architecture) are with the Area Director (AD) for final review. The main focus of the meeting was an extensive discussion on the proposed new charter text, particularly the objectives, goals, and a list of new deliverables. Strong interest was expressed in including "asset exchange" as a key deliverable.

## Key Discussion Points

*   **Existing Document Status**: The three core documents (SATP Core Protocol, Usage Document, and Architecture Document) are complete and have been submitted for AD review. The IANA registration process for these documents will occur during the AD review phase, managed by IANA directly.
*   **Rechartering - Objectives Section**:
    *   **Scope of Assets**: A suggestion was made to explicitly include "e-money tokens" or "tokens" alongside "real-world private assets" to align with regulations like MICA, though the general term "assets" was argued to be broad enough.
    *   **Data as an Asset**: Peter proposed adding "data as an asset" to the examples. Concerns were raised about the semantic differences between transferring fungible assets (where the asset disappears from one network and reappears in another) and data. The use case document was suggested as a better place for detailed examples.
    *   **Exchange Interoperability**: Luke advocated for explicitly covering "exchange interoperability" in the charter's objective, beyond just asset movement, as it's a critical use case with minor protocol modifications.
    *   **Gateway vs. Owner Focus**: Ned requested clarification that the protocol focuses on "gateway to gateway" interactions, rather than directly "owner to owner," and how authorization/ownership is handled in this context.
    *   **ACID Properties**: Ned raised the importance of explicitly mentioning the ACID properties (Atomicity, Consistency, Isolation, Durability) of transfers, particularly avoiding double-spending, to differentiate SATP from other gateway technologies. While this is inherent in the two-phase commit, its explicit mention in the charter was considered useful for clarity.
*   **Rechartering - Goals Section**: The phrase "peer gateways" was suggested to be expanded to "peer entities or gateways" or "gateways or owners" to better reflect the potential endpoints.
*   **Rechartering - Deliverables Section**:
    *   The chairs presented five proposed new deliverables, distilled from previous WG discussions and surveys:
        1.  Stage Zero / Onboarding
        2.  A method for registering and discovering network, asset, and gateway information
        3.  A protocol for communicating asset-related information (beyond just transfer)
        4.  Requirements for asset networks to participate in SATP
        5.  Threat model for SATP
    *   **"Requirements for Asset Networks"**: This deliverable sparked significant discussion regarding its wording.
        *   Ned found "Requirements" too broad and suggested focusing on "asset properties" or "system architecture context" using "ility" words (availability, integrity, security).
        *   Denis clarified the intent was to define requirements for *implementing* ACID properties (e.g., locking, rollback capabilities) within a network.
        *   Claire cautioned against imposing asset network requirements, emphasizing that it should instead define what a *gateway implementation* needs to consider to interoperate, maintaining network agnosticism.
    *   **"Threat Model"**: Ramit questioned the scope and output of a threat model document, especially concerning its coverage for both transfer and exchange, and its potential for becoming a living document. The chairs noted its commonality in IETF for identifying security aspects.
    *   **Asset Exchange as a Deliverable**: Luke, Thomas, and Dennis strongly advocated for including "asset exchange" as a deliverable. Luke highlighted that existing work on exchange involves minor modifications to SATP core and could be an "easy win" for the group. There was a sense that the other five deliverables largely apply to both transfer and exchange without significant additional work.
    *   **Number of Deliverables**: The chairs noted that the ADs typically prefer a limited number of deliverables (e.g., five). The discussion revolved around whether to swap out an existing item for exchange (Thomas suggested swapping out the Threat Model for later) or to propose six deliverables and make a case to the ADs, given the strong interest and perceived low effort for exchange.

## Decisions and Action Items

*   **Decision**: To include "Asset Exchange" as a new deliverable in the proposed recharter, making a total of **six** proposed deliverables.
*   **Action Item**: Chairs (Claire and Wes) will clean up the proposed charter text, incorporating feedback from today's discussion (including refining wording for "Requirements for Asset Networks" and "Registry" to be more generic and problem-focused, and adding "asset exchange").
*   **Action Item**: The refined proposed charter will be posted to the SATP mailing list for further review, wordsmithing, and discussion.
*   **Action Item**: The chairs will engage with the IESG to seek approval for the recharter, advocating for the expanded list of deliverables based on the WG's dedication and the perceived effort levels.

## Next Steps

1.  Chairs to revise the proposed charter document incorporating the day's feedback.
2.  The revised charter will be circulated on the SATP mailing list for broader WG review and final comments.
3.  The chairs will then submit the recharter proposal to the IESG and engage in discussions to gain approval for the defined work items, including the newly added asset exchange.
4.  The WG will continue its practice of frequent interims to maintain progress on the expanded set of deliverables.