Smart Contract Development
Solidity contracts designed for gas efficiency and safety, with full test coverage, fuzzing, and audit preparation before anything touches mainnet.
What we build
Full-stack Ethereum development
From contract architecture to the frontend your users touch, one senior team owns the whole build.
DeFi and Protocol Engineering
AMMs, lending markets, staking, and vault systems. We model the economic mechanics and the attack surface, not just the happy path.Tokens and NFTs
ERC-20, ERC-721, and ERC-1155 implementations with the mint, vesting, and access logic your model requires, built on audited standards like OpenZeppelin.dApp Frontends
Production web applications with wallet connection, transaction handling, and clear failure states, so users trust the interface as much as the contracts.L2 and Scaling
Deployments on Arbitrum, Optimism, Base, and other rollups, plus cross-chain messaging and bridging strategies chosen for your cost and latency targets.Audits and Upgrades
Code review of existing contracts, audit remediation, and safe upgrade paths using proxy patterns with disciplined governance around admin keys.
How we work
A process built for code that handles money
(4)- 1
Discovery and threat modeling
We define what the protocol must do, who can call what, and how it could be attacked or drained. Security assumptions are written down before code is. - 2
Architecture and spec
You get contract architecture, upgradeability decisions, and gas budgets in a reviewable spec, so audits and integrations are planned rather than improvised. - 3
Build and test
Development in short cycles with unit tests, fork tests against mainnet state, and fuzzing. You see working testnet deployments throughout, not at the end. - 4
Audit, launch, support
We prepare the codebase for external audit, remediate findings, run the mainnet deployment, and stay on for monitoring and iteration after launch.
Why Webisoft
Ethereum engineering without the agency roulette
Smart contract bugs are permanent and public. We staff Ethereum work with senior engineers and treat security as the core deliverable, not a line item.
Senior North American team
Your contracts are written by experienced engineers based in North America, in your timezone, who have shipped Ethereum systems to mainnet.Security first
Threat modeling before code, extensive testing including fork tests and fuzzing, and codebases structured so external auditors can do their best work.Full-stack ownership
Contracts, backend indexing, and frontend from one team, so nothing falls between a contract shop and a web agency.Straight technical advice
If your use case does not need a token, or belongs on an L2 rather than mainnet, we will say so. You are paying for judgment, not just Solidity.
FAQ
Questions founders and CTOs ask us
(4)- Scope drives it. A well-defined token contract is a small engagement, while a novel DeFi protocol with audits is a significant multi-month project. The main cost drivers are protocol complexity, the depth of testing and audit preparation required, and whether a frontend and indexing layer are included. A fixed-price discovery or architecture phase at the start is the standard way to turn a rough idea into a concrete quote.
- Contracts that will hold user funds should be reviewed by an independent external auditor, since a team auditing its own code is a conflict of interest. Good practice is to build to an audit-ready standard with full test suites and documentation, submit to a third-party firm, and then remediate the findings before mainnet deployment. Arriving at audit with clean, tested code keeps audit timelines short and findings minor.
- It depends on the users' fee tolerance and the product's need for mainnet liquidity and composability. Many consumer-facing products belong on L2s such as Arbitrum, Optimism, or Base, where transactions cost cents instead of dollars. Products that depend on deep DeFi liquidity or composability with existing mainnet protocols often still deploy on mainnet. The decision is best made during architecture based on fee modeling and integration requirements rather than fashion.
- Yes. The standard entry point is a paid code review covering security, test coverage, and upgrade risk, which produces an honest assessment of the codebase regardless of who continues the work. From there the options are remediation, extension, or a full takeover of ongoing development. For contracts already deployed with value in them, upgrade patterns and migration planning are the key techniques for making changes safely.
Where we add value
Ethereum capabilities beyond writing Solidity
Shipping on Ethereum means making decisions about layers, gas, security, and upgradeability that are expensive to get wrong. These are the areas where our team earns its keep.
Smart contract engineering
We build in Solidity with Foundry and Hardhat, on top of audited primitives like OpenZeppelin rather than hand-rolled versions of solved problems. Contracts ship with full test suites including fuzz and invariant tests, because the checked-in tests are what protect you during every future change, not just the first audit.L2 and rollup strategy
Most new products should not deploy to Ethereum mainnet alone. We help you choose among Arbitrum, Optimism, Base, and other L2s based on fees, sequencer trust assumptions, bridge risk, and where your target liquidity actually sits. The decision is documented with its trade-offs so it can be revisited as the L2 map shifts.Gas optimization that matters
We profile gas per function with realistic state, then optimize where users actually pay: storage layout and packing, calldata size for rollups, minimizing cold storage reads, and choosing errors over require strings. We stop where optimization starts hurting readability and auditability, because unreadable assembly that saves pennies is a bad trade for a contract holding funds.Security and audit readiness
Security is a process, not a final check: threat modeling at design time, static analysis with Slither, invariant testing, and internal review against known exploit classes like reentrancy, oracle manipulation, and access control gaps. We then prepare the package external auditors need and manage the finding-fix-retest cycle, which measurably shortens audit timelines.Upgradeability and governance
Proxies, UUPS patterns, timelocks, and multisigs each move trust somewhere, and pretending otherwise is how protocols get embarrassed. We design the upgrade and admin key policy alongside the code: what can change, who can change it, and with what delay, then implement it so the on-chain reality matches what your documentation promises users.Full dApp and integration layer
Beyond contracts we deliver the rest of the product: frontends with wagmi and viem, wallet onboarding including account abstraction flows under ERC-4337, event indexing with subgraphs or custom indexers, and backends that reconcile on-chain state reliably despite reorgs. Buyers get one accountable team from contract storage slots to the browser.
Our approach
How we run an Ethereum engagement
(4)- 1
Design and threat model
We begin with the protocol design: contract architecture, token flows, actors and their incentives, and an explicit threat model. Decisions on chain and L2, upgradeability, and oracle dependencies are made here with trade-offs recorded. The deliverable is a design document an auditor can read, which pays for itself when the audit starts. - 2
Build with tests as the spec
Contracts are developed in short cycles with unit, fork, fuzz, and invariant tests written alongside the code, using mainnet forking to test against real deployed protocols you integrate with. Gas benchmarks run in CI so cost regressions are caught per commit. You see the repository and test reports throughout, not a black box. - 3
Audit cycle and hardening
Before any value is at risk, code goes through internal review and static analysis, then a third-party audit that we scope, coordinate, and respond to. Every finding is fixed or explicitly accepted with rationale, and fixes are retested. In parallel we rehearse deployments on testnets with the exact scripts and multisig signers that will run mainnet. - 4
Deployment and live operations
Mainnet deployment runs from rehearsed scripts with verified source on Etherscan, ownership transferred to the agreed multisig or timelock, and monitoring in place for contract events, balances, and anomalous activity. We hand over runbooks including an incident response plan, and can stay engaged for iteration, upgrades, and ongoing protocol work.
FAQ
Questions buyers ask about Ethereum development
(6)- Contract complexity and value at risk drive everything. A token with a staking contract is weeks of work, while a lending protocol or anything with novel economic mechanisms is months, mostly because testing and audit depth must scale with what an exploit would cost. External integrations, oracles, and cross-chain components each add surface area. Audits add both budget and calendar time, since reputable firms book out weeks in advance, and we plan that into the schedule from day one.
- It depends on who pays gas and where your liquidity or users already are. Consumer products with frequent small transactions almost always belong on an L2, where fees are cents rather than dollars. DeFi protocols often need mainnet or the specific L2 where their counterpart liquidity lives. Multichain deployments multiply operational and security burden, especially around bridges, so we usually advise launching on one chain and expanding deliberately once the product is proven.
- An audit is necessary and not sufficient. Audited protocols get exploited when the audit covered different code than what shipped, when scope excluded the integration that failed, or when admin keys were mishandled. Our process treats the audit as one layer: threat modeling, invariant tests, and static analysis come before it, and monitoring, timelocks, and incident response come after. We coordinate the audit itself, manage findings to closure, and make sure the deployed bytecode matches what was reviewed.
- That is a design decision we make together, because upgradeability is a trust trade-off. Immutable contracts maximize user trust but cannot be patched, while proxy patterns allow fixes but mean users trust whoever holds the upgrade keys. Common middle grounds are multisig-controlled upgrades behind a timelock, so changes are visible before they take effect. Whatever the choice, we implement it precisely and document it, because vague answers about admin keys are a red flag for serious users and investors.
- We are engineers, not lawyers, but we build with compliance requirements as inputs. That includes transfer restrictions and allowlists for permissioned assets, sanctions screening hooks, data handling that keeps personal information off-chain, and audit trails your counsel can point to. Token design choices interact heavily with securities analysis in most jurisdictions, so we recommend engaging specialized legal counsel early and we implement whatever constraints they define.
- If you are pre-build, start with the design and threat model phase, typically two to four weeks, which produces the architecture, chain choice, and a costed delivery plan. If you have existing contracts, a code review is the natural entry point and often surfaces issues worth fixing regardless of who does the fixing. Both are fixed-price, standalone deliverables, so you can evaluate the work before committing to a full engagement.
