Skip to main content

Overview

Dynamic’s Node SDK provides support for TRON blockchain operations, including wallet creation, transaction signing, message signing, and key management. Wallets are MPC-backed, so no complete private key exists in one place during signing. If you use the export methods covered in these guides, the exported key is complete key material and must be protected accordingly.

Key Features

  • MPC Wallet Creation: Create secure TRON wallets with threshold signature schemes
  • Transaction Signing: Sign TRON transactions from their raw_data_hex without exposing private keys
  • Message Signing: Sign messages using the TIP-191 standard (signMessageV2)
  • Key Import/Export: Import existing private keys and export wallet data
  • Multiple Security Models: Choose between different threshold signature schemes

Available Threshold Signature Schemes

  • TWO_OF_TWO: Maximum security, requiring both server and Dynamic infrastructure
  • TWO_OF_THREE: Balanced security and availability, requiring 2 out of 3 shares
  • THREE_OF_FIVE: High availability, requiring 3 out of 5 shares

Quick Start

Core Functions

Wallet Management

  • createWalletAccount() - Create new TRON wallet
  • importPrivateKey() - Import existing private key
  • getWallet() - Get specific wallet details
  • getTronWallets() - Get all TRON wallets
  • deriveAccountAddress() - Derive the TRON address from an MPC public key (synchronous)

Signing Operations

  • signMessage() - Sign messages using TIP-191 (also available as signMessageV2())
  • prepareSignMessage() - Compute the TIP-191 digest that signMessage() signs
  • signTransaction() - Sign a TRON transaction and return the broadcast-ready JSON

Key Management

  • exportPrivateKey() - Export the wallet’s private key
  • exportKey() - Export wallet key data
  • offlineExportPrivateKey() - Export private key from key shares offline
  • encryptKeyShare() - Encrypt key shares
  • decryptKeyShare() - Decrypt key shares

Backup and Recovery

  • storeEncryptedBackupByWallet() - Store encrypted backup
  • recoverEncryptedBackupByWallet() - Recover encrypted backup
  • refreshWalletAccountShares() - Refresh wallet shares

Guides

Prerequisites

Before using the TRON SDK, ensure you have:
  1. Dynamic Project Setup: Set up your Dynamic project
  2. Environment Configuration: Configure your environment ID and auth token
  3. TRON Chain Enabled: Enable TRON chain in your Dynamic developer console
  4. Dependencies Installed: Install required packages

Installation

Environment Variables

TRON-Specific Concepts

Address Format

TRON addresses are Base58Check strings that start with T. The SDK derives the address by taking the keccak256 hash of the uncompressed secp256k1 public key, keeping the last 20 bytes, prefixing them with 0x41, and encoding the result as Base58Check.

Message Signing (TIP-191)

TRON signs messages using the TIP-191 standard, the same signMessageV2 surface exposed by TronLink. There is no V1 message-sign path for TRON. The SDK applies the \x19TRON Signed Message:\n<length> prefix and keccak256 hashing client-side, then sends the 32-byte digest through the sign path.

Transaction Signing

TRON transactions are assembled by a full node (for example, via /wallet/createtransaction or /wallet/triggersmartcontract), which returns an unsigned transaction containing a raw_data_hex field. The SDK signs the SHA-256 digest of raw_data_hex, appends the signature to transaction.signature, and returns the complete transaction as a JSON string ready for /wallet/broadcasttransaction.

Native Unit

TRON uses SUN as its smallest unit: 1 TRX = 1,000,000 SUN.

Network Support

Mainnet, Shasta, and Nile share the same address format and keyshare namespace. The network is selected at the broadcast layer by the full node you build raw_data against:

Security Considerations

  • MPC Architecture: Private keys are never stored in plain text
  • Threshold Signing: Multiple parties must collaborate to sign transactions
  • Key Share Backup: Use backUpToDynamic: true for secure storage
  • Password Protection: Implement strong passwords for additional security layers

Error Handling

Always implement proper error handling:

Next Steps

Last modified on October 15, 2026