The Anatomy of SATP

Inside one ledger, moving value is easy: a single consensus decides the order of events, so a transfer either happened or it did not. Across two ledgers there is no shared decider. Each chain will happily accept a write without knowing anything about the other, which is exactly how the same value ends up existing twice, or vanishing entirely.[1][8]

The temptation is to trust a bridge: a piece of software that watches one chain and writes to the other. That works until it does not. Most large interoperability failures were not consensus failures; they were failures of the component in the middle, which had authority over assets and no protocol constraining what it could claim.[7]

SATP takes a narrower position. It does not try to make two chains agree. It defines a conversation between two gateways, each of which is the only authorised agent for its own network, and it fixes the order of that conversation so that no intermediate state is dangerous. Value is locked before anything is created. Value is created before the original is destroyed. Each party signs what it saw, and each signed message commits to the previous one, so nobody can later claim a different agreement was made.[9][5]

If a gateway crashes mid-transfer, the session is not lost: the protocol's recorded state is what recovery works from, which is the subject of a separate draft.[11] And whether you need any of this in the first place is itself a design question worth asking before adopting an interoperability solution.[4][3]

Hyperledger Cacti implements SATP as the cactus-plugin-satp-hermes package. Everything below is read from one file in that package, core/satp-protocol-map.ts, which declares the entire protocol as an ordered list of steps. That list is the ground truth for this page: the table table and the animation in Chapter 3 are the same 36 steps, in the same order.

Stage 1 is the negotiation that everything else rests on. Four messages: a proposal, a receipt, a commence request and an acknowledgement. After them, both gateways hold signed evidence of exactly the same terms, and only then may an asset be locked.

Pick a message and open its fields. Every field carries a plain-language note saying what it is and why it exists; the highlighted rows are the hash and signature fields that chain the messages together. Switch to the raw view to see the same object as it appears on the wire, in the shape the Cacti v02 proto defines.

The picture starts before SATP does. Alice, a human operator, asks her application to move the asset; the application then activates a transfer in its own gateway. Those two hand-offs are the dashed arrows on the left of the diagram: they are ordinary API calls, not protocol messages, and everything after them is SATP.

Four parties then matter: Alice's application, the gateway that speaks for Alice's network, the gateway that speaks for Bob's network, and Bob's application. The two gateways take roles, not identities: whichever gateway starts the transfer is the client, the other is the server. The same software can be either.

Scroll the steps below and watch three things: which lane the message is on, which gateway is checking rather than sending, and what the two ledger bands at the bottom say. Stage 0 covers discovery and session setup and is being specified in the IETF draft draft-avrilionis-satp-setup-stage; stages 1 to 3 are the standardised protocol.[9]

The invariant to watch for is in the last stage: the asset is minted on the destination while it is still locked at the source, and only then is the source copy burned and the destination copy assigned to Bob. At no point does the value exist twice as spendable, and at no point does it exist nowhere.

Everything in the previous chapters happens between two gateways. Before any of it starts, an application has to ask its own gateway for a transfer, and then follow that transfer to completion. That local interface is API1.

Scaffold — this chapter is planned. It will walk through the transfer request, the session identifier handed back, the status calls the application polls, and the final receipt, with the same lane-diagram treatment used for the gateway conversation.

A gateway never writes to a ledger directly. Each supported network has an adapter: a bridge object in the plugin, a connector to the network, and a wrapper smart contract that owns the lock, mint, burn and assign operations.

Scaffold — this chapter is planned. It will use a worked example from the Cacti demos to show the same protocol step landing on Besu and on Fabric through two different adapters.

Every earlier chapter looks at one layer in isolation: the messages, the stages, the API the application calls, the adapter that reaches the ledger. This chapter walks the Hyperledger Cacti CBDC demo, where those layers run together: a central-bank digital currency issued on one network is moved to a second network while the applications on both sides keep their own view of the user's balance.

The narrative follows one transfer from the operator's click in the sender application, through gateway activation, the four Stage 1 messages, the lock and burn on the origin ledger, the mint and assign on the destination ledger, and finally the gateway telling the receiving application that the value has landed.

Scaffold — this chapter is planned. Todos:

• Diagram the full stack: two CBDC apps, two gateways, Besu and Fabric, with the API1 and adapter boundaries marked.
• Trace one transfer end to end, reusing the Stage 0–3 step ids from Chapter 3 so the same vocabulary carries over.
• Show the balance view on both sides before and after, to make conservation of value visible.
• Point at the concrete Cacti demo packages and the commands used to run them.
• Explain what an operator sees when a transfer is recovered or rolled back mid-flight.