Set aside working funds and define the payment rules. Your agent does the permitted work and brings back the receipts. Your keys stay on your device.
macOS · Linux · MIT licensed · No service account
Follow one payment test. See where the funds go, what the wallet checks, and where a request stops.
Fund a dedicated wallet with 50 USDT and gas, choose the payees, set a limit per payment and an access window. Give your agent the task.
Read the transcript ↗Amounts are illustrative. Reports are assembled by the agent from transaction evidence. Built-in cumulative budgets and task reports are WIP.
“Send me gas. I need USDT, too. Run the transaction and check if it worked.”
Blockchain development kept handing the work back to the person. I wanted to give my agent working funds, let it finish the task, and see what it spent. So I built a wallet I could run and own locally.
Agents that can run shell commands can use the CLI. A terminal UI gives the person at the keyboard access to the same wallet and rules.
Read balances, transfer supported assets and look up transactions across eight EVM networks and Tron. Token transfers use exact registry deployments.
Read EVM contracts and invoke allowed recipients and selectors. Use preflight checks and transaction evidence to develop and test payment flows.
Agents use JSON results, transaction hashes, receipts and the local send journal. A pending or unknown result calls for a hash lookup before another send.
Support varies by network. Tron sends TRX and registry USDT to listed payees; native gas is still needed. Check feature status for what your installed channel includes.
Illustrative amounts, not a live transaction.
The signing process decodes the requested transaction and checks the policy itself. An agent calling it an “allowed payment” is not enough.
Per-payment limits are not cumulative budgets. Repeated permitted payments can spend the balance, and same-user processes share the access boundary. Lock does not reverse transactions already sent. Read the security model ↗
The wallet can become a foundation for service, shopping and investment agents. The integrations below are future work.
Buy the APIs and tools a task needs. Requires payment adapters, invoice validation and proof of delivery.
Find an item and complete an order within your instructions. Requires merchant adapters, final quotes, shipping privacy and refunds.
Act within your asset, venue and risk constraints. Strategies and execution controls are not implemented; returns are not guaranteed.
WIP Cumulative budgets and native spend reports are also future work. These directions do not imply ready-to-use integrations with every agent or merchant.
Read the future PRD ↗Install locally. Create and unlock the wallet yourself. Try the first transfer on Sepolia with testnet funds.
brew install 2lab-ai/tap/zwallet
No zwallet service account or dedicated token is required. You still need funds, native gas and RPC access for the network you choose.
Agents that can run the local CLI and read JSON results can use it. The person sets up the wallet and policy first. The diagram explains the workflow; it is not a shipped dashboard.
Today, the allocation is the balance you put in a dedicated wallet. Limits per transaction are available; enforced task and daily budgets are WIP. Repeated permitted payments can spend the full balance.
There is no built-in investment strategy, merchant checkout or service-payment adapter today. zwallet is the wallet component; these workflows are WIP. Investing can result in losses.