Tari Protocol Documentation

repository·development·Indexed 19 days ago

https://github.com/tari-project/tari

A privacy-centric protocol featuring a suite of applications including nodes, wallets, miners, and MCP servers for AI integration. Documentation covers the minotari_console_wallet (TUI, gRPC, and script modes), the minotari_ledger_wallet installation and development for Ledger devices (Nano S Plus, Nano X, Stax, Flex), and the minotari_app_grpc crate for cross-application gRPC definitions.

Tokens
247.9K
Snippets
747
Records
1.2K
Agent score
66%

What's inside Tari

  1. Overview of Tari Core

    development
    Tari Core is a fundamental crate within the Tari Cryptocurrency project. It serves as a central repository for core protocol definitions, providing the shared data structures and interfaces used across the ecosystem. Developers building on Tari will use this crate to interact with standard protocol entities like Transactions and Blocks.
  2. Overview of Minotari application grpc

    development
    The minotari_app_grpc crate serves as the centralized source for all cross-application gRPC definitions and provides the necessary conversion logic between gRPC message types and tari::core types. Developers building applications that need to communicate with Tari components via gRPC should use this crate to ensure consistent message formats and type compatibility.
  3. Overview of Tari project applications

    development

    The Tari ecosystem is composed of several specialized applications that work together to provide a complete cryptocurrency environment. Key applications include:

    • minotari_node: The full base node implementation for the Tari blockchain.
    • minotari_console_wallet: A command-line interface (CLI) wallet used for managing Tari transactions.
    • minotari_miner: An implementation for SHA-3 based proof-of-work mining.
    • minotari_merge_mining_proxy: A proxy server designed for merge mining with Monero/XMRig.
    • minotari_ledger_wallet: An implementation providing hardware wallet support for Ledger devices.
    • deps_only: A utility used during development to build dependencies.
  4. Overview of Tari gRPC Services

    development

    Tari provides several gRPC services for programmatic interaction with the ecosystem. These services use Protocol Buffers (protobuf) and are implemented using the tonic framework in Rust.

    Available Services

    • BaseNode service: Handles core blockchain operations, mining, and chain queries.
    • Wallet service: Manages wallet operations, transaction management, and payment handling.
    • ValidatorNode service: Manages smart contract operations and sidechain interactions.
    • ShaP2Pool service: Manages P2Pool mining operations.

    Service Hosting and Connection Details

    ServiceHosted ByDefault Address
    BaseNodeminotari_node127.0.0.1:18142
    Walletminotari_console_wallet127.0.0.1:18143
    ValidatorNodeValidator NodeVaries by deployment
  5. Overview of the Minotari Miner

    development

    The Minotari Miner is a standalone application designed to mine blocks on the Minotari network. It must be connected to both a Minotari Base Node and a Minotari Console Wallet.

    Its primary functions are:

    1. Inserting coinbase transactions created by the Minotari Wallet.
    2. Mining blocks that match the required network difficulty.

    It also serves as a reference implementation for developers looking to build custom miners.

  6. Overview of Tari FFI Libraries and Support

    development

    Tari provides C-compatible Foreign Function Interface (FFI) libraries to allow integration with non-Rust applications.

    Available Libraries

    • minotari_wallet_ffi: Used for comprehensive wallet operations in mobile and desktop applications.
    • minotari_mining_helper_ffi: Provides mining utilities for mining pools and stratum servers.

    Supported Platforms

    • iOS: Static library (.a)
    • Android: Dynamic library (.so)
    • Linux: Dynamic library (.so)
    • macOS: Dynamic library (.dylib)
    • Windows: Dynamic library (.dll)

    Supported Languages

    Integration is possible via:

    • C/C++: Direct usage.
    • JavaScript/Node.js: Via ffi-napi bindings.
    • Swift: For iOS integration.
    • Java/Kotlin: For Android integration.
    • Python: Via ctypes or cffi.
    • C#/.NET: Via P/Invoke.
  7. Minotari HTTP API Overview

    development
    The Minotari Base Node exposes several HTTP endpoints for interacting with the network. These include REST-like GET routes for retrieving blockchain data and a JSON-RPC endpoint for structured method invocation. The API allows developers to query tip information, block headers, UTXO statistics, and transaction data.
  8. Use the Tari comms DHT module for network messaging

    development
    The Tari comms DHT module provides the network messaging capabilities for the Tari protocol. To integrate and use this library within your application, you should use the CommsBuilder pattern to configure and instantiate the messaging layer.
  9. Configure the Minotari Node HTTP API server

    development

    The Minotari base node provides an HTTP REST API built on Axum. The server is configured with the following defaults:

    • Listen address: Configurable (defaults to 0.0.0.0).
    • Authentication: None (security must be managed via network or firewall settings).
    • Body size limit: Approximately 10 MB.
    • API Documentation: You can access the interactive Swagger UI at /swagger-ui or the raw OpenAPI specification at /openapi.json.
  10. What is a Payment Reference (PayRef)?

    development

    A Payment Reference (PayRef) is a globally unique, 64-character hexadecimal identifier for individual transaction outputs on the Tari blockchain. It serves as verifiable proof of a payment without revealing sensitive information like amounts, sender/receiver identities, or transaction relationships.

    Key Properties:

    • Privacy Preserving: Only proves an output exists in a specific block.
    • Verifiable: Can be independently computed using the formula: PayRef = Blake2b_256(block_hash || output_hash).
    • Stable: Becomes permanently stable after a configurable number of confirmations (default is 5 blocks).