edipascale/iothackffm

Smart contract for the P2P Parcel Delivery project for the Frankfurt Summerschool on IoT and Blockchain

Smart contract for the PePaDe project at the Frankfurt Summer School on Blockchain and IoT. Copyright Emanuele Di Pascale, 2017. See LICENSE for information on reusing this code.

The contract represents a decentralized agreement between a sender and a deliverer of a parcel. In the current iteration, the sender specifies the intended recipient and the constraints on the shipment that he has (e.g. the maximum time the delivery can take since the contract creation or the maximum temperature the parcel should be exposed to).
Deliverers can see the pending shipment requests and candidate themselves to carry them out by proposing a fee. We intend to integrate uPort identities to enable reputation tracking, although at the moment this has not been implemented yet. The offer also comes with an expiration date to make sure that carriers don't get stuck in a commitment indefinitely but again right now this is not enforced. The sender selects a candidate deliverer; the contract is now agreed upon and must be funded by the sender, i.e., enough funds must be put in the contract to cover the agreed fee. At this stage the contract is Funded. When the deliverer reaches the sender's place to collect the parcel, both the sender and the deliverer need to confirm that the package has changed hands. The state of the contract then moves to Shipping. During the shipping phase, the iot sensor of the deliverer monitors the status of the parcel. If the temperature goes above or below the max/min threshold specified at the contract creation, the contract is notified of the Exception. If no exception takes place, when the parcel reaches its destination the intended recipient (and only him) can confirm the correct delivery of the package. If the package was delivered within the established time and temperature constraints, the payment phase is unlocked and the deliverer is allowed to withdraw the fee from the contract funds. In the current iteration, if any exception happens or if the parcel is delivered after the specified time constraints the deliverer gets nothing for its service. On the other hand no deposit fee is requested of him. All these things, including the ability for third party insurer to join the contract, would have to be looked into and developed in a real business product. Finally, any remaining funds can be sent back to the sender if the contract is in the Paid, Expired, or Exception states, and also if it is still waiting for the deliverer to show up after the expiration time has passed. Note that this allows malicious senders to create shipping requests that they do not intend to honor at no personal cost, thereby disrupting the service. In production a small deposit should be required from the sender (or alternatively uPort reputation could be used for senders as well.)