Summary

  • IETF Last Call on SATP Core revision 17 runs through 9 October 2026; the companion Architecture and Use Cases drafts are in Last Call through 7 October and remain work in progress.
  • SATP’s signed, hash-linked messages make the gateways’ ordered assertions auditable, culminating in ACK-Final-Receipt, where the receiver gateway asserts assignment to the intended beneficiary.
  • Burn and mint proofs remain specific to each asset network, while portable crash-recovery log semantics are future work. The final receipt is strong transcript evidence, not a universal readback of both networks or beneficiary control.

A receipt with a precise issuer

SATP Core describes a transfer between a sender gateway and a receiver gateway representing different asset networks. Its burn-and-mint sequence uses a two-phase commitment model and states an objective of atomicity, consistency, isolation and durability. On 25 September, the IESG opened Last Call on revision 17 for Proposed Standard. The Architecture and Use Cases companions entered Last Call two days earlier as proposed Informational documents. None is yet an RFC.

The protocol builds an unusually useful common record. Messages are signed and linked to the preceding message by hash. The receiver gateway’s Commit-Ready carries its assertion that an equivalent asset has been created and is ready. The sender gateway’s Commit-Final carries a signed burn assertion. The receiver gateway then issues ACK-Final-Receipt, asserting that the destination asset was assigned to the intended beneficiary. Receipt of that message completes Stage 3 in the current draft.

That chain can establish who made each protocol claim, in which session, and after which prior message. It raises the cost of rewriting the conversation and gives authorized third parties material for audit or dispute. Those are substantive properties. They should not be diluted by calling the receipt merely administrative.

But the signature identifies the asserting gateway; it does not turn the gateway into an independent sensor of every external fact named inside the assertion. The evidentiary question is therefore not whether the receipt is “real”. It is what, exactly, the receipt proves.

The layer below the transcript

The Architecture draws the boundary candidly. Burn and mint mechanisms are specific to each asset network and outside its scope. Cryptographic proof that an asset was burned or minted is likewise network-specific. A public ledger might expose a transaction and finality rule. A permissioned system might supply a signed state query, an operator record or a different settlement proof. SATP does not force those heterogeneous systems into one universal proof object.

That is a defensible interoperability choice. Gateways need a shared conversation even when their local systems have different semantics. The consequence is that an auditor may need at least two evidence families: the SATP transcript showing the gateways’ claims and the network-specific records supporting those claims. A third record may be needed to show that the beneficiary can actually control or use the destination asset. Assignment asserted by the receiver gateway and possession demonstrated by the beneficiary are related, but not identical, facts.

The irreversible boundary makes the distinction operational. Core says an abort before the origin asset is burned can be reversed with comparatively limited cost. After Commit-Final, abort is ineffective: the origin asset has been burned, the destination asset minted, and the receiver gateway has agreed to assign it. At precisely that point, a decision-maker needs evidence from the systems that carried out the irreversible changes, not only evidence that the gateways exchanged the expected messages.

Durability is not yet a portable recovery contract

The Architecture requires implementations to maintain event logs and checkpoints. It imagines a backup gateway resuming a transfer if the log is accessible and standardized, yet says the restart point depends on the implementation’s recovery strategy. It lists crash-management log semantics and syntax as future work. Core revision 17 is even more direct: session recovery and resumption are not supported in the current version.

This does not prove that implementations cannot recover. An operator may maintain durable state, replicate keys and checkpoints, or build a safe local recovery procedure. It means the inter-gateway protocol does not yet give an independent operator a portable recipe for interpreting another implementation’s checkpoint and resuming the same session.

TLS 1.3 can protect the channel. JWT can encode an assertion. Syslog may inform a future recovery format. Each is useful at its own layer. None independently observes the origin network, the destination network, beneficiary possession or the exact durable state from which a replacement process may safely continue.

Heng Lu’s disclosed analytical lens is helpful here: trust and mechanisms should not be collapsed, and a recorded assertion should not be treated as operational truth beyond what the control surface can observe. SATP makes gateway trust explicit. Leadership can accept that trust model while still requiring the evidence bundle appropriate to an irreversible transfer.

Sources