How an asset transaction is signed

The path

1. Console — collects what you want to do and sends it to the Gateway. It holds no key and never receives one.
2. Gateway — builds one immutable intent from your request and the chain's current state, fingerprints it, stores it, and returns the review projected from that intent.
3. Confirmation — names the fingerprint. The body is ignored entirely; there is no field that could change what was reviewed.
4. Custody — receives a *semantic operation*, derives the signer from the key it holds, builds the transaction and the sign document itself, and signs.
5. Chain — accepts or refuses. Its answer is recorded against the intent.
6. Indexer — reads the result back, and the Console shows it with the height it was read at.

What does not cross the boundary

Custody accepts an operation, not bytes. There is no sign(bytes), no digest, no raw sign document and no arbitrary type URL — in either direction, and not as a field that exists and is unused. A signing service that will sign whatever it is handed is a signing service that will sign anything.

Key material never leaves Custody. There is no export, no debug path and no method that returns a private key. What comes back is a public key, an address, and a signature.

Displayed equals signed

The fingerprint covers the operation, every field of it, the signer, the chain id, the account number, the sequence, the fee and the gas — and the organization it belongs to, so two organizations issuing an identical transaction have different fingerprints. Change any of them and it is a different intent with a different fingerprint, which this deployment did not issue and will not sign.

Confirming an intent that already has an answer returns that answer. It does not sign again.