How Type-Driven Development Can Turbocharge your Contract's Security
summary
Argues that swapping primitive returns for explicit types stops common footguns: for example ECRecover’s sentinel address zero becomes a non-zero address type so the compiler forces checks instead of runtime mistakes; using units-as-types prevents swapping token A and B at compile time; practical pitfalls include Solidity treating custom types as aliases at ABI level (so address zero can still slip through), struct gas and boilerplate costs, and lack of a standard library. Announces Sensei language aiming for 500 ms worst-case compile, standard lib, editor tooling and a closed beta on Telegram; language is under active development, not production-ready.
AI-written summary · about
chapters (9)
- 0:00Introduction to speaker
- 0:47The challenge of security
- 1:27Type-driven design patterns
- 5:26Case study: Math with units
- 8:13Case study: Ownership
- 9:39Applying TDD concepts
- 11:50Limitations in Solidity
- 12:47Introducing Sensei language
- 19:51Q&A session
related talks
22mThink you know TypeScript? Think again.
21mBeyond Type Checking Building Bulletproof TypseScript Applications
20mDon't Break the Contract: Keep Consistency with Full Stack Type Safety
22mReclaiming your sanity: Webpack and Ethereum smart contracts with Typescript
26mNo Time for Types
49mThe Trouble With Types
25mWhy static types in Javascript? — Preethi Kasireddy
15mWhat would Solidity look like if it was built today?