TECHNOLOGIES

Smart Contract

Code that runs on a blockchain, executes deterministically, and cannot be changed once deployed (unless you designed it to be).

Last reviewed: byKevin Riedl wiki ↗

A smart contract is a program deployed to a blockchain. Once deployed, its bytecode is immutable, its state is publicly readable, and its execution is governed by consensus rules that nobody can override. That permanence is the feature and the risk: a bug in production is a bug forever, unless you built upgrade machinery in (which itself is a vulnerability surface).

Most production smart-contract systems are not a single contract but a set of them: a proxy for upgradeability, an implementation contract for the logic, often an access-control contract for governance. The pattern is familiar to anyone who has built versioned APIs; the cost of getting it wrong is higher.

Worked example of why the deployment discipline differs from normal software: ship a bug in a SaaS backend and you patch it and redeploy in an hour. Ship a reentrancy bug in a contract holding user funds and an attacker can drain it before you can react, because there is no rollback and the value is live from block one. This is why the question is not “should we audit” but “how do we structure upgrades safely”. The usual answer is a proxy pattern behind a timelock and a multisig: immediate upgrade authority is a single point of failure, no upgrade path leaves you stuck with the first bug, and timelocked upgrades transparent to users is the middle ground most production systems converge on.

The honest trade-off and common founder mistake: founders treat the contract like a feature and the audit like an optional line item. For any contract holding non-trivial value, the audit is the cheapest insurance you will ever buy, usually 1 to 2 weeks of the build budget against the entire value at stake. Wavect writes smart contracts in Solidity for EVM chains and Rust for Solana, Near, and ICP, and the language is downstream of which chain your web3 use case demands, not a preference. We recommend a third-party audit before mainnet on anything that matters, and we have shipped audited contracts to production. Skipping the audit is how teams learn this the expensive way.

// FAQ

FAQs

For any contract holding non-trivial value: yes. The audit cost is usually 1 to 2 weeks of the build budget. Skipping it is one of the cheapest ways to lose all of the value the contract is holding. Insurance and bug bounties are complements, not substitutes.
Solidity for EVM chains (Ethereum, Polygon, Arbitrum, Optimism, Base). Rust for Solana, Near, and ICP. The choice is downstream of which chain matches your use case; the language is a constraint, not a preference.
Proxy pattern with a timelock and a multisig on the admin keys. Immediate upgrade authority is a single point of failure; no upgrade path leaves you stuck with the first bug. The middle ground (timelocked upgrades, transparent to users) is what most production systems converge on.