the-TRUSTLESS-report
2025
2024
2023
2022
The Titanium Trust Gap: Smart Contract Forensics in Aerospace Industrial Supply Chains
Last quarter, I was hired by a tier-1 aerospace supplier to investigate a data integrity issue in their serialized parts registry. Their system—a smart contract–based provenance chain—was modeled closely on Boeing's 2023 structure for tool and material traceability. The client had traced an inconsistency in their audit trail: certain materials appeared to meet all paperwork requirements, complete with digital custody records and certificates, but physical inspection revealed they'd skipped an upstream validation step entirely.
These were not forgeries on paper, but mismatched or unverified materials were moving through a system that depended on the Certificates of Authenticity to be enough.
I was given access to their codebase, a clone of the live registry being used to track end-to-end materials shipments. The dataset has since been pseudonymized and is available for public analysis.
The core flaw turned out to be a logic omission in the receive() function. It accepted incoming custody events without requiring upstream validation. If you claimed to have received a toolkit by entering a tokenId value matching the character requirements, the registry wrote it in without proof of shipment, and without an upstream check for shipment ID.
This wasn't a crash or compile failure, it was a small but functional logic gap. Their ledger behaving as specified, but with the wrong specifications.
It's the kind of flaw that doesn't trip alarms in simulation. Everything "works." But the trust model is broken.
In this case, a downstream location could record physical custody of a toolkit that had never officially entered the system. With no upstream check, the ledger treated those events as truth.
What made the issue more interesting was the structure of the code itself, and here's where I'll say what's probably already obvious: the contract logic looks like it was written—or at least scaffolded—by an LLM.
I mean that in the forensic sense. The way the validation logic is structured looks like someone asked a general-purpose model to "write a supply chain asset receipt contract," and then filled in just enough domain knowledge to get it to compile. The conditionals are shallow. The custody state machine isn't really a machine—it's just a sequence of state overwrites. There's no adversarial modeling. No checks for phantom entries. No assumptions that actors might be lazy, let alone malicious.
The absence of skepticism is what turned this edge case into a systemic risk.
If this flaw had gone unnoticed, it could have allowed falsified custody entries for anything in the serialized parts list: titanium billets, torque sets, composite casings. This isn't the result of malicious tampering.
This is just the kind of quiet mis-recording that escapes notice until something goes wrong.
In the case of Boeing-Airbus, 1,000 separate parts had to be recalled and individually chemically tested for their alloy values, and every single one of those 1,000 parts were in active use by commercial airlines at the time of their recall.
The fix was simple: enforce upstream reference checks before accepting downstream custody. But that fix only works if you realize the risk exists in the first place.
The events highlight that the danger in these systems isn't only that they crash, or even anymore that a malicious actor will force entry or injury on a valuable supply chain.
With the ubiquity of LLM-generated logic controls, the danger is increasing that these systems silently accept bad data and keep moving. Once they do, they create a record that looks authoritative but isn't.
-Howell Francis
SAFE CEX: LESSONS FROM THE FTX CRASH
Originally published 15 Nov 2024
This week, we're talking about innovations in cryptography driven by the November FTX crash. This newest – and ongoing –Tech Fail sparked a technical discussion between Ethereum co-founder Vitalik Buterin and lead staffs at Coinbase, Kraken and Binance. The outcome of their talk lays a foundation for innovation in cryptographic techniques to solve the problem. We're fascinated by what they proposed – and we want you to know about it too.
Central to the controversy surrounding the FTX collapse is the company's hidden insolvency – until as late as 7 November, FTX CEO Bankman-Fried was tweeting that they still had enough money to cover all their client holdings. As we know now, FTX halted all withdrawals the very next day, leaving client accounts unfulfilled to a total of at least 1 billion USD, with the actual number still unknown as of writing.
The overnight turnaround highlights the fundamental flaw in replacing centralized government-backed finance with centralized crypto exchanges: no government backing means no cover for customer withdrawals in the event of mass-abandonment – the crypto equivalent of a bank-run. Without government oversight, FTX was able to make behind-the-scenes transfers with Alameda Research (CEO Bankman-Fried's crypto trading company), leaving no way for clients or traders to know FTX was so dangerously over-leveraged.
The antithesis to centralized exchange is decentralization, where the technological structure is designed to operate transparently. On a decentralized exchange, those suspect transfers made between FTX and Alameda would have been visible. Centralized and decentralized exchanges do not exist in a mutually exclusive binary, however: there is a spectrum of functionality between CEX and DEX. It is in this space of hybrid-centralization that cryptographic constraints are used to thwart and prevent misuse.
The rest of our discussion here digs into those cryptographic questions: What are the technologies available now that create the existing transparent products? What challenges to those technologies face? -and - What are the limitations faced in truly proving mathematically – beyond any doubt – the solvency of an exchange?
Let's start at the beginning: Proof of Solvency is the process of establishing an exchange has the funds to pay back all its depositors. At its most basic level, proving deposits without having to rely on trust means publishing a list of account holders and their respective balances. Obviously, this approach sacrifices the privacy of the account holders. Over time, improvements in maintaining overall data privacy while publishing parts of useful information has led us to our current technologies: adding cryptographic proofs of reserve.
Proving an exchange has enough funding in reserve while also maintaining privacy consists of a combination of proof of assets and proof of liabilities. Vitalik Buterin says it plainly: 'If you prove that customers' deposits equal X and prove ownership of the keys of X coins, then you have proof of solvency: you've proven the exchange has the funds to pay back all of its depositors'.
Let's look further into proof of deposits, where we prove customers' deposits equal X-value. The state of current technology lies in Zero-Knowledge Proofs. The goal of zero-knowledge proofs is for a verifier to establish that a prover possess knowledge of a secret parameter (called a witness), without revealing the contents of the parameter to the verifier or to anyone else. In concrete perspective, this means that a program C, taking two inputs: a public input x and a secret witness input w, is denoted: C(x, w). The output of the program is Boolean, either true or false. The goal of giving a specific input x is to establish the prover knows the secret input w, such that C(x, w) == true. zk-SNARKS are the current technology allowing a prover to show that they know the value of w without revealing the value itself.
Where could proof of asset innovation happen now? In his conversation, Buterin imagines that even more complex constraint systems can be possible. In one example, Buterin imagines a leveraged trading system where a zk-SNARK is used to prove that the exchange is not risking customer funds by secretly exempting certain classes of users from the rules of the exchange. Buterin also extrapolates an application for lending environments: where anyone seeking a loan could evaluate the leverage of their lender for themselves.
On the complimentary side to proof of reserves is proof of holdings/assets, where it is established that an exchange has ownership of X-value coins. As it currently stands, the simplest way to establish proof of assets is to move X-coins at a pre-agreed time, which stamps their travel on the public ledger. Another common method is to move coins that have been labeled by the owner in the data field of the transaction. A primary practical problem with this method is dealing with the cold storage realities that come with managing the high values – and volumes – at stake. Many security protocols used by exchanges involve multi-party computations between several devices to maintain air-gaps and reduce chances of a hack compromising a single key device or location.
A second major challenge is protecting against collateral dual-use: a concept that mirrors the behavior of FTX, which led directly to its insolvency: collateral dual-use means shuttling collateral/coins back and forth between accounts to make it seem like an exchange is solvent when isn't.
Proof of solvency, in a hybrid-decentralized model, would ideally be done in real time, with a proof that updates after every block in the chain. In a practical reality, this could look like coordinating proofs on a fixed schedule between exchanges: agreeing on a predetermined time and date for proving reserves on all platforms, preventing the ability to shuttle any collateral before or after the proof.
Where could proof of holdings innovation happen now? Buterin describes several paths an exchange can take to reduce expense and increase security. In one, he suggests exchanges generate a few addresses, publish a proof of each address one time to prove ownership, and then continue to use those addresses repeatedly. This option is at once the simplest, the most secure, and the least private.
A second approach is a modernization on a current model some exchanges already use, with a human auditor, where some addresses are randomly selected for proof. Buterin suggests that pairing this auditor-model with a larger pool of addresses from the beginning, and then retiring each address after it has been used, would be a sound approach. Already the principle exists where the auditing could be automated, although there are no current use cases as of writing.
The FTX crisis earlier this month highlighted the need for transparency in liquidity disclosures, without a doubt. While the FTX collapse will likely scare some investors away from the crypto asset class entirely, we are already seeing some embrace more transparent products – and we are seeing calls for a return to crypto's decentralized roots.