Signing
MCP prepares unsigned transactions and broadcasts signed payloads. It never needs your private key. This kit offers two workflows:
Local EVM development wallet
npm run wallet creates an unencrypted .wallet/private-key with exclusive creation. Set WALLET_KEY_FILE to a location outside the project before generating if you want to keep it away from workspace tools. Protect that directory using your operating system permissions; the signer needs read access.
npm run kit -- sign prepared.json signed.json validates the sender, chain 7000, nonce, gas, exact value, calldata and fee model; prints those public fields; and requires you to type SIGN in an interactive terminal. It never connects to RPC or MCP while signing. It refuses unknown transaction fields and unsupported transaction types instead of silently dropping them.
npm run kit -- broadcast signed.json parses the signed transaction, recovers its sender, checks chain 7000 and displays its contents before requiring BROADCAST. The signed payload then goes to the MCP server. Signing does not mean broadcast; broadcast submission does not mean confirmation. Use get_transaction_receipt to check the result.
Private keys and signed files must not be committed, copied into chat, or included in a shared archive. Client deny rules are useful guardrails, not process isolation. Never ask an AI client to read the key file or automatically answer terminal confirmations.
External wallet
For funded accounts or Cosmos operations, review the unsigned data in your own wallet (for example a compatible hardware wallet, MetaMask for EVM, or a Cosmos wallet supporting ZetaChain). Export the signed transaction using that wallet's supported workflow. The kit does not bundle a hardware-wallet driver or a Cosmos signer.
EVM broadcast accepts serializedTransaction as signed hex. Cosmos broadcast accepts txBytes as signed base64. Never feed a Cosmos prepared message into the EVM signer. Verify chain ID, denom, validator/recipient, fees and sequence in the wallet before authorizing it.