The problem TrazaMed solves

The problem

Medicine shipments can be exposed to temperature excursions, impacts, or suspected unauthorized opening. When records are fragmented across manufacturers, carriers, and pharmacies, it is difficult to reconstruct what was reported during transport and connect that evidence to payment.

What TrazaMed does

TrazaMed is an IoT and blockchain prototype for recording shipment alerts and linking escrow release to the batch's recorded condition.

• Edge: an ESP32 with DHT11, ADXL345, and PIR sensors provides temperature, impact, and motion signals.
• Gateway: a Cloudflare Worker encodes the alert and readings into a compact record and signs the transaction with viem. The blockchain private key stays in the gateway environment.
• Blockchain: a Solidity contract on HashKey Chain Testnet (chain ID 133) stores an append-only batch history, restricts batch and event registration to authorized addresses, and holds native-token escrow.
• Web interface: a React application lets users inspect batch history and payment status without a wallet, and connect MetaMask to request delivery confirmation.

How payment works

Payment release requires a call to confirmarEntrega; it is not triggered autonomously by the sensors. The contract releases funded escrow to the batch's registered manufacturer if no damage flag has been recorded and payment has not already been released. If the batch is flagged, the call reverts and the funds remain in escrow. In the current prototype, any recorded condition other than the exact value OK sets that flag.

The intended users are laboratories, distributors, pharmacies, and auditors who need a shared record of reported shipment conditions. Blockchain makes recorded events independently inspectable; it does not prove that a sensor reading is physically accurate or that a medicine is safe.

Testnet contract: 0x75B81d9dCd1101b0C5854509d0065368d9596d13.

Challenges we ran into

The biggest challenge was the hardware. The Raspberry Pi I originally planned to use failed due to a corrupted SD card, so I pivoted to an ESP32, rebuilding the entire environment from scratch. Wiring three sensors (DHT11, ADXL345, PIR) to the correct pins —avoiding the input-only ones— took several attempts, verifying each connection carefully.

The second challenge was that the ESP32 could not sign Ethereum transactions directly: the available libraries were outdated and wouldn't compile. I solved this with a gateway architecture: the device sends its data over HTTP to a Cloudflare Worker that signs with viem, so the private key never lives on the field hardware —which is also a security improvement.

On-chain access and physical trust

The contract uses OpenZeppelin Ownable, AccessControl, and ReentrancyGuard. The repository includes seven Foundry tests covering authorized registration, custody history, unauthorized writes, duplicate batches, withholding payment after a damage flag, and releasing payment for an unflagged batch. These tests cover specific behaviors; they are not a security audit of the complete system.

The oracle problem remains a limitation: multiple sensor signals and blockchain roles do not by themselves prevent physical tampering or forged requests to the gateway. The current Worker accepts incoming POST data and signs it, so device-to-gateway authentication and validation remain necessary production work. Another integration constraint is that the contract treats every condition other than the exact value OK as damage; the gateway's packed records therefore belong to the alert path.

The prototype also retains flagged escrow without a refund or dispute-resolution function. Those settlement rules and stronger device provenance need to be defined before real-world use.