Gate Wallet DApp Skill

DApp interaction domain — Connect wallet, sign messages, execute DApp transactions, ERC20 Approve authorization, with mandatory confirmation gating and contract security review. 4 MCP tools + cross-Skill invocation.

Trigger scenarios: User mentions "connect DApp", "sign message", "sign message", "authorize", "approve", "DApp interaction", "NFT mint", "DeFi operation", "add liquidity", "stake", "stake", "claim", "contract call", or when other Skills guide the user to perform DApp-related operations.

Step 0: MCP Server Connection Check (Mandatory)

Before executing any operation, Gate Wallet MCP Server availability must be confirmed. This step cannot be skipped.

Probe invocation:

CallMcpTool(server="gate-wallet", toolName="chain.config", arguments={chain: "eth"})

Display when Cursor is not configured

❌ Gate Wallet MCP Server not configured

The MCP Server named "gate-wallet" was not found in Cursor. Please configure it as follows:

Method 1: Configure via Cursor Settings (recommended)
  1. Open Cursor → Settings → MCP
  2. Click "Add new MCP server"
  3. Fill in:
     - Name: gate-wallet
     - Type: HTTP
     - URL: https://your-mcp-server-domain/mcp
  4. Save and retry

Method 2: Edit configuration file manually
  Edit ~/.cursor/mcp.json and add:
  {
    "mcpServers": {
      "gate-wallet": {
        "url": "https://your-mcp-server-domain/mcp"
      }
    }
  }

If you do not have an MCP Server URL yet, please contact your administrator.

Display when remote service is unreachable

⚠️  Gate Wallet MCP Server connection failed

MCP Server configuration was found, but the remote service could not be reached. Please check:
1. Confirm the service URL is correct (is the configured URL accessible)
2. Check network connection (VPN / firewall may affect connectivity)
3. Confirm the remote service is running normally

Display when API Key authentication fails

🔑 Gate Wallet MCP Server authentication failed

MCP Server connected but API Key validation failed. This service has AK/SK authentication enabled (x-api-key header).
Please contact your administrator for a valid API Key and confirm the server configuration is correct.

Authentication

All operations in this Skill require mcp_token. User must be logged in before calling any tool.

• If no mcp_token is present → Guide user to gate-dex-mcpauth to complete login, then return.
• If mcp_token has expired (MCP Server returns token expired error) → First try auth.refresh_token for silent refresh, if that fails then guide user to re-login.

DApp Interaction Scenarios Overview

MCP Tool Invocation Specification

1. wallet.get_addresses (Cross-Skill) — Get wallet addresses

Get wallet addresses for the account on each chain, for DApp connection. This tool belongs to the gate-dex-mcpwallet domain and is invoked cross-Skill here.

Invocation example:

CallMcpTool(
  server="gate-wallet",
  toolName="wallet.get_addresses",
  arguments={ account_id: "acc_12345", mcp_token: "<mcp_token>" }
)

Return example:

{
  "addresses": {
    "eth": "0xABCdef1234567890ABCdef1234567890ABCdef12",
    "bsc": "0xABCdef1234567890ABCdef1234567890ABCdef12",
    "sol": "7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU"
  }
}

Agent behavior: EVM chains share the same address. Provide the target chain address to the DApp to complete wallet connection.

2. wallet.sign_message — Sign message

Sign arbitrary messages using server-hosted private key. Supports personal_sign and EIP-712 typed data signing.

Parameter description:

Invocation example (personal_sign):

CallMcpTool(
  server="gate-wallet",
  toolName="wallet.sign_message",
  arguments={
    message: "Welcome to Uniswap! Sign this message to verify your wallet. Nonce: abc123",
    chain: "eth",
    account_id: "acc_12345",
    mcp_token: "<mcp_token>"
  }
)

Invocation example (EIP-712):

CallMcpTool(
  server="gate-wallet",
  toolName="wallet.sign_message",
  arguments={
    message: "{\"types\":{\"EIP712Domain\":[{\"name\":\"name\",\"type\":\"string\"}],\"Permit\":[{\"name\":\"owner\",\"type\":\"address\"},{\"name\":\"spender\",\"type\":\"address\"},{\"name\":\"value\",\"type\":\"uint256\"}]},\"primaryType\":\"Permit\",\"domain\":{\"name\":\"USDC\"},\"message\":{\"owner\":\"0xABC...\",\"spender\":\"0xDEF...\",\"value\":\"1000000000\"}}",
    chain: "eth",
    account_id: "acc_12345",
    mcp_token: "<mcp_token>"
  }
)

Return example:

{
  "signature": "0x1234abcd...ef5678"
}

Agent behavior: Before signing, show the user the message content and explain the purpose. After signing, return the signature to the user.

3. wallet.sign_transaction — Sign DApp transaction

Sign unsigned transactions built by DApp using server-hosted private key. Only invoke after user explicitly confirms.

Parameter description:

Invocation example:

CallMcpTool(
  server="gate-wallet",
  toolName="wallet.sign_transaction",
  arguments={
    raw_tx: "0x02f8...",
    chain: "eth",
    account_id: "acc_12345",
    mcp_token: "<mcp_token>"
  }
)

Return example:

{
  "signed_tx": "0x02f8b2...signed..."
}

4. tx.send_raw_transaction — Broadcast signed transaction

Broadcast the signed DApp transaction to the on-chain network.

Parameter description:

Invocation example:

CallMcpTool(
  server="gate-wallet",
  toolName="tx.send_raw_transaction",
  arguments={
    signed_tx: "0x02f8b2...signed...",
    chain: "eth",
    mcp_token: "<mcp_token>"
  }
)

Return example:

{
  "hash_id": "0xa1b2c3d4e5f6...7890"
}

Supported DApp Interaction Types

Supported Chains

Skill Routing

Based on user intent after DApp operation, route to the corresponding Skill:

Operation Flows

Flow A: DApp wallet connection

Step 0: MCP Server connection check
  Call chain.config({chain: "eth"}) to probe availability
  ↓ Success

Step 1: Authentication check
  Confirm valid mcp_token and account_id
  No token → Guide to gate-dex-mcpauth for login
  ↓

Step 2: Get wallet address
  Call wallet.get_addresses({ account_id, mcp_token })
  Extract target chain address
  ↓

Step 3: Display address

  ────────────────────────────
  🔗 Wallet Connection Info

  Chain: {chain_name}
  Address: {address}

  Use this address for DApp connection.
  EVM chains (Ethereum/BSC/Polygon etc.) share the same address.
  ────────────────────────────

Flow B: Message signing

Step 0: MCP Server connection check
  ↓ Success

Step 1: Authentication check
  ↓

Step 2: Intent recognition + parameter collection
  Extract signing request from user input:
  - message: Content to sign (required)
  - chain: Target chain (optional, default eth)
  - Signing type: personal_sign or EIP-712 (auto-detect from message format)
  ↓

Step 3: Display signing content for confirmation

  ────────────────────────────
  ✍️ Message Signing Request

  Chain: {chain_name}
  Signing type: {personal_sign / EIP-712}
  Content to sign:
  {message_content}

  This signature does not create an on-chain transaction and does not consume Gas.
  Reply "confirm" to sign, "cancel" to abort.
  ────────────────────────────

  ↓ User confirms

Step 4: Execute signing
  Call wallet.sign_message({ message, chain, account_id, mcp_token })
  ↓

Step 5: Display signing result

  ────────────────────────────
  ✅ Signing complete

  Signature: {signature}

  Submit this signature to the DApp to complete verification.
  ────────────────────────────

Flow C: DApp transaction execution (main flow)

Step 0: MCP Server connection check
  Call chain.config({chain: "eth"}) to probe availability
  ↓ Success

Step 1: Authentication check
  Confirm valid mcp_token and account_id
  No token → Guide to gate-dex-mcpauth for login
  ↓

Step 2: Intent recognition + parameter collection
  Extract DApp operation intent from user input:
  - Operation type (e.g. "add liquidity", "stake ETH", "mint NFT")
  - Target protocol/contract (e.g. Uniswap, Aave, Lido)
  - Amount and tokens
  - Chain (optional, can infer from context)

  For missing parameters, ask user one by one:

  ────────────────────────────
  Please provide DApp interaction info:
  - Operation: (required, e.g. "add ETH-USDC liquidity on Uniswap")
  - Chain: (optional, default Ethereum)
  - Amount: (may need multiple amounts depending on operation type)
  ────────────────────────────

  ↓ Parameters complete

Step 3: Get wallet info (cross-Skill: gate-dex-mcpwallet)
  Call wallet.get_addresses({ account_id, mcp_token }) → Get from_address
  Call wallet.get_token_list({ account_id, chain, mcp_token }) → Get balance
  ↓

Step 4: Security review (recommended step)
  Call token_get_risk_info({ chain, address: contract_address }) (cross-Skill: gate-dex-mcpmarket)
  Evaluate contract risk level
  ↓

Step 5: Agent builds transaction
  Based on DApp operation type, Agent encodes contract call calldata:
  a) Known protocol (Uniswap/Aave/Lido etc.): Encode per protocol ABI
  b) User provides ABI + parameters: Agent parses and encodes
  c) User provides complete calldata: Use directly

  Build transaction parameters:
  - to: Contract address
  - data: calldata
  - value: Amount of native token to send (if any)
  ↓

Step 6: Determine if Approve is needed
  If operation involves ERC20 token (non-native token):
  - Check if current allowance is sufficient
  - Insufficient → Execute Approve transaction first (see Flow D)
  ↓

Step 7: Agent balance validation (mandatory)
  Validation rules:
  a) Operation involves native token: native_balance >= amount + estimated_gas
  b) Operation involves ERC20 token: token_balance >= amount AND native_balance >= estimated_gas
  c) Gas only: native_balance >= estimated_gas

  Validation failed → Abort transaction:

  ────────────────────────────
  ❌ Insufficient balance, cannot execute DApp operation

  Required {symbol}: {required_amount}
  Current balance: {current_balance}
  Shortfall: {shortfall}

  Suggestions:
  - Reduce operation amount
  - Deposit tokens to wallet first
  ────────────────────────────

  ↓ Validation passed

Step 8: Display DApp transaction confirmation summary (mandatory gate)
  Display content see "DApp Transaction Confirmation Template" below.
  Must wait for user to explicitly reply "confirm" before proceeding.
  ↓

  User replies "confirm" → Proceed to Step 9
  User replies "cancel" → Abort transaction
  User requests modification → Return to Step 2

Step 9: Sign transaction
  Call wallet.sign_transaction({ raw_tx, chain, account_id, mcp_token })
  Get signed_tx
  ↓

Step 10: Broadcast transaction
  Call tx.send_raw_transaction({ signed_tx, chain, mcp_token })
  Get hash_id
  ↓

Step 11: Display result + follow-up suggestions

  ────────────────────────────
  ✅ DApp transaction broadcast successful!

  Operation: {operation_description}
  Transaction Hash: {hash_id}
  Block explorer: https://{explorer}/tx/{hash_id}

  Transaction submitted to network. Confirmation time depends on network congestion.

  You can:
  - View updated balance
  - View transaction details
  - Continue with other operations
  ────────────────────────────

Flow D: ERC20 Approve authorization

Step 0: MCP Server connection check
  ↓ Success

Step 1: Authentication check
  ↓

Step 2: Determine Approve parameters
  - token_address: Token contract address to authorize
  - spender: Spender contract address (e.g. Uniswap Router)
  - amount: Authorization amount

  Agent recommends exact amount over unlimited:

  ────────────────────────────
  💡 Authorization amount recommendation

  This operation requires authorizing {spender_name} to use your {token_symbol}.

  Recommended options:
  1. Exact authorization: {exact_amount} {token_symbol} (only for this operation, more secure)
  2. Unlimited authorization: unlimited (no need to re-authorize for future operations, but higher risk)

  Please choose authorization method, or specify custom amount.
  ────────────────────────────

  ↓

Step 3: Build Approve calldata
  Encode ERC20 approve(spender, amount) function call:
  - function selector: 0x095ea7b3
  - spender: Contract address (32 bytes padded)
  - amount: Authorization amount (uint256)
  ↓

Step 4: Display Approve confirmation

  ────────────────────────────
  ========== Token Authorization Confirmation ==========
  Chain: {chain_name}
  Token: {token_symbol} ({token_address})
  Authorize to: {spender_name} ({spender_address})
  Authorization amount: {amount} {token_symbol}
  Estimated Gas: {estimated_gas} {gas_symbol}
  ===============================
  Reply "confirm" to execute authorization, "cancel" to abort.
  ────────────────────────────

  ↓ User confirms

Step 5: Sign + broadcast Approve transaction
  Call wallet.sign_transaction({ raw_tx: approve_tx, chain, account_id, mcp_token })
  Call tx.send_raw_transaction({ signed_tx, chain, mcp_token })
  ↓

Step 6: Approve success
  Display Approve transaction hash, continue with subsequent DApp operation (Flow C Step 9)

Flow E: Arbitrary contract call (user provides ABI)

Step 0: MCP Server connection check
  ↓ Success

Step 1: Authentication check
  ↓

Step 2: Collect contract call info
  User provides:
  - Contract address
  - Function name or ABI
  - Function parameters
  - value (optional, needed when sending native token)
  - Chain
  ↓

Step 3: Agent encodes calldata
  Encode function call data based on ABI and parameters
  ↓

Step 4: Security review + balance validation + confirmation gate
  Same as Flow C Steps 4 ~ 8
  ↓

Step 5: Sign + broadcast
  Same as Flow C Steps 9 ~ 11

DApp Transaction Confirmation Template

This confirmation summary must be shown before the user explicitly replies "confirm". Agent must NOT execute signing before that. This is a mandatory gate that cannot be skipped.

Standard DApp transaction confirmation

========== DApp Transaction Confirmation ==========
Chain: {chain_name}
DApp/Protocol: {protocol_name} (e.g. Uniswap V3)
Operation: {operation} (e.g. Add liquidity)
Contract address: {contract_address}
---------- Transaction Details ----------
{operation_specific_details}
(e.g. Token A: 0.5 ETH, Token B: 1000 USDC)
---------- Authorization Info ----------
{approve_info_if_needed}
(e.g. Approve required: USDC → Uniswap Router, amount: 1000 USDC)
(When no approval needed: No additional authorization required)
---------- Balance Info ----------
{token_symbol} balance: {balance} (sufficient ✅ / insufficient ❌)
{gas_symbol} balance (Gas): {gas_balance} (sufficient ✅)
---------- Fee Info ----------
Estimated Gas (Approve): {approve_gas} (if needed)
Estimated Gas (Transaction): {tx_gas} {gas_symbol}
---------- Security Check ----------
Contract security audit: {risk_level} (e.g. audited/low risk/high risk/unknown)
===============================
Reply "confirm" to execute, "cancel" to abort, or specify modifications.

Note: DApp interaction involves smart contract calls. Please confirm contract address and operation are correct.

Unknown contract warning confirmation

When target contract is unaudited or audit result is high risk:

========== ⚠️ DApp Transaction Confirmation (Security Warning) ==========
Chain: {chain_name}
Contract address: {contract_address}

⚠️ Security warning: This contract is unaudited or marked as high risk.
Interacting with unknown contracts may result in asset loss. Please confirm you trust this contract.

---------- Transaction Details ----------
{operation_details}
---------- Balance Info ----------
{balance_info}
---------- Fee Info ----------
{gas_info}
---------- Security Check ----------
Contract audit status: {risk_detail}
=================================================
Reply "confirm" to proceed anyway (at your own risk), "cancel" to abort.

Cross-Skill Workflow

Complete DApp interaction flow (from login to completion)

gate-dex-mcpauth (login, get mcp_token + account_id)
  → gate-dex-mcpwallet (wallet.get_addresses → get address)
    → gate-dex-mcpwallet (wallet.get_token_list → validate balance)
      → gate-dex-mcpmarket (token_get_risk_info → contract security review)
        → gate-dex-mcpdapp (Approve? → confirm → sign → broadcast)
          → gate-dex-mcpwallet (view updated balance)

DApp message signing (no transaction)

gate-dex-mcpauth (login)
  → gate-dex-mcpdapp (wallet.sign_message → return signature result)

Guided by other Skills

Invoking other Skills

Contract Address Validation Rules

Contract address validation for DApp transactions and Approve:

When validation fails:

❌ Invalid contract address format

Provided address: {user_input}
Expected format: {expected_format}

Please check the address is correct, complete, and matches the target chain.

ERC20 Approve Calldata Encoding Specification

When building Approve transactions, Agent must encode calldata per the following rules:

Function signature: approve(address spender, uint256 amount)
Selector: 0x095ea7b3

Calldata structure:
0x095ea7b3
+ spender address (32 bytes, left-padded with zeros)
+ amount (32 bytes, uint256)

Example (approve Uniswap Router to use 1000 USDT, 6 decimals):
0x095ea7b3
000000000000000000000000 68b3465833fb72A70ecDF485E0e4C7bD8665Fc45  ← spender
00000000000000000000000000000000000000000000000000000000 3B9ACA00  ← 1000 * 10^6

Exact vs unlimited authorization:

Recommend exact authorization unless user explicitly requests unlimited.

EIP-712 Signature Data Parsing Specification

When displaying EIP-712 signing requests, Agent must parse JSON structured data into human-readable format:

Parsing points

1. Domain info: Extract name, version, chainId, verifyingContract, display in table format
2. Primary Type: Clearly label the primary type of signature data (e.g. Order, Permit, Vote)
3. Message fields: Display each field; truncate address type for display; try to convert uint256 to human-readable values
4. Known type recognition:
   • Permit (EIP-2612) → Label "Token authorization permit", highlight spender and value
   • Order (DEX order) → Label "Trading order", highlight trading pair and amount
   • Vote (governance vote) → Label "Governance vote", highlight vote content

Known EIP-712 signature types

Edge Cases and Error Handling

Security Rules

1. mcp_token confidentiality: Never display mcp_token in plain text to user; use placeholder <mcp_token> in invocation examples only.
2. account_id masking: When displaying to user, only show partial characters (e.g. acc_12...89).
3. Token auto-refresh: When mcp_token expires, prefer silent refresh first; only require re-login if refresh fails.
4. Confirmation required before signing: All signing operations (message signing, transaction signing, Approve) must display full content to user and obtain explicit "confirm" reply before execution. Cannot skip, simplify, or auto-confirm.
5. Contract security review: When DApp interaction involves unknown contract, must call token_get_risk_info for security review and display result to user. High-risk contracts require additional prominent warning.
6. Default exact authorization: ERC20 Approve defaults to exact authorization amount. Use unlimited only when user explicitly requests, and must display unlimited authorization risk warning.
7. EIP-712 content transparency: EIP-712 signing requests must be fully parsed and displayed in human-readable format to user; cannot omit any key fields (especially verifyingContract, spender, amount-type fields).
8. Gas balance validation mandatory: Before DApp transaction and Approve, must validate Gas token balance; prohibit initiating signing and broadcast when balance is insufficient.
9. No auto-retry on failed operations: After signing or broadcast fails, clearly show error to user; do not auto-retry in background.
10. Prohibit operations when MCP Server not configured or unreachable: If Step 0 connection check fails, abort all subsequent steps.
11. MCP Server error transparency: All MCP Server error messages displayed to user as-is; do not hide or alter.
12. raw_tx must not be leaked: Unsigned transaction raw data flows only between Agent and MCP Server; do not display hex original to user.
13. Broadcast promptly after signing: After successful signing, broadcast immediately; do not hold signed transaction for long.
14. Permit signature risk warning: EIP-2612 Permit signature consumes no Gas but is equivalent to authorization; must remind user to note spender and authorization amount.
15. Phishing prevention: Agent does not actively construct transactions or signing requests pointing to unknown contracts. All DApp interaction data should be provided by user or from trusted sources.