Skip to main content
A team can build the TSN programs, services and SDK from the repository and operate them under its own deployment configuration. Running services against TrustLink’s existing Devnet program IDs shares the existing governed chain state. Deploying independent programs requires matching new IDs, authorities, account initialization and SDK/runtime bindings; several supplied helpers currently use fixed reference IDs. The canonical build and operation guide covers tool/dependency installation, Windows and WSL commands, four-program deployment, TIP/Mother/TCAP/asset initialization, thirteen-input proving artifacts, funding root, explicit credit rekey and separate five-input epoch verifier enrollment, persistent Node configuration, protected amount-opening journal, witness snapshots, Receiver/Cranker setup and application integration. Its source obligations and unverified clean-machine/independent-network gates are explicit.

​
Installation order

  1. Choose the reference deployment or reconcile every program/SDK/service binding for new IDs and authorities.
  2. Install the host/deployment tools and build the local SDK dependencies.
  3. Deploy TIP, TSNP, TCAP and GPRU; verify binaries/authorities separately from account initialization.
  4. Initialize TIP, Mother, TCAP registry/state, assets and funding root; enroll exact private-credit and separate epoch verifiers.
  5. Provision matching native/proving artifacts, metadata pins, persistent witness state and dedicated service keys.
  6. Configure/start the gateway, Receiver, Node and registered Cranker, then build the SDK/app.
  7. Verify identity, real pool capture/release, private credit, complete epoch accounting and owner recovery separately.

​
Operating boundaries

The Receiver owns durable work coordination, Node verifies and prepares proofs, and Cranker submits permitted transactions. A healthy endpoint or accepted work does not establish a completed credit. Native funded-note credit is separate from retained epoch/DNA payout/refund, debit/exit and cross-chain capabilities. The private-amount replacement remains experimental. Real local credit/epoch proofs and native verification passed with matching development keys; SBF build, on-chain activation and complete live accounting remain unverified. Historical November 5 credit was amount-public. Development artifacts are not a production ceremony. Public deposits, epoch totals, token/roots/ciphertext/timing and Node knowledge remain privacy boundaries. Use SDK setup, payment integration and failure recovery for app code. In particular, an expired owner-signed funding blockhash needs a fresh wallet signature after reconciling the original attempt; a confirmed reserve deposit with incomplete settlement should be recovered through that existing work rather than funded again. The former twelve-input Node Memo-validation error has a scoped authenticated retry after loading the corrected thirteen-input validator; see Receiver recovery.