Skip to main content
Glama

prepare_tron_lifi_swap

DestructiveIdempotent

Build an unsigned LiFi cross-chain bridge transaction from TRON to any EVM chain or Solana. The tool verifies the destination chain and receiver before outputting the tx for Ledger signing.

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.
Behavior5/5

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

Annotations indicate destructive/write operation and idempotent. Description adds substantial behavioral details: protobuf decoding, contract address assertion, destination chain/receiver cross-check, NEAR Intents allowlisting, TRC-20 approval requirement, blind signing, and broadcast endpoint. No contradiction with annotations.

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

Conciseness4/5

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

Description is relatively long but well-structured, front-loaded with purpose, and each sentence adds value (prerequisites, flow, technical details). Slightly verbose but justified by complexity.

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 tool complexity (7 params, no output schema, rich annotations), description covers all necessary aspects: purpose, prerequisites, signing requirements, technical decoding steps, broadcast method. Complete for a developer to use correctly.

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

Parameters3/5

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

Schema description coverage is 100% with detailed parameter descriptions. The tool description reinforces operational context but does not add new semantic meaning beyond the schema. Baseline 3 is appropriate.

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?

Description clearly states the tool builds an unsigned LiFi-routed cross-chain bridge with TRON as source chain. It uses specific verbs and resource, and distinguishes from sibling tools like prepare_solana_lifi_swap and prepare_btc_lifi_swap by specifying TRON source.

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

Usage Guidelines4/5

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

Description provides clear usage context including prerequisites (pair_ledger_tron, TRC-20 approve) and blind signing requirement. It implies when to use (cross-chain from TRON) but does not explicitly state when not to use or list alternatives.

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/vaultpilot-mcp'

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