Goal: show off the Lido on Ethereum security practices; share insights & gotchas we've discovered / employed so far in the process of making scary changes and operation safe(-ish)

## Outline

20m — tight timeline

1. Hi I'm Eugene from LoE
2. Disclaimer: this is not "how to solidity securely" kind of talk — that's covered way better elsewhere; what should the team do above that?
3. I'm from Lido on Ethereum: 7.5m ETH staked, 32% of the staked ETH so far
4. What is Lido v2? (v1 + staking router and withdrawals) (this slide gives the audience a helicopter view what is lido and quick intro about v1 -> v2 upgrade)
- V2 features = 2* V1 features
- V2 code = 3* V1 code
5. The migration has to be single transaction (no way for a soft launch; proxies, ownership, DAO vote, whatnot) (AAVE decided not to do automatic V2->V3 liquidity migration; every Uniswap "upgrade" is new pools with no liquidity; we don't have that option)
6. Smart contract zoo: multiple solidity versions (thank you Aragon), three access models ("owner", Aragon ACL & OZ ACL)
7. How to upgrade? Voting based on EVM scripts + upgrade template contract
8. Upgrade timeline
- Nov — start for real
- Feb — V2 Snapshot
- AUDITS
- Late March — April — testnet
- May — onchain upgrade
9. Stories from the trenches
- How to spec safe protocol
- Main "adversary" one's planning against — sophisticated actors (look at mempool design and the whole MEV industry)
- 80% research / code goes towards edge-cases
- On/off chain design: trust-minimized oracles
- Not "well-checked and trusted", but have tight safety checks in onchain code (asymptotical bounds)
- GateSeal
- How to expect the unexpected (and not give outthe keys from town to strangers)
- Surviving multiple audits
- Cadence
- Dedicated "audits manager" from our side
- WOW it's way better to space things and not go this way
- How to prepare the DAO motion (diffyscan & deployment play)
- Dev team prepares the upgrade. How to spot their mistakes? How to prevent them from being approved & enacted by the DAO?
- Dev team publishes upgrade plan in the open for the challenge (we ran yet-to-be-deployed code bounty with Immunefi)
- Audit the deployment!
- Check the template & all the hardcoded values: addresses & constants
- Space to improve: the whole upgrade is in the template
- Paranoia in the DAO Ops
- show 'em minimal blockchain action checklist
- org: two pilots & everything is transparent & explained beforehand
- acceptance blcochain fork tests for the protocol before/after the vote(s)
- test your upgrade as early as possible, it'll save you grey hair later (costed us some for sure)
- Certora is awesome: formal verification, "invariant-based thinking" and deep digging
- Very experient team; co-authors, and not just auditors
- Invariants list helps to iterate on the code faster
- Having to think in invariants improves the dev culture in the whole team
10. Protocol Security Layered Cake (picture for inspiration [The Paramount Importance of Data Protection: Pyramid Security](https://www.dataart.com/blog/the-paramount-importance-of-data-protection-security-pyramid-in-detail))
1. People
- Hiring
- Paranoia culture
- Security champion
- Ownership
- Key management & opsec
- Incident handling practices
2. Protocol Design
- Sophisticated actor-resistant design
- Mindful of griefing
- Design is a balance between security & UX
3. Smart Contract Implementation incl. internal review
- Use industry standarts
- KISS all the way down
- Optimize only after code AND the test suite is here
- Have internal review culture
4. Testing
- Acceptance testing on the mainnet-fork
- Formal verification & fuzzing
- Testnet runs: for internal checks & for partners
5. External security
- Audits
- Bug bounties
6. DAO Ops
- Transparency & verifiability
7. Monitoring and safeguards
- Forta
- Emergency brakes & GateSeal
- On-call, incident policy & practices
8. Radical transparency
- Postmortems
- Public everything
- Don't rely upon secrets being secret (no EOAs in the design, safety checks & self-expiring access)