Blockchain & Web3 · Smart contracts
Smart contracts written to survive scrutiny
We write Solidity and Rust smart contracts that are small, readable and heavily tested, then prepare them for an independent third-party audit before they are deployed to mainnet or hold real value.
- Specification before code
- Proven building blocks
- Fuzz and invariant testing
Overview
Writing contracts for a hostile environment
Smart contract development differs from ordinary programming in one important way: the code runs in public, often holds value, and anyone can call it with any input in any order. That changes how the work is done. Requirements are written as precise rules and invariants, designs favor fewer moving parts, and testing tries to break the system rather than confirm that the happy path works. Readability is a security feature, because reviewers can only protect what they understand.
Several decisions shape every contract. Upgradeable proxies allow fixes but introduce an administrator who must be trusted and protected. Immutable contracts earn trust but leave no room for mistakes. Gas optimization lowers user costs but can make code harder to review. Using established libraries reduces risk but brings their assumptions. We recommend a position on each, explain the trade-off in writing, and let you decide with your team.
Good contract work produces code an outside auditor can understand quickly, tests that encode the specification, and a short list of documented assumptions. Desverso is not an audit firm. We recommend an independent third-party audit before mainnet or before contracts hold real value, prepare the package auditors need, and fix and re-test their findings.
Who it’s for
Built for teams like yours
- 01
Teams with a clear specification
Product and protocol teams that know what the contract must do and need careful engineers to implement, test and prepare it for an independent security audit.
- 02
Projects preparing for audit
Teams with existing contract code that lacks tests, documentation or a specification, and who want it made reviewable before paying an auditor to look at it.
- 03
Businesses tokenizing a process
Companies encoding a business rule on-chain, such as access, attestations or escrow, that need the logic kept small, explicit and easy for their advisers to understand.
Why it matters
Code you cannot quietly patch later
Deployed contracts are public, permanent and often hold value, so mistakes are expensive and visible. We favor simple designs, well-reviewed libraries such as OpenZeppelin, and explicit invariants that tests can check. Every function is written assuming someone will try to misuse it, because on a public network someone eventually will.
Testing is our job; independent auditing is not. Desverso is not an audit firm, so we recommend a third-party audit before mainnet, prepare everything the auditors need and fix what they find.
Every engagement includes
- Requirements & specroles, flows and invariants agreed in writing before development starts.
- Contract developmentSolidity or Rust code following established security patterns.
- Test suiteunit, integration, fuzz and invariant tests delivered with the code.
- Audit packagespecs, test reports and known limitations prepared for an independent auditor.
- Remediationfixes for audit findings, with each change re-tested and documented.
- Deployment & handoververified source on block explorers, deployment scripts and key procedures.
Features
Our contract practice
- 01
Specification before code
A written spec of roles, states and invariants that tests, auditors and your team can all check against.
- 02
Proven building blocks
Audited libraries for tokens, access control and upgrades instead of hand-rolled versions of solved problems.
- 03
Fuzz and invariant testing
Foundry or Hardhat suites that hammer contracts with random inputs to find edge cases early.
- 04
Static analysis
Tools such as Slither run on every change to catch common vulnerability patterns before review.
- 05
Gas-aware design
Storage layouts and logic tuned so routine actions stay affordable without sacrificing readability.
- 06
Admin key controls
Multi-signature ownership, timelocks and pause functions designed so no single key can cause harm.
In practice
Contracts we are asked to write
Access and membership logic
Contracts that issue, check and revoke membership or access rights, with clearly defined roles for who can grant and remove them, and events that off-chain systems can follow reliably over time.
Multi-party approval workflows
Contracts that require sign-off from several named parties before an action executes, with timelocks, cancellation paths and an on-chain history showing exactly who approved what, and when they did it.
Vesting and scheduled releases
Contracts that release tokens or rights to recipients on an agreed schedule, with cliff and revocation rules defined in writing. Securities and tax treatment are settled by your legal advisers.
Registries and attestations
Contracts that record attestations, certificates or approvals issued by known parties, with revocation, expiry and issuer key rotation built in so the registry stays accurate as the organizations involved change.
Process
How we work
- 1
Specification
We write a plain-language spec listing every role, function, state transition and invariant, plus what the contract must never allow. You approve it before a line of Solidity or Rust is written.
- 2
Threat review
We walk through the likely attacks for this particular design, such as reentrancy, price manipulation, signature replay and privileged-key compromise, and record how the code will prevent or limit each one.
- 3
Implementation
We write small, commented contracts on established libraries, keeping admin powers minimal and explicit, and add NatSpec documentation so that reviewers and integrators can follow the intent of every function.
- 4
Adversarial testing
Unit tests cover expected behavior; fuzz and invariant tests hammer the contracts with random call sequences; static analyzers flag known risky patterns. Coverage reports and findings all go into the audit package.
- 5
Audit & deployment
Your independent auditor reviews the code and we fix and re-test each finding. We then deploy with scripted, reproducible steps, publish verified source, and place admin keys in a multi-signature wallet.
Deliverables
What you receive
- Approved specification with written invariants
- Threat review notes for the design
- Commented contract source with NatSpec
- Unit, fuzz and invariant test suites
- Static analysis and coverage reports
- Audit package and remediation log
- Reproducible deployment scripts and verified source
Tools & methods
Languages & frameworks
- Solidity
- Rust
- Vyper
- Anchor
- OpenZeppelin Contracts
Testing
- Foundry
- Hardhat
- Echidna
- Medusa
- Invariant testing
Analysis & ops
- Slither
- Aderyn
- Tenderly
- Safe multisig
- Etherscan verification
FAQ
Frequently asked questions
Anything else about Smart contracts? Ask us directly.
No. Desverso builds and tests contracts but does not act as an auditor. Before mainnet we recommend an independent third-party audit, because a separate team catches what the authors miss. We help you shortlist firms, prepare the audit package and fix the findings they report.
Let’s work together
Have a project in mind?
Book a strategy call and we’ll show you exactly how to turn your goals into a system that generates consistent results.