Reward Fund Transfer
In this tutorial, we we'll learn how to transfer funds.
This step continues to use the decentralized task app that was described in the previous
sqlbranch of the tutorial. We're going to use a specific business workflow for this branch of the tutorial as follows:
- After owner creates a task, another person called "absent-minded" will try to work on this task. "Absent-minded" takes this task and clicks "complete" when done.
- The owner verifies that the worker hasn't completed the task to specification. So the owner "rejects" the task.
- "Absent-minded" loses their deposit.
- The third user called "hard-worker" takes the same task and clicks "complete" when done.
- The owner verifies hard-worker's work is successfully done and clicks the "Confirm" button.
- The winner takes the price and the absent-minded's deposit.
- The task is done.
We'll learn in this walkthrough how to transfer funds between users of this task app based on the business logic.
As we've done several times in previous steps, we switch branches by running
git checkout rewardto the reward branch. Next build the two sample-actor and sample-txn-executor wasm files. They'll be copied to the dev-runner local/a-node and local/b-node folders.
The build scripts are in the following locations of the
In order to clean up the state data from previous steps, make sure you delete the
.tokenstatedirectory in the
dev-runnerrepo before launching the docker container. This will make dev-runner start with a fresh state.
Start dev-runner by running
docker compose upfrom the root of the dev-runner directory.
Now from the
sample-front-enddirectory of the
tutorial-v1repo, run the following commands:
Now that the backend server is running, we'll need a few initialization steps before we can use the fund transfer function in our task TApp. The first step is to access the TApp in your browser by navigating to http://localhost:3200.
Because this is a brand new state, please make sure you click the Init TApp token and Init TApp db buttons located in the Admin page before doing anything else.
Now you can login to the TApp by clicking the login button in the upper right of the browser to spawn the Metamask modal window to login to the app.
Your account has no TEA when beginning from a fresh state, so you'll need to use the Faucet button to load your account with some TEA. Note that this sends 1000 T to your layer2 account, and you don't need to be logged in with Metamask (layer1) to do this step.
Next you'll need to set the spending limit for the TApp before using it. Each TApp in the TEA Project has a spending limit that is set by the user to ensure that the TApp's business logic can withdraw user funds only up to that amount.
Now that we're ready to use the TApp, let's first go through the design of the business logic.
User A as the owner creates a task. You'll be playing the role of the task creator and of two different task workers for this section of the tutorial, which means you'll need to have three different Metamask accounts. After using the faucet and setting the spending limit for the owner account, you can now log out of the owner account and switch to the second user (we call them "absent-minded") in your Metamask.
Because absent-minded is a new user, they have zero balance now. In order to continue, use "Faucet" add 1000 TEA to their account and also set the spending limit for the app.
Then switch to the Task page where you'll find the UI has a "take" button as shown below:
Pasted image 20230317091008.png
This task is created by the owner, so as a worker, "absent-minded" can take this task.
After clicking "take", absent-minded is now the worker for this task. We'll simulate that this worker has done some work, so go ahead and click "Complete".
Pasted image 20230317091258.png
At this time, user absent-minded's balance changes from 1000 to 995.
Pasted image 20230317091328.png
That's because by taking this task, the user will need to pay 5 T as a deposit. In the next step, if their work was accepted by the owner, they would take the 5T deposit back as well as the 10T task reward.
Now let's log out as absent-minded, and re-login with the Owner account.
We can see the task has two buttons: "Confirm" and "Reject".
Pasted image 20230317091629.png
In our demo, we assume that user "absent-minded" somehow mismanaged the task and that the owner isn't satisfied, so you as the owner will go ahead and click "Reject". Note, as a demo, we assume everyone is honest. We may release a secure oracle feature to take such decisions out of human control, but that would potentially be in a future version of this tutorial.
After rejection, absent-minded lost their 5T deposit. The task status is set back to "new". Anyone can take this task and the winner will take 10+5=15T.
Now logout as the owner and switch to the third user account. This person's name is "hard-worker". Hard-worker will login, and also add 1000T test token using the faucet as well as setting the spending limit for the app. Again follow the same steps to take the task, and click the complete button. Again, log out as hard-worker, and login as owner.
This time, the owner is satisfied with the work of hard-worker. You as the owner will thus click "Confirm".
This task is "Done". To verify if the user "hard-worker" has received the 15T reward, you can logout of the owner account and log back in to hard-worker's account to check their balance. You should find roughly 1015 T in their account balance (1015T less any small gas fees).
Pasted image 20230317092248.png
So the workflow matches our expectation.
There are no major changes for the sample-actor project when we went from the
src/layer2/task.jsto read the code yourself.