Smart Contracts in Production: What I Learned Building an NFT Marketplace

Before building an NFT audio marketplace, my mental model of deployment risk came from web backends: ship carefully, monitor, roll back if needed. Ethereum deleted the last step. A deployed contract is immutable — every bug is permanent, every funds-handling mistake is potentially unrecoverable, and "we'll patch it Monday" is not a sentence that exists. Building and deploying ERC721 and ERC1155 contracts under those rules changed habits I've kept ever since.

Standards first, creativity never

The marketplace needed unique audio pieces (ERC721) and editioned releases (ERC1155). The single best decision was treating OpenZeppelin's audited implementations as the foundation and keeping our custom logic — minting rules, royalty handling, marketplace escrow — as thin extensions on top. In most software, novel code is an asset. In contracts, every novel line is attack surface. The expensive exploits in this space overwhelmingly live in bespoke logic that reimplemented something a standard already did safely.

Testing like the rollback doesn't exist

• ▸Unit tests against a local chain (Truffle + Ganache at the time) for every state transition — including the ones that must fail: double-mints, unauthorized transfers, reentrant calls.
• ▸Adversarial tests as first-class citizens: we wrote tests that attempted the exploits we could imagine — reentrancy on withdrawal, integer edge cases on royalty math, front-running the listing flow.
• ▸Full deployment rehearsals on a public testnet, including the multi-sig ceremony, gas estimation under realistic state, and the Web3.js integration path end-to-end.
• ▸An external review of the final bytecode-generating source. Fresh eyes on immutable code is not optional overhead; it's the last line.

The mindset shift: on a web backend, tests raise confidence. Here, tests are the deployment safety net in its entirety. We treated a deploy like a hardware tape-out — a date you prepare for, not a button you press.

Gas is a product constraint, not an optimization

Every storage write costs users real money at unpredictable prices. That reshaped the architecture: metadata and audio lived off-chain (IPFS) with the contract storing only hashes; batch operations used ERC1155's native batching rather than loops of single transfers; and anything computable off-chain stayed off-chain. The discipline resembles embedded programming more than web development — you count bytes and writes, because your users pay for them per operation.

The dApp boundary is where users get hurt

Most user-facing failures weren't contract bugs — they were the Web3.js/MetaMask integration layer: dropped transactions the UI treated as failures (they later succeeded — double-mint risk), chain reorgs briefly rewriting recent history, users on the wrong network signing no-ops. The frontend has to model transaction state honestly: pending is a real state that can last minutes, confirmed-once is not confirmed, and every action the UI offers must be safe to submit twice. Idempotency again — the same discipline as Celery tasks, with higher stakes.

What carried over to my non-blockchain work

• ▸Design reviews now ask "what if we could never patch this?" — a clarifying question even when you can.
• ▸Adversarial test cases (not just happy-path and error-path) became standard in my API test suites.
• ▸State machines for anything money-adjacent, with explicit handling for the in-between states.
• ▸Deep respect for boring, audited, standard implementations over clever custom ones.