walletconnect

Pair and use an EVM and/or Solana wallet via WalletConnect v2. No authentication required — available to every user (including unauthenticated/anonymous). Non-custodial: the server never holds keys and the user approves every signature/transaction in their own wallet. Pairing proposal is controlled per request via optional pairingTarget on action: "connect": eth (default, eip155 only), solana, or both. Many mobile wallets fail if eip155 and solana are proposed together; prefer eth or solana unless the user needs both in one session. Every call must include action (string). Connect QR (critical for assistants): On action: "connect", successful responses return (1) an MCP type: "image" PNG of the pairing QR (render this even if the host has no resources/read), then (2) optional resource_link, then (3) text JSON with pairingQrResourceUri, presentation, nextSteps, url, optional mobileDeeplinks, etc. Desktop / scan UX: show the image content block first. Mobile / no-camera: follow nextSteps; when present, mobileDeeplinks lists HTTPS url (+ nativeUrl) per curated WalletConnect wallet. Raw wc: (url / walletConnectLinkForUser) remains fallback. Avoid calling connect again while pairing is still in progress unless the user must reset — pass walletSessionToken to resume the same pairing after MCP session rotation. Flow: (1) connect as above. (2) User approves in the wallet (EVM only, Solana only, or both). (3) status until kind is session — optional evm / solana blocks; address/chains remain legacy EVM when EVM is connected. (4) sign / send_transaction or swap execute=true (swap execute remains EVM unless extended elsewhere). kind: "pending" on status is success — keep polling. Actions (exact JSON shapes): - connect — { "action": "connect", "sessionTtlDays"?: number, "pairingTarget"?: "eth" | "solana" | "both", "walletSessionToken"?: string } - status — { "action": "status" } (anonymous sessions include a terms block showing the connected wallet's 1inch Terms-of-Use acceptance state) - sign — EVM: personal_sign / eth_signTypedData_v4. Solana: solana_signMessage / solana_signTransaction (see schema fields params, chainId, solanaChainId). - send_transaction — EVM: tx.to, numeric tx.chainId. Solana: string tx.chainId (solana:...), tx.serializedTransaction (base64). Set tx.namespace when both WC namespaces are active and the payload is ambiguous. - accept_terms — { "action": "accept_terms", "address"?: "0x…" }. When the user has not accepted yet: write to the user that they must sign the 1inch Terms of Use in their wallet (one-time, gas-free personal_sign), then immediately call this action in the same turn so the signature prompt appears. You trigger the signing — do not only instruct them to sign. Required before anonymous aqua create_position / close_position. Idempotent — already-accepted wallets return immediately without a prompt. - disconnect — { "action": "disconnect" } Anonymous durable sessions: for unauthenticated callers, pairing connect (QR) returns a walletSessionToken. Store it and pass it back as walletSessionToken on later status / sign / send_transaction / accept_terms / disconnect and on a later connect to resume the same pairing after MCP session rotation. A tokenless connect that resumes an already-approved session does not mint a new token — within this MCP session, status / sign still work via anon:{sessionId}. Authenticated callers ignore the token (their WC session is scoped by org/app). Non-custodial relay; no authentication required. It is categorised as a Destructive tool in the 1inch MCP MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.

walletconnect accepts 10 parameters: tx, action, method, params, address, chainId, pairingTarget, solanaChainId, sessionTtlDays, walletSessionToken. Required: action. The full parameter table on this page comes from the server's own tool schema.

Register the 1inch MCP server in PolicyLayer and add a rule for walletconnect: 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 1inch MCP. Nothing to install.

walletconnect 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 walletconnect 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 walletconnect. 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.

walletconnect is provided by the 1inch MCP server (https://api.1inch.com/mcp/protocol). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.