Summary

  • SATP Core revision 17 says aborts before Commit-Final can still reverse an origin lock or a destination self-mint; an abort after the sender has burned the origin asset is ineffective.
  • The current Core does not support session recovery or resumption. Its companion architecture requires logs and checkpoints, while leaving interoperable log semantics and the restart point to future or local work.
  • An operator therefore needs a point-of-no-return ledger that distinguishes a message sent, a peer receipt, a gateway assertion and observed state in each opaque asset network.

The danger begins with a perfectly valid message.

A sender gateway has already transmitted Commit-Final, asserting that it extinguished the asset in the origin network. The connection drops before the sender receives the destination gateway's final acknowledgement. An incident operator presses abort. The request may be signed, correctly addressed and recorded. It still cannot put the original asset back.

That is not an implementation corner hidden between clauses. Section 11.5 of SATP Core revision 17 says an abort after Commit-Final is ineffective: the sender has burned the origin asset, while the receiver has minted an asset and committed to assign it to the beneficiary. The protocol label “abort” no longer describes a reversible state transition.

The timing matters because revision 17 entered IETF Last Call on 25 September 2026, with comments due by 9 October. The Datatracker history records an active Internet-Draft being considered for Proposed Standard publication. It is not yet an RFC, and the record proves no deployment or completed transfer.

SATP connects two gateways representing asset networks that remain opaque to one another. The architecture asks a transfer to preserve atomicity, consistency, isolation and durability. Yet it also states a harder truth: messaging interoperability can communicate intent and state claims, but is insufficient by itself to ensure those properties. The underlying systems must actually update state in concert.

The protocol makes that separation visible through stages. Stage 0, outside Core's scope, may establish the application context, identify originator and beneficiary, validate gateway ownership, carry regulatory information and negotiate parameters. A gateway entering Stage 1 is not proof that those external decisions were correct. It means the gateways have a context in which they can propose a transfer.

Stage 1 signs the proposal and its receipt, then exchanges Transfer-Commence and ACK-Commence. The receipt hashes the initialization claim; later messages hash their predecessors. The chain is valuable evidence about which gateways agreed to which bytes and in what order. It is not evidence that the asset has moved.

Stage 2 introduces the first state constraint. The sender transmits a signed lock assertion saying that the origin asset is locked or escrowed to prevent another change. Core says the claim format depends on the origin network and is outside the specification. The receiver must validate the payload before continuing, then sends an assertion receipt. That receipt proves acceptance of a claim. It does not magically grant the receiver direct vision into the origin ledger.

Stage 3 approaches the irreversible edge. It must finish before lockAssertionExpiration. In Commit-Ready, the receiving gateway says it has minted an equivalent asset, assigned that asset to itself and is ready. Before this message, an abort can still let the sender unlock the origin asset; after Commit-Prepare but before Commit-Ready, the receiver can reverse its own provisional state.

The next message changes the recovery vocabulary. Commit-Final carries the sender's signed burn assertion. It says the origin asset has been extinguished. ACK-Final then says the receiver assigned the newly minted asset to the intended beneficiary. Only after that does Transfer-Complete close the session.

Those are deliberately different receipts. Commit-Ready is not beneficiary assignment. Commit-Final is not an acknowledgement from the destination. ACK-Final is not the sender's closure message. Compressing all three into a dashboard value called “committed” discards the very evidence needed when the connection fails between them.

The abort path has its own uncertainty. Core notes that an abort can be lost and that a gateway can crash before receiving it. A control plane should therefore record at least four events: abort requested locally, abort message sent, peer receipt or other evidence of reception, and local network state restored. The first three do not imply the fourth.

The recovery gap makes this more than terminology. Section 10.8 says session recovery and resumption are not supported in the current Core. The companion architecture requires implementations to maintain event logs and checkpoints for crash recovery, and imagines a backup gateway continuing an interrupted transfer. But it also says the log syntax and semantics are future work and the restart point depends on the implementation's recovery strategy. RFC 5424 offers a possible logging foundation, not a SATP replay contract.

Transport and message security cannot fill that gap. Core requires TLS 1.3, standardized in RFC 8446, and signs SATP messages using JWS from RFC 7515. Errors use RFC 9457. These mechanisms protect channels, bind assertions to keys and structure failures. They do not prove that a gateway's network-specific burn, mint or assignment claim corresponds to running state.

That boundary also limits the word “legal.” Core explains why a post-burn abort cannot reverse the flow partly by saying the receiving gateway has legally agreed to assign the asset. Protocol evidence can preserve the signed agreement. Whether the gateway owner had authority, whether the beneficiary was eligible and what remedy applies are Stage 0 or external legal questions, not conclusions a message type can settle.

The SAT use cases make the consequence concrete without proving adoption. A bill of lading, letter of credit or other digital asset may carry rights across trade, logistics or finance networks. In such a setting, a duplicate, missing or stranded representation is not merely a protocol statistic. The protocol still needs network-specific proof about what each system actually did.

A usable point-of-no-return ledger should bind the session ID and transfer-context ID to every signed message and predecessor hash. It should add the exact asset and profile identifiers, gateway identities, negotiated algorithms, lock expiry, send and receive times, origin lock and burn evidence, destination mint and assignment evidence, network finality, crash generation, and every abort request and receipt. The record should name the last stage both gateways mutually evidenced, not the most optimistic state one gateway reports.

Heng Lu's Running-Code Primacy provides the editorial discipline: the running systems decide whether state changed; the coordination artifact must not claim more authority than its evidence supports. Minimum Initial Specification supports a narrow common wire contract while leaving network-specific execution local. Reality Layers warns against promoting a symbol into the reality it names.

SATP's signed messages can make a cross-network commitment auditable. Their value increases when their limits are preserved. After Commit-Final, “abort” is not rollback. It is a late instruction arriving on the far side of an irreversible act.

Sources