Smart contracts have been around for a while now and drive billions in transactions every day, yet the fact is that smart contract and dApp development requires a specific mindset. Part of it is obviously shared with other software specializations, but the restrictions inherent to smart contracts require us to insist on specific qualities that don’t always get enough attention.
The adversarial default
In most software, we build for users who are trying to accomplish something, and our job is to make that work well. Smart contracts operate in a fundamentally different context because every external call is an opportunity for someone to extract value, and they’ll approach it with unlimited time, capital, and creativity. This changes what we need to care about when writing and testing contract code.
Consider a simple vault: the deposit function handles deposits, the withdrawal function handles withdrawals, and the tests confirm both work as expected. But what we actually need to think about is what happens when someone calls withdraw before the state update from their deposit has settled, or when a flash loan lets an attacker temporarily hold enough governance tokens to pass a proposal and drain the treasury within a single transaction. 62.1% of price manipulation attacks in major DeFi hacks involved flash loans, and that kind of attack doesn’t show up in any test suite that only validates the intended usage path, because the intended path isn’t where money goes missing.
This is why threat modeling needs to happen before writing code rather than during auditing. We define invariants that must hold regardless of call ordering (total withdrawn can never exceed total deposited, token supply stays constant across any transfer) and then spend testing effort trying to break them, because if we don’t find the violation, someone with a flash loan and more patience will.
Your contract is a backend
We tend to think of the smart contract as just the on-chain piece that holds funds and enforces rules, but in any real application it ends up owning business logic, state transitions, access control, and settlement. The frontend needs data it stores, the backend reacts to events it emits, and the monitoring system watches for state changes that signal trouble, so the rest of the architecture inevitably bends around what the contract can and can’t do efficiently. In practice we’re designing a backend system that happens to be immutable and expensive to operate.
The general principle is to keep only the trustless minimum on-chain (balances, ownership, permissions, protocol parameters) and push everything else off-chain. That sounds straightforward, but deciding where that boundary actually falls is one of the harder architectural calls we have to make since it determines gas costs, query capabilities, and how much off-chain infrastructure we need to build just to make the product usable.
How you get data out shapes everything else
There are three ways to read data from a smart contract, and each one shapes the rest of the application architecture in ways that are hard to change later. Direct RPC queries give sub-second reads of current state, but current state is all we get, so any kind of history or aggregation is off the table. Event indexing is cheap to emit on-chain (Vitalik has called logs “a cheap way to store data that is not part of the state”) but building an indexer that handles chain reorgs without corrupting its database is a project unto itself. The Graph handles the reorg complexity for us but introduces query fees at scale and subgraph update delays we can’t control.
Getting this wrong tends to surface mid-development, when the frontend needs historical transaction data that RPC can’t provide, or when an indexer silently drops events during a reorg and nobody notices until users report wrong balances. It’s not a backend concern we can defer to later since it determines what the product can actually show its users.
Two sources of truth, one of them lying
The moment we have both on-chain state and an off-chain database, they can disagree, and at some point they will. The blockchain says a user has 500 tokens, the database says 450 because the indexer is behind, and the frontend shows whatever it happens to query first. Event-sourced synchronization is the safest approach here: the database only updates in response to confirmed on-chain events, never the other way around, so the blockchain stays authoritative and the off-chain layer converges toward it over time.
The problem is that “over time” can mean seconds or minutes, and during that window the database is stale, which means users might see balances that don’t reflect their latest transaction or attempt actions the contract will reject. Chain reorgs compound this because a reorg invalidates events the indexer already processed, leaving the database with state derived from transactions that no longer exist. If the indexer doesn’t detect and roll back those phantom events, it silently corrupts, and rebuilding from scratch takes hours.
Immutability is the constraint, not the feature
A deployed contract can’t be patched. There are ways around this (proxy patterns, and some chains even allow direct contract upgrades) but none of them are cheap or fast, because pushing a new version on-chain typically means a new audit. That means allocating resources, paying a sometimes hefty fee, and working around audit team availability, which can take weeks even for a small change. And even if the change itself is minor, it can bubble up and impact behavior in dependent contracts that were built against the original interface, which brings its own round of verification. We haven’t even mentioned state migrations yet: if the new implementation changes how storage is structured, existing data needs to be migrated without corrupting it, and getting that wrong on an immutable chain is not something we can undo.
When something breaks and you can’t redeploy
Since we can’t just push a fix, we need incident response mechanisms in place before anything goes wrong, because we can’t build them after the fact.
Pause mechanisms let authorized actors halt protocol functions while the team investigates, but “pause” immediately raises the question of what exactly we’re pausing. Take a DeFi protocol with liquidity pools: do we pause the whole protocol, or just the affected pool? Do we prevent new deposits, or also block withdrawals? Blocking withdrawals protects against further damage but also locks users out of their own funds, which creates its own kind of crisis. Function-level parameter limits (tightening borrowing ratios, capping withdrawal amounts) offer finer control without freezing everything, but they require having thought through which knobs to expose before the incident happens. Proxy patterns let us deploy new logic behind the same address, but a storage layout mismatch between implementations corrupts contract state, and a compromised admin key on the pause mechanism turns our safety net into an attack vector, so every layer of protection is also a new surface we need to secure.
The process around these mechanisms matters just as much as the mechanisms themselves. Organizations like Lido, Curve, and Matter Labs run security councils with multisig controls and timelocked operations, maintain incident playbooks with escalation procedures, and drill their response regularly because having the technical ability to pause a contract doesn’t help if it takes three hours to figure out who’s authorized to trigger it.
Where this leaves us
All of these points come back to the same quality: smart contract development requires treating failure as a first-class design concern. The indexer will fall behind, data sources will disagree, someone will find the call sequence we didn’t test, and at some point we’ll need to fix something that can’t be fixed in place. The teams that build protocols people trust with real money are the ones who have thought through those scenarios before deployment, not out of pessimism but because the alternative is learning the answers in production, at someone else’s expense.