AskGrokWallet · a real monthly record

What the gate actually did for 30 days

Pulled live on 2026-09-24 from the public demo pool. It is not a client's record — a client's version carries their own policy constraints and a name. Everything below is the real thing, unedited, including the parts that look small.

Decisions

Outcome	Count	Meaning
Auto-allowed	15	inside the policy, no human needed
Approved by a human	10	escalated, then a person said yes
Refused	7	stopped (detail below)
Executed	3	settled, with a receipt
Still pending	7	waiting on a human when the window closed — nothing executed
Total	42

The seven refusals

Why it stopped	Count
A human declined it in the approval inbox	3
Daily budget already spent	2
Hit a "never" rule	1
Action type forbidden by policy	1

The distinction matters: three of these were stopped by a person, four by the rules. Reporting them as one number would overstate automation.

The ledger behind the numbers

entries             68
anchors             19
integrity           intact: true
latest anchored     entry 67
chain               Ethereum Sepolia (chainId 11155111)
anchor transaction  0xe5c9d3c5bfdc29427b6f9f3001c3b94dcacb246a869c4b1a7f870ba3217d393c
                    confirmed in block 11759509, status success

An anchor is the log's head hash written into a blockchain transaction every hour. Its point: the state of the log at that moment is fixed in public, and afterwards not even we can change it.

Check it yourself

# the whole log, readable by anyone
curl -s https://askgrokwallet.io/api/receipts/chain | head -c 400

# the anchor above, on a block explorer: search 0xe5c9d3c5… on Sepolia

# one record, end to end
curl -sLO https://github.com/richard7463/askgrokwallet/releases/download/verify-receipt-v1.0.1/SHA256SUMS
curl -sLO .../verify-receipt-v1.0.1/verify-receipt.mjs
shasum -a 256 -c SHA256SUMS
node verify-receipt.mjs receipt.json

What this proves — and what it does not

Proves. Every number above comes from signed records; each has a fixed position in the chain; the head is inside a successful on-chain transaction. The counts distinguish policy refusals from human refusals.

Does not prove. That nothing was omitted — that needs an enforcement point that refuses to execute an unrecorded action, which is not built yet. The classification of a refusal is derived from the signed reason text by a fixed rule, not independently verified; a reader who wants to check the classes must hold the receipts. And a quiet month would be reported as a quiet month: zero decisions is information, not a gap in the data.

If it had been a client's month

This sample	A client's version
Public demo pool, all activity	That operator's strategy account only
Refusals grouped by reason class	Each refusal mapped to the clause it would have broken
Amounts hidden	Amounts disclosable to the funder, still hidden from the public

None of that is "more proof". It is the same record, said in the language the reader needs.

For the person funding the bot → · Verification procedure for auditors →