The community WPS system for EOS could be structured as a new DAC launched using the EOSDAC DacFactory. The custodians could be appointed as community technical experts or some other criteria. No code change is needed for this since any new DAC is simply managed based on token weights of a newly created token. (eg. an arbitrary number of tokens could be minted and given to and arbitrary number of "experts" into the community who would then become the voted in custodians to manage the WPS.) EOSDAC is based around token holders of the EOSDAC token which would most likely not be be suitable to manage the WPS. Vigor is also using our system with the VIG token as well as a few other DACs on EOS and WAX. (details to allocate custodians to control this should be discussed separately - but suffice to say it is flexible).
Once there are custodians appointed for the WPS DAC they would administer the funds for the WPS (wherever they are sourced from - details to be discussed separately) all details of this WPS would be managed through the smart contracts we have already built so no single custodian could run off with the funds. This also has nothing to do with BPs other than just running the underlying blockchain.
A worker would create a proposal with details recorded as on-chain transactions. The required details include text descriptions the proposal, amount for payment and an optional, trusted arbitrator. The custodians would then vote to approve starting a worker proposal and again to approve the payment at completion of a worker proposal. Funds for the proposal are locked in an escrow account to protect the worker and if there was a disagreement between the worker and the custodians the pre-agreed arbitrator could step in to override the custodians and approve/deny payment for the worker proposal.
##Detailed workflow (TLDR):
- A potential worker creates a proposal and submits it through an EOS action with the following details:
- Proposal Title
- Summary description of the proposal
- Content hash to ensure details from another attached document for the proposal are immutable
- Proposed pay amount - could be any eosio.token compatible token.
- Category - a number to represent different categories of proposals (eg. marketing, wallets, infrastructure, defi, gmaing etc.)
- Expected time duration for the job to be completed
- Arbitrator - EOS account for a trusted arbitrator but this could be skipped or set to 0 to opt out of this part of the process.
- Arbitrator pay amount
- The current custodians of the WPS DAC would vote on the proposals with either a Approve or Deny vote until a deadline for proposal approval has passed. Another option is for custodians to delegate their vote for a proposal or a category of proposals to another custodian of their choice. (This allows the custodians to have different areas of specialty within the group and allow specialties to delegated explicitly on chain by other custodians without their vote power being wasted.)
- If within the proposal approval time window a voting threshold has been met then the worker can "start work" on the proposal. This is another EOS contract action which only succeeds with enough Approve votes before the expiry deadline has passed. At this point the proposal payment funds plus payment for the nominated arbitrator are transferred and locked into an escrow account. This is then out of reach of the custodians to be able to take the tokens or over spend elsewhere. This secures the future payment for the worker.
- Once the worker has completed their work they would call another EOS contract action to "complete work". This would have the effect of moving the proposal into a state where the custodians would vote again but this time vote if the proposal has been completed and has met the specs as agreed in the initial proposal. (At present this is purely subjective but the contract could be extended to include objective measures if they were included in the initial proposal.)
- If the custodians have agreed through their votes that the completed work satisfies the proposal based another voting threshold the worker can call the "finalize" action which will transfer the proposal funds to the worker from the escrow account and optionally to the arbitrator for agreeing to be on standby for a dispute.
- If the custodians do not agree to approve the work at the completion of the proposal the worker can choose to "dispute" the decision. At this point the proposal and the associated escrow record are put into a dispute state and locked for a longer. This is only useful if there was an arbitrator set as part of the proposal. Then the mutually trusted arbitrator would be able to step in, assess the situation and would then have the ability to rule in favour of the worker or the custodians and approve the transfer of proposal tokens to the worker or back to the WPS pool account.
- If there was not dispute and the custodians did not agree the locked funds in the escrow account could be refunded back to the WPS funds pool after an expiry period (set to double the expected job duration from the initial proposal).
###Config Options
The above parameters that have been italicised represent variables that can easily set to custom values as agreed jointly by the WPS DAC custodians. These configurable variables include:
- proposal_threshold - the number of custodian votes required to agree to approve a proposal. This includes the votes that custodians have delegated to other custodians through a proposal delegation or a category delegation. Each custodian has an equal vote per proposal which may be delegated to another custodian to increase their vote weight.
- finalize_threshold - As above but for the completion of a proposal. This should be set to a lower number or equal to the propose_theshold since if someone has agreed to start a worker proposal they should agree to complete it if the work was done to the proposal spec.
- approval_duration - The time that a proposal has for approval before it is expired.
While we have these contracts deployed and connected with EOSDAC and the EOSDAC UI The worker proposal functionality has not been extensively battle tested and the arbitrator aspect of the contract still needs some work to integrate in with the UI. The code contracts from above (including automated tests) are all open source and available for further interrogation on Github