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, Allbrid...
AI agents call prepare_tron_lifi_swap to permanently remove resources in VaultPilot MCP — typically in cleanup and lifecycle workflows. It does its job in a single call, and there is no undo.
| Parameter | Type | Required | Description |
|---|---|---|---|
wallet | string | Yes | TRON base58 wallet (T-prefixed, 34 chars) — funds the swap and signs the source tx on Ledger via USB. Pair via `pair_ledger_tron` first. |
toChain | string | Yes | Destination chain. Any EVM chain (cross-chain bridge to EVM) or "solana" (cross-chain bridge to Solana). LiFi internally picks the best bridge protocol (NearInt |
toToken | string | Yes | Destination token. 0x-prefixed EVM token when toChain is EVM; SPL mint base58 when toChain="solana". "native" works on both (resolves to the chain's conventiona |
fromToken | string | Yes | Source 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 |
toAddress | string | Yes | Destination wallet — REQUIRED. EVM hex when toChain is EVM; Solana base58 when toChain="solana". The TRON source wallet isn't a valid recipient on either destin |
fromAmount | string | Yes | Raw integer amount in base units (NOT decimal-adjusted). For TRX (6 decimals) 1 TRX = '1000000'; for TRC-20 USDT (6 decimals) 10 USDT = '10000000'. |
slippageBps | integer | — | Slippage tolerance in basis points (50 = 0.5%). Omit for LiFi's default (0.5%). Cross-chain bridges may impose their own minimums above this. |
Parameters from the server's own tool schema.
An AI agent that decides to call prepare_tron_lifi_swap doesn't hesitate, doesn't double-check, and doesn't stop at one. Whatever it removes from VaultPilot MCP is gone — there is no undo for destructive operations.
Attacks that exploit this kind of access
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). It is categorised as a Destructive tool in the VaultPilot MCP MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.
prepare_tron_lifi_swap accepts 7 parameters: wallet, toChain, toToken, fromToken, toAddress, fromAmount, slippageBps. Required: wallet, toChain, toToken, fromToken, toAddress, fromAmount. The full parameter table on this page comes from the server's own tool schema.
Register the VaultPilot MCP server in PolicyLayer and add a rule for prepare_tron_lifi_swap: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches VaultPilot MCP. Nothing to install.
prepare_tron_lifi_swap is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.
Yes. Add a rate_limit block to the prepare_tron_lifi_swap rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for prepare_tron_lifi_swap. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
prepare_tron_lifi_swap is provided by the VaultPilot MCP server (vaultpilot-mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.