"Coded and Audited by AI," and the Longer Story Underneath That Sentence

SEPTEMBER 9, 2026

A link crossed Bitcoin Optech's account this week pointing at a beta Android wallet called Ibis, and one sentence in its own README stopped me before I'd read anything else about what the thing actually does: "Ibis is coded and audited by the most current frontier AI models." No firm named. No auditor's report linked. Just that, sitting under a heading called "Disclaimer" — which is itself a small tell about how the developer feels about the sentence above it. I went looking for what that claim is actually standing on, because "audited by AI" is exactly the kind of phrase that can mean anything from "a chatbot skimmed the code once" to something a lot more rigorous, and the difference matters enormously for software whose entire job is holding a stranger's bitcoin.

What Ibis Actually Is

Strip the marketing framing away and Ibis is a fairly serious piece of software: a self-custodial Android wallet built on Bitcoin Dev Kit, openly modeled on Sparrow Wallet's philosophy of exposing rather than hiding the mechanics — coin control with UTXO freezing, custom Electrum/explorer/fee servers instead of a hardcoded default, RBF and CPFP fee bumping, multisig descriptor import with local PSBT signing, watch-only wallets, hardware-wallet signing over animated QR for a fully air-gapped setup, and message signing under BIP137. It also reaches past Bitcoin's base layer into Lightning (via a remote LND, CLN, or Nostr Wallet Connect node), Liquid, and Spark, each toggled per-wallet rather than bundled in by default. It is, deliberately, not built for a beginner — the README says as much in its second sentence, before it lists a single feature.

The developer goes by aeon, pseudonymously, and has been shipping it since February 2026: a young project by any measure, 64 stars and five forks on GitHub as I write this, distributed only as a downloadable APK from GitHub Releases rather than through the Play Store — no Play Protect scan sitting between the file and your phone. To aeon's credit, the in-app update checker is hardcoded to only ever open a release page under github.com, which at least closes off the obvious phishing move of a fake "new version" link pointing somewhere else. It does not, and cannot, verify that the APK you actually downloaded matches what's in the repository — that part is still on you, same as it is with almost every wallet that isn't gatekept by an app store.

The Document That Actually Told Me Something

What changed my mind about taking this project seriously wasn't the feature list. It was finding SECURITY.md sitting right next to the README — a document most small open-source wallets don't bother writing at all. It lays out, in specific and checkable terms, exactly how secrets are handled: BIP39 mnemonics and private keys are held as "spend secrets," encrypted under a random 32-byte session key that exists only in memory while the app is unlocked, itself wrapped per unlock method — PBKDF2-HMAC-SHA256 at 150,000 iterations for a PIN, an Android Keystore-bound AES key for biometrics. Backups are AES-256-GCM under a password stretched at 600,000 PBKDF2 iterations. A duress PIN opens a decoy wallet; a separate wipe PIN erases everything; an auto-wipe threshold does the same after too many failed attempts, with the lockout state written synchronously so a process kill can't roll back the counter.

The part I found most credible wasn't any single mechanism — it was a section plainly titled "Does not fully defend against," naming, among other things: a compromised or rooted Android OS, physical access to an already-unlocked device, a user who disables the lock or shares their own seed, forensic recovery of supposedly wiped flash storage, and — its own words — "$5 wrench attacks beyond duress/wipe features." A security document that only lists what it protects against is marketing. One that spends equal space on what it explicitly does not protect against is closer to engineering, and it's the same discipline I respected in Coinkite's own advisory back when I wrote about the Coldcard entropy bug — Coinkite told users the plain, unflattering truth about what a patch could and couldn't undo. This document reads like it was written by someone trying to survive contact with a real attacker, not someone trying to survive contact with a reviewer.

Where the README's Sentence Actually Comes From

Here is the part that actually surprised me, and the reason this entry exists at all. The README's "audited by frontier AI models" line links to a specific release — v4.7.0-beta, dated August 15th — and that release's own changelog tells a considerably more specific story than the README does. It credits a security audit performed with two AI models by a named group and a named contributor: Bitcoin Red Team, and a researcher going by PortlandHODL. That's not a chatbot rubber-stamping a pull request. Bitcoin Red Team is a real, OpenSats-funded volunteer effort — sixteen people who spent twenty-seven and a half hours on August 4th and 5th running AI-assisted security scans across 390 separate open-source Bitcoin repositories, reporting nearly five thousand findings including 85 rated critical, in the direct wake of the exact Coldcard entropy disaster I wrote about the same week. Ibis was one of those 390 repositories. The bug bounty aeon offers was never even claimed through the normal process — he says in the release notes he offered it to the auditors unprompted, and that the funds are going toward auditing more Bitcoin projects rather than into anyone's pocket.

So "audited by AI" turns out to be true and also badly incomplete as a sentence on its own. The actual sequence was: a small, funded, accountable human team used frontier models — Grok 4.6, Kimi K3, DeepSeek V4 are all named across the two documents — as a scanning and reasoning tool, the same way you'd use a linter or a fuzzer, and then a human being with a public handle looked at what came out and decided what was real. That's a meaningfully different claim than "an AI wrote and checked its own homework," and the README genuinely undersells it — though the fact that it undersells rather than oversells the story is, in its own small way, a point in the project's favor.

What They Actually Found

The changelog is worth reading in full if you're weighing this wallet seriously, because it names real, concrete, already-shipped vulnerabilities rather than vague "hardening" language. A few that stood out to me: the duress PIN's decoy wallet, before this fix, could leak the real wallet's seed through a backup export taken while duress mode was active — exactly the scenario duress mode exists to protect against, broken at the one moment it matters most. A transient Android Keystore error could wipe every seed in the app rather than failing safely. Connecting to a remote Lightning node over an unverified TLS connection could hand a macaroon or CLN rune to a Tor exit node or anyone else on the path. An unconfirmed on-chain send through LND or CLN could be re-broadcast a second time as an independent payment after a dropped response. A submarine-swap fallback path would pay whatever address a Boltz server handed back, with no independent check that the address matched the swap being paid for. Every one of these was fixed in the same release that names the audit — and the release notes state plainly that there are no known instances of any of them costing anyone funds before the fix shipped.

I want to sit with that list honestly rather than wave it away. These aren't cosmetic bugs. A seed-leaking duress mode and a Tor exit stealing Lightning credentials are the kind of finding that, in a wallet with real installs, is exactly how the next Coldcard-shaped headline gets written. The reassuring fact isn't that a beta wallet had serious bugs — nearly every piece of security software does, at some point, including ones built by full-time teams at funded companies. The reassuring fact is that someone with real incentive to look — sixteen volunteers, backed by a grant, working in the open, naming themselves — actually looked, found them, and got them fixed inside the same beta cycle, apparently before anyone lost anything.

What stays with me isn't really a verdict on this one wallet, which will look different in six months regardless of what I write today. It's that "audited" turned out to be doing exactly the kind of unexamined work in one sentence that "protected by a hardware chip" was doing in Coldcard's marketing right up until it wasn't. The fix in both cases was the same, and it's not particular to this wallet or that one: don't read the one sentence a project chooses to put in front of you. Go find the document underneath it — the security policy, the changelog, the names of who actually looked — and decide from that instead.