S.W.A.T Initiative Discussion

Hello StakeWise Community,

Some of you may recognize me from discord, many may not. I’ve been a lurker in the StakeWise community, primarily discord, since around May of 2021. In that time, I’ve enjoyed learning and experiencing all this great community has to offer. With that being said, it brings me to the purpose of this post: the SWAT Initiative.

Let me first start with a little background of myself. I’m a recent College graduate (April 2021), and I’ve spent a large portion of my time since completing my diploma researching and learning the innerworkings of DeFi. This was through various hackathons, work as a contractor, and general interest in my free time. During one of my hackathons, my team explored the idea of DAO tooling to reward contributions and participation (@brianchilders and @kiriyha may remember my questions in discord). Safe to say that like most hackathon projects, we didn’t make it far past the scope of our hack, however, not all was lost. Shortly after, StakeWise CC #2 happened and the idea for the SWAT was presented.

In leu of the recent post by @kiriyha, The StakeWise Acceleration Taskforce (S.W.A.T) Initiative, I’d like to start a public discussion where we can contribute ideas, ask questions, and help build the structure of SWAT and the corresponding Bureau. Please feel free to post any thoughts of your own or ask questions if you have any :blush:

I’ll start things off with some of my own thoughts that have come to mind over the past week:

  1. Do we want The Bureau and SWAT teams to be mutually exclusive? There could be a conflict of interest if a member is participating in both, but diversity on either side would help mitigate the risk of gaming the system.

  2. Much like the SWAT members, The Bureau will be inadvertently contributing to SWISE through their responsibilities. Should we consider an allocation of SWISE to members of The Bureau to ensure their important role is met with compensation?

  3. What kind of approval criteria should we consider for SWAT members? This can be baseline all the way to advanced.

  4. Should we implement a requirement for SWAT member activity? For example, if a SWAT member hasn’t completed a task in x time periods should we remove them from the taskforce?

  5. Will we set up a time period for task lists or will it be like a live bounty board that SWAT members pick items off with their predefined pay? This of course depends on if the SWAT initiative is extended beyond the original four weeks.

That’s all for now. If you made it this far, thank you for reading. I hope to hear some great ideas in the comments below, and as always, stake wise my friends :smiley:

2 Likes

@chak

Thank you for helping to stimulate this topic / thread of conversation further - you have some great thoughts / questions that I aim to explore / respond in detail. :slight_smile:

I agree - it would be good to have diversity in both areas. The question is how are the approvals of the work done? If we explore this area (there are multiple approaches to solve this problem and I can propose one for consideration), we may find ways to help avoid gaming the system.

Let’s pull in some of the concepts that @kiriyha discussed and perhaps try to refine some of the processes within the high-level implementations that were proposed:

Specifically:

So if we were to maybe sketch out a process for the high-level thoughts in term of what’s called an assignment or work item:

  1. Ideas
    Someone comes up with an idea that may be suitable for an assignment. The idea can come from anyone: DAO, Community, Bureau, Outsider, Core Dev Team, Investor and so on. The idea would be ultimately processed by the Bureau (after consulting appropriate individuals to determine feasibility of the idea) and will be dispositioned appropriately. Potentially a TypeForm could be set up for Idea Submission. The idea would be either accepted for an assignment, or rejected.
  2. Assignment
    When an idea is turned into an assignment, there will be characteristics of the assignment that are defined. Some characteristics of the Assignment might be:
  • expected delivery date of the assignment
  • suggested SWISE rewards for the SWAT Member
  • suggested SWISE staking requirement by a Bureau Member (more detail on this later)
  • required skills to complete the assignment, summary of the requirements / deliverables that would qualify the task the task to be marked as complete
  • and so on…
    The assignment would then be posted on a “SWAT Board”, and a SWAT member can work on the task. One thing to note: an assignment is not “exclusively owned” by a SWAT member. As we have an open market for assets, we could have an open market for work. Not every task will be suited for all SWAT members. We have people in the community that have varying skill sets and we should leverage each of their specialized skillsets. For example, a SWAT member that is strong in talent acquisition should not be expected to be strong in Solidity programming. A person with a strong skillset in Solidity programming should not expected to have the skills necessary to be a graphic artists / logo design / meme generation.
  1. Completed Work
    Once the assignment is completed by the SWAT Member (multiple members may compete against each other for the same task), the submitted work is reviewed by The Bureau for accuracy and completeness of the task. Additionally, if multiple people submitted work for the same task, The Bureau can opt to [1] decide who the “winner” is for the task and/or as appropriate [2] note multiple SWAT members qualified to earn the rewards (e.g. if another individual’s work is found to complement other submitted work for the same assignment). The caveat here is that if a person is in a SWAT member capacity submitting the work, they must recuse themselves from two steps [1] The Bureau evaluation process for submitted tasks and [2] the DAO voting process. I recognize that a person could have multiple addresses and attempt to game the system - but at this time, I don’t think anyone has a “super majority” at this time - but hopefully The Bureau members and the DAO being “two filters” - would help eliminate the potential of gaming the system.
  2. Submit work for approval by the DAO
    Now here’s where it could get interesting. I didn’t say that this could be a requirement of The Bureau, but worth consideration.
    To ensure that The Bureau members have a vested interest in the StakeWise ecosystem, we could establish a minimum amount of SWISE that one would need to own in order to participate in The Bureau.
    Another requirement is that The Bureau member should have the needed skillset to understand / evaluate the work that is being done by the SWAT member.
    But let’s go back to the idea that a Bureau member should have an X amount of SWISE to participate. A control that we could place on the Bureau is that the Bureau member would need to “stake” X amount of SWISE when approving the Completed Work that a SWAT Member did. Basically the amount of SWISE staked by the Bureau member when approving the work needs to be effective enough that if the DAO vote rejects the SWAT Members work, the “staked” SWISE would be slashed from the Bureau member and returned back to the SWISE Rewards pool allocation.
    However if the work is accepted, the Bureau member would get the “staked” SWISE returned plus either a % reward or fixed amount for reward acceptance (this could be fleshed out in detail later). This then enables the Bureau Member to “earn rewards” for the time / work they do as a Bureau member and do so in a “moderated / regulated” fashion.

I would think each task would have it’s own set of approval criteria. If multiple team members submit work for the same Assignment, either a winner takes all or as appropriate rewards could be given to the winner(s) as suggested previously.

If we enable multiple SWAT members to “compete” for the same task, this may become a non-issue. Additionally, it will encourage the SWAT member to “put their best foot forward” when submitting work for a task.

I think this is very much a trial period - we could start with a limit of four weeks during the trial - but if our trial is successful, based on the task we could have “open ended” tasks vs. pre-defined. For example, if it’s “referring a resource” that could be considered an “open ended” task. If it is a task that would enable StakeWise to gain a competitive advantage, we would need to have a “pre-defined” time limit.

I just want to say - great post and thank you for helping to get the conversation started!

Eat Steak, Be Wise!

-Brian

2 Likes

Enjoy the ideas and thought behind this. Don’t have much to add now but looking forward to continued discussion.

3 Likes

Thanks @chak @brianchilders for the discussion and ideas.

IMHO the Bureau and SWAT teams should be mutually exclusive but we could limit this to a particular task, i.e a Bureau member can not vote if he run for a task.
But it’s all theory because we dont want to run KYC or anything…

The ideas to stake SWISE to vote is great but could be a problem on network congestion period. What about a snapshot for the vote ?

3 Likes

yes, the mechanics of “staking” would have to be worked out to be cost-optimal (thinking off-chain somehow) or it could go along the lines of if I’m going to be the bureau and I vote on 5 things I would need to deposit at least 500 SWISE (1 for each vote) into the contract.

now what the contract could do is hold the deposit (e.g. ideally you wouldn’t get slashed) and you would leave the swise in there for each subsequent vote (provided you don’t get slashed).

or there may be a better way.

1 Like

While we don’t run KYC, I think as proposed you should have some sort of registration, e.g. as @kiriyha outlined previously.

so some form of “private” dox’ing is needed to an extent. That being said, always could generate a new ETH Wallet address for the purpose of SWAT Rewards.

1 Like

Thanks for the great response and ideas, Brian!

First off, I think approaching the SWAT and Bureau teams exclusivity through a combination of your and @remche’s suggestions is a great start. This would include having open tasks that one or many members can work towards and preventing a Bureau member from voting if they participate in said task. Which allows us to: 1. Limit an individual from gaming the system in their favour, and 2. Allow for diversity and competition in submissions. However, one avenue this doesn’t cover is a member of the Bureau working in cohorts with one or more members of SWAT. This will be partially covered in the open competition of certain tasks but maybe we should give it extra attention as we continue discussions?

I like the idea of having Bureau members stake SWISE to contribute to voting but it does become a fee concern with the current state of the network. One idea that comes to mind, along with points already made, is to have an off-chain mechanism for Bureau members to prove a stake and generate rewards. This method could include taking a snapshot of all Bureau members wallets before a voting period and then handing out a % or fixed reward based on the validity of their votes. While this doesn’t include any slashing penalty where Bureau members are financially punished for bad actions, it is in their financial interest to be a honest participant. To further secure this mechanism we could also have inner-voting inside the Bureau where they can snuff out bad actors. However, with that it could become a popularity contest, which we definitely do not want.

As for the rest of your points (answers to my questions 3, 4, and 5), I think they’re all great. I especially like the idea of tasks being open-ended and pre-defined on the job board. Although, I do see a future in the scale of the StakeWise DAO where the board may become too heavy and things need splitting up :slight_smile:

These are just my general ideas, I’d love to hear more from you and the rest of the community on ways to tackle this.

2 Likes

So today Vitalik proposed an idea of leveraging NFTs not for signaling who has the most wealth but perhaps something else. He highlights how NFTs could be leveraged to be “soul bound” e.g. non-transferrable. He highlights POAPs but we could also use the proof-of-humanity attestation e.g. https://www.proofofhumanity.id/ or perhaps https://www.brightid.org/

This may be “not ready for prime time” - but this is a thread of thought that could be leveraged to help reduce the amount of “bad actors”. The fact that you have PoH (Proof of Humanity) could help discourage bad actors.

That being said, privacy is also a concern - and the implementation does need to be worked out - but he also proposes a way forward in his article.

Just some more food for thought.

-brian

1 Like

Really like this idea, with more discussed in @zkwolf’s Non Nontransferable Social Tokens post, it just brings me on board even more. I will read through this and formulate my own ideas for implementation over the next little while, along with some additional research.

2 Likes

First of all, @chak it is great to see someone pushing the SWAT discussion forward! Love that the work & research you’ve done in the space earlier can help us with this initiative, and hope that down the line a standalone project could be spun off from SWAT (at least I think it’s a possibility if we do it right).

To the points discussed in this thread:

  • I believe separating the Bureau from the SWAT members (aka executors of assignments) would limit the folks in the Bureau, rather unnecessarily. However, I also recognise the risk of corruption stemming from this model. Considering that the Bureau would likely want to be compensated for their time & efforts, and that the DAO will be the ultimate voters on whether the compensation to SWAT members was assigned fairly or not, I propose to give the Bureau members an allocation of SWISE that gets unlocked with every successful DAO vote to distribute rewards for the SWAT program. A successful vote means that the community approves of their work (e.g. calculation of rewards earned by the SWAT members), and then compensation is unlocked accordingly. I am slightly against performance-based pay for the Bureau members, because their role here is mainly administrative and task-agnostic; thus it doesn’t feel fair to award them more if a certain task does well. Happy to hear your thoughts on this.

  • In my opinion, registration is only necessary to prevent (or minimise the chance of) gaming the system - it’s just an extra hurdle to jump over for the people that want to earn SWISE from multiple accounts for one-off actions like upvoting a proposal on another DAO’s forum. With this in mind, I wouldn’t keep tabs on the SWAT members’ activity. Of course, it would be ideal to keep SWAT as a highly engaged group that jumps on every assignment but given the decentralised and informal setting, I find it unlikely that we find such a group of consistent contributors (hope to be proven wrong here).

  • On the other points re parameters for the assignments, I think each assignment should be open-ended in terms of approach & delivery period, unless something is time-sensitive or there is a specifically requested medium. I’d let the Bureau deal with that.

It feels like there’s a rough consensus in terms of direction, and once you guys @chak @brianchilders share your thoughts on some of my points above, I would proceed to implementation of SWAT (seeing that it received broad-based support in the community forum). Happy to work on this in the open for others to contribute.

2 Likes

I agree with this approach. A fixed amount from an allocated SWISE amount would be unlocked with the successful DAO vote would be awarded to the Bureau members. I agree that the role of the Bureau is administrative and task-agnostic.

The one time that a Bureau member would not get awards is if they were acting in the capacity of a SWAT member, e.g. they did the task / worked on it / contributed as part of the team. The Bureau member would also have to recuse themselves from the Bureau role of proposing the reward for the SWAT member(s) and presenting the work to the DAO for the vote.

It is fair to expect some level of transparency when receiving rewards. Both Bureau members and SWAT members should expect their community name (Discord/StakeWise forum/Reddit/Twitter) and their ETH Wallet Address to be public as a result of participating in this program. I don’t think this is an unreasonable expectation.

Agreed, let the Bureau deal with this - tasks could be of different types - but as part of the administrative work that the Bureau does, they will outline the proposed work to be done and classify it as one time or recurring and so on.

I am willing to work on putting out an implementation of the SWAT as well and would love for others to contribute as well.

2 Likes

The above plans on the acts of the Bureau and SWAT are fair and fit nicely. I wanted to initiate a discussion where we consider the potential risks for those participating in both, and I think that was done well here. I also agree that we should not have performance based pay for the Bureau, like previously stated, it should be task-agnostic.

As noted in the original thread, I agree that twitter/discord/reddit/wallet is reasonable public exposure for both a member of the Bureau and SWAT.

To the other points I have not noted here, I am in full agreement. I’m excited to move forward on this as soon as possible.

1 Like

Just as a point here with the Twitter/discord/Reddit/wallet. I am not on Twitter nor any other social media. I do have the other 3 though. If 4 points are necessary what could be a substitute?

1 Like

I would submit that you would need to have at least one of the four points, not necessarily all four points if that would help your thinking in this?

-brian

In my opinion not all 4 points are necessary, but the more you have the stronger case you make. At the end of the day it is a DAO vote, so the more requirements you are able to meet the higher chance you have at being approved. That also means one does not have to score a perfect 100% for approval.

However, if we do decide that 4 social points are necessary maybe we could substitute a Github account for twitter. This would of course only apply to developers.

1 Like