Security Workstream Budget (closed)

I propose that:

  • be “re-elected” as Security Workstream Leader for a period of 6 months, and be compensated at the rate of $$$/year
  • The Security Workstream be allocated $$$ FOX each month for the next 6 months, to be handled as described below.

Still need to pick numbers here, but wanted to get the general idea out for feedback.


I propose that the DAO pay the Security Workstream Leader on a salary basis, commensurate with the compensation of the leaders of other workstreams. The downside to this approach is that it may potentially create an appearance that the security workstream leader is paid out-of-proportion to other workstream contributors; personally, I expect to spend a significant amount of my time contributing to other workstreams (primarily Engineering – after all, code quality and investment in sound architecture are first-order security concerns!) but that time will effectively be paid for from the security budget.

Given this structure the Security Workstream Leader will not be eligible to receive compensation for completing discretionary security tasks via the process outlined below, in the interest of preventing even the appearance of a conflict of interest. They will remain eligible for funds made available to Security Workstream members via other proposals (the on-call stipend suggested in SCP-46 is an example of this).

I’ve asked for advice from a few members of the community about the best way to structure workstream leader compensation in this case, and the consensus seems to be that the wisest choice is to stick with the salary model for this role for the sake of simplicity. This seems appropriate to me in the context of a appropriate general bias towards continuity and what we know works, and well as the avoidance of any potential unintended perverse incentives that might be created by a more complicated setup.



Security tasks sometimes overlap with engineering ones, but sometimes don’t. I don’t envision a huge flow of security-specific work, which makes a traditional salary-style method of compensation less of a good fit. What we need is a system that’s flexible enough to adapt to a variety of circumstances: from “slow days” through to crisis response.

I expect that some Security Workstream contributors (hopefully, most of them!) will also be contributors to other workstreams. As such, I propose that the DAO pay for time instead of for people, by establishing a standard hourly rate for security work. Workstream contributors will submit payment requests on Colony for time spent on approved security tasks; the Workstream Leader will be responsible to veto any such payment requests that involve misrepresentation or abuse.

Still need to choose the hourly rate.

This obviously will involve a level of trust that contributors aren’t goosing their numbers, but it’s much more flexible than assigning pre-set values to individual tasks. I also feel that accidentally creating an incentive to rush security tasks is a much more dangerous failure mode than incidentally creating an incentive to move slowly. (In addition, trustworthiness is essential for security work, and if someone decides to lie about the time they’ve spent it’s a relatively cheap and reasonably detectable way to discover that they’re not right for the job.)


Each payment request made to the Security Workstream will be tied to a tracked task, which will provide the community with transparency into how funds are spent. Security tasks that are relevant to a particular repository will be tracked in concert with Engineering; at the moment that means GitHub issues on the associated repo, probably with an extra ‘security’ tag. A different system will be needed to track more general Security tasks, such as review of prospective partners’ code, or ones which need to remain confidential for a period of time; the precise system is TBD at the moment, but there are a number of options. The goal is a Kanban-ish “cards moving right” paradigm with “eventual transparency”, in the sense that any tasks that do require confidentiality (i.e. remediation of reported security issues) will still be tracked in a manner that will eventually (i.e. after the issue is fixed) end up publicly visible.


Security tasks will generally require a degree of trust in the contributor. (A contributor performing a security review will have to be trusted to disclose the issues they find rather than hiding them and exploiting them later; a contributor asked to help remediate a serious security issue will have to be trusted to maintain confidentiality.) For this reason, some tasks may require the approval of the Workstream Leader before beginning work, and confidential tasks may only be visible to certain approved contributors.


I hope to get this dialed in to a much more deterministic system in the future, but for now I ask that you trust me as workstream leader to choose and assign tasks on-the-fly in a responsible manner. We’re still evolving as an organization, and security usually deals with unknown unknowns. There’s still some level of split-responsibility to be sorted out between workstreams, like which tasks belong as Security initiatives and which belong to Engineering more generally, as well as what’s appropriate to handle via longer-term plans like the roadmap and what should be fast-tracked through the Security process.

I’d have preferred to bring a list of specifics here, but I do have confidence we’ll be able to sort it all out as we go. We’re approaching the point where we need to get started recruiting more active workstream contributors and prepare to jettison our centralized training wheels, and my feeling is that flexibility at this stage is essential.

Test Funds

The Security Workstream may distribute funds for testing purposes or for payment or reimbursement of necessary gas costs. These are expected to be minimal amounts, and the proposed discretionary budgetary allocation is expected to be sufficient.

  • Update: after the AMA on Friday, I now intend to revise this proposal to leverage Coordinape as the primary mechanism of rewarding security tasks.

    Preliminary ideas:

    Leader is full-time, salaried, and ineligible for Coordinape compensation

  • People doing work specified in other proposals get paid according to those proposals: i.e. the RDP proposal includes a stipend for being on-call. That would be allocated to the Security workstream in Colony and paid out directly without using Coordinape.
  • Fixed-cost things (i.e. software licenses, cloud services, paying auditors, hiring an outside dev for a one-off engagement) will be handled via Colony directly but will be paid in stables and won’t earn rep.
  • Coordinape will be used to determine contributor rewards:
  • The size of the pot each epoch will be determined by vote, with each vote weighted by Colony rep score
  • The allocation of the pot will be determined via Coordinape; any DAO workstream contributor will be allowed to give GIVE, but only security contributors will be allowed to receive it
  • The results of the Coordinape distribution will be distributed via Colony and paid out in each contributor’s desired token allocation (xFOX/xUSDC)
  • Contributors who want to be paid in stables may opt to participate in an extended testing program, where they get sent some extra xFOX before each payment cycle on the condition that they send it right back. This amount will equal the value of the stables they’re to be paid with, but contributors will not have legal claim to those test funds and will be required to send them straight back to the workstream, and if they don’t, they’ll forfeit their claim to the stables of the same amount they otherwise would have been paid.

    This is silly, and will require the workstream to have some extra FOX as working liquidity, but it will get Colony to give them rep for the whole amount. It also may (hopefully, IANAL, consult your accountant) avoid any potential tax reporting complications associated with getting paid in 100% FOX and then generating another taxable event by swapping it into stables.

    (Once Colony figures out how to reward rep in a more flexible manner, we can avoid all that.)

(Closing in favor of Security Workstream Budget (Coordinape Version)… at least as much as a topic can be closed on Discourse!)