Skip to main content
TSN splits transport into three non-overlapping roles: the Receiver accepts and stores work, the Mother Node verifies and coordinates it, and independent Cranker Nodes submit the exact authorized transaction. “Mother Node” is the public architecture role; tsn-node remains the implementation name used by existing paths and configuration. None of these services holds a user private key, and none can alter the payment plan after it is signed.

​
Receiver: durable ingress and work storage

The Receiver is authenticated ingress for payment intents. It uses Firestore for accepted work, state transitions, idempotency, short leases, and compact confirmation receipts. When a sender submits a signed intent, the Receiver stores it and marks it RECEIVED. The Receiver does not verify the plan, choose a recipient, or sign a Solana transaction. It also never receives plaintext roots or private snapshots. Its job is to hold work briefly and hand it off to the Node for verification.

​
Mother Node: stateless verification and route decisions

The Mother Node takes a short lease on received work and performs verification before any Cranker Node can act. It checks:
  1. Canonical 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 matches the signed commitment and route version.
  5. The amount, mint, sources, and transaction commitment match the authorized plan.
If all checks pass, the Node returns the work as VERIFIED with the recipient identity redacted from the durable record. The Node keeps a separate, short-lived Node-only route reference keyed by work ID that contains the recipient TIN, signed route commitment, route version, and expiry. This reference expires and is deleted; it is never mixed into the sender’s payment work.

​
Cranker Node: exact submission only

Any admitted Cranker Node can lease verified work. It is an executor, not a decision-maker. For payment funding, it submits the exact sender-authorized epoch-treasury transaction. For a claim payout, it submits the exact Mother-Node-authorized, lease-bound settlement transaction. The Mother-DNA admission boundary identifies the participant; it is not an IP-based presence system. After submission, the Cranker returns the Solana transaction signature and confirmation result. It cannot change the amount, token, recipient binding, commitments, sequence, policy, nullifier, or expiry. The current implementation is a Python daemon.

​
Work lifecycle

Every payment moves through the following states:
REJECTED is terminal for invalid work. A lease expiration may return eligible work to the queue, but it does not grant the Cranker authority to alter the plan. The Cranker must re-lease the exact same work if the lease expires and the work is still valid.

​
Summary of boundaries