Frequently asked questions

No separate registration form is required. The product requests a one-time nonce, builds a site-bound sign-in message, and asks your wallet to sign it. The server verifies the signature and consumes the nonce before creating the browser session; there is no password or email step.

No. Sign-in signs a text challenge, not a TRON transaction, and the login flow does not receive your wallet's private key. The signature proves control of the address for the session. If the account has funds for orders, they come from the platform's internal balance rather than a separate wallet transfer for each order.

Buyer orders use funds recorded in the buyer's internal available balance; they do not let the platform transfer TRX from the wallet connected for sign-in. Autosell onboarding accepts a bot permission only when its operations bitmap is limited to DelegateResource and UnDelegateResource, and the product signer rejects other contract types. That limit is enforced by the product rather than by the TRON network, so verify the permission before enabling autosell and revoke it when you stop using the service.

Personal buyer deposits are available only when the balance API and dashboard show a configured personal platform address. Send TRX only to that displayed address, never to the TronLink address used for sign-in. Eligible transfers at or above the configured minimum are credited automatically after the required confirmations. If no personal address is shown, do not send funds. Withdrawals and seller payout execution remain unavailable.

When an order is placed, its principal and slippage allowance are reserved from the account's internal available balance. Settled fills draw against that reservation, and any unused amount is returned through the order lifecycle. The connected wallet is not charged separately for each order.

The uncommitted portion of the reservation is returned to the internal available balance; amounts backing fills already in progress remain protected, and settled portions remain spent. For an underfilled order, current cancellation and expiry handling attempts to charge 1 TRX from the available balance after the release. If that balance cannot cover the fee, the fee is skipped.

API keys carry explicit read, buy, and/or sell scopes. Read covers account and order views, buy gates order creation, editing, and cancellation, and sell gates seller-pool changes. Key creation and revocation stay browser-session-only, and a key cannot perform actions outside its scopes. The current route set has no API-key withdrawal or payout action.

The dashboard derives delivered amounts from fills recorded as settled. For settled P2P fills with complete delegation evidence, it shows a transaction hash linked to TRONScan plus recorded delegation and unlock times; provider fills are identified separately and may not have a platform-owned delegation record. These records describe the platform's settled evidence; they do not establish every possible chain outcome.

There is no separate sandbox. If the dashboard shows a configured personal platform address, sending real TRX to that address can fund the real account after the configured minimum and confirmation requirements are met, and those funds can pay for a real order. This is real-money activity, not test credit, so a mistake can cause a loss of funds. If no personal address is available, a new account cannot self-fund.

Keep the order ID and any transaction hash shown for a settled P2P fill. The dashboard exposes those identifiers when the corresponding recorded evidence exists. Never send a wallet seed phrase or private key.

The footer links to the project's Telegram and X profiles. These are public project links; neither a response time nor support availability is stated.