How to… build a dApp for team motivation
A decentralized app in the form of a bot that allows for an incentive and reward system aiming to motivate employees through Slack, a business communication platform.
In continuation of the theme of exploring examples of smart contracts in Ride, the programming language of Waves Protocol, this post will discuss a decentralized application called Billy.
Meet Billy
Billy is a decentralized app (dApp) in the form of a bot for Slack, a communications app used by a lot of projects internally. A detailed description of how Billy operates is available on the project’s official website https://iambilly.app or in this article. However, here is a brief explanation of Billy’s components and how the dApp uses the blockchain.
Situations often emerge during the work day when we need to support colleagues, or we need help from them. Particularly seen in many start-ups, cross-functionality is often the case within the organization, and some employee tasks fall outside of their job description. In order to incentivize colleagues to be more cross functional in times of need, with just one click you can add Billy to the internal Slack channel and start incentivising those who go beyond their usual responsibilities.
How exactly does it work? Well, the general rules are as follows: for each employee, Billy generates a unique address and saves it in the database. On a monthly basis, the bot adds 500 “thank you” tokens to each generated address, which can be spent with the help of the same bot. To send tokens, employees can use commands (10 thank @username) or just react to messages with a specific emoji designated by the dApp.
The unused balance of the 500 monthly “thank you” tokens are burned at the end of each month. However, tokens received from other employees are not burned and can be used in three ways:
• Transfer to other employees to thank or reward them. Tokens can be transferred to kind, funny or helpful colleagues at any time
• Purchasing goods in an in-house store. A company can set up an in-house store to enable its employees (and/or other authorized individuals) to offer goods and services in exchange for “thank you” tokens
• Participation in voting and crowdfunding campaigns. Any user can propose a goal for which they collect tokens (for instance, the organization of an internal meetup). The company’s management could also initiate a voting session, where a token will be equal to one vote, employees who gather more tokens will have a bigger impact on the outcome of the voting. In addition to a required number of tokens, a crowdfunding campaign will have an end date and an execution date. The voting mechanisms are similar to those of a DAO (a decentralized autonomous organization).
A video demonstration of the bot’s operation is available on the project’s website. The system hides the integration of blockchain technology from users. Should they require, users can request their seed phrase and use tokens outside of Slack. However, to avoid creating extra barriers, the implementation details are not shown in the dApp itself.
Billy is a free dApp, once added to Slack it is easy to learn its mechanics.
What’s “under the hood”?
Before implementing the idea, let’s describe our requirements for the dApp in a more formal way:
1. For each Slack team, a unique token is issued, which will be the team’s internal currency
2. For each team member, a separate account is created, where they can only hold the token of their team
3. Team tokens can only be transferred between its team members. Therefore, a list of addresses for each team member needs to be stored somewhere
4. Any team member can burn their tokens
5. Voting is done by calling dApp functions with team tokens attached
6. In each voting session, a user obtains a unique non-fungible token (NFT) that confirms their vote.
The system is complex and needs to include several scripts. The first step, the issuance of a team token, is a relatively straightforward operation of sending a token issue transaction. We don’t want system users to pay transfer transaction fees in WAVES that they would need to buy for that purpose. Therefore, we will use the sponsorship functionality. It will enable users to pay transaction fees in “Thank you” tokens, while fees in WAVES will be deducted from the team’s administrator account.
We use the function waitForTx from the library waves-transactions to make sure a token issue transaction has been added to the blockchain, after which we’ll send a sponsorship transaction.
To some extent, the use of the sponsorship functionality puts restrictions on compliance with the other requirements, as sponsorship cannot be used with smart assets. That is, at the token level, we cannot introduce restrictions on transferring tokens only to other team members. In the future, once the proposal WEP-2 Customizable sponsorship has been implemented, turning in sponsorship for smart assets will be possible. For now, we can find another solution. For instance, a script can be added to each team member’s account (making it a smart account) that will check if the token recipient is on the team list and, based on that, confirm or deny the transaction.
The team address list has to be also stored on the blockchain. Since we have a dApp for purchases and voting, we can add a team list management function.
Here’s an example of how to build a dApp that will enable adding a user to the list or removing them. The addition function will accept an address as an argument and add the key-value pair to the storage, in which the key will be the address and the value will be true. The removal function will update the record in the storage and change a specified address’ value for false.
Now, let’s write code for a smart account that will be installed for each team member:
The scripts described above enable meeting the following requirements:
1. For each Slack team, a unique token is issued, which will be the team’s internal currency
2. For each team member, a separate account is created, on which only their team’s tokens can be held
3. Team tokens can only be transferred between team members. Therefore, a list of the team members’ addresses needs to be stored somewhere
4. Any team member can burn their tokens.
However, we still need to meet two more requirements:
1. Voting is done by calling dApp functions with team tokens attached
2. In each voting session, a user obtains a unique non-fungible token (NFT) that confirms their vote.
Voting and collecting funds for a specific goal (we’ll further refer to the latter as a crowdfunding campaign) can be initiated by any team member. To do that, they will need to call the dApp function by indicating:
• a unique identifier
• end time for a crowdfunding campaign or voting session
• end time for project execution
• a minimum amount of collected funds for the campaign to be considered successful
In the dApp, we won’t provide the names and descriptions of the campaigns to avoid disclosing internal information. Campaign data can be stored in a centralized database available to company employees.
If a campaign is successful, meaning the collected sum exceeds the minimum sum indicated at the start of the campaign, then the collected tokens need to be blocked on a smart contract until the project execution time. At that point, the investors will vote on whether the project has been executed. If the majority decides that it has, the tokens on the smart contact are unblocked and sent to the campaign initiator. Otherwise, the token will remain on the contract indefinitely. This approach helps avoid situations when funds have been collected and the project has not been executed.
Here is how to build the dApp step by step.
The start function for a crowdfunding campaign or voting session can be the following:
We’ll create many keys that we will use in other functions, as well. Therefore singling them out in separate functions makes sense to avoid duplication and typos:
All team members, except for the campaign initiator, can provide their tokens for the execution of the project or as votes. However, a user’s contribution cannot exceed 33% of the required sum. For sending tokens, users will need to call the dApp’s method, enter the campaign’s unique ID and attach tokens as a payment.
We have implemented a functionality for creating and funding a campaign. We will now implement a function that campaign investors can call to confirm the execution of a project. The absence of a user’s vote will be considered as a vote against.
If a campaign hasn’t been successful and the target number of tokens has not been collected, investors will need to be able to withdraw their funds:
User interface
Once the main code is implemented in Ride, the dApp will have to be able to interact with users, the platform’s API, database, etc. For a deep dive into how the dApp works for end users, check out the demo video on the project’s website — https://iambilly.app or follow Billy on Twitter. It’s also very easy to, install Billy in Slack for free and start using it ;)
For more tutorials on the RIDE programming languages and what else you can do, check out our “How to” section on our blog.
Read Waves News channel
Follow Waves Twitter
Watch Waves Youtube
Subscribe to Waves Subreddit
