Biatec Wallet's published AI audits caught a critical swap-signing flaw

An audit trail written by machines

In May 2021 the project now called Biatec Wallet shipped its first public version: create a wallet, protect it with a password, view basic account information — all inside a browser tab. Five years later, the same codebase, renamed and expanded under the Biatec¹ brand, still runs entirely in the browser, and it has taken up an unusual practice for a small community wallet: it publishes dated security-audit reports, written by AI models, directly in its public GitHub repository², alongside a living registry of every risk those audits have found.

The most recent report, dated August 4, opens with a warning most projects would rather bury: 'The headline result is negative: this audit raises one Critical and one High finding, both of which are realistic paths to complete loss of an account's funds.' Both findings sit in the swap feature — the one place in the wallet where the user's private key is briefly exposed to the output of a remote server — and how they were found and fixed is a fair measure of what this kind of self-published audit program can and cannot guarantee.

A wallet that never touches your keys

Biatec Wallet is a free, open-source, non-custodial Algorand wallet created by Scholtz & Company, jsa. of Bratislava, Slovakia (company ID 51 882 272, VAT SK2120828105) and developed under the Biatec brand. Non-custodial means no third party ever holds the private keys: there is no backend server, no sign-up form and no KYC, and the wallet file is encrypted with AES-256 and stored in the browser's own IndexedDB. The password is used only locally to encrypt and decrypt — it is never transmitted anywhere, including to Biatec's own infrastructure — and the wallet locks itself five minutes after the last activity, clearing the decrypted key from memory. The project describes itself as the first open-source Algorand wallet; news coverage records Algorand's official wallet only becoming fully open source in June 2021, a month after AWallet's first public version.

Trying it takes a browser and a password choice: open wallet.biatec.io³ — the project's README marks the older a-wallet.net domain as a deprecated mirror of the same deployment — pick a wallet name and a password (the app recommends twelve or more characters mixing cases, numbers and special characters), and the wallet file is created locally. The app runs on mainnet by default, pointed at AlgoNode's public nodes, with settings to switch providers — including Biatec's own Algorand node and indexer infrastructure.

How the audit program runs

The process is codified in a file called ai-audit-instructions.md: typing 'do new audit' in the repository triggers a fresh pass by an AI model, which must act as 'a professional smart-contract / wallet-security auditing company' would — skeptical, adversarial, and precise about severity, with every finding tied to specific file paths and line numbers. Each report records the audited commit, the model that performed it, and the instruction version used; the risk registry carries every finding forward forever, never deleting rows and keeping closed ones for traceability.

Source: 4 raw.githubusercontent.com

The finding: swaps signed blind

The Critical finding, tracked as AW-2026-043, concerns the one part of a wallet that must, by design, trust a stranger for a moment. When a user swaps one asset for another, the wallet asks an aggregator — Deflex, Folks Router, or Biatec Router — to compute the route and return the unsigned transactions for the trade. The wallet decodes those transactions and signs them directly with the account's raw private key. What the audit traced is that none of the three paths validated anything about the server-supplied transactions: not that the sender is the user's own account, not the recipient or amount against the quote shown, not even the network's genesis ID — and the transactions are never rendered to the user before signing. The user clicks one Execute button and an opaque batch of remote transactions is signed with their key.

The stakes are specific to how Algorand transactions work. A signed transaction can carry fields beyond 'pay X to Y': a closeRemainderTo field closes the account out, sweeping its entire ALGO balance — or, on an asset transfer, the whole token holding — to whatever address the field names, and a rekeyTo field transfers signing authority over the account to a different key entirely. On Algorand, rekeying lets an account delegate its signing authority to a different key; the ledger then records which key actually signs. A compromised or malicious aggregator API could return exactly such a transaction, and the wallet would sign and submit it silently — bypassing the red close-to and rekey warnings that an earlier remediation (AW-2026-001) had added to every other signing surface in the app.

The second finding: a domain check that trusts the attacker

The High finding, AW-2026-044, sits in the new ARC-60 arbitrary-data signing feature. ARC-60 extends WalletConnect — the QR-code protocol that lets a web app connect to a wallet and request signatures without ever holding the keys — so a connected DApp can ask for an authentication signature over arbitrary data, the basis for passwordless sign-in flows. The wallet displays the requesting domain, purpose and a full data preview before signing. The audit found the domain-binding check was self-referential: both the claimed domain and the authenticatorData meant to attest to it arrive inside the same DApp-controlled request and are checked only against each other, never against the actual WalletConnect session peer. A malicious DApp could therefore obtain a valid signature bound to any domain it cared to name — precisely the spoofed sign-in the feature's own source comment says it prevents.

What's in the current code — and what isn't verified yet

A fix landed the same day the report was published (commit 0b3947e, 'feat: enhance ARC-60 security and DEX aggregator transaction validation'). A new shared helper, assertSwapTransactionSafe, now runs over every transaction before any of the three aggregators signs, refusing the whole batch if the sender does not match the connected account or if any transaction carries a rekey or a close-out field. On the ARC-60 side, a new domainMatchesSessionOrigin check compares the claimed domain against the hostname of the actual WalletConnect session peer instead of the request's own payload.

The fix is on master and in the deployed wallet: the guard's refusal messages are present in the minified JavaScript bundle served by a-wallet.net, confirming the validation code ships in what users actually run, and both domains serve the same build (36221a6, August 13). What has not happened yet is verification of the fix by the program that found the bug. The risk registry's most recent entry is the August 4 audit itself, which reviewed an earlier commit; the validation commit came separately the same day, and no later audit report exists in the repository to re-verify AW-2026-043 and AW-2026-044 as closed.

That unverified status is worth weighing against what the program actually is. The audits are performed by AI models under the project's own standing brief, with no independent security firm named in any of the six reports, and the repository publishes no tagged releases — builds ship straight from the CI/CD pipeline — so there is no release-certification step to lean on. The August 4 report itself is explicit that its headline findings were traced in static source, not proven against a running deployment. As a transparency experiment the program is genuinely unusual — most wallets publish audit summaries, not the raw 'what we found this month' files. As an independent security guarantee, it does not yet cover its own most recent fixes.

A community project funding itself

Biatec is independent of Algorand Inc. and the Algorand Foundation, receiving no ongoing funding from either, according to its FAQ, but it has drawn one-off xGov community grants. The xGov repository records 10,000 ALGO for AWallet itself and 60,000 ALGO for its payment scheduler as Approved; two 2024 proposals — a retroactive request for 36,912 ALGO and an on-chain identity project for 148,999 ALGO — are listed as Final. The project's own framing, in the retroactive proposal's abstract, is that AWallet is 'one of the most advanced wallets on Algorand.'

The financial footprint behind that claim is small. The published donation address holds 25.6 ALGO and roughly 1.03 USDT on-chain; the project's Discord has 411 members with 7 online at the time of the check; the most visible recent social post about the wallet, on Bluesky, has a single like. Development itself is not dormant: the repository was pushed to on August 15, carries 672 stars, and its two main contributors account for 546 and 62 commits respectively.

One concentration point a reader should weigh: the wallet's swap screen routes through Biatec's own aggregator alongside the two third-party routers, and Biatec also runs the Algorand node and indexer infrastructure the wallet can connect to. None of that is a problem by itself — the non-custodial design means the wallet only signs what the user approves — but the August 4 audit shows exactly why the aggregator layer is the trust boundary that matters, and the team's own router sits squarely on it.

The same Slovak company has built a broader toolkit around Algorand: a free, open-source payment gateway that lets merchants accept ALGO, USDC or USDT directly to their own account with no financial middleman and no wallet account required, an open-source voting system, and the Stabilitas national-stablecoin framework, which this outlet previously found halted since 2023. The wallet's audit program, whatever its limits, is the part of that portfolio where the team shows its work in the most inspectable way.