Summary

  • On 25 September the IESG opened Last Call on SATP Core revision 17 as a possible Proposed Standard, with comments due 9 October. The draft has not been approved as an RFC.
  • The draft says an abort's effect depends on the stage of the transfer. Once the sender transmits commit-final, a subsequent abort is ineffective; an abort message may also be lost if a gateway crashes.
  • The current core expressly does not support session recovery or resumption. That is a protocol-scope limit, not proof that every outside recovery arrangement fails.

The most important moment in an asset transfer is not when a gateway sends its first proposal. It is when the parties can no longer safely treat a cancellation as an undo command. SATP Core, now in IESG Last Call, spells out that distinction in its message sequence. This is a new review of the proposed Standards Track protocol itself; the architecture and use-case documents that entered a separate Last Call two days earlier seek Informational status and ask different questions.

SATP is intended for two gateways, each speaking for a different digital-asset network. The core uses a secure channel and a two-phase commitment process to coordinate one valid asset state across networks. Its sequence is not a single atomic button press. The sender first locks the origin asset and provides a signed assertion. In the commitment stage, the receiver prepares and mints an asset under its control, signals readiness, the sender burns the origin asset, and the receiver subsequently assigns the destination asset to the beneficiary.

Each message marks a state that operators must be able to identify, not merely a line in a happy-path diagram.

Section 11.5 is unusually direct about cancellation. An abort sent after the lock but before the receiver declares itself ready can allow the sender to unlock the origin asset; the draft also describes reversing destination-side changes before that ready point. But it cautions that an abort message may never reach the peer when a gateway crashes. After the sender transmits commit-final, the draft says an abort is ineffective, explaining that burn and mint have crossed the relevant commitment boundary. This is not a claim that every failed exchange causes permanent loss. It is a warning against treating the presence of an abort message type as a universal recovery guarantee.

The adjacent silence matters as much as the named messages. Section 10.8 says session recovery and resumption are not supported in this version and may be specified later, either in another version or separately. A reader could miss that sentence while focusing on two-phase commit and assume an interrupted session has a defined path back into the exchange. The document itself does not supply one. Whether operators can reconcile states using external agreements, records and manual processes is a separate operational question; the draft's omission should not be inflated into a claim that recovery is impossible.

The security section gives this boundary economic weight. It discusses denial of service, delays or deliberate message drops at crucial points, possible network fees and financial loss for a gateway operator. These are risks identified by draft authors, not reports of a named incident. The working-group charter likewise places likely legal or other inter-network agreements outside SATP's scope. A signed message can record what a gateway asserted; it cannot by itself settle who bears the consequence of a lost final acknowledgement or a dispute over an interrupted transfer.

On 25 September the IESG asked the community to comment on revision 17 by 9 October. That opens a review window; it is neither a certificate of safe deployment nor a guaranteed publication date. The useful question for reviewers is not whether the protocol has an abort message, but which precise state transitions remain reversible, what evidence survives a peer failure, and what an operator must do when the protocol specifies no resumption. Those are testable boundaries to put beside a proposed standard before the marketing shorthand of “seamless transfer” hardens around it.

Sources