Set a maximum amount of hours your employee can work and bill you daily
Contract Life-span
Contract can have a Life-span - anywhere 1 to 365 days. No more work can be billed after contract life.
Delayed Withdrawals
Set a Payout frequency from 1 to 30 days - so the Client can have time to check the work done before any funds can be withdrawn
Guaranteed Balance
Contract should loaded with a minimum 1 day balance to allow to start the work.
Start/Stop Time Tracking
To start earning ETH - just send a startWork transaction. When you're finished - invoke stopWork, and your earnings will be saved.
Comments On Tasks
A comment needs to be added when the Employee starts work. That way the Client can track tasks and hours spent.
Possible Use-cases
There are numerous use-cases the Hourly Pay contract can be applied in:
1
Full-time hourly-wage work with a single client
Automate the payments for your work with a full-time Client using the Hourly Pay contract.
2
Protect yourself during Freelance work
Hourly Pay contract is also perfect for small tasks work. Have a one week task from a new client? Suggest to use this contract to protect both of you.
3
Targeted Donations
Use the contract with 0x0 as a Client to receive Donations for your Project. That way people would see the work you do, and allow you prove that every penny they've donated went to improve the Project.
How Does It Work?
Contract Creation & Setup
1. Client creates the contract
2. Funds the balance with ETH
3. Sets the options, such as:
- Daily Limit
- Contract Duration
- Payday Frequency
- Convenient NewDay timestamp
Hire Freelancer
1. Client Hires an Employee
2. During the Hire, the Hourly Rate is set
Work!
1. Employee can bill the client hourly using Start Work and Stop Work calls
No more than Daily Limit can be billed
Withdraw ETH
After the Payday Period passes Employee can Withdraw the billed Earnings.
Default Payday frequency is every 3 days.
Future Plans
There are a lot of ideas how this Contract can be improved:
1
More features
Currently the contract is a basic MVP and is restricted in many ways. For example, if the work session happens on the two days boundary - only first day is counted toward your earnings. This could be solved, but it requires a more complex approach with much more sturdy testing.
2
Good UI / FrontEnd
Work-In-Progress test FrontEnd is available here:
https://vicnaum.github.io/hourlyPayTest/ Although it's far from convenient, and still not functional for sending transactions.
Mobile App is also planned.
3
Code Review, More Tests and Refactoring
As the contract is still just a Working Prototype, its code isn't perfect (but tested to be safe). Tests code also needs rework, with separating for Unit tests and Test Scenarios.
Help the project evolve.
Make a Targeted Donation:
This contract is still MVP and there is so many ideas and so much work still to be done: FrontEnd, Mobile UI, Contract Improvements, etc...
Just send some ETH with a simple transaction, and this will add to the Contract balance.
Which means that all donations sent there would be spent on making this Contract better!
FAQ
Is it 100% safe?
Of course it's not 100% safe, because the Client/Worker dilemma can't be solved without an expert third-party managing an Escrow. If there's no arbiter to judge if the work had been done properly and the funds can be release - there would always be a risk of losing money or working without pay. Hourly Pay Contract goal is to minimize such risk.
So how do you minimize the risk?
By splitting the unpaid work to minimal parts. The regular PayDay periods mean that only the last period is at risk of not getting Work for money or Money for work.
By default - it's 3 days worth of work/money. But it can be even more reduced to just 1 day!
So, you're not risking the whole project anymore. Not risking a two-weeks worth of a milestone. Not reminding your client to pay your invoice or asking each week for a payment.
The stake at risk is just 1 day worth of money or work!
But what stops the Worker from just logging 8-hour days and do nothing?
The same thing that stops you from doing so at your regular job - visible progress and intermediate results. If you can't show any progress to the Client or explain why you spent 40 hours without anything to show - you will be fired.
Also, when starting work you have to put a comment on what part of the project you're working on. And all this is logged into the block-chain!
Ideally, the Client should keep track of the progress before each PayDay, because there is still an option to fire the Worker and refund the unpaid earnings.
Wait, so the Client can cancel all and refund the money?
Not exactly. Only the latest PayDay period can be refunded, money from previous periods are available for withdraw at corresponding periods ends. So again - only the latest period worth of work is at risk.
But why give such a permission to Client, even only for the latest period?
Because from my point of view - Client/Worker relationship is a bit unbalanced from the start.
Let's take a look at the things both sides have at stake in both situations - BadClient and BadWorker:
A) BadClient: If the Client is bad, Worker risks just one thing - spending his time, and not getting any monetary reward for this.
But the BadClient itself has a full set of risks if he acts maliciously:
1) Lose a contractor to finish the project and need to seek a new one.
2) Wasted time, missed deadlines and project plans.
3) Money is worth its every cent, but 1 day of code usually is useless, if the project is longer-term.
4) It's not so easy to be a BadClient as it is to be a BadWorker - you need to have a real project to earn gains from this fraud, and projects usually value reputation much more than anonymous Workers.
B) BadWorker: If the Worker is bad and "takes the money and runs" - BadWorker risks nothing but his reputation. But there are much more Workers out there than clients, so the reputation is harder to track.
But the Client has all the same risks as above from his ruined project, wasted time, no work done and missed deadlines. Plus - he loses real money.
Thus, it's harder to cheat when you're a Client, and especially if the PayDay Periods are so small that no meaningful work can be done within the period.
That's why I've decided to allow clients to refund the work done in current PayDay Period.
Ok, but why block-chain? Why contract? Why can't I just ask my client to pay me everyday?
The answer is in your question - because it looks silly and suspicious to ask the client for payment everyday. Also it fills client with chores to transact everyday, have a hot-wallet ready by hand everyday, etc. The contract automates it!
Moreover - the contract automates work tracking and logging.
So the client can see on the web-site, or in a mobile app:
1) How the work is going.
2) How much hours and funds had been spent and how much left.
3) On what tasks did the Worker work.
4) And how many hours he had spent on each.
All that is there - in the Events of the contract, ready to be displayed and analyzed.
I think it reminds me of something...
Yes. The main idea of the Hourly Pay Escrow was taken from such freelance sites as Upwork.com - it's very similar, except one thing:
There is no 20% commission, as on these sites!
It's block-chain, so the transfers are unrestricted and pretty cheap.
How cheap is the contract? How much gas does it use?
The creation of contract is 1.800.000 gas, which is 0.018 ETH ($13) @ 10Gwei gas price - it is paid by the Client.
StartWork() and StopWork() is dirty cheap - just around 40.000 gas - twice the ordinary transaction - or 0.0004 ETH ($0.30!) @ 10Gwei gas price - these are paid by the Worker.