Hello, I am Loredana and today I will show
you an example of a smart contract written
I have recently started building decentralized
apps with Ethereum and wanted to share some
insights about the process.
In this video, I will just go through the
code I wrote in Solidity and understand what
is happening (show diagrams).
In later videos, we will show some existing
options for development and testing smart
contracts and Dapps.
In short, the idea for the contract came from
a spreadsheet that I use to to keep track
of my time on certain projects or tasks.
I usually have a deadline and an actual sum
of money that gets put aside if I go beyond
I wanted to have a more automated way of doing
So, we have a contract named OnTrack that
knows about a client, a provider of service,
a 3rd party observer and a deadline.
The function that’s called when the contract
is first created is the one that has the same
name as the contract; or if you have an unnamed
function, that will be used as fallback.
To simplify things, I made the client be the
same as the contract creator, so we got rid
of one input value.
The deadline is the standard time in milliseconds
from 1970 and then we get the blockchain addresses
of the provider and observer.
I have three public functions: completed,
which can only be called by the Provider after
he completes the project.
We do this by adding a modifier: onlyProvider,
We have the Confirm function, which can only
be called by the client, to confirm that the
project was fulfilled.
And requestFunds, which can be called by any
of them in case the other did not keep his
end of the deal.
I opted for requestFunds because I haven’t
found a Solidity API to directly schedule
actions inside the contract.
There is one project (Ethereum Alarm Clock)
that does just that, but I wanted to keep
Through the code, you will see a couple of
events defined here.
They are a good way to log what is happening
in the contract and they can also be watched
through the web3.js api in your web application.
We also have some internal functions like
calling an Observer or handling payment.
The observer is called in case the client
and provider do not agree.
It returns a boolean that tells us wether
the project was fulfilled or not.
I have made some diagrams for the OnTrack
Here is a flow diagram that helps understand
the process a bit better and you can also
use it to see if you have cases that are not
So, when we create the contract, the ETH value
gets sent from the client to the contract
and we initialize the status variable with
Status can be 0, 1, 2, 3 or 4.
If the provider completes the project before
the deadline, status is 1.
If the client confirms, status will be 2 and
we call the payup function.
This function pays the provider if the status
is 2 and the client otherwise.
We will have a status of 4 afterwards.
So, what happens if the deadline passes and
project is not completed or if the client
does not confirm fulfillment?
The contract keeps the money unless someone
Then, we check the status.
If the contract was already solved before,
we just end and throw away the current transaction.
If the status is 0 or 2, the payup function
is called because everything is clear.
If the status is 1, the Observer is notified.
If he returns true, the project is fulfilled,
status is 2, provider gets paid.
If false, we mark the contract as observed,
status is 3, the payup function is called
and client gets his funds back.
And that’s it.
We can now think about extending this contract
to support multi signatures from both client
Make the provider also pay some ether up front
in case he does not keep his end of the deal.
We should also pay the Observer something.
Now, I have tested this with 2 Observers that
return either always true or always false.
We can also have a human Observer contract
and instead of getting a synchronous automatic
answer, modify the OnTrack contract to wait
for the Observer’s answer.
In the next video, we will see how to set
up some tools in order to test this contract.
Thank you for watching and do check out my