Flight Data Verification: Why We Use Blockchain

One of our sponsors is an Avalanche-based blockchain company, so 'use blockchain' initially looked like it was just there to check a sponsorship box. But once we sat down and wrote out the actual problem, a real engineering angle showed up: when we tell a competition jury or a visitor that a flight log hasn't been altered since the competition, why should they believe us? If we show a database record, we can also edit that record. The solution is simple: write the claim somewhere they don't have to take our word for.

What we write to the chain, and what we don't

We never upload the log file itself anywhere, not to the chain, not to a server. We only write its SHA-256 hash, a 32-byte fingerprint. The file itself stays with us; anyone who wants to verify uses their own copy. There are two reasons for this: file size (some logs run to tens of MB) would make on-chain storage prohibitively expensive, and more importantly, verification doesn't require the file to be public, only that it can be proven unchanged.

• Written to the chain: logId, title, date, SHA-256 hash, transaction hash.
• Not written to the chain: the log file itself, raw telemetry, GPS data.
• The contract has a single function: anchorLog(logHash, logId, title), owner-only.
• The same logId can't be anchored a second time (AlreadyAnchored), meaning a record can't be overwritten later.

Why Fuji testnet, not mainnet

Writing to the Avalanche C-Chain mainnet was possible too, but that would mean spending real AVAX, and paying gas fees after every flight doesn't make sense on a student team's budget. Fuji testnet is EVM-compatible, so it's the same contract code, the same tooling (viem), the only difference is that test AVAX comes free from a faucet. There's no loss in verifiability: like mainnet, testnet is public, immutable, and not controlled by any third party. In a competition context the proof carries the same weight, at zero cost.

You don't need to trust us. You just need to trust the math, and that's public.

We kept the contract deliberately dumb

FlightLogRegistry.sol has no upgrade mechanism, no role management, one function. In the first draft we considered adding multi-authorization and a record-update function in case we needed it later, then dropped the idea. This contract has exactly one job: write a hash, once, irreversibly. The fewer moving parts, the easier it is to audit and trust. The contract was deployed by hand through Remix; we didn't add a toolchain like Hardhat to the repo, that would have been unnecessary complexity for a one-time operation.

The verification flow: no server in the middle

When you upload your own file on the verification page, the SHA-256 hash is computed in your browser, the file is never sent to us. Then the browser connects directly to Fuji's public RPC and reads the hash from the chain, a read-only call, no signature required. If the two hashes match, it shows a match. Our server has no role in this step at all, which means we have no way to manipulate the result either. On the admin side it's the opposite: once the file hash is computed, it's signed with the team's wallet and written to the chain, a step that of course requires authorization.

The takeaway

This feature isn't a badge we added for show, it's the solution to a real problem: verifying our claim doesn't require trusting us. On the verification page you'll find both the registered logs and a tool to verify your own file.