Skip to main content
Glama

prepare_tron_lifi_swap

DestructiveIdempotent

Prepare an unsigned TRON cross-chain bridge via LiFi from TRON to EVM chains or Solana. User signs the TRON transaction on a Ledger device; the bridge delivers tokens to the destination after source confirmation.

Instructions

Build an unsigned LiFi-routed cross-chain bridge with TRON as the source chain. User signs a TRON tx via Ledger over USB; the bridge protocol delivers tokens on the destination (any EVM chain or Solana) after the source confirms (typically 1-15 min). LiFi aggregates NearIntents, Wormhole, Allbridge, etc. The builder (1) decodes the TRON protobuf to extract the TriggerSmartContract envelope, (2) asserts the contract_address is the LiFi Diamond on TRON (TU3ymitEKCWQFtASkEeHaPb8NfZcJtCHLt) and the owner_address is the user's wallet, (3) decodes the inner ABI calldata's BridgeData tuple and cross-checks destinationChainId + receiver against the user's request — refuses on any mismatch. NEAR Intents routes (intermediate-chain settlement on NEAR's pseudo-chain 1885080386571452) are allowlisted via a hardcoded source-code constant so a hostile aggregator cannot fabricate 'intermediate-chain' encodings; receiver-side checks still apply unchanged. TRC-20 source flows REQUIRE a prior approve to the LiFi Diamond — call prepare_tron_trc20_approve first with spender: "TU3ymitEKCWQFtASkEeHaPb8NfZcJtCHLt" and the amount you intend to swap; insufficient allowance reverts the swap on-chain. BLIND-SIGN on Ledger (LiFi Diamond not in TRON app's clear-sign allowlist) — enable "Allow blind signing" in the on-device Solana app Settings; the device shows the txID, which the user matches against the txID in the prepare receipt. Pair the Ledger via pair_ledger_tron first. Broadcast goes via TronGrid's /wallet/broadcasthex endpoint (LiFi gives us only raw_data_hex, not the deserialized JSON shape /wallet/broadcasttransaction requires).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
walletYesTRON base58 wallet (T-prefixed, 34 chars) — funds the swap and signs the source tx on Ledger via USB. Pair via `pair_ledger_tron` first.
fromTokenYesSource token. T-prefixed TRC-20 contract address OR the literal string "native" for TRX (LiFi maps "native" to TRX's contract address internally). TRC-20 source REQUIRES a prior approve to the LiFi Diamond on TRON (TU3ymitEKCWQFtASkEeHaPb8NfZcJtCHLt) — this tool does not prepare the approve; insufficient allowance reverts on-chain.
fromAmountYesRaw integer amount in base units (NOT decimal-adjusted). For TRX (6 decimals) 1 TRX = '1000000'; for TRC-20 USDT (6 decimals) 10 USDT = '10000000'.
toChainYesDestination chain. Any EVM chain (cross-chain bridge to EVM) or "solana" (cross-chain bridge to Solana). LiFi internally picks the best bridge protocol (NearIntents, Wormhole, Allbridge, etc.).
toTokenYesDestination token. 0x-prefixed EVM token when toChain is EVM; SPL mint base58 when toChain="solana". "native" works on both (resolves to the chain's conventional native sentinel).
toAddressYesDestination wallet — REQUIRED. EVM hex when toChain is EVM; Solana base58 when toChain="solana". The TRON source wallet isn't a valid recipient on either destination chain family.
slippageBpsNoSlippage tolerance in basis points (50 = 0.5%). Omit for LiFi's default (0.5%). Cross-chain bridges may impose their own minimums above this.
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey destructive and idempotent nature. The description adds valuable context: user signs via Ledger, bridge delivery time (1-15 min), builder cross-checks, and blind signing requirement. It does not contradict any annotation. Minor deduction for slight redundancy (e.g., mentioning TronGrid endpoint twice).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely verbose, spanning multiple paragraphs with technical minutiae (e.g., protobuf decoding, contract addresses, endpoint details). While informative, it could be streamlined to a concise overview (e.g., 'Builds unsigned LiFi cross-chain swap from TRON. Requires paired Ledger and prior approve for TRC-20.') without losing essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, no output schema, cross-chain mechanics), the description covers all critical aspects: prerequisites, signing flow, bridge protocols, validation steps, error conditions (allowance revert), and output (unsigned tx). It is comprehensive enough for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the description enriches every parameter with actionable details: wallet mentions pairing, fromToken explains 'native' and approve, fromAmount clarifies base units, toChain enumerates options and bridge selection, toAddress warns about source wallet incompatibility, and slippage defines basis points and default. This exceeds what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'Build an unsigned LiFi-routed cross-chain bridge with TRON as the source chain.' It names the specific action (build unsigned tx), resource (LiFi cross-chain bridge), and context (TRON source). This clearly distinguishes it from sibling tools like prepare_solana_lifi_swap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides thorough guidance: it specifies when to use (cross-chain bridging from TRON), prerequisites (pair Ledger via pair_ledger_tron, approve TRC-20 if needed), and important steps (blind signing, broadcast via TronGrid). It also warns about insufficient allowance and mentions the allowlist for NEAR Intents, leaving little ambiguity for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/szhygulin/recon-crypto-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server