Authorization versus transport
Authorization is proof that a payment may happen. The sender device signs an intent that binds amount, mint, fee limits, expiry, nonce, sender authorization, and a recipient route commitment. After verification, the Node and Mother produce a short-lived, signed ConfidentialSettlement receipt. No transport role can forge this receipt. Transport is the mechanical work of holding, verifying, and submitting. The Receiver stores work. The Node verifies signatures and policy. The Cranker pays network fees and submits the already-authorized transaction. Transport roles never decide who gets paid or how much.What each role can and cannot do
Cranker is strictly bound
The Cranker cannot change any material field of the transaction it submits. It receives only the opaque slot, commitment digest, nullifier, public recipient coordinates, mint, amount, vault, and signed permit. It learns the payout destination only inside the short-lived claim authorization. If the Cranker tries to alter the plan, the TSN program rejects the transaction before any token movement.Privacy boundaries
The Node stores the full payment binding as an encrypted off-chain record. The encryption key never leaves Node/Mother. The Cranker never receives the encrypted record, a private escrow address, a record PDA, or a funding-account secret. The slot is deliberately absent from the funding transaction.On-chain enforcement
The TSN program is the final enforcement point. It repeats every authorization check on chain: permit signature, lease validity, slot state, nullifier consumption, and treasury liability. The first valid settlement or refund wins atomically; a later operation against the same slot fails before any transfer.Related pages
- Separation of concerns for how TSN, TIN, GPRU, and TCAP divide responsibility
- Mother authority for how Mother materializes the SettlementDna PDA
- Node, Receiver, Cranker for the operational flow
- Security invariants for formal checks the program enforces