TSN Authority and Key Material: Who Holds What

TSN uses distinct key material for each role. No single key dominates the protocol, and no operator receives plaintext secrets belonging to another boundary. This page enumerates the key types, their owners, what they authorize, and how they rotate.

​

Key material table

​

Key boundaries

​

Sender/owner wallet

The root wallet signs the wallet-owner-signature-v1 envelope. This authorizes access to the TIN, derives the local data key on the current device, decrypts the seed locally, and derives the GPRU authority scoped to the exact authorization context. The plaintext seed and derived child keys never leave the device.

​

TIN owner-key commitment

This is public verification material, not private authority. It lets the Node verify that a route commitment matches the current owner without revealing the owner’s private keys or the TIN’s encrypted material.

​

Mother authority

Only Mother authority can materialize the SettlementDna PDA. This is program-enforced. There is no permit signer beyond the Node-signed permit and the Mother-rooted authorization.

​

Node permit

The Node signs a short-lived Ed25519 permit per lease. The permit binds every field required for settlement and expires no later than the Receiver lease. The Solana program re-verifies the permit signature and every bound field on chain.

​

Encrypted binding key

Node/Mother encrypt the full payment binding with a key that never leaves their trust boundary. The Cranker never receives this key, the ciphertext, or the plaintext binding.

​

Node-only route reference

After verification, the Node keeps a separate, short-lived route reference keyed by work ID. It contains the recipient TIN, signed route commitment, route version, and expiry. It is not mixed into the sender’s durable payment record and is deleted when it expires.

​

Cranker fee-payer

The Cranker pays Solana transaction fees. The fee-payer key has no authorization over amount, mint, recipient, commitments, or policy. Changing any bound field causes the on-chain instruction to fail regardless of who pays the fee.

​

Owner snapshot key

The owner device holds a snapshot key for AES-GCM decryption of EncryptedTCapBalanceSnapshotV1. The key and plaintext never leave the device. The owner fetches the public tip commitment, locates the matching ciphertext, decrypts locally, and verifies envelope bindings and commitment hash before trusting the balance.

​

Related topics

• Mother authority explains the epoch escrow and DNA model.
• Security invariants lists the canonical rules enforced by these keys.