Smart contract development: what changes when the code holds the money
Smart contract development is the practice of writing programs that run on a blockchain and custody real value. Unlike a backend, the deployed code cannot be patched, its entire state is public, and anyone in the world can call it. Those three constraints change every engineering decision that follows.
Why it is not backend development
In a normal service you ship, discover a bug, and deploy a fix in the afternoon. On-chain there is no afternoon. The bytecode is immutable once deployed, so a mistake is permanent unless you designed an upgrade path before launch. There is no private data either: variables marked private are only invisible to other contracts, never to someone reading the chain.
And the threat model is inverted. A web backend assumes most traffic is legitimate. A contract holding funds assumes the opposite: every caller is an adversary with a financial incentive to break it, and the exploit is worth exactly as much as you hold.
The stack, and why
- Solidity on Ethereum, its L2s and sidechains — the largest ecosystem of audited, battle-tested primitives. We build on OpenZeppelin Contracts rather than reimplementing standards like ERC-20. Rewriting a token from scratch is not craftsmanship, it is a new attack surface.
- Solana when throughput and fees dominate the design — a different account model and a different set of trade-offs. See the Solana docs.
- Foundry for testing, because tests written in Solidity itself can fuzz and fork mainnet. The Foundry Book is the reference.
- Language reference: Solidity documentation.
Choosing the chain is a business decision
| If what matters is | Reasonable choice |
|---|---|
| Composability, liquidity, institutional trust | Ethereum L1 |
| Same ecosystem, low fees | An L2 (rollup) |
| High throughput, cheap frequent transactions | Solana |
| Control, privacy, regulated environment | Private or permissioned chain |
We have built on the last one too: a private blockchain that anonymized transactions for a fintech, and a carbon credit offsetting platform for a Swiss bank.
"Finished" means tested against an adversary
Unit tests only prove the contract works when used correctly. That is the easy half. What matters is fuzzing (thousands of random inputs looking for a case you did not imagine), invariant testing (properties that must hold no matter the sequence of calls — total supply never exceeds the cap, no user withdraws more than they deposited), and fork testing against real mainnet state with real protocols.
Audit is not the last phase
Reviewing security the week before launch means finding architectural problems when they are most expensive to fix. We audit while we build, and we built Basalt for it: an open-source purple team of AI agents that proves each finding by reproducing the exploit in an isolated sandbox, instead of producing a list of maybes.
Contracts we did not write, we audit as an external service. Code that handles real money gets reviewed before it ships — ours included.