Skip to main content
A payment intent in TSN is a sender-signed authorization that binds amount, token mint, fee limits, expiry, one-time nonce, sender authorization, funding evidence, recipient route commitment, and route version. The Node submits the resulting authorized funding work to the Receiver’s authenticated /intents endpoint. This page traces the work item from local signing through every state transition to final Solana confirmation. Understanding the lifecycle helps you build reliable integrations, debug rejections, and handle retries safely.

​
Intent structure

The sender constructs and signs the authorization locally on the authorized device. The authorization is immutable once signed: any tamper invalidates the signature. The exact HTTP payload is integration-specific; the Receiver validates the required funding fields and sender signature before the Node performs protocol verification.
Illustrative intent shape
The commitment is a tamper-evident fingerprint of the recipient’s active route. It lets the Node prove the sender approved this route version without placing the recipient’s full route map in ordinary payment work.

​
Work state diagram

REJECTED is terminal. A lease expiration may return eligible work to the queue but does not grant a Cranker authority to alter the plan.

​
State transitions

​
RECEIVED

The Node submits the authorized funding payload to POST /intents with the Node service API key. The Receiver records the work as RECEIVED and coordinates it; it does not decide that the payment is valid.

​
NODE_VERIFYING

The Node takes a short lease and verifies all of the following before returning VERIFIED:
  1. The canonical message and signatures are valid.
  2. The request exactly matches the signed message.
  3. The nonce has not been used and the authorization has not expired.
  4. The recipient TIN’s current route has the same signed commitment and route version.
  5. The amount, mint, sources, transaction commitment, and program constraints match the authorized plan.
If any check fails, the Receiver records REJECTED. A Cranker can never lease rejected or merely received work.

​
VERIFIED

After successful verification, the Node redacts the recipient identity from the durable verified payment record. The record keeps only payment/work IDs, the sender-approved amount and mint, the route commitment and version, bounded expiry/replay evidence, state, and later transaction receipts. It does not keep the recipient TIN, the full recipient route, a recipient wallet address, the raw sender authorization message/signature, or the original serialized transaction. The Node keeps a separate, short-lived recipient-route reference keyed by the work ID. It contains only the recipient TIN, signed route commitment, route version, and expiry. It expires and is deleted when no longer valid.

​
CRANKER_LEASED

A Cranker requests a short lease on verified work. The Receiver grants a time-bound lease that binds the exact work ID, amount, mint, and permitted transaction bytes. The Cranker cannot change the plan.

​
SUBMITTED

The Cranker submits the exact authorized transaction to the Solana TSN program. The program enforces the lease holder, commitment, amount, mint, expiry, and one-time/replay state. A valid signature alone is not enough if any rule does not match.

​
CONFIRMED

The Receiver records the confirmed signature and compact receipt information. Treat the confirmed Solana transaction and account state as the final evidence that the work completed.

​
What each role sees

​
Retention and redaction

After a confirmed payment, the durable Receiver record excludes the recipient TIN, full route map, recipient wallet, raw sender authorization, and original serialized transaction. Once the Cranker has confirmed payment work, the Receiver keeps a compact receipt context instead of the original authorization data. The Node’s short-lived route reference expires and is deleted.
The recipient is not chosen from an unsigned request at payout time. The Node re-resolves the recipient TIN, checks the same commitment and route version again, and selects an eligible receiving account using the verified route. If the route changed, expired, or no longer matches the sender-signed commitment, the payout authorization is refused.