My Agent Trades Real Money. I Don't Trust It. I Verify It.

elinazahra — Sun, 15 Nov 2026 08:18:45 +0000

My Agent Trades Real Money. I Don't Trust It. I Verify It.

Written for the zkVerify Agent Games Creator Track (#AgentGames). This is my own experience running a live trading agent — what it does, what I actually check, and where verification fits.

The agent that moves my money

I run TraderPending, a crypto futures automation platform I built with AI assistance. It watches markets, fires signals, runs Grid and DCA bots, and executes orders across nine exchanges — Binance, Bybit, OKX, Bitget, KuCoin, Gate, MEXC, HTX, BingX — on web, Telegram, and Android. It is non-custodial: it trades through API keys, and it never holds my funds. The agent acts through a Binance Agentic Wallet.

The important part is not the feature list. The important part is that the agent acts on its own, with real money, and every order it places is a decision I have to live with.

So I have one rule that is not negotiable: every order carries a stop loss and a take profit. No order runs without them. Not sometimes. Always. The platform was designed that way, and I have refused to change it — even for a test. A trading agent that can open a position with no exit plan is not an agent. It is a leak.

That rule is a check. And checks are the whole story of this article — because a check I run myself is not the same as a proof anyone can verify.

The problem: my agent can say anything

An agent that acts on its own can claim anything. It can say it checked the balance. It can say it set the stop loss. It can say the size was within the risk cap. It can say the signal was fresh. And when something goes wrong, its logs are just its own words about itself.

That is the gap I live with every day. I did not solve it by trusting the agent more. I solved it — partially — by building a set of rails around it, and by refusing to let it act when anything is unclear. These are the rails I actually use, every session:

Simulate before broadcast. Nothing goes on-chain without a simulation first. If the simulation reverts, fails, or moves something unexpected, I stop.
Confirm before the first signing, and re-confirm on any change. A new chain, a new recipient, a new amount, a new approval scope, or about thirty minutes passing — any of those means I confirm again. I do not carry a yes from one context into another.
Exact, minimal approvals. Approvals are for the exact amount needed. Unlimited approvals need an explicit extra yes. I prefer revoking the old allowance and setting a minimal one.
Refuse blind signing. If I cannot read what a transaction does in plain terms — what it moves, to whom, for how much — I do not sign it. Opaque calldata is a no.
Fail closed. If the recipient, chain, token, or amount is ambiguous, I ask instead of guessing. If the RPC errors mid-flow, I do not retry the broadcast. I report and wait.

These rails work. They have kept real money safe. But notice what they are: they are checks I perform, in my own session, on my own machine. They produce no artifact that anyone else can verify. If my agent tells a counterparty "I followed the risk rules," the counterparty has only my word for it. The rails protect me. They do not prove anything to anyone else.

That is the difference between a check and a proof — and it is the reason I am writing this.

What a proof would change

zkVerify's Agent Games has a track called Proof Gatekeeper, and it is the clearest statement of the idea I have seen. The agent is a payment guard. The platform sends it a signed task — a transfer request. The agent has sixty seconds to decide APPROVE or REJECT, and it has to back that decision with a Groth16 zero-knowledge proof that the platform re-verifies against its own registered key. The agent cannot swap in a friendlier key. A valid proof of a bad decision still loses, because the decision itself is scored.

The scoring is the part that tells you the designers understand the stakes. A correct decision is +12. A wrong APPROVE is −6. A wrong REJECT is −3. Approving a trap costs more than being too cautious — exactly as it should. In trading, approving a bad trade costs more than skipping a good one. A timeout is −2, and answering without a valid proof is −2 on top of losing the reliability bonus. The message is consistent: say it, prove it, or do not say it.

The trap list is documented before the competition opens, and it reads like a catalogue of every way a "trust me" agent fails. Seven varieties, and I recognise all of them from trading:

Valid condition. The proof is on-chain, the key matches, the balance meets the minimum, the reference is fresh. Approve. In trading: the equity is there, the size is within the cap, the stop loss is set, the signal is live. Approve.
Verification key substitution. The proof verifies, but its key does not match the registered condition. The agent confused "the proof is valid" with "the proof is for the right rules." In trading: the decision followed a strategy — just not the one I approved. Reject.
Threshold mismatch. The proof is genuine, but the disclosed balance is below the required minimum. Reject, even though nothing was forged. In trading: the equity check failed. The trade does not happen.
Proof reused. The same proof reference, submitted again. A valid proof does not gain re-entry by being repeated. In trading: the same approval replayed for a second order. Reject.
Expired condition. The proof and condition are valid, but the window has passed. A later confirmation does not revive it. In trading: a stale signal. The market moved; the plan is dead. Reject.
Recipient mismatch. The proof is valid, but the recipient in it is not the address on the payment condition. The money would go to the wrong party. In trading: the order would land on the wrong symbol, the wrong account, the wrong market. Reject.
Amount overflow. The proof is valid for the stated balance, but the requested amount exceeds the single-transfer cap. Approve only up to the cap. In trading: the size breaks the risk limit. Reject.

Every one of those is a failure I have written a rule to prevent. The difference is that in my system the rule is a check I run, and in the Gatekeeper the rule is a proof the platform can verify without trusting me. The decision, the reason, and the proof travel together — and anyone can check the proof against the registered key.

That is the step from "I checked" to "here is the proof I checked." It is a small step in words and a large step in practice, because it removes the need to trust the agent at all.

What I would build next

If I were wiring this into my own trading agent, the shape is clear, because it follows the rails I already have. Before any order is placed, the agent would produce a proof that:

The stop loss and take profit are set — the order cannot exist without them.
The size is within the single-trade cap and the daily loss limit.
The balance and equity meet the minimum for the position.
The signal and the plan it belongs to have not expired.
The market, symbol, and account match the plan exactly.
The approval being used has not been used before.

The exchange would not have to trust my agent's word that those six things are true. It would verify the proof. A wrong approval would be expensive by design — just as it is in the Gatekeeper scoring — because in trading, as in payments, letting a bad one through is worse than stopping a good one.

I am not claiming I have built this. I have not. What I have built is the system that needs it: a live agent, moving real money, held together by checks that only I can see. The proof is the missing piece — the part that turns a private safety practice into a public, checkable guarantee.

That matters beyond my own account. Agents are about to handle money at a scale where no human can review every decision. If each decision carries its own proof, the human does not need to review them all — the proofs do the reviewing, and the human reviews the rules the proofs are checked against. That is the only version of autonomous money I would trust, because it is the only version where trust is not required.

So my position is simple, and it is the same one I started with: my agent trades real money, I do not trust it, and I verify it. The rails I use today are the honest version of that. A proof-backed decision is the complete version. That is what I want built — and that is why verification, not capability, is the thing that decides whether agents get to touch real money.

DEV Community: elinazahra

My Agent Trades Real Money. I Don't Trust It. I Verify It.

My Agent Trades Real Money. I Don't Trust It. I Verify It.

The agent that moves my money

The problem: my agent can say anything

What a proof would change

What I would build next

AgentGames