Abstract

This whitepaper abstractly describes a system designed to tokenise labour-hours using blockchain technology.
ChronoBank is a proposed implementation of the described system that can be deployed in several economic localities.
The proposed system leverages smart contract techniques to automate a process whereby a country-specific ‘labour-hour’ token may be redeemed for real labour-hours via legally binding (traditional) contracts with labour-offering companies.
The proposed ‘stable-coin’ implementation provides a non-volatile, inflation-resistant digital asset transfer system.

1. Introduction

With the advent of cryptocurrencies, relatively instant low-cost transfers of value have become a reality.
Blockchain technology, which is a defining feature of most cryptocurrencies, has recently been applied to solve a great variety of problems.
Currently the most widespread implementation of blockchain technology is Bitcoin [ 1 ], which is a simple asset transfer system.
The asset in Bitcoin’s case is a bitcoin (BTC).
The value of this token has seen rapid variation since its inception in 2009, which has hindered its feasibility as a global currency.

There have been a variety of attempts to realise the advantages of blockchain technology while simultaneously mitigating issues regarding the stability of value for cryptocurrency applications.
To achieve this, many attempts employ the notion of a stable-coin, whereby each token of value in the system has a counterpart of equal worth stored in a non-digital and tangible form in the ‘real world’.

Two example implementations of the aforementioned stable-coin paradigm are listed below:

USDT by Tether[ 2 ]:
Each USDT token is backed by an equivalent amount of United States Dollars (USD) held in a reserve account by the private company Tether Limited.

Digix[ 3 ]:
Each token is backed by an equivalent amount of gold, which is stored in reserves by a dedicated precious metal storage custodian.

In both examples, it is always possible for a token holder to redeem that token for its counterpart, thus ensuring its fundamental ‘stable’ value.

Another notable example of a stable-coin is Bitshares [ 4 ], which attempts to decentralise the entire system through the use of digital Contract For Differences (CFD) [ 5 ] interactions.
The system presented in this whitepaper does not attempt to achieve decentralisation, but instead attempts to address some of the drawbacks surrounding existing centralised stable-coins.
These drawbacks include difficulties regarding the storage of physical or economic wealth, and the increasing likelihood of attacks, as a single entity centralises the entire wealth of the system.
Typical stablecoins are also subject to fluctuations in the value of their underlying asset.
While these fluctuations are usually very small when compared with fluctuations in traditional cryptocurrencies, they are still significant.
For example, USDT is subject to the devaluation of USD due to inflation.

In this paper, we propose a stable cryptocurrency system which addresses the aforementioned drawbacks of existing stable currency solutions.
Specifically, we propose a new type of token which is not backed by any existing fiat currency or physical store of wealth, but instead is backed by legally binding contractual obligations to provide real-world labour-hours.
As such, the system and its controlling entity are not responsible for the centralised storage and management of wealth.
Further, the value of an unskilled labour-hour in a particular geographic region naturally adjusts according to economic conditions such as inflation, thereby maintaining the long-term intrinsic value of the cryptocurrency.

This paper is organised as follows:
In Section 2 we provide an overview of the system as a whole before discussing the technical details of the necessary system components and processes.
Section 3 provides economic considerations in brief, regarding the real-world deployment of this system and its feasibility.
Finally, Section 4 discusses future directions and applications of the system and of ChronoBank.
The appendix of this document provides supporting reference of several concepts introduced throughout the paper.
In particular Appendix B and C list the variables that encapsulate the functionality of the system.
These variables are also summarised in Table 1.

2. The ChronoBank System

Similar to existing stable-coins (such as USDT by Tether and Digix), we propose a centralised entity that coordinates the creation, redemption, and destruction of Labour-Hour Tokens (LHT).
We refer to this entity as the ChronoBank Entity (CBE).
It is responsible for the acquisition and coordination of legally binding contracts for labour, in addition to the creation and dissemination of LHT.
Ultimately the role of the CBE is to ensure the stability of the LHT system through careful management of the system’s underlying processes.
This section will provide details describing the proposed processes, practices, and operations undertaken by the CBE and its associates.
An overview of the functionality of the ChronoBank system’s
constituents is shown in Figure 1.

Figure 1.
An overview of the ChronoBank system.
This diagram shows the system’s constituents and their interactions.
CBE refers to the ChronoBank Entity, LOC to Labour-Offering Companies, LHT to Labour-Hour Tokens and TIME to the token purchased during the crowdsale.

The system as a whole is designed with the intent of a single deployment per economic region.
For instance, the system could be deployed once in Australia using the value of one labour-hour in the Australian economy, measured in Australian dollars.
As this document is an abstract description of the system, it does not refer to any region-specific implementation but instead refers to generalised system parameters that must be tailored for each region.
With few exceptions, all processes and structures described in this document may have slight variations in implementation between regions in which ChronoBank operates.

The initial implementation of the CBE will utilise the Ethereum[ 6 ] blockchain; however, future implementations may tokenise assets on alternative blockchain systems (e.g. Waves [ 7 ], Bitcoin [ 1 ]) when it is deemed appropriate.

The CBE provides economic benefit both to the environment in which it is deployed, and to a group of stakeholders that assist the CBE by providing initial operating capital.
Unlike the region-specific deployment of the CBE system, only one group of CBE stakeholders (a.k.a. TIME token holders) exists globally.
These stakeholders provide initial operating capital to the CBE in the form of both fiat and cryptocurrencies, in exchange for a portion of future profits attained by the CBE.

2.1. Stakeholders & TIME Tokens

In order to fund the development and operation of the ChronoBank system, there will be a fundraising phase known as the crowdsale.
During the crowdsale, individuals may purchase TIME tokens at a fixed rate, which provides the token holder with the right to receive a proportion of the profits arising from the operation of the system.
In addition to the entitlements regarding the system’s operating profit, holders of TIME tokens will also be granted the right to vote on important decisions regarding the ChronoBank system.

TIME tokens will be developed utilising the Ethereum ecosystem, specifically leveraging the ERC20 token standard[ 8 ].
The ERC20 specification will be extended to provide voting functionality and rewards distribution; this is discussed further in Sections 2.1.3 and 2.1.2 below.

2.1.1. Crowdsale

During the crowdsale, TIME tokens will be created as necessary and sold at the fixed price of 100 TIME tokens for 1 bitcoin (BTC).
There is no limit to the number of TIME tokens generated during the crowdsale; however, no further TIME tokens will be generated after this phase of the project.

ρ	Total percentage of minted LHT taken by the CBE
fc	Fee taken during minting by the CBE
fr	Fee taken during redemption by the CBE
fi	Issuance fee taken during minting
S	Percentage of minted LHT put into the SGF
LT	Percentage of minted LHT put into the Liquidity Reserve
L0	Percentage of minted LHT used for LOC insurance
M	Number of months until L0 is transferred into the SGF
l	Percentage of LT used for LOC insurance
P	Interval between TIME token reward payouts

Table 1. List of abstract variables and constants used throughout this paper for reader’s reference. See the Appendix for further details.

All TIME tokens purchased during the crowdsale will constitute 88% of the total TIME tokens generated during the initialisation of the ChronoBank system.
The remaining 12% of tokens will be split with 10% given to the ChronoBank.io team (for ongoing research and development) and 2% to advisors and early adopters of the system.

Figure 2.
Issuance fees (fi) and transaction fees (ft) are deposited into the rewards contract.
TIME holders can withdraw a portion of the LHT after each snapshot, if their TIME tokens were deposited into the contract.

2.1.2. TIME Token Rewards

For the use of the LHT, users will be charged a fixed fee, ft = 0.15% on all transactions.
Complementary to transaction fees, issuance fees (fi) will be taken during the minting process (further details in Section 2.2.1).
The issuance fees will start at 3% during the first year of operation and will stepwise decrease by 1% each year until a final issuance fee of 1% is achieved and maintained.

Both the transaction and issuance fees will be automatically collected and sent to a rewards contract on the Ethereum blockchain as shown in Figure 2.
The rewards contract is designed such that TIME token holders can withdraw their earned rewards in a manner that makes them non-unique (i.e. withdrawal of rewards is not tracked on a per-token basis) and hence tradeable on exchanges for equal value.

The rewards contract will allow TIME token holders to retrieve their rewards at regular payout intervals, P.
At any given stage, TIME holders may deposit their tokens into the rewards contract.
At the onset of a payout interval, a snapshot of deposited TIME tokens and the current contract reward balance will be taken.( 1 )
The rewards will be divided equally among the TIME tokens that were deposited at the time of the snapshot.
Depositors may then withdraw their share of rewards during the following payout interval.
At the next payout snapshot, any unclaimed rewards will be forfeited and added to the total balance of that snapshot.
Figure 3 illustrates this concept by plotting the rewards contract balance over time.
We also note that we expect P to be of the order of a few months.

TIME holders may deposit and withdraw their TIME tokens at any stage, however only TIME holders who have deposited before the snapshot of each payout interval can claim rewards.
Withdrawing TIME tokens from the contract will also withdraw any rewards currently owed to the depositor.
TIME holders may also leave their tokens deposited in the rewards contract indefinitely and claim their rewards periodically.

Figure 3.
The rewards contract receives Pr rewards for every payout interval P (in our example, we assume that Pr is constant).
At each snapshot, the portion of rewards that are not withdrawn is d.
Rewards that are not withdrawn roll over to the following payout interval P.
The dashed line indicates the withdrawable balance, which reduce over each payout interval as TIME holders withdraw their rewards.

This reward payout system gives upper bounds to the amount of rewards that can be stored in the contract in any interval, under some reasonable assumptions.
The total rewards obtained via fees for a particular payout interval, P, is Pr.
If we assume a constant amount of transaction and issuance fees per payout interval (i.e. a constant Pr), and an average percentage of locked TIME holders that do not withdraw in any payout interval, d, we can calculate the upper bound of the LHT stored in the smart contract through the limiting geometric series relation( 2 ):

To clarify this, let us take a conservative estimate, that 90% of all locked TIME token holders do not withdraw their rewards in every payout interval (only 10% actually withdraw).
In this scenario, no more than 10Pr worth of rewards will be stored in the rewards contract at any given time.
A less conservative estimate, being 50% of locked TIME holders withdrawing each payout interval, will ensure the rewards contract never contains more than 2Pr worth of rewards.
Through the careful (and potentially dynamic) choice of P we can find a balance between practicality (frequency of reward withdrawal) and security (safe level of stored value in a smart contract).

2.1.3. TIME Voting

From time to time, the CBE may hold polls on the Ethereum blockchain to elicit the opinion of TIME token holders.
Poll results will be incorporated into decisions made by the CBE concerning the financial or technical direction and/or implementation of the CBE system.
Only valid TIME holders are considered current stakeholders in the CBE system and are the only parties authorised to participate in a poll.

3. Economic Considerations

In this section we briefly mention some interesting properties and immediate economic consequences of this system.

4. Future Work

Economic Models.
Key to the success of the ChronoBank system is an informed choice of the aforementioned economic parameters.
It is essential to perform further analysis so as to determine how parameter modification impacts the feasibility and sustainability of the system in a wider context.
This will necessarily be performed before a realworld implementation is constructed.

LaborX.
The digital asset transfer system described in this document is proposed as a first step towards a larger decentralised labour system.
LHT as described by this paper forms the base currency for a decentralised labour exchange platform entitled LaborX.
The intention of LaborX is to enable peer-to-peer exchange of labour-hours with LHT, thereby reducing the centralisation of the proposed ChronoBank system.
LaborX will incorporate a rating system whereby holders of LHT can identify fair trades by examining the quality and/or specialisation of the labour provider, given their history on the platform.
By enabling direct exchange of LHT with labour-hours, the system’s dependency on contractual arrangements with LOCs is significantly reduced.
This potentially reduces the cost and increases the stability of the system as a whole.

5. Conclusion

This paper proposes a non-volatile, inflationaryresistant, digital asset transfer system.
This innovative system is only made possible by recent advancements in blockchain and cryptographic technologies.
Leveraging these technologies, this system tokenises contractual debt in a manner that can be both economically feasible and highly practical for digital platforms, such as LaborX.
The intrinsic value of the proposed token mirrors the average hourly rate of human labour - the most fundamental unit of economic value.

References

[1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.

[2] Tether.to. Tether: Fiat currencies on the bitcoin blockchain. 2014.

[3] Anthony C. Eufemio Kai C. Chng Shaun Djie. Digix’s whitepaper: The gold standard in crypto-assets. 2016.

[4] Fabian Schuh Daniel Larimer. Bitshares 2.0: Financial smart contract platform. 2015.

[5] Investopedia. Contract for difference.

[6] Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper, 2014.

[7] Sasha Ivanov. Waves whitepaper. 2016.

[8] Ethereum Request for Comments (ERC) 20.

[9] The ChronoBank Team. ChronoBank: Business Outline.

[10] IPFS: A peer-to-peer hypermedia protocol to make the web faster, safer, and more open.

[11] Viktor Tron Aron Fisher Daniel A. Nagy.

Appendix A. Terminology

The following is a list of terms used throughout this document.
• CBE - The ChronoBank Entity.
• LHT - Labour-Hour Token.
• LOC - Labour-Offering Company.
• SGF - Security Guarantee Fund.

Appendix B. Minting Contract Parameters

There are number of parameters that are required to be negotiated during the minting process.
For clarity we list here the variables that should be considered and determined by the CBE during the minting process:
• S - A percentage of the minted tokens to be stored in the Security Guarantee Fund.
• LT - The total percentage to be stored in the liquidity fund.
• l - The percentage of LT dictating how much of the liquidity fund is used as LOC insurance, LI . The remaining funds will be kept for liquidity in L0.
• M - The total number of months until the LOC Insurance LI is transferred to the Security Guarantee Fund. This dictates the rate at which the funds are transferred, i.e. LI /M per month.
• Expiry Date - The expiry date of the contract, whereby the LOC must buy back the value of the minted LHT.

Through the definition of the above variables, the CBE on a case-by-case basis will fix ρ, the total percentage deducted from LOCs initially through the relation (2).

Appendix C. Fee Summary

The fees of the ChronoBank system can be summarised in the following:
• fc - This is the fee taken by the CBE during the minting process for services rendered. We expect fc ;sblisin; [0, 0.01].
• fi - This is the issuance fee, which will be taken during minting and deposited into the TIME token holder’s rewards contract. This will start at 3 percent and decrease by 1 percent each year until it is maintained at a steady 1 percent.
• ft - These are transaction fees, which are deposited into the TIME token holders rewards contract. This is a flat fee of 0.15%.
• fr - This is a fee taken by the CBE during the redemption process for services provided and to add a deterrent to continual redemption requests. We expect fr ;sblisin; [0, 0.01].

Abstract

In Phase 1, Chronobank introduced labour-hour tokens which represent the average value of one labour hour.
This phase involves the design and construction of a decentralised platform capable of making labour exchange as easy as riding a taxi with Uber.
This white paper describes a decentralised marketplace where people of real-world professions will be able to sell their labour to any participating client of the system.
LaborX is a proposed implementation of the described system.

This is a draft version of the white paper prepared for community review.
A Bounty of 1000 TIME tokens (an equivalent of 10 BTC) will be divided between the best contributors.
To participate, join our #whitepaper Slack channel.
To a get Slack invite, visit https://chronobank.herokuapp.com

1. Introduction

In 2009 (the same year that Bitcoin emerged), Uber, a mobile application which revolutionised the taxi business, was developed.
The easy to use, fast and comfortable service made Uber a worldwide company with $1.5 billion in revenue.
Uber removes the middleman – in its case, the taxi dispatcher - from the buyer/seller equation, allowing each driver to be his boss and work independently of a central company[ 1 ].

Similarly, LaborX aims to revolutionise the labour hiring industry by providing an open and decentralised ecosystem.
It has the potential to benefit both highly skilled workers, who prefer independence or a more flexible work schedule, as well as low-skilled labourers who will be able to find flexible part-time work when it is convenient for them.
LaborX targets offline workers providing real-life services which cannot be done remotely or supervised by special software.

The Problem.
Currently, numerous agencies are providing centralised services which offer to hire workers listed in their internal databases.
The reputation of such a system is fundamentally linked to the centralised agency which verifies and endorses the workers within the system.
Further, such systems often fail to disclose employee’s experience, reputation, or past jobs.
The situation is complicated even more by inflated agency fees and a plethora of agencies to choose from for any particular job.

Proposed Solution.
The LaborX Platform is a decentralised system that not only provides a labour hire marketplace but also is capable of automating (at least in part) the process of hiring individual workers given specific contract work.
This includes the selection and vetting of workers based on the main attributes, such as availability, location, a field of work, skills, and reputation.
This system leverages blockchain technology, specifically Ethereum, for its core systems and can therefore significantly lower operational and maintenance costs relative to competitors in the labour-hire industry.
Moreover, the public nature of Ethereum will allow participants to view all worker’s previous experience and recommendations.
The system will also utilise the commercial side of blockchain enabling immediate payments for completed work.
In addition, decentralisation allows the system to be global, autonomous, and versatile in the sense that workers and clients can accept a variety of location-independent currencies, in the form of any ERC20[ 2 ] compatible tokens (such as Labour Hour tokens[ 3 ]).

Contributions.
This paper provides a high-level overview of a blockchain-based decentralised labour hiring system and its conceptual realisation in real world applications.
Section 3 provides an overview of the base system components and processes including minor technical details.
Section 4 provides economic considerations in brief, regarding the real-world deployment of this system and its feasibility.
Section 5 describes the rating system that allows the community to have control over LaborX.
Section 6 is focused on interface features.
Section 7 details how privacy issues are handled.

2. Design goals

We aim to make short-term employment as accessible and rewarding as long-term employment, giving workers the flexibility to determine their schedules while being paid a fair rate for their time, expertise, and reputation.
We plan to achieve this through the LaborX platform, which will enable trading of labour time at market rates.
A decentralised reputation system will facilitate feedback for each entity, allowing employers to hire the most competent professionals.
It will also enable individual workers to secure payment in line with their training, skills, and experience.

LaborX system is designed specifically to target workers in the labour industry (areas such as cleaning, plumbing, gardening, etc.).
The system is intended to be distributed and have no central controlling authority.
This means that it wouldn’t be controlled by any single individual or company, but by a set of publicly verifiable predefined rules.
Anyone can fork, modify and redeploy the system, like it can be done with the Ethereum network itself[ 4 ].

The system has to satisfy the following usage requirements:
(1) The client should be offered a selection from the most competent workers based on their search preferences.
(2) Workers that have higher ratings should have higher compensations.
(3) A worker can set their own rate.
(4) Both the client and the worker should have a rating.
(5) Both the client and the worker can reject a given sealed job contract (see more at Section 3.2).
(6) The worker always receives money for the time they spent on labour.
(7) The client should be able to stop work at any time.
(8) The system should vet clients and workers that have bad ratings.
(9) The client could pay with any ERC20 cryptocurrency, should the worker accept these tokens.

3. System overview

The decentralised nature of this system allows clients to hire workers using the Ethereum blockchain.
Thus the core features of the system will run as a set of smart contracts[ 5 ], making the system available for use independently of any particular user interface realisation.
These contracts will govern the behaviour of the system, dictate the agreements between parties, and serve as a public ledger containing profiles of clients and workers.

Figure 1. Sequence diagram

4. Economic model

LaborX is a multi-currency service that will support any token that complies with the ERC20 standard[ 2 ] including, but not limited to, Labor Hour tokens.
A simple multi-currency wallet capable of receiving and sending any supported ERC20 token will be integrated into the LaborX platform.
Users will be able to pay and get paid by tokens they choose from a list of supported on job boards tokens.
Providers may list local currencies, allowing communities to pay for jobs in unusual digital assets, should both the client and the worker accept the currency by selecting the job board.

As mentioned in the previous section, the LaborX system will deduct 1%( 3 ) from each completed job part of which will go as a revenue to TIME token holders and other part to providers for their services.
Provider receives payment only for completed jobs posted on provider’s job board.

5. Rating and activity points system

For every worker and client there are two metrics called rating and activity points.
The first describes how well a client or worker performs their duties and is dictated by their partners.
The second is a point system based on all LaborX activity.

The better the individuals rating (based on previous work), the higher the price they are be able to demand for an hour of work.
After a job is completed, both the client and worker are asked to rate to each other.
The rating is in the range between 1 and 10, where 1 corresponds to a total disaster and 10 represents exceptional work.

The rating system will be time and quantity aware.
By this, we mean that older ratings should contribute less to the current rating than recent ratings (i.e., the ratings are recency-weighted).
This means, for example, a bad rating accrued a year ago by a worker, can be redeemed by a series of recent good ratings, thus restoring the reputation of the worker.

Activity points are used only in the LaborX DApp and have a crucial security role by limiting the amount of available functionality to newcomers.
This limits threats such as spamming, posting advertisements with ambiguous links, or evildoers trying to overload the system with an infinite job posting.

Every new user begins with a single activity point which will automatically increase when performing various actions inside the app (see
An alternative way to gain activity points is by verifying one’s identity with various verificators or by passing skill assessment with an evaluators.
The activity points count will always be greater than or equal to 1.

An example of activity point elevators are given in
Some of the proposed features that will require some amount of activity points is given in
The listed values in these tables are examples only and may change during the implementation and system testing period.

Figure 3. Contract interaction diagram

Table 2. Actions that affect activity points.

Table 3. Actions that require activity points.

6. LaborX DApp features

7. Privacy

It is truly unsafe to publish sensitive, private data in a blockchain.
However, we have to eliminate the possibility of a worker re-registering to reset their profile.
Therefore, we have to maintain a balance between anonymity and notoriety.
To achieve this, each worker will have a publicly available blockchain profile containing their nickname (first name and the first letter of their surname), small photo, field(s) of work, skills, rating, rate, activity points, approximate location, a list of completed jobs and payments.
Optionally, a worker may apply for a document verification or a skill evaluation (see Sections 3, 6) which will be reflected in his public profile and confirmed by the electronic signature of the governing party.
There will be a data set which will never appear on the blockchain.
This includes, but is not limited to, the exact geolocation of the client and the worker, additional private instructions for the worker, document scans.

Hashes[ 6 ] of private data blocks will be published on the blockchain to prove that they have not been altered.
These hashes should also be electronically signed by submitter of the stored information and linked to the worker’s public profile.
In this way, only the signature and hash of the sensitive information will be publicly available, and any confidential data may be stored without revealing it to the public.
An entity which gains authorised access to the information will also be able to check the signature to prove the origin of information.

Figure 4. Verification of documents

8. Conclusions

This white paper proposes a decentralised system designed to revolutionise the labour-hire industry.
It will be capable of automatically matching available workers to corresponding jobs according to their location, field of work, skills, and reputation.
Using the Ethereum blockchain as a basis, this system can significantly lower fees for system maintenance, relative to traditional systems offering a similar service.
Moreover, decentralisation makes the system autonomous and global as it runs on Ethereum and is capable of using any currently existing ERC20[ 2 ] tokens.
This innovative system is only made possible by recent advancements in blockchain and cryptographic technologies.
Leveraging these technologies this system allows people to trade human labour - the most fundamental unit of economic value.

References

[1] The Huffington Post. ’uberization’ of everything is happening, but not every ’uber’ will succeed. http://www.huffingtonpost.ca/2015/04/01/uberization-uber-of-everything_n_6971752.html, 2015.

[2] Ethereum Foundation. Erc20: Ethereum token standard. https://github.com/ethereum/EIPs/issues/20, 2015.

[3] The ChronoBank Team. Chronobank - phase 1: A non-volatile digital token backed by labour-hours. https://chronobank.io/files/whitepaper.pdf, 2016.

[4] Ethereum Classic. Website. https://ethereumclassic.github.io/, 2016.

[5] D. Tapscott and A. Tapscott. Blockchain Revolution: The Brilliant Technology Changing Money, Business and the World. Penguin Books Canada, 2016.

[6] Wikipedia. Cryptographic hash function. https://simple.wikipedia.org/wiki/Cryptographic_hash_function.

[7] Ethereum Foundation. Whisper wiki article. https://github.com/ethereum/wiki/wiki/Whisper, 2016.

Glossary

activity points:
is an integer in a range of 1 to infinity which measures positive contribution to LaborX ecosystem.
The more activity points the user has, the more advanced actions they can perform.
See the full list in

client:
is a person that has some work and needs to get it done.
Client posts a job and pays for it. 2

DApp:
is an abbreviated form for decentralised application.
A DApp has its back-end code running on a decentralised peer-to-peer network.
Contrast this with an app where the back-end code is running on centralised servers. 3–7

evaluator:
a highly rated worker with lots of experience and reputation which prove they are a master in their field of work and thus can verify skills of other workers. 2, 5

job:
is some work or task to get done.
Job can be a list of tasks but all within one field of work. 2

job board:
is a publicly available database managed by the creator.
It will be implemented as a smart contract in Ethereum network.
More information in Section 6. 3, 5, 6

LaborX core:
this is a sub-system of the LaborX platform encapsulating the majority of the core inner functionality and blockchain-dependent logic. 2, 3, 6

ledger:
is a publicly available database that holds information.
It will be implemented as a smart contract in Ethereum network. 2

provider:
is an entity which offers its services to connect clients and workers through a job board because of legal, security, or spam issues.
Anyone can become a provider, and both parties (a client and a worker) could choose which providers they trust.
Providers get paid for their services by receiving a percentage of job payment fees. 2, 3, 5–7

rate:
amount of money that will be paid hourly to a worker. 1, 2, 6, 7

rating:
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures
the quality of work done by a worker.
LaborX uses rating to select workers for a job. 2–6

verificator:
a worker with flawless reputation who offers services of verification for documents and
identity of other entities. 2, 5

worker:
is a person that is assigned to fulfil client’s job and get paid for it. 2

Appendix A. LaborX Wireframes

Figure 5. Client’s jobs screen10

Figure 6. Worker’s profile editing

program'Developing

description::
Two Week Software Cycle
We are pleased to announce that we will be switching from a feature-based versioning and release model to a continuous release model with a two-week, two-phase software cycle.
The first phase is a one week merge period. In this week any stable Pull Requests will be accepted into the development branch. The second phase is a one week test/regression and release period. During this stage we will branch a new release/version, then test, patch or undo any PRs that are unstable.
This will allow a process of continual deployment and incremental improvement for LaborX, while also allowing features to develop and mature before being included into the release version. The approach also allows us to ‘roll back’ or regress certain changes, should they become problematic. Hopefully this will enable us to release a new version of LaborX consistently every two weeks .
[https://blog.chronobank.io/chronobank-dev-update-7-49b387396b2c#.odbp6hdr9 {2017-03-26}]

program.Smart-Contract (chbctp)

description::
ChronoMint, Labour Hours and Time contracts.
ChronoBankPlatform.sol acts as a base for all tokens operation (like issuing, balance storage, transfer).
ChronoBankAsset.sol adds interface layout (described in ChronoBankAssetInterface.sol)
ChronoBankAssetWithFee.sol extends ChronoBankAsset.sol with operations fees logic.
ChronoBankAssetProxy.sol acts as a transaction proxy, provide an ERC20 interface (described in ERC20Interface.sol) and allows additional logic insertions and wallet access recovery in case of key loss.
EventsHistory.sol holds all operations events to avoid events lost in case of contract replacement during upgrade or extension.
ChronoBankPlatformEmitter.sol provides platform events definition.
[https://github.com/ChronoBank/SmartContracts]

name::
* McsEngl.Chrono.tech'solidity-contract,
* McsEngl.Chrono.tech'smart-contract,

addressWpg::
* https://github.com/ChronoBank/SmartContracts,

specific::
* ChronoBankAsset.sol,
* ChronoBankAssetInterface.sol,
* ChronoBankAssetProxy.sol,
* ChronoBankAssetProxyInterface.sol,
* ChronoBankAssetWithFee.sol,
* ChronoBankAssetWithFeeProxy.sol,
* ChronoBankPlatform.sol,
* ChronoBankPlatformEmitter.sol,
* ChronoBankPlatformInterface.sol,
* ChronoMint.sol,
* Configurable.sol,
* ContractsManager.sol,
* ERC20Interface.sol,
* EternalStorage.sol,
* EventsHistory.sol,
* Exchange.sol,
* ExchangeInterface.sol,
* LHT.sol,
* LOC.sol,
* Managed.sol,
* Migrations.sol,
* Owned.sol,
* Rewards.sol,
* Rooted.sol,
* Shareable.sol,
* TIME.sol,
* Vote.sol,

pragma solidity ^0.4.8;

import "./ChronoBankAsset.sol";

/**
 * @title ChronoBank TIME tokens contract.
 *
 * The official ChronoBank TIME implementation.
 */
contract TIME is ChronoBankAsset {

}
    

pragma solidity ^0.4.8;

import "./ChronoBankAssetWithFee.sol";

/**
 * @title ChronoBank LHT tokens contract.
 *
 * The official ChronoBank Labour-Hours implementation.
 */
contract LHT is ChronoBankAssetWithFee {

}
    

contract ChronoBankAssetInterface {
    function __transferWithReference(address _to, uint _value, string _reference, address _sender) returns(bool);
    function __transferFromWithReference(address _from, address _to, uint _value, string _reference, address _sender) returns(bool);
    function __approve(address _spender, uint _value, address _sender) returns(bool);
    function __process(bytes _data, address _sender) payable {
        throw;
    }
}
    

contract ChronoBankAssetProxyInterface {
    function __transferWithReference(address _to, uint _value, string _reference, address _sender) returns(bool);
    function __transferFromWithReference(address _from, address _to, uint _value, string _reference, address _sender) returns(bool);
    function __approve(address _spender, uint _value, address _sender) returns(bool);
}
    

contract ChronoBankPlatformInterface {
    /**
     * Returns asset balance for a particular holder id.
     *
     * @param _holderId holder id.
     * @param _symbol asset symbol.
     *
     * @return holder balance.
     */
    function _balanceOf(uint _holderId, bytes32 _symbol) returns(uint);

    /**
     * Returns current address for a particular holder id.
     *
     * @param _holderId holder id.
     *
     * @return holder address.
     */
    function _address(uint _holderId) returns(address);

    function reissueAsset(bytes32 _symbol, uint _value) returns(bool);
}
    

contract ERC20Interface {
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed from, address indexed spender, uint256 value);

    function totalSupply() constant returns (uint256 supply);
    function balanceOf(address _owner) constant returns (uint256 balance);
    function transfer(address _to, uint256 _value) returns (bool success);
    function transferFrom(address _from, address _to, uint256 _value) returns (bool success);
    function approve(address _spender, uint256 _value) returns (bool success);
    function allowance(address _owner, address _spender) constant returns (uint256 remaining);
}
    

contract ExchangeInterface {
  function setPrices(uint _buyPrice, uint _sellPrice) returns(bool);
}
    

program.ChronoMint-dApp

description::
Control panel for ChronoBank and Labour-Offering Companies.
[https://github.com/ChronoBank/ChronoMint]

name::
* McsEngl.Chrono.tech'ChronoMint,
* McsEngl.ChronoMint,

program.ChronoWAVES-dApp

description::
Waves is a natural partner for ChronoBank due to its straightforward and user-friendly token-creation facilities. ‘We consider every blockchain with CATs (Custom Application Tokens) functionality as a potential infrastructure for LH tokens,’ comments ChronoBank’s lead developer. ‘We have recently started development of ChronoWAVES and have been in touch with Waves’ developers from the beginning, familiarising ourselves with all the technical details of the platform. ChronoWAVES will be an advanced lite wallet implemented in Javascript and fully compatible with the original Waves GUI.’
In addition to basic features such as blockchain data validation on the client side and multi-address accounts, the Waves version of the ChronoWallet will be tightly integrated with ChronoBank’s services, natively supporting LH tokens issued on the Waves blockchain. A key feature to be used by the wallet is Waves’ decentralised exchange (DEX), soon to be released on mainnet.
‘After release it will allow trades to be settled on the blockchain and we are going to utilise this fully for the exchange of Labour Hours. Additionally, a token-swap feature will offer potential integration of Ethereum tokens with the Waves blockchain. We definitely plan to share our contribution in the JavaScript infrastructure for Waves Platform with the community. We see it as an advanced JavaScript framework similar to the web3.js one that exists for the Ethereum project.’
[https://blog.chronobank.io/chronobank-partners-with-waves-to-create-chronowaves-wallet-c6e24be533a4?goal=0_c14d97ba45-da6d178ca4-32550077#.v6d9i1dc5]

EvuLH'Baker

description::
One of the major drawbacks in a debt-backed currency system is the possibility of backers (LOC in our case) defaulting on their contractual obligations.
[idChbwpr232]

EvuLH'Smart-contract (link)

EvuLH'Issuance

Q: Who are the issuing labour-hire companies?
A: Chronobank selects labour hire/recruitment and HR companies based on their credibility, size, and financial performance, among other factors.
Please refer to our company selection methodology in our business description document, available on our website.
Initial list of companies who agreed to issue LH tokens:
Anderson Recruitment and Training Pty Ltd
http://www.andersonrecruitment.com.au
canderson@andersonrecruitment.com.au
Host Group/Host Labour Hire
http://www.hostaustralia.com.au
john.allery@hostaustralia.com.au
AES Labour Hire Pty Ltd
http://www.aesau.com.au
jammiek@aesau.com.au
Edway Labour Hire
http://www.edwaylabourhire.com.au
stan@edway.com.au
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

EvuLH'Exchange-rate

Q: What will guarantee that LH value will stay stable relative to fiat, in the case of a massive short-sale attack by speculators?
A: To stop a possible short-sale attack by speculators, Labour Hour tokens will always be refundable at a small discount less the issuance fee. That will remove any motivation for any short-sale attack.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

EvuLH.AGGREGATE

Q: What are the total number of LH tokens?
A: The total number of coins will always depend on the number of companies in the system and labour hours available in those companies that companies are able to fulfill.
[https://blog.chronobank.io/chronobank-io-faq-4b920f003640#.sraeqe3iv]

EvuTIME'exchange-rate

{2017-05-17},
TIME/BTC
Bid: 0.010004
Ask: 0.0103
[https://www.livecoin.net/en/trade/orderbook]

{2017-04-22},
TIME/BTC
Bid:0.00770002
Ask:0.0078999
[https://www.livecoin.net/en/trade/orderbook]

{2017-03-08},
TIME/BTC    0.00561952 BTC    5.57%    12485.84    0.00639996 BTC    0.00451 BTC    0.00550049 BTC    0.00578 BTC
[https://www.livecoin.net/en/trade/orderbook]
===
TIME / BTC 0.006700004.1230.07
[https://mercatox.com/exchange]

EvuTIME'creator

Contract Creator:
address:    0x28a44f49b940b3875f882d08487d16295fb8bc09,
at txn:    0x5dd58b1b6e4ce36604c65ad7bdd98c78a55e4af547ed2934042b7c2bf1dad3e4,

EvuTIME'address

address::
TIME contract address: 0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53

EvuTIME'codeBinary

codeBinary::
0x6060604052361561014e5763fff...dd6a500029
[https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53#code]

EvuTIME'codeAssembly

codeAssembly::
PUSH1 0x60
PUSH1 0x40
MSTORE
...
BLOCKHASH
'a9'(Unknown Opcode)
'f9'(Unknown Opcode)
[https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53#code]

EvuTIME'ognExchange

description::
Livecoin is a well-established exchange that opened in 2015, at the bottom of the bitcoin bear market. Registered in London, the exchange has undertaken a series of measures to make it an attractive destination for traders, including lowering fees and offering VISA cards for rapid and easy withdrawal of funds. Currently, the majority of TIME’s volume occurs on Livecoin, as recorded by CoinMarketCap.
Liqui is a fairly new and relatively small exchange, but one that has a thriving community and a dedicated core of traders. Liqui is often fast to add new coins, proving agile where the larger exchanges take their time. At the present time, Liqui leads on price.
Mercatox is a professional trading platform for digital currencies. Although they focus on bitcoin, they have taken the decision to add TIME as well, judging it to have potential and appeal to their traders.
EtherDelta is a decentralised exchange built on Ethereum. More tech-savvy users will be able to trade peer-to-peer, without any risk of hacking or the failures that come with centralised exchanges.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]

specific::
* Bittrex,
* DABTC.com, (Chinese)
* Livecoin, https://www.livecoin.net/
* Lykke,

EvuTIME'similar

addressWpg::
* https://etherscan.io/address/0x1818c9f1e2b22e37c3652c1a8df060f946dc6231,
* https://etherscan.io/address/0x1c440ded36ce7d8526ffac48b3bf293c320369a6,
* https://etherscan.io/address/0xf39c5f30a8c1e2e00b0b9ab3dc061b1c36a998ae,

EvuTIME'resource

addressWpg::
* https://etherscan.io/token/TIME,
* https://etherscan.io/address/0x6531f133e6deebe7f2dce5a0441aa7ef330b4e53,
* https://blog.chronobank.io/how-to-add-time-to-myetherwallet-e9057388c76a#.onuflhr05,

EvuTIME.AGGREGATE

description::
After ChronoBank’s ICO ended in February, a total of 710,113 TIME tokens were created on the Ethereum blockchain and distributed to supporters.
[https://blog.chronobank.io/chronobanks-time-launches-on-four-exchanges-71c2bb5c989a#.wnktm5kng]

LaborX'canceling-job

description::
If the client is not satisfied with the worker or their work they can cancel the job at any time.
Nevertheless, the client is required to pay a minimum of one hour (which is a minimal time unit that can be paid).
The client may then leave a negative recommendation and rating that will negatively flag the worker for future clients.
[#idChblxw33P1]

name::
* McsEngl.Chtk-LaborX'canceling-job,

worker'compensation-per-hour (rate)

description::
rate: amount of money that will be paid hourly to a worker. 1, 2, 6, 7
[#idChblxwrate]
===
It should be noted that client does not pay the worker’s transportation time and expenses.
Instead, they should be included in the worker’s individual rates.
[#idChblxw33P1]

name::
* McsEngl.Chtk-LaborX'rate,
* McsEngl.Chtk-LaborX-worker'compensation,

worker'evaluation

description::
For workers.
Benefits for workers are also significant.
Due to lower fees than in traditional labour hiring companies workers may ask for higher hourly rates.
The most skilled and responsible workers with the best ratings will be highly sought after and may, therefore, demand a higher hourly fee than their not-so-amazing colleagues.
For the first time in the labour hire industry, diligent and attentive workers will be rewarded for providing better services.
The decentralised nature of LaborX will not only guarantee that workers will get paid, but will enable real-time payment to the worker as the work is completed.
Since the system is fully automated, the workers will be able to plan their schedules corresponding to their preferences.
[#idChblxw41P2]

name::
* McsEngl.Chtk-LaborX-worker'evaluation,

worker'profile

description::
To achieve this, each worker will have a publicly available blockchain profile containing their nickname (first name and the first letter of their surname), small photo, field(s) of work, skills, rating, rate, activity points, approximate location, a list of completed jobs and payments. Optionally, a worker may apply for a document verification or a skill evaluation (see Sections 3, 6) which will be reflected in his public profile and confirmed by the electronic signature of the governing party. There will be a data set which will never appear on the blockchain. This includes, but is not limited to, the exact geolocation of the client and the worker, additional private instructions for the worker, document scans.
[#idChblxw7P1]

name::
* McsEngl.Chtk-LaborX-worker'profile,

worker'rating

description::
rating: is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures the quality of work done by a worker.
LaborX uses rating to select workers for a job.. 2–6
[#idChblxwrating]
===
A negative rating will also adversely affect evaluator’s reputation.
[#idChblxw33P1]

name::
* McsEngl.Chtk-LaborX'rating-of-worker,
* McsEngl.Chtk-LaborX-worker'rating,

worker.EVALUATOR

description::
evaluator: a highly rated worker with lots of experience and reputation which prove they are a master in their field of work and thus can verify skills of other workers. 2, 5
[#idChblxwglrP2]

name::
* McsEngl.Chtk-LaborX'evaluator.worker,
* McsEngl.Chtk-LaborX-worker.evaluator,

description::
Evaluation by Clients. Any verified client may advertise individual worker’s skills after completing the job if some of them are exceptional. This information would be used to separately promote the workers who are constantly rated 10/10.
[#idChblxw61P4]

worker.VERIFICATOR

description::
verificator: a worker with flawless reputation who offers services of verification for documents and identity of other entities. 2, 5
[#idChblxwglrP5]
===
Verification. Entities with high reputation could serve as verification hubs and be paid for their services by workers. They will check that worker’s documents correspond to the worker’s identity, scan documents, publish document LaborX core in the blockchain and confirm this action by signing the hashes with their digital signature (see Section 7 for more information).
[#idChblxw61P2]

name::
* McsEngl.Chtk-LaborX'verificator-of-worker,
* McsEngl.Chtk-LaborX-worker.verificator,

employer'evaluation

description::
For clients.
There are numerous benefits for clients.
Because of smaller mediator fees than in traditional labour hiring companies, the resulting work price will be lower.
Decentralisation of the service makes it fast, reliable, secure, and permanently available.
A public worker rating system ensures that clients are seeing profiles of real workers along with their unique histories and therefore genuine ratings.
The ability to pay with a variety of digital tokens makes the system universal and not tied to any particular country/region.
Furthermore, LaborX will implement an easy to use interface, paying serious attention to UX.

name::
* McsEngl.Chtk-LaborX'evaluation-of-employer,
* McsEngl.Chtk-LaborX-employer'evaluation,

employer'searching-for-worker

description::
6.2. Workers selection
According to the current model, the governing smart contract returns a selection of workers that fit the criteria of a given job posted by a client. The LaborX DApp takes preference of workers who have more completed jobs and higher ratings. The system may grow such that the ratio of workers to jobs becomes quite large. It is therefore important that the LaborX DApp does some advanced filtering. This means that the application should not show all workers capable of performing a given job, instead select only several of the available best workers with varying rates and ratings. In this way, the most competent workers will get more work and will be paid more for their reputation. Clients may also use different custom filters that will help them to find the most fitting worker to suit their needs. They may also pick specific workers they are already familiar with. The application will also utilise smart filtering to minimise the worker intersection between clients. This is crucial for the system, especially when considering similar jobs.

name::
* McsEngl.Chtk-LaborX-employer'searching-for-worker,
* McsEngl.Chtk-LaborX'searching-for-worker,

employer'protection

description::
However, protections are also built in for the client in the case of poor performance on the part of the worker. Clients can cancel work at any time, though they will always have to pay for time so far worked. If it turns out that a worker has not spent the time well and has been bad value for money, the employer can end the contract and leave negative feedback for the worker. They will need to pay for a minimum of one hour of the worker’s time before doing this, to prevent malicious individuals from trying to ruin a worker’s reputation at no cost to themselves.
[https://blog.chronobank.io/laborx-getting-paid-on-time-every-time-364700e3709#.fa8sj2r0p]

name::
* McsEngl.Chtk-LaborX-employer'protection,

Compensation

description::
Provider receives payment only for completed jobs posted on provider’s job board.
[#idChblxw4P2]

LaborX'Job-board

description::
job-board: is a publicly available database managed by the creator.
It will be implemented as a smart contract in Ethereum network.
More information in Section 6. 3, 5, 6
[#idChblxwjobboard]
===
Each LaborX provider will be able to set cryptocurrencies that will be permitted for payments on their job boards.
Clients and workers who choose a job board, agree to use one of the supported methods of payment.
[#idChblxw63P1]

name::
* McsEngl.Chtk-LaborX'job-board,

LaborX-job'work-description

name::
* McsEngl.Chtk-LaborX-job'work-description,
* McsEngl.Chtk-LaborX-job'job-description,

LaborX-job'location

description::
A location is also a selectable parameter that will typically represent a city/region.
If a city/region is large, then a district/sub-region may be specified.
A city/region includes all of its districts/sub-regions.
A location is used to map workers to nearby clients.
Precise addresses (for job locations) will be revealed to workers once the job has been mutually agreed on and solidified by the smart contract.
[#idChblxw32P2]

name::
* McsEngl.Chtk-LaborX-job'location,

LaborX-job'provider-used

name::
* McsEngl.Chtk-LaborX-job'provider-used,

LaborX'Activity-points

description::
is an integer in a range of 1 to infinity which measures positive contribution to LaborX ecosystem.
The more activity points the user has, the more advanced actions they can perform.
[#idChblxwactivitypoint]

name::
* McsEngl.Chtk-LaborX'activity-points,
* McsEngl.Chrono.tech'activity-points,

description::
Activity points are used only in the LaborX DApp and have a crucial security role by limiting the amount of available functionality to newcomers.
This limits threats such as spamming, posting advertisements with ambiguous links, or evildoers trying to overload the system with an infinite job posting.
Every new user begins with a single activity point which will automatically increase when performing various actions inside the app (see
An alternative way to gain activity points is by verifying one’s identity with various verificators or by passing skill assessment with an evaluators.
The activity points count will always be greater
than or equal to 1.
An example of activity point elevators are given in
Some of the proposed features that will require some amount of activity points is given in
The listed values in these tables are examples only and may change during the implementation and system testing period.
[#idChblxw5]

LaborX'Rating

description::
is an integer in a range from 1 to 10 (where 1 is a disaster and 10 is perfect) which measures the quality of work done by a worker.
LaborX uses rating to select workers for a job.. 2–6
[https://github.com/ChronoBank/Documentation/blob/master/laborx_whitepaper.pdf]
===
A negative rating will also affect evaluator’s reputation.

name::
* McsEngl.Chtk-LaborX'rating,

LaborX'White-paper (link)

LaborX'messaging

description::
6.5. Messaging
LaborX will use a messaging system with an underlying protocol like Whisper[6], enabling client and worker to establish an encrypted connection. These messages could be used to exchange job details, address, confidential instructions, etc. The exact realisation will be decided at the time of development (specified in the LaborX road map) taking into account the potential research and new possibilities that will be available in 2017. [#idChblxw65]

name::
* McsEngl.Chtk-LaborX'messaging,

LaborX'searching

description::
6.4. Search
High load testing and analysis would be performed while developing LaborX to determine exact implementation and architecture of the search system.
The main part of a search logic should be performed in the LaborX LaborX core.
Only Ethereum transactions that write to blockchain have gas limit and cost Ether.
The search operation is read-only, therefore it would perform computations on user’s Ethereum node and will not require paying Ether.
A worker-to-job matching will include complex queries and therefore require a significant amount of computational power of the machine where Ethereum node software is running.
Therefore LaborX DApp could handle part of the filtering and caching logic on client’s side.
This approach will significantly improve the user experience.
[#idChblxw64]

name::
* McsEngl.Chtk-LaborX'searching,