PayLink Guard

Safe payment links for PayBox agents. A PayBox plugin for the MoonPay Hackathon (Chapter 1, Merchant tools), built by Michael Lip.

Merchants already ask for crypto with standard payment links: EIP-681 (ethereum:...) and Solana Pay (solana:...). An agent that receives one of these links has to answer three questions before it spends the user's money:

1. What does the link ask for: which chain, which asset, how much, and to whom?

2. Is the recipient safe? It should be a real wallet, not a token contract or a flagged address.

3. Does the payment match what the user agreed to, and can the user's wallet cover it?

PayLink Guard answers all three and then returns an unsigned PayBox transaction proposal. PayBox simulates it, the user approves it, and the vault signs it. The plugin never sees a key and never signs anything.

Tools

Related MCP server: x402-mcp

How a payment is checked

The pay tools take the user's intent as input: asset, max_amount, and optionally expected_recipient. Before any network call, the tool refuses a link in another asset, a link above the cap, or a link that pays someone else. This matters because a single typo in a link can change what gets paid. For example, SPL-TOKEN= in upper case would otherwise turn a 5 USDC invoice into a 5 SOL payment. PayLink Guard refuses unknown link parameters for the same reason.

Then the live checks run:

A block never produces a proposal. A caution returns a short confirmation code together with the reasons. The agent must show the reasons to the user and call again with that code. The code is bound to the link, the amount, the reasons and a 5-minute window, and it is keyed with a value only the plugin owner sets. A merchant cannot print a valid code on an invoice, and the agent cannot reuse a code for another payment. If no recipient check can run at all (for example the network is down), the tool makes no proposal.

All amounts use exact integer arithmetic. No floating point touches money.

Evidence

Hosted configuration

Upload dist/plugin.mjs only. Add these 5 network hosts: mainnet.base.org, base-rpc.publicnode.com, solana-rpc.publicnode.com, api.mainnet-beta.solana.com, api.gopluslabs.io. Add one variable, PAYLINK_CONFIRM_KEY, set to a random 64-character hex value. It keys the confirmation codes. No API keys are needed: every endpoint is public.

Each RPC call times out after 3 seconds and then tries a second provider, because the official Solana endpoint rate-limits shared IP addresses. No new attempt starts after 8 seconds. If every request hangs, a tool still answers inside the 10-second budget.

Build

pnpm install --frozen-lockfile
pnpm unit      # unit tests
pnpm test      # type check, deterministic build, MCP conformance
node scripts/call.mjs check_payment_link '{"link":"solana:<wallet>?amount=1&spl-token=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"}'

Node.js 24 and pnpm 11.11.0, as PayBox starter 1.0.2 requires.

Limits

PayLink Guard supports ETH and USDC on Base, and SOL and USDC on Solana. Other tokens and chains get a clear refusal. Interactive Solana Pay transaction requests (solana:https://...) are not supported. GoPlus covers EVM addresses only, so Solana recipients get on-chain checks only. Base payment links have no reference key, so verify_payment cannot tell two invoices to the same address apart: record each transaction hash and accept it once. ETH paid through a smart wallet cannot be traced with public RPCs and is reported as such. A pass is not a guarantee: the checks catch common and costly mistakes, and the user still approves every payment in PayBox.

Author

Michael Lip, github.com/theluckystrike. MIT License.