Signer Approved a 59,676-Sat Fee on a 60,676-Sat Input
A newly disclosed issue in UTEXO Protocol’s enclave signer shows that its plain-Bitcoin signing path can approve a transaction that sends almost an entire signer-controlled UTXO to Bitcoin miners as fees, bypassing protections intended to limit how much BTC the mint wallet can lose in a single operation.
The issue, opened on GitHub at 07:47 UTC on September 25 by a UTEXO contributor, concerns the enclave’s SignBtc route. In a supplied reproduction, the signer was given a real UTXO from the project’s current development environment containing 60,676 satoshis. The proposed transaction returned only 1,000 sats to a self-controlled output and left the remaining 59,676 sats — approximately 98% of the input — as the miner fee.
The enclave signed it successfully.
The transaction was deliberately not broadcast, meaning the reproduction itself did not destroy the funds. The report also does not describe an outside attacker remotely taking control of the wallet. Exploitation requires a compromised or malfunctioning host capable of submitting transactions to the mint signer.
That distinction is important. Unlike crypto bridge security incidents where assets can be redirected into attacker-controlled wallets, this flaw does not simply allow the host to send the mint wallet’s Bitcoin to itself.
The enclave still checks whether outputs belong to addresses it controls and restricts plain-BTC signing to the wallet’s vanilla Bitcoin account. The problem is what happens to the difference between the inputs and outputs.
On Bitcoin, that difference becomes the miner fee.
UTEXO’s current validate_btc_request checks the PSBT structure, requires input amounts to be available, limits payments to outputs the enclave can prove it controls or permits under a small unowned-output allowance, and imposes a maximum total input value. It does not currently impose a maximum absolute miner fee, a maximum fee rate or a maximum percentage of the transaction input that can disappear into fees.
That creates an unusual failure mode: a transaction can satisfy the ownership controls while still economically destroying almost everything being spent.
The issue resembles other code-level security flaws where individual validation rules work as designed but fail to cover a dangerous combination of otherwise valid inputs.
The contributor says a compromised host could repeat the process across separate vanilla Bitcoin UTXOs. The existing BTC_MAX_TOTAL_SATS setting limits how much one transaction can spend, but it does not establish a cumulative fee budget and does not stop the host from submitting another excessive-fee transaction using a different UTXO.
The result would therefore be less like conventional theft and more like deliberate destruction of the mint wallet’s operating Bitcoin balance. If repeated, the attack could eventually leave the wallet unable to create UTXOs or complete operations that require Bitcoin liquidity.
Public Evidence Points to Signet Today, but the Code Is Being Prepared for Mainnet
The most important qualification is that the reported reproduction does not establish a loss of real mainnet Bitcoin.
The GitHub report explicitly rates the issue as High severity if the affected architecture is used on Bitcoin mainnet, but only Low–Medium in UTEXO’s current Signet development environment. Signet uses test Bitcoin rather than economically valuable mainnet BTC, so draining a development wallet primarily creates operational disruption rather than a comparable financial loss.
Public repository evidence reviewed for this story does not establish that the vulnerable mint signer is currently protecting live production mainnet balances.
In fact, the contributor specifically describes the current environment as Signet. Recent repository work also shows deployment components still being reorganized. A role-separation change merged on September 25 splits mint and burn signing into distinct enclave images, but its own deployment notes describe a remaining gap between building those images and releasing them through the repository’s existing deployment path.
At the same time, UTEXO is clearly building toward production deployment.
The repository contains release configurations explicitly designed for Bitcoin mainnet and Arbitrum One, including production enclave builds, mainnet Bitcoin indexer settings and attested security-policy controls. The codebase therefore cannot be dismissed as a purely academic experiment.
That makes the timing of the disclosure important. Crypto projects generally have far more room to correct a validation bug before production than after a flaw begins affecting user assets, as incidents ranging from a production blockchain exploit to a custodial wallet breach have demonstrated.
As of publication, GitHub issue #248 remained open. It had no maintainer response, and no public pull request matching the proposed fee-safety fix had appeared in the repository search reviewed for this article.
UTEXO Already Has a Fee Check — Just on a Different Signing Route
The most interesting part of the disclosure is that UTEXO already has code designed to detect excessive Bitcoin fees.
It simply is not applied to SignBtc.
The separate SignPsbt path used for bridge and mint operations calls a function named check_psbt_fee_rate. That protection calculates the implied transaction fee and compares its fee rate with a recommended Bitcoin fee rate obtained by the enclave.
The current rule can reject a PSBT when its implied fee rate exceeds three times the recommended rate.
Copying that exact check into SignBtc, however, may not be the cleanest solution.
UTEXO already has another open issue involving the same fee-checking system. Issue #241 describes the opposite problem: the SignPsbt protection can reject a legitimate mint after an EVM deposit has already been locked because the recommended Bitcoin fee rate changes or because the unsigned transaction size causes the calculated rate to appear too high.
In one documented development-environment case, the enclave rejected an 8.11 sat/vB PSBT because its dynamically calculated ceiling was 6 sat/vB.
The two issues expose both sides of the same security problem.
One signing route is too permissive because it has no fee ceiling. Another can become too restrictive because its ceiling depends on a changing external fee estimate.
The contributor behind issue #248 therefore proposes a shared enclave-level policy rather than simply duplicating the current dynamic check. The suggested design would introduce a pinned maximum fee rate, preferably a maximum absolute fee in sats as well, and fail closed whenever the signer cannot reliably calculate the fee.
An operational fee check could still use current network conditions, but the enclave itself would maintain a hard safety ceiling that a compromised host could not override.
The Real Risk Is a Signer That Protects the Destination but Not the Economics
This bug is a useful example of why wallet security is not only about stopping an attacker from changing the destination address.
The UTEXO signer appears to do that part relatively well.
A malicious host cannot simply construct a normal transaction sending the full vanilla BTC balance to its own wallet and ask the enclave to sign it. Output-ownership checks are specifically designed to prevent that.
But a signer also has to understand the economic consequences of the transaction it authorizes.
If 60,676 sats enter a transaction and only 1,000 sats return to the wallet, validating that the 1,000-sat output belongs to the correct owner is not enough. The other 59,676 sats have still left the wallet permanently.
They have just gone to a miner instead of the attacker.
That makes this different from the direct asset diversion seen in a cross-chain bridge exploit, but the operational result can still be serious. A sufficiently funded mainnet wallet could lose real BTC repeatedly until it no longer had the UTXOs needed to continue mint operations.
For an attacker interested in disruption rather than profit, that is enough.
The issue also highlights why hardware-backed or enclave-based signing should not automatically be treated as equivalent to transaction safety. Keeping private keys inside an AWS Nitro Enclave significantly limits key-extraction risk, but the enclave still needs correct authorization logic. A perfectly protected key can sign a disastrous transaction if the policy deciding what is safe is incomplete.
The wider crypto industry has repeatedly learned that lesson. Large security breaches tend to focus attention on stolen keys and drained wallets, while subtler failures can originate in transaction validation, infrastructure assumptions or application logic long before a private key itself is compromised.
Even incidents involving wallet infrastructure failures show how operational dependencies can matter independently of whether the underlying blockchain remains secure.
The encouraging part is that this particular weakness appears to have been found before any publicly documented mainnet loss.
The harder question is whether UTEXO closes it before the signer moves from a Signet environment into one where satoshis have real economic value.
The technical path is already visible: calculate every fee, impose a hard enclave-controlled ceiling and make both signing routes obey the same underlying safety policy.
Until that happens, the signer can answer the wrong question correctly.
It can prove that the Bitcoin is not being sent to an attacker while still approving a transaction that makes almost all of it disappear.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.