Smart Contract Development
A smart contract is code that holds money, cannot be quietly patched, and is readable by anyone looking for a mistake. That changes how it should be written. Zelpex builds contracts with the caution the medium demands — small surface area, established patterns, heavy testing, and an external audit before anything of value is at stake.
We write and review contracts in Solidity and Rust, covering tokens, vesting, escrow, staking, royalties and access control. We also audit contracts written elsewhere, which is frequently how engagements start: a team is close to launch and wants a second pair of eyes before the deployment becomes irreversible.
- Solidity and Rust contracts using established, audited patterns
- Test suites with fuzzing and adversarial cases, not just happy paths
- Upgrade strategy, admin key policy and emergency stop decided up front
- Audit preparation and remediation, including reviews of third-party code
Specify the rules exactly
Who may call what, under which conditions, with which limits — written as a specification before implementation, because ambiguity in a contract specification becomes an exploit in a deployed one.
Keep the surface small
Less code on chain means less to get wrong and less to audit. Anything that does not need to be trustless goes off chain, where it can be fixed on a Tuesday.
Test adversarially
Unit tests, property-based tests and fuzzing, plus explicit cases for reentrancy, overflow, access control and the sequence nobody expects. We assume someone is paid to break this.
Audit before value arrives
External audit, then remediation, then deployment with limits in place. An audit booked after launch is a report about money already at risk.
What teams ask us about smart contracts
It is a genuine trade-off. Upgradeability lets you fix bugs but introduces an admin key, which is itself a target and a trust assumption users can reasonably object to. For contracts holding significant value we favour immutable code with a well-tested migration path over a proxy nobody has stress-tested.
If the contract will hold value that matters, yes, and our own testing is not a substitute. We prepare for it — clean code, documented invariants, full test coverage — which makes audits cheaper and faster, but the independent review is the point precisely because it is independent.
Yes, and it is a good share of this work. We look for the standard failure classes and, more usefully, for logic that does not match what the team believes it does. That mismatch is more common than exotic exploits and is often what an audit surfaces first.
Why the caution
Contract bugs are not incidents you patch quietly on Monday. They are public, permanent and frequently expensive.
We use established libraries rather than writing primitives ourselves, keep on-chain logic minimal, and document invariants so an auditor can check intent against implementation. If a deadline does not leave room for an audit, we will say that the deadline is the problem.
Thinking about a project like this?
Tell us what you are building and what is getting in the way. You will get an honest read on scope, approach, and whether we are the right team for it — including when the answer is that you do not need us.
Services that pair well with contract work
Adobe Commerce Integration
Enterprise-grade e-commerce solutions with Adobe Commerce (Magento). Full integration, customization, and ongoing support for scalable online stores.
BigCommerce Development
Build and scale your online store with BigCommerce. Custom themes, integrations, and performance optimization for growing businesses.
Shopify Commerce Development
Custom Shopify stores, theme development, and app integrations. From startups to enterprise with Shopify Plus solutions.