What does smart contract development actually involve?
Writing the contract is a fraction of it. The work that determines whether the result is safe is specification, testing, review, audit preparation, deployment mechanics, and the operational tooling around the deployed system.
A typical engagement runs through: modelling the mechanism and writing down its invariants; implementing against established standards where they exist; building a test suite that includes fuzz tests over the invariants and fork tests against real mainnet state; static analysis and internal review; freezing the codebase and preparing a threat model for third-party audit; remediation; a rehearsed deployment with verified sources and configured access control; and monitoring plus runbooks so the system can be operated.
The step teams most often skip is fork testing. A contract that passes every unit test can still fail on mainnet because a dependency behaves differently than its documentation says. Testing against real state, real liquidity, and real integrated protocols is what catches that class of problem before an attacker does.
How much does smart contract development cost?
A single standard contract — a token, a vesting or staking contract, an NFT collection — is typically $5K–$15K including tests and deployment. This is well-trodden ground and should be priced like it.
A contract system with custom logic — a vault with a strategy, a launchpad, a tokenized instrument with transfer restrictions — generally runs $20K–$60K depending on how much of the behaviour is genuinely new.
A full protocol contract suite — a DEX, a lending market, a perpetuals venue — runs $60K–$200K as the on-chain portion of a larger build. On our projects, contracts are usually 20–35% of total engineering cost; the indexers, keepers, backends, and frontends around them are the rest.
Third-party audits are separate and are not ours to mark up: $30K–$100K depending on scope and firm. Book the slot early — reputable auditors are months out, and a launch date set without a confirmed audit slot is a date that will move.
How do you test and audit contracts?
Testing happens in four layers, each catching a different class of defect. Unit tests cover intended behaviour and revert conditions. Fuzz tests run randomised inputs against documented invariants — solvency, accounting identities, access control — which is how you find the edge case nobody thought to write a test for. Fork tests execute against real mainnet state and live integrations, catching mismatches between how a dependency is documented and how it actually behaves. Static analysis runs in CI so known bug patterns fail the build rather than the audit.
For third-party audit we prepare properly: the codebase is frozen, invariants and architecture are documented, and a threat model states what we consider in scope and what assumptions the system makes. Auditors reading a moving target find less, and audits of undocumented code spend their first days reconstructing intent you could have handed over.
Our contracts have been audited by Sherlock, PeckShield, and Obsidian across DeFi and NFT-lending protocols. We work with whichever firm you prefer or can get a slot with — we have no referral arrangement and no incentive in that choice.
An audit is not a guarantee and no honest engineer will present it as one. It is one control among several, which is why timelocks, multi-signature admin control, monitoring, and a rehearsed incident path matter as much as the audit report.
Should your contracts be upgradeable?
Upgradeability is a trade-off, not a best practice. A proxy lets you fix bugs and evolve the product; it also means whoever controls the upgrade key can change the rules under your users, which is itself a security assumption and a trust cost.
Our default is minimal upgradeability: immutable core accounting, upgradeable peripheral modules, and any privileged action behind a timelock and multi-signature control so users can see a change coming and exit if they disagree. That gets you most of the flexibility with far less of the trust burden.
Full immutability is right for simple, finished contracts — a token, a vesting schedule — where there is nothing to evolve and immutability is itself the product. Broad upgradeability is right early in a protocol's life when the mechanism is still being learned, and it should be narrowed as the design settles rather than left open by inertia.
The failure mode worth naming: an upgrade key held by a single externally-owned account, with no timelock. It is the most common privileged-access defect we see in reviews, and every user of that protocol is trusting one private key.
What actually matters in gas optimization?
Storage. Reading and writing storage slots dominates the cost of almost every real contract, and the meaningful wins come from packing structs sensibly, avoiding redundant writes, caching in memory inside loops, and not storing what can be derived or emitted as an event.
After that: batch operations so users pay one base cost instead of five, keep loops bounded so a call cannot become unexecutable as data grows, and pick data structures against the access pattern rather than out of habit.
What does not matter as much as internet advice suggests: micro-optimizing arithmetic, aggressive assembly in code that runs rarely, and shaving opcodes off paths users almost never take. These trade meaningful readability and audit surface for savings that round to nothing.
The order is correctness, tests, measurement, then optimization — on the paths users actually take. Optimizing before measuring is how you introduce a bug to save 800 gas on a function called twice a month.
Which chains and languages do you work in?
Solidity on EVM chains is our centre of gravity, and it is where the depth is: Ethereum, Arbitrum, Base, Optimism, Polygon, BSC, plus newer networks including HyperEVM, Blast, Berachain, and Sonic, all with production deployments. Toolchain is Hardhat and Foundry, with OpenZeppelin as the base for standard components.
Beyond EVM: we have shipped Rust work on Solana as part of a cross-chain bridge built on LayerZero, and we engineer Daml contracts for Canton where a permissioned, privacy-preserving ledger is the requirement — see our Canton Network development page, which includes a straight account of where that experience currently stands.
Backend integration is a real part of contract work and often the part that decides whether a system is operable. Ours is ASP.NET with Nethereum plus Node.js services for indexing, event processing, and keeper automation — the infrastructure that turns deployed contracts into a product people can use.
What does Aegas bring to a contract build?
Contracts we wrote are running now and have carried real volume: $22B in platform volume across 8M trades on Privex, $783M cumulative on Nest, and $10M+ in initial mint sales with peak load of 100K users per minute on the Gutter Cat Gang NFT universe during our 2021–2023 engagement.
We have worked inside the major protocol codebases rather than only alongside them — Algebra, Aerodrome, Symmio, Gondi, Uniswap V4, Seaport, LayerZero — and contributed back to Seaport's open-source documentation. That matters because most contract work today starts from an existing design, and the risk lives in the assumptions you inherit without noticing.
We are 16 core engineers, senior-only, most with us for years, working as an outsource partner: we own architecture, delivery, QA, DevOps, and deployment, and hand over a system your team can operate. And we will tell you when a contract is the wrong solution — plenty of things people ask us to put on-chain do not need to be.
