Permissionless wallet infrastructure for AI agents. Create wallets, sign transactions, and broadcast on EVM + Solana. Pay and accept x402 payments. Built-in guards. No KYC. Up to 50% less expensive than Coinbase.
claude mcp add agentwallet-mcp -- npx -y agentwallet-mcp
A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
3 ★ · hifriendbot/agentwallet-mcp · read from the GitHub search API · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 3 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository hifriendbot/agentwallet-mcp;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
Permissionless wallet infrastructure for AI agents. Create wallets, sign transactions, and broadcast on-chain, on any EVM chain and Solana. Built-in guards. No KYC. The only AI agent wallet that accepts crypto for its own API fees. **Your keys can stay on your machine.** Set one environment variable and every signature happens in your own process. No server sees the key, no company can freeze the wallet, and you can verify that claim by reading src/local-wallet.ts or by running the server with the API pointed at a closed port. **No KYC. No KYT. No approval process. No transaction monitoring. No one can block your wallet. Pay with USDC on-chain, no credit card required.** Two modes | | Local (self-custody) | Hosted (custodial) | |---|---|---| | Who holds the key | You, in your own process | Encrypted on AgentWallet servers | | Set up | One env var, no account needed | API key | | Chains | EVM + Solana | EVM + Solana | | Can anyone freeze it | No | Yes, that is what pause is for | | Spend guards | AGENTWALLET_MAX_TX_NATIVE, AGENTWALLET_MAX_TX_TOKEN, AGENTWALLET_MAX_TX_SOL, AGENTWALLET_MAX_AUTOPAY | Server-side limits, pause, rate limits | | Paywalls, usage, billing | Needs an API key too | Included | Run wallet_mode at any time and the server will tell you which one you are in, and which address it controls. Local signing in one variable Use AGENTWALLET_KEYFILE=/path/to/key instead if you would rather keep the key out of your shell config (one or the other: the server refuses to start when both are set). The key is read once, never written to disk, never logged, and never included in an error message. AGENTWALLET_RPC_ (or AGENTWALLET_RPC_URL for all chains) points at an endpoint you trust (https; plain http only on localhost). Without it a public RPC is used, and a public RPC can see which addresses you ask about. Decimals for a token outside the registry come from that RPC and are accepted only up to 18; pin anything else with AGENTWALLET_TOKEN_DECIMALS. AGENTWALLET_MAX_TX_NATIVE is a per-transaction ceiling in native units (ETH, MATIC and so on). In hosted mode the server enforces limits; in local mode there is no server, so these guards are the only ones there are. Set them. AGENTWALLET_MAX_TX_TOKEN is the equivalent ceiling for ERC-20 movement, in human units of the token. **Set this one too if you hold stablecoins.** The native cap cannot see a token transfer: an ERC-20 send carries value = 0 with the amount in the calldata, so AGENTWALLET_MAX_TX_NATIVE alone leaves a USDC balance uncapped. AGENTWALLET_MAX_TX_TOKEN covers transfer, transferFrom, approve, increaseAllowance, Permit2 approve, and deposit() / withdraw(uint256) on the chain's own wrapped-native contract (so wrap_eth and unwrap_eth keep working under the cap), the approvals because an unbounded allowance is a drain waiting to happen. Any other calldata sent to a token contract or to Permit2 is refused while the cap is set, because the guard cannot price it; set AGENTWALLET_ALLOW_UNKNOWN_TOKEN_CALLS=1 to allow such calls deliberately. increaseAllowance is judged on the resulting total: the current allowance is read first and the call refuses if it cannot be, so two compliant increments cannot stack a standing allowance above the cap. Calls to other contracts (routers, bridges) pass, since they can only pull what an approval already allowed; a contract counts as "other" only when it demonstrably declines decimals(), so an absurd or malformed answer, or an RPC that cannot be reached, refuses rather than allows. Decimals are resolved locally from the trusted registry, then the token's own decimals(); a token that resolves neither way is evaluated at 0 decimals, the only value that cannot fail open. For a token outside the registry the RPC is the only source of decimals, and an RPC you do not control could scale the amount and the cap together; pin such tokens with AGENTWALLET_TOKEN_DECIMALS (for example 8453:0x =6) and the pin is used everywhere the RPC's answer would have been. Solana local signing Accepts whichever format you already have: a solana-keygen id.json array, a base58 secret key as exported by Phantom, or base64. Use AGENTWALLET_SOLANA_KEYFILE to point at a file instead. Native SOL and SPL token transfers are both signed locally, and a missing associated token account is created for the recipient automatically. Set either key, or both. They are independent: run EVM locally and Solana hosted, or the reverse.