Preventing Hacks with Security Rules Written in Solidity
summary
Phylax Credible Layer uses Solidity to express runtime assertions as Foundry-style fork tests that run during each state transition and can parallelize because they are atomic and read-only. A validator sidecar executes those assertions and drops transactions that violate rules, preventing attacks before blocks finalize. Example: a Balancer rule forbids K-factor changes greater than 3x in one call, a heuristic that stopped a class of exploits. Tradeoffs include leaking heuristics and needing application-specific sequencers for liveness versus security.
AI-written summary · about
chapters (10)
- 0:00Solidity security rules intro
- 1:28Beyond smart contracts
- 3:15Monitoring to fork tests
- 5:24Fork tests enforce invariants
- 7:12Hack prevention with assertions
- 8:18Balancer invariant checks
- 10:24Summary and Q&A
- 11:05Public invariant checks security
- 13:11Validator adoption and dropping
- 14:56Invariants scope and op-code checks
related talks
23mUsing LLM Generated Formal Specs to Prevent the Next DeFi Hack
20mSolidity's most common security pitfalls and its best safeguards
22mA Multi-Layer Dynamic Security Framework for DeFi Smart Contracts
01h 00mAI Safety through Programming?
21mFrom High-Level DeFi Properties to Concrete Security Bugs
38mBuilding Secure Systems in Haskell
28mSolidity Best Practices - 10 Tips
10mRuntime Assertions New Paradigm for Customized Contract Security