Most AI assistants answer from training data. Ask one about a specific transaction or contract and it will give you something fluent and confident, with no live view of the chain. It is autocompleting an answer that looks right.
In most domains a confident wrong answer is an awkward correction. In crypto it is a drained wallet. That asymmetry shaped the whole product. When the cost of being wrong is someone's money, the model cannot be the source of truth. The chain has to be.
So TxDesk reads first, then talks. Ask about a transaction and it fetches the real one, decodes the actual function and events, and on EVM chains re-simulates a failed call to recover the revert reason. Ask about an approval and it reads your current on-chain allowance right now, so it will not report one you already revoked. Ask about a contract and it pulls structured signals (verified on the explorer, age, proxy status) and explains them. The model's job is to read the data to you, not to recall facts about the world.
The part I care most about as a founder is the honest boundary. Two decisions that came out of that:
It never treats chain free-text as proof. A token symbol, a contract name, a spender label, every one of those is a string chosen by whoever deployed it. An attacker can name a contract "Safe Router." So none of those feed a safety verdict, only structured signals do. A label cannot talk the tool out of a warning.
And when it cannot read the data, it says so instead of returning an empty result that quietly implies you are clean. A blank is not a clean bill of health, and I refuse to let it read like one.
It is read-only with respect to your funds, never holds a key, and works across more than forty chains. But read-first is the whole point.
I wrote up the full mechanics (the actual decode path, the allowance re-check, how risk scoring stays free-text-proof) here if you want to go deeper: https://dev.to/txdesk/your-ai-assistant-shouldnt-guess-in-crypto-a-confident-wrong-answer-costs-you-your-wallet-13ho
Curious how other builders handle the "be honest about what you couldn't verify" problem in their own products, it is harder to get right than it looks.
That line about a blank result not being a clean bill of health was the part that stuck with me.
A lot of products seem to treat uncertainty as a UX problem.
You're treating it more like a product responsibility.
I'm not sure those lead to the same decisions.