1) The document discusses the risks of a "YOLO" or reckless approach to developing decentralized applications without properly considering security. 2) It outlines various threat actors and threats that could impact dapps, including hacks, bugs, price manipulation, and more. 3) The author advocates for a more responsible "parenting" model where security is prioritized from the start through thorough threat modeling, use of audited code, monitoring, and emergency planning.

1. The Risks of YOLOing
Dr. Arnold Yau
Security @ Ava Labs

2. Intro
● Bio - old school boring crypto guy
○ Crypto means cryptography, also IACR CRYPTO conference
● Speaking from perspective of project evaluator (e.g. for investment /
co-marketing) / security reviewer (“auditor”)
● Mostly aimed at dapp development
● Disclaimer - opinions my own etc

3. YOLO - acronym meaning you only live once,
used to express the view that one should
make the most of the present moment
without worrying about the future

4. YOLO Development Model (Caricature)
● Follow tutorial “Build a Dapp in 20 minutes”
● Fork, search & replace $PROJECT_NAME
● TC;DT: outsource to StackOverflow, copy & paste.
Crowdsourcing FTW!
● Build frontend with [framework] using NPM.The
blockchain is immutable and secure, right?
● Testnet: Get friends and family to test! Great it
works.
● Mainnet launch! :crossed-fingers:
● (Documentation is for losers)

5. Threat Landscape
Threat actors
● Lone hacker
● Criminal gangs
● Law enforcement / intel agencies / nation-state - nuclear program
● Yourself / your team
Threats
● Supply chain attacks - dependencies
● Smart contract bugs - re-entrancy, unauthorized access / state transition
● Defi - flash loan attacks, price oracle manipulation
● Bridge attacks
● Private key compromise
● Phishing / scam
● (Potential) rug pull
● Web 2 attacks
● Privacy / front running

6. YOLO -> Responsible Parenting
● Resources
● Professional health check - pre-, post-delivery
● Development: nutrition / coding + eng practices
● Monitor
● Emergency plan
● But… it’s not just YOUR “baby”

7. Fundamentals
● Think about security from the start
● Threat model your whole system
○ Assets - funds, credentials, wallets, PII
○ Attack surface, attack vector
○ Infrastructure and application
○ Source code repository
○ Risk = Impact x likelihood of attack
● Make conscious, documented philosophical decisions on
○ Identified or anonymous
○ Governance model
○ Decentralization objectives
○ Open source development (probably yes?)

8. Design and Implementation
● Get best developer you can find/afford
● Use audited libraries and design patterns e.g. OpenZeppelin
○ Pausable and upgradeable
○ Monitoring: events, invariants
● Learn about common Solidity vulnerabilities and keep up with the version
changes
● Code defensively
○ Validate parameters
○ Cater for edge cases
● Dependencies
○ Eventstream (Copay), UAParser (miner, password exfil)
● Comment your code - explain what you intend to do before you forget

9. Security “Audit” Top Tips - Make it Easy
● Pick a reputable vendor - review published audit reports
● Schedule audit early
○ Best vendors can be booked up months in advance
○ Vendor may provide consultation to keep you on the right track
● Clean static analysis / code scanner output
● Documentation
○ Architecture - high level components and interactions
○ Component / function interfaces, param specifications and assumptions
○ Roles and permissions
○ End-to-end flow for major use cases
● Scope
○ Code review
○ Dynamic test - include front end
○ Infrastructure
● Build in time for fixing and retest
● Do not assume audit will identify all vulnerabilities. The buck stops with you.

10. Deployment and Operations
● Verify contract
● Should have at least a basic IR plan
○ Escalation routes, roles and responsibilities
○ Rehearsed playbook to perform rapid response actions
● Bug bounty / responsible disclosure
● Monitor for scams and phishing
● Secure your domain and cloud infrastructure
○ Hardware 2FA secure everything
○ Set up SPF/DMARC/DKIM for your domain to prevent email spoofing
● Move to multisig wallet
● Be aware of centralization risks
○ Moxie - My first impressions of web3

11. Advanced Cryptography (aka Moonmaths)
● Zero Knowledge Proofs
● Homomorphic Encryption
● Multi-party computation
● Avalanche Subnet?
● Can achieve really cool privacy-preserving
objectives
○ Deciding who’s the biggest whale without revealing their
wealth (millionaire’s problem)
○ Anonymous KYC, Decentralized-ID
○ Threshold Signature
● Not mature, only for experimentation or expert use

12. Takeaway
● Be responsible - consider the security of your project from Day 1.
Understand and mitigate your risks.
● Be documented - make security audit easy
● Be open - publish and verify your source code, documentation and audit
reports to provide security assurance to your users
● Be prepared - assume something will go wrong, monitor for attacks and
have a plan for it