The gig management flow is crucial for DistributedTown's fully functional communities and the correct Q2T distribution.
Only a member of an active community, who has their skills already validated can create gigs.
In the gig management flow, there are three main roles/types of users that will be called in the rest of this section as follows:
creator - the user who has created a gig. The creator of the gig has to be a member of an active community, who has their skills validated.
taker - the user who is taking the gig
requester - the user who has requested to take a gig
The taker/requester can only be a member of the same community, who may or may not have their skills validated.
Please keep in mind that the taker and the requester might be the same user.
After passing the validation process of creating a gig, the gig is considered open and visible for other users with the appropriate skills in the community. By clicking on theTake Gig button, the user becomes a requestor of the gig. The creator of this gig then receives a notification, that someone wants to take this gig. The creator can decide whether they accept or decline this request. The creator can accept this request by scanning a unique QR code that has encoded the skillWalletID of the requestor and the gigID. After the creator scans the QR code the gig is considered taken by the requestor (now taker) and the work on it can start. When the taker is done with the gig, they mark it as submitted. The creator then can review the work done and decides whether to accept it as completed or not. If the creator is satisfied with the work done, they can scan a unique QR-code and mark the gig as Completed. After successful gig completion, the creator will be prompted to rate the gig, therefore validate the taker's skills.
The gig management is implemented via a finite state machine. You can see the state transitions on the following diagram:
Since gigs are such an integral part of the Quadratic Distribution process, we need to make sure that the data management is in sync. For this reason, gigs are efficiently validated peer-to-peer and off-chain. Our system verifies them one-by-one through a decentralized oracle integration with Chainlink. When a new gig is created, DistributedTown generates a unique hash for it and sends this hash to the GigValidator smart contract. At this point, through our integration with Chainlink, the Smart Contract calls the backend for gig verification. Once the hash is validated the requestFulfiled event gets emitted, and this triggers the fulfil function. This sets the validation result. Since only a valid gig can be added to the Gig registry, the same hash validation is used for any other meaningful state change of a Gig. Namely, take gig, and complete gig. Each new validated gig releases DITO credits, and after hitting a threshold of 3840 DITOs per Treasury, this triggers a new Quadratic Distribution on Q2T.
After gig completion, it's time for the gig rating process. The creator of the gig should rate if the taker's skills were accurate according to the work done. The creator rates a gig on a scale from 1 to 10. After the user receives 5 rates per skill the platform automatically calculates and adjusts the skill level of the user. This adjustment flow calculates the skill level as follows:
Or simply put - the average of all the rates. After the skill level of the user gets adjusted, the credits of this user also get adjusted accordingly. The skill adjustment triggers a recalculation of the community scarcity score as well.
Once the user receives the first 5 rates, the user's skill wallet is considered validated and the user is now a fully-functional member of the community. Moving forward the user skills will get reevaluated only when a community member hits 3840 DITOs, this is also when the scarcity score of the community will get updated.
Every gig has a predefined credit amount. It is calculated by the following formula:
commitment is a number between 1 and 10, and skillValue is 6, 12, 24, depending on the skill selected.
Once the gig is completed, the payment gets released to the gig taker, after validation of the hash of the gig.
Gigs might be combined in a project. Every community can have multiple projects which group a lot of gigs. The project is considered completed, once all of the gigs inside the projects are completed. From Q2T an investor or a community member can fund a specific project inside a community. The more gigs are getting closed the more funds are getting released from Q2T.