Draft AGP for Vote #2: Aragon Network Security Partner

Title: Aragon Network Security Partner for Vote 2.
Author: maurelian
Status: Stage III
Track: Finance
Created: YYYY-MM-DD


We propose to continue working closely with the A1 team, following the productive and successfuly collaboration of our ongoing security advisory engagement during the first voting period.

Address of the transfer recipient

TBD prior to final submission of this AGP.

Amount of the transfer

TBD prior to final submission of this AGP.

Purpose of the transfer

Funding of the following activities and deliverables in support of securing the Aragon Network:


We propose to work with A1, supporting their work to iterate on the following basis:

  1. We will break up the work for this AGP into 3 sprints of 1 month each. On the final Tuesday of each month (April 30, May 28, and Jun 30) we will meet with A1 to plan for the following month.
  2. In each of the 3 months, we will set aside 1 week for intensive review of whatever code A1 has ready for us to review. These intensive review periods will function more like mini-audits☨, and as much as possible we will encourage A1 to package their reviews as such.
  3. During the remainder of the month, we will be in regular communication with A1. Through the same shared Keybase channel we currently use, we will be available to answer questions about architecture, process, and comment on the state of preparedness for upcoming mini-audits.

☨ By auditing larger changes, and ideally entire new apps we are able to better understand how these changes fit into the overall picture. By working in discrete sprints of intensive focus, with down time in between, we believe that we can provide a better service, and more significantly impact the quality and security of the project.


In this forum:

  • At the beginning of each one month period we will publish a summary of the discussion and plan for the next period with A1.
  • Following each intensive mini-audit period, we will publish a list of our findings and comments.

In the interest of efficiency, these posts be less formal than our typical reports, but no less informative or descriptive of our findings.


Note: We are also collaborating with @jack and @wadeAlexC of the Authio team on a proposal they’ve drafted which would:

Give the Aragon Association the discretionary authority to select and fund security partners until processes, which facilitate on-chain funding of security services for the Aragon ecosystem, are designed and implemented to address the challenges which motivate this policy.

That would allow for more flexible security and audit procurement processes, which I agree the A1 and Flock teams would benefit from. However we also feel the need to put forth this AGP to continue the work we’ve started, and not leave A1 without a security partner while a new process is established.

Feedback requests:
@sohkai, @jorge, @bingen, @light, @luis, and @the_whole_damn_community: I’d appreciate any feedback you can provide on the original post above.

In particular the proposed cadence.

Also note that this does not include process improvement consultation, which we’ve done some early work on already. I think that I should break that out into a separate AGP. What do you think?

ps: Look at me! 5 days and 20 minutes before proposals are due. :bowing_man:

This is really good, interesting and necessary - I read the last report that Diligence did and I’m curious to learn more about the mini-audits. Do you have any examples?
Good luck!!

I’d curious to know more about the relationship with Authio if this proposal gets approved.

Do you still envision working together? My main concern is funding two security partners, which seems like an overkill right now in terms of treasury. A valid answer is that ANT holders can decide which one they prefer, but I just wanted to get clarity if that’s the angle or there’s another one.

Hey @maurelian, I notice you only mention A1 in this proposal. Is there going to be any bandwidth set aside for other teams in the Aragon Network?

@mariapaulafn here is one we did for 0x, it was a single contract that extends their existing contract system: https://github.com/ConsenSys/0x-audit-report-2018-12

1 Like

I don’t want to speak for Authio, but as I understood it they said they would focus on establishing this new funding process as an alternative to the current AGP process.

Splitting the whole project across both teams doesn’t makes a lot of sense IMO. Allocating different projects between providers feels better to me.


I think other security services for the Aragon Network should be covered by either:

  1. a separate AGP,
  2. the team’s own funds,
  3. another process which allows the AA to spend funds from a security budget without an AGP vote.

Great points. I can think of a number of large-scale and longer-term projects the Aragon network will want to undertake. There’s a lot of room for multiple providers to work concurrently. Some of these may have some overlap, but I think some amount of cross-pollination is healthy. Off the top of my head:

  • Implementing network-wide security standards and guidelines. With the number of Flock teams rising, the ANSP should take advantage of the growing community. Unlike most projects in Ethereum, there are clear avenues to develop shared security infrastructure between Aragon teams. I think there’s a lot of potential for this to create a really healthy ecosystem new developers will want to be a part of!

  • Migration of aragonOS codebase in favor of more passive security benefits. I’ll be expanding on this more as the AGP-18 engagement comes to a close. In short, there are a number of changes that can be made to the aOS codebase that will make it cheaper to develop, easier to audit, and safer to use. Given that aOS is the backbone of a lot of current and future projects, this is a really challenging task to plan for and will likely be a continuous process.

  • Improving aOS testing infrastructure to handle larger changes. This has some amount of overlap with the previous point, but I thought I’d separate them as this is its own beast. Martin from Diligence produced a really amazing advisory on the aOS testing infrastructure that will be released as AGP-18 winds up. I think there’s a lot of room to expand on his work!

  • Developing custom tooling and monitoring for aOS applications. I’m less familiar with the security tooling ecosystem, but I believe Diligence is a big part of that with MythX and Harvey. I would bet there is a lot of expansion to be done in that vein. Slightly related, Martin introduced me to his VSCode plugin - a syntax highlighter geared towards auditing Solidity - which was really helpful during portions of the aOS audit!

  • Any Flock team, individually, is its own project. I wanted to separate this from the rest of the points because it’s important to note. There are (as of this post) 2 Flock teams, with 3 more proposing for the next round of voting. It’s pretty clear to me that there’s a lot of work to be done for Aragon One alone - but the future Flock looks to be growing quickly!


Okay - interesting to know. As an Aragon Network Partner, would you be able to choose which Flock teams you wanted to work with? Would your team have the bandwidth to scale your services as the Network grows?

I understand if the budget in this next quarter is Aragon One specific, but as an “Aragon Network Security Partner” I am interested in understanding how the partnership would work with the Aragon Network as a whole vs. a single company in the network. Hence, I think you should then outline what you stated in your official AGP proposal (for example):

" As a security partner, additional services for the Aragon Network can be covered by either:

  1. A separate AGP that we prepare, once we are aware other teams require our services
  2. A team’s own funds as outlined in their Flock proposals
  3. A process which allows the AA to spend funds from a security budget without an AGP vote.

We have the right to choose Flock teams we work with on a case-by-case basis."

The budget in the draft above was informed by our experience in the Vote1 phase, and your feedback is illuminating where the proposal is incomplete. Looking at the forum right now, my sense is that there might be as many as 5 or 6 new projects we could work with in this phase!

The challenge for us is to assemble a proposal to services projects that are being voted on at the same time as our proposal.

That formulation puts us in a fairly political position choosing who we service. I don’t love that idea, but that’s how we operate as a business too, ie. we take on the projects that fit with our price structure and interests. :slight_smile:
In this case, one of our great interests is to make the Aragon Community happy, and help the Network succeed. So, perhaps I would keep your ammendment, and append “We will select teams in consultation with the community, and do our best to provide transparency into that process”.


To add to what @maurelian said, it can’t be understated, Aragon’s multi-team code review process itself is uncharted territory, without even including the AGP process.

In the short-term, a more flexible model that prioritizes working relationship formation, punctual shipping, capital efficiency, and the ability to freely explore open challenges in the code review process will greatly benefit the network’s initiatives.

Check out our AGP draft which goes into more detail->

Feedback is appreciated :slight_smile:


OK, here’s a sketch of a new approach to the Security Partner AGP based on some discussion with @sohkai, which I think addresses some of @stellarmagnet’s points:

Time length:

Either 6 months or 1 year.


Payment would have 2 components:

1.Retainer for ongoing services: $XX, payable in 2 installments of $YY at 3 month intervals
2. A deposit for upcoming audit work of $ZZZ

What we’d provide:

  • Ongoing services:
    • Auditing the ongoing progress of the Aragon Network and its core components, aragonOS, its core apps, the generic Staking component, and the Court.
  • Flock project audits:
    • We would provide audits to flock projects using our normal project flow (scoping, estimation, SOW etc.)
    • We would reduce the balance of the deposit accordingly when we do an audit.
    • Every three months, we will report on the funds spent, and the work performed and request funds to top up the deposit in order to complete future work.
    • Of course this could also include additional work done for A1 beyond the scope of the ongoing services retainer.

The edit looks great!

One other possibility that would be kind of aligned with the other ANSP proposal and helps the network budget out yearly costs better, is if there was some estimate on the rough cost to audit a risky app and pad that value by about 150%, then estimate the number of apps that may be released in the next 6 months. Then instead of a deposit for this additional amount, the AA has the power to approve up to this amount of funding for additional Flock/Nest team’s security audits outside of AGP cycles. After each cycle, the SPs will also have a better idea of costs for this “discretionary budget”, so the amount proposed in each subsequent budget proposal can be tweaked.

E.g. Let’s say in the next 6 months, there will be 6 new apps released by Flock teams. Then let’s say the cost of auditing one app is $30,000. Then this is 6 x $30,000 x 1.5 = $270,000 budget. You won’t get this sent to you in installments nor as a deposit, but can be allocated in chunks as the audits begin for the additional apps and you have a better idea of the costs.

If one budgets for 6 months of this discretionary spending, and every 3 month can make updates to this budget, I think the network can be pretty agile.

The deposit you get for the things you know you have to audit in that cycle will provide you with more financial security that you don’t have to wait for payments, this discretionary budget that isn’t deposited to you will give other teams more security that they know there is for sure some pool of funds available outside of AGP cycles and the greater network will have a better projection into the potential burn rate as well.

(But I’m not sure if this type of budgeting should be included in the other proposal, if the strategy was for the two types of AGPs to act independently - cc: @jack)

My two main motivations for supporting a retainer model with Aragon Network Security Partners:

  1. As much as possible, reducing friction and bureaucracy from both sides of the engagement (auditee and auditor)
  2. Ensuring a baseline level of security services for core Aragon Network software components, while still being flexible enough to accept periphery components as resources allow

Given our Q1 2019 experience with AGP-18, I wholehearted agree with the sentiment in Draft AGP for ANV-02: ANSP Engagement Policy that numerous improvements could be made in regards to how the Aragon Network procures security services.

The biggest improvement, to me, would be a clear separation of concerns and scope.

The Network itself should first and foremost be deeply concerned about the security of its core components (outlined by @maurelian above). The ability to contractually bind a stable Security Partner for longer periods of time, assuming things go well, gives the Network some relative certainty that, at minimum, security audits and ongoing diligence will be performed for these core components without having to continually re-enter the procurement process with service providers.

Given that this is a Network-level objective, I believe the AGP process is still the best fit for selection of this partner, as community members should be allowed to weigh in with their approval or disapproval of potential security partners and the baseline budget being spent for this additional service.

With this in mind, I also support Draft AGP for ANV-02: ANSP Engagement Policy 's intent in allowing the Network to officially delegate to the Aragon Association many aspects of the security engagement process. However, I’d scope it primarily for periphery projects not core to the Aragon Network, such as many Flock and Nest projects, or in cases of emergency where there is no established Security Partner.

The gives the Association relative freedom in assessing the value-to-cost ratio of each of these projects requiring security services to determine how, or if, they will be submitted to the Security Partner (or alternative service provider). The protocol for doing so would be dependent on the Security Partner or service provider chosen and initially agreed upon the Partner’s onboarding or procurement process. This may involve the pre-approved deposit or budget strategy discussed above, although an open question is to what degree should the community be involved in these decisions (if the budget doesn’t come from the Association’s own yearly budget).

Individual Flock and Nest teams still have the freedom to negotiate with alternative service providers, although they would be primarily responsible for costs as it should not be the responsibility of the Network to guarantee their projects’ security. There may be reasonable protocols between the Association and teams whereby these costs could be included in funding milestones (or amended into future milestones) conditional on performance or other metrics (e.g. user adoption), amongst other means to reduce the monetary burden on teams.


This is now AGP-37.

Thank you @sohkai for your feedback on the prior drafts.

We certainly don’t want more bureaucracy, and we don’t want friction for the sake of frictions. We want Aragon to succeed in its mission, and we feel strongly about wanting to continue to be part of that story.

Responding to another quote* from @sohkai on a side channel discussion:

The main problem I have with strictly timeboxing the “1 week per month” is that it’s unlikely we’ll have things so neatly packed and ready each month. You will be able to speak more about how the last three months have gone in terms of organization and planning (I believe we’re usually a week late on our side from when we “expected” things to be done), as well as time spent on the rolling reviews.

I hear you, and I hope having “4 weeks over 3 months” gives a lot more flex than “1 week per month”.

My main objective is to reduce the friction of obtaining security approval as much as possible, and I’d be worried if something that needed to be audited couldn’t, because we ran out of allotted time one month.

Please believe that we are not going to just leave you hanging. We don’t want to reduce our level of commitment and we don’t want to slow down your release pace.

We just need to be able to plan and schedule internally for other projects, and I think this will enable us to give you better service and more secure code.