The development and acceptance process of Lido-on-X protocol (Lido on Solana, Polygon, Kusama/Polkadot) involves a pre-release security assessment. These assessments are expensive and are needed not only for the team building Lido-on-X, but for the Lido DAO as a method of acceptance test (so we could say that indeed, that version of the protocol is safe to deploy, use, promote and incentivize).
It’s never boiled down to the point of contention, but the teams are extremely cognizant of the upfront costs of assessments (before they even know if their solution will have a PMF), and are de-incentivized to go for the best quality, more expensive firms. We should not put development teams in a situation where they have a conflict of interests on getting the best security practices.
My proposal here is for Lido at large, acting through LEGO, to bear all the costs of final security assessments of the Lido-on-X protocols, limited to two assessments with reputable firms per upgrade. With LEGO council in charge of judging what is a reputable firm.
I also propose to retroactively fund the security assessments for Mixbytes(), Shard Labs, and Chorus One.
The costs of doing this are quite substantial (audits costs for a full protocol are anywhere between $30k to $200k, might be even more), but I gather them to be less than bug bounty costs, which are topped at $2M per bug currently.
For decentralized finance brands and protocols, security is of utmost importance. Lido should take pre-release security assessments as seriously as they possibly can be taken to protect against possible financial black swan events and damage to its brand. If the means to be able to spend incrementally more on greater prudence and higher quality security are available, and these processes have been screened properly by contributors, they should be taken.
I do reckon the significance of pre-release security assessment and agree with the proposal. For one Lido-on-X, the project should not be released once only and it will be released with version upgrade in multi times with bug fixing and function updating. I think for every big release, a security assessment is necessary. How will the fee be covered?
A couple of thoughts from our side. We are a security audits provider ourselves so we speak from experience:
On a proposal, stage teams have no way to estimate audit costs and book slots with the auditing teams. Currently, this presents a huge blocker and a serious possible financial risk because even if you deliver on your proposed code you might not be able to book good auditors. If this risk is somewhat mitigated, Lido will attract a lot more teams to its ecosystem, especially those that are on the smaller/younger side.
Totally agree with the point about audits being much more capital effective than bug bounty. If our clients paid $2M for every critical we find during audits, a portion of them would be bankrupt at this point for sure))
I can speak from our experience working on Lido for Polygon:
We take security very seriously since these products are impacting users and underlying network stability and decentralisation.
For that reason, we made a decision to do the re-audit and delay the launch for ~1 month. Audit put a significant extra cost on Lido for Polygon development.
Also, since it delayed the launch, the time where we expect to start earning from the project was also delayed.
That being said, Shard Labs fully supports this proposal and we think it will benefit the expansion of Lido ecosystem in the long term.
I completely support this proposal as well based on the points outlined by the team. The only question I’d ask the team is whether the LEGO grants program budget should be expanded (which I would also strongly support). My understanding is that the established budget allocates 240K LDO per quarter across all LEGO grants (https://lego.lido.fi/). I don’t know what the expectations are in terms of volume of security assessments but if the entire budget is just over $400k per quarter at current price levels and these audits can reach up to $200K in cost then I’d think the team would want to create some add’l room in the budget for other LEGO grants.
The LEGO budget can be extended with a governance vote if needed, so if it’s dried up with security assessments and/or bug bounty payouts, we will be able to ask for a top-up.
But it’s a good idea to pre-extended it for the next period, thanks.
generally in favor of this but curious if the team has considered more decentralized alternatives to formal audits (e.g. pre-release community bounty bug programs or something like code4rena)?
Bug bounties are there but they are not an alternative to audits. They fill a different role. Code4rena is something we want to try but it’s not a replacement to an audit either, it’s an additional thing (though would go to the same budget).
Forum did not allow me to post more than 2 links so I just provided tx hashes.
There is still one pending PR to be reviewed for version 1 and the new codebase for version 2 which is currently in development. Transactions for those will be posted once they are executed.
The compensation can be issued here: 0x4290db8e966a880d7Fd734884FBa93ee671984ea
MixBytes transferred 12,000 USDT to Dedaub as an advance for the auditing services. Ethereum Transaction Hash (Txhash) Details | Etherscan
The compensation for MixBytes can be issued here: 0x193128E013bB56d150555833Dc2a669d07D11842
52,500 USDT is still outstanding and needs to be paid to this address: 0xF5Da01d6aFfEf5af0E326bff01b6A1c2bd93c046