The State Transition SDK is a TypeScript library that provides an off-chain token transaction framework. Tokens are managed, stored, and transferred off-chain with only cryptographic commitments published on-chain, ensuring privacy while preventing double-spending through single-spend proofs. This is a low-level SDK, that supports transferring tokens, making payments, and splitting tokens. In this system, tokens are self-contained entities containing complete transaction history and cryptographic proofs attesting to their current state (ownership, value, etc.). State transitions are verified through consultation with blockchain infrastructure (Unicity) to produce proof of single spend.
- Off-chain Privacy: Cryptographic commitments contain no information about tokens, their state, or transaction nature
- Horizontal Scalability: Millions of transaction commitments per block capability
- Zero-Knowledge Transactions: Observers cannot determine if commitments refer to token transactions or other processes
- Offline Transaction Support: Create and serialize transactions without network connectivity
- TypeScript Support: Full type safety and modern development experience
- Modular Architecture: Pluggable address schemes, predicates, and token types
npm install @unicitylabs/state-transition-sdkEnd-to-end runnable examples live under tests/examples/:
- Mint:
tests/examples/mint/ExampleTest.ts - Transfer:
tests/examples/transfer/ExampleTest.ts - Split:
tests/examples/split/ExampleTest.ts
Tokens are shipped between parties as CBOR — use token.toCBOR() on the sender side and Token.fromCBOR(bytes) on the receiver side.
A thin client over the aggregator. As a consumer you'll typically:
- Build a
MintTransactionorTransferTransaction. - Submit its
CertificationDataand wait for an inclusion proof. - Turn it into a certified transaction and apply it to a
Token(Token.mint/token.transfer). - Call
token.verify(...)on the receiving side.
StateTransitionClient covers step 2 only:
submitCertificationRequest()- Submit a commitment to the aggregatorgetInclusionProof()- Retrieve an inclusion proof for a state id
- Minting: Create new tokens
- Transfer: Submit state transitions between owners
Prerequisites Recipient knows some info about token, like token type for generating address.
A[Start]
A --> B[Recipient Generates Predicate]
B --> C[Recipient Shares Predicate with Sender]
C --> D[Sender Creates Transaction]
D --> E[Sender Submits Transaction]
E --> F[Sender Retrieves Inclusion Proof]
F --> G[Sender Creates Certified Transaction]
G --> H[Sender Updates Token with Certified Transaction]
H --> I[Sender Sends Token to Recipient]
I --> J[End]
A Token is a self-contained, CBOR-serializable record that bundles its genesis with an ordered transfer history:
genesis: aCertifiedMintTransaction(aMintTransactionplus itsInclusionProof). The mint transaction carriesnetworkId,tokenId,tokenType,salt,recipient, optionaljustification, and optionaldata.transactions: an ordered list ofCertifiedTransferTransactionentries, each wrapping aTransferTransaction(recipient, state mask, optional data) with itsInclusionProof.
See src/transaction/Token.ts for the authoritative shape.
- Commitment-based: Only cryptographic commitments published on-chain
- Self-contained: Tokens include complete transaction history
- Zero-knowledge: No information leaked about token or transaction details
- Minimal footprint: Blockchain only stores commitment hashes
- Double-spend prevention: Enforced through inclusion proofs
- Cryptographic verification: All state transitions cryptographically verified
- Predicate flexibility: Multiple ownership models supported
- Provenance tracking: Complete audit trail in token history
npm run buildRun the default suite (unit + functional tests):
npm testRun the example flows (requires a reachable aggregator; URL is read from each example's config.json):
npm run test:examplesRun the end-to-end suite (expects a local aggregator at http://localhost:3000 — see tests/e2e/E2ETransitionFlowTest.ts):
npm run test:e2eLint all code (source and tests):
npm run lintLint with auto-fix:
npm run lint:fix- Test Gateway:
https://gateway-test.unicity.network - Network identifiers:
NetworkId.MAINNET,NetworkId.TESTNET,NetworkId.LOCAL - Token type: caller-supplied; use
TokenType.generate()or construct from explicit bytes
The Unicity Network uses a standardized signature format to ensure data integrity and cryptographic proof of ownership. All cryptographic operations use the secp256k1 elliptic curve, SHA-256 hashing, and 33-byte compressed public keys.
The standard is designed for efficiency and broad compatibility across different programming environments, including Node.js, browsers, and Go.
A Unicity signature is a 65-byte array, structured as the concatenation of three components: [R || S || V].
| Component | Size (bytes) | Offset | Description |
|---|---|---|---|
| R | 32 | 0 | The R value of the ECDSA signature. |
| S | 32 | 32 | The S value of the ECDSA signature. |
| V | 1 | 64 | The recovery ID (0 or 1). This value allows for the recovery of the public key directly from the signature. |
1. Signing
The raw message data is first hashed using SHA-256. The resulting 32-byte hash is then signed using the signer's 32-byte secp256k1 private key to produce the 65-byte signature.
2. Verification The verifier hashes the original message using SHA-256. Using this hash and the signature, the verifier recovers the public key. The recovered key is then serialized into the compressed format and compared byte-for-byte against the expected 33-byte compressed public key to confirm validity.
This project is licensed under the MIT License - see the LICENSE file for details.
- Repository: GitHub
- Issues: GitHub Issues
- Gateway API:
https://gateway-test.unicity.network
Note: This SDK is part of the Unicity ecosystem. For production use, ensure you understand the security implications and test thoroughly in the testnet environment.