Smart Contract Standards
What makes a smart contract trustworthy — the language it's written in, or the years it has survived?
A hyperlink says "go here." A smart contract says "if this condition is met, value flows here, verified on-chain." The contract is only as good as the standard behind it. Three platforms, three philosophies of what "standard" means.
Three Philosophies
| Platform | Standardizes The | Approach | Trust Source |
|---|---|---|---|
| EVM | Interface | Define the shape (ERC-20), let anyone implement | Community battle-testing |
| SVM | Program | One shared implementation (SPL Token), everyone calls it | Foundation maintenance |
| Move (Sui) | Language | Compiler-enforced ownership, capabilities, linear types | Structural impossibility |
Each philosophy produces a different trust profile. EVM trust comes from survival — thousands of deployments, billions at stake, years of exploits hardening the patterns. SVM trust comes from centralization — one canonical program, foundation-audited. Move trust comes from prevention — the compiler rejects entire vulnerability classes before deployment.
The full comparison: Smart Contracts.
Standard Fittings
In P&ID: you do not build your own pressure relief valve. You specify an ANSI-rated assembly by code. Smart contract standard fittings work the same way — audited, composable building blocks you compose rather than create.
Lindy Effect
The Lindy Effect: the longer a non-perishable thing survives, the longer its remaining life expectancy. Every year a standard fitting goes without exploit extends its expected trustworthiness. Time is the audit that never ends.
| Library | Platform | Lindy Age | What It Provides |
|---|---|---|---|
| OpenZeppelin | EVM | 2016 — 10 years | Token standards, access control, proxy upgrades, governance |
| Solady | EVM | 2022 — 4 years | Gas-optimized alternatives to OpenZeppelin |
| Solmate | EVM | 2021 — 5 years | Minimalist, gas-efficient primitives |
| SPL Token | SVM | 2020 — 6 years | Canonical fungible/non-fungible token program |
| Anchor | SVM | 2021 — 5 years | Framework-level account validation, IDL generation |
| OpenZeppelin Sui | Move | 2025 — new | Access choreography (two-step, time-locked), safe math |
OpenZeppelin arriving on Sui is the maturity signal. Language-level safety handles objects and ownership. It does not handle access choreography or overflow-safe arithmetic. Even Move needs standard fittings.
Fitting Catalog
| Fitting | Library | P&ID Equivalent | What It Does |
|---|---|---|---|
ERC20 | OpenZeppelin EVM | Flow meter | Fungible token interface — balance tracking, approvals, transfers |
Ownable | OpenZeppelin EVM | Manual interlock | Single-owner access control |
ReentrancyGuard | OpenZeppelin EVM | Safety relief valve | Prevents recursive call exploitation |
two_step_transfer | OpenZeppelin Sui | Two-key interlock | Ownership handoff requires initiate + accept |
delayed_transfer | OpenZeppelin Sui | Time-delay relay | Time-locked wrapper with enforced minimum delay |
mul_div | OpenZeppelin Sui | Flow computer | (a * b) / c without intermediate overflow |
u512 | OpenZeppelin Sui | Extended-range gauge | 512-bit math prevents precision loss in tokenomics |
In A&ID nomenclature: standard fittings are instruments. Code: SF — Standard Fitting. Reading: DA-SF01 = Digital Agent using Standard Fitting #1.
Development Paths
| Path | Mental Model | Standard Fittings | Time to Productive |
|---|---|---|---|
| EVM Development | Global state + msg.sender | Deepest — OpenZeppelin, Solady, Solmate | Weeks |
| Solana Development | Accounts + PDAs + CPIs | Growing — SPL Token, Anchor, Metaplex | Months |
| Sui Development | Objects + ownership + capabilities | Emerging — OpenZeppelin Sui, native patterns | Weeks |
Safety Comparison
Which vulnerabilities does each platform prevent by design versus by convention?
| Vulnerability | EVM | SVM | Move |
|---|---|---|---|
| Re-entrancy | Standard fitting (guard) | Runtime (CPI depth) | Impossible (no recursion) |
| Asset duplication | Standard fitting (accounting) | Runtime (slot checks) | Impossible (linear types) |
| Integer overflow | Language (Solidity 0.8+) | Partial (debug only) | Always (bytecode verifier) |
| Access control | Standard fitting (modifiers) | Convention (signer checks) | Structural (capabilities) |
Where the platform prevents it structurally, no standard fitting is needed. Where it doesn't, the fitting IS the standard. This is why OpenZeppelin is Lindy on EVM — it fills gaps the language leaves open.
Auditing
| Tool | Platform | What It Does |
|---|---|---|
| Slither | EVM | Static analysis — detects common vulnerabilities |
| Echidna | EVM | Property-based fuzzing |
| Certora | EVM | Formal verification (commercial) |
| Move Prover | Move | Formal verification (built-in, free) |
| Metamorphic | EVM | Metamorphic contract detection |
| SCSFG | EVM | Security field guide |
Contract Tooling
Indexed repositories for finding existing contracts:
- cookbook.dev — Search and deploy verified contracts
- codeslaw.app — Search deployed contract source code
- reactive.network — Reactive smart contracts
- thirdweb — Pre-built contract suite
- base-org/contracts — Base L2 contracts
- nftstandards.wtf — NFT standard reference
DeFi Primitives
Production protocols as reference implementations:
| Category | Protocols |
|---|---|
| AMMs | Uniswap v3, Curve, Balancer v2, 1inch |
| Lending | Aave v3, Compound, dYdX |
| Derivatives | Opyn, Vega, PsyOptions |
| Insurance | Nexus Mutual |
| Yield | Yearn, Enzyme |
| Prediction | Polymarket, Augur |
| Solana DeFi | Drift v2, GooseFX, TWAMM |
Starter Kits
- Cyfrin Foundry Dev-Ops — EVM development toolkit
- BuidlGuidl/scaffold-base — Base L2 starter
Context
- Smart Contracts — Full platform comparison: safety, speed, composability, ecosystem
- A&ID Template — Standard fittings as instruments in the agent nomenclature
- Hacker Laws — Lindy Effect: survival compounds trust
- Standards — Why standards compound quality without requiring heroes
- Protocols — Algorithms decide; protocols handshake; contracts execute
- DeFi Tokens — Token economics behind the primitives
- Knowledge Stack — Primitives, protocols, standards, platform
- Developer Experience — DX as northstar for adoption
Links
- OpenZeppelin EVM — The Lindy standard library
- OpenZeppelin Sui — Standard fittings arrive on Move
- Solady — Gas-optimized EVM primitives
- Solmate — Minimalist EVM building blocks
- Anchor — Solana framework with account validation
- Alchemy Tools — EVM tooling directory
- SCSFG — Smart Contract Security Field Guide
- Cyfrin Updraft — EVM development course
- Renascence Labs — Audit report examples
- Colony Network — DAO contracts reference
- NBA Top Shot — Gaming NFT reference
- PatrickAlphaC/rwa-creator — Real-world asset tokenization
Questions
Does the chain with the oldest audited library always win on trust — even if a younger chain is structurally safer?
- If standard fittings get safer with age (Lindy), what happens when a vulnerability is found in a 10-year-old pattern — does the trust reset or does the fix compound it?
- OpenZeppelin fills gaps the language leaves open. If Move closes those gaps structurally, does OpenZeppelin on Sui become redundant — or does it solve a different class of problem?
- Which DeFi primitive is most overdue for a standard fitting that doesn't exist yet?
- At what point does a standard fitting become too trusted — where its presence replaces thinking about the actual security model?