20 posts tagged with "tutorial"

Multi-signature parameters manage merchant administrator permissions, fund security, withdrawal destinations, balance limits, and operation frequency.

Each parameter has its own scope. The governance voting ratio only affects administrator proposals, while withdrawal intervals apply to their respective fund withdrawal paths independently.

Auto-refund automatically returns eligible funds to user addresses. This document covers configuration, prepaid account setup, strategy configuration, and the complete refund creation workflow.

Auto-refund involves on-chain operations that incur Gas Fees. The platform can configure refund fees based on business requirements.

Step-by-step guide covering wallet registration, sub-contract creation, auto-sweep, and auto-withdrawal configuration

This document is designed for non-API merchants. It walks you through generating recharge addresses, setting up prepaid deposits, enabling KYT detection, configuring auto-sweep and auto-withdrawal strategies, and handling blacklisted fund sweeps — all from the admin console without any code integration.

This guide will walk you through configuring the auto-sweep, fund withdrawal, and distribution strategies in the merchant admin console to automate your fund management.

Overview​

This guide explains how to use the sub-wallet features of TronLink / MetaMask to manage multiple merchant accounts with 4 mnemonic groups (3 multisig admin groups + 1 treasurer group), each corresponding to 4 master wallets, and complete the following tasks:

• Create sub-wallets for each merchant's multisig admins and treasurer address
• Register a new merchant and configure the multisig admin and treasurer wallets
• Obtain the API Key for integration by the development team

This guide is intended for merchant operations and fund security teams. It covers the full workflow for cold vault replacement, emergency sweep address setup, emergency fund withdrawal address setup, and high-risk fund handling.

You can execute the process in the following order:

• Replace the cold vault (multisig)
• Set the emergency sweep address (multisig)
• Set the emergency fund withdrawal address (multisig)
• Sweep and withdraw funds from blacklisted sub-contracts

This document describes how to rapidly batch-create TRON sub-contracts for payment business. The core approach is: first activate TRX currency in the admin console, then generate sub-contract addresses by creating payment orders, and finally deploy the contracts by transferring a small amount of TRX (approximately 1.277 TRX, valued at around 0.5 USDT) to complete batch initialization at minimal cost.

Use Cases​

• Payment business based on the TRON (TRC20) network
• Merchants need to pre-provision large quantities of payment-collection sub-contract wallets to handle high-concurrency payment demands
• Desire to reduce batch sub-contract creation costs by paying gas fees in TRX

1. Introduction to Cross-Chain Bridges​

A cross-chain bridge is a protocol mechanism used to transfer assets between different blockchain networks. Because various public blockchains (such as TRON, Ethereum, BSC, etc.) are independent and use incompatible protocols, assets cannot be transferred directly. Cross-chain bridges enable equivalent circulation of the same asset across different chains through mechanisms like "lock → mint" or "swap → release".

Cross-Chain Capabilities of This Platform​

This admin console already has built-in cross-chain swap functionality, allowing you to complete asset transfers between major blockchains without integrating an external bridge. It works similarly to "currency exchange": select the asset to sell, choose the destination chain for the asset to buy, enter the receiving address on the counterparty chain, and confirm to complete the cross-chain transfer.

1. Overview​

Tag Address is used to categorize and manage wallet addresses. When creating a payment order, merchants can specify tagId so the system automatically assigns a receiving address from the corresponding tagged address pool.

Address allocation rules:

• If an available address exists under the tag, the system prioritizes reusing it.
• If all addresses under the tag are occupied, the system automatically creates a new address.
• The newly created address is automatically assigned to the same tag.

This mechanism helps merchants achieve:

• Address categorization
• Address reuse
• Automatic address expansion

This mechanism is ideal for merchant scenarios that require managing a large number of receiving addresses.