Smart contract development in Solidity and Cairo
A contract that compiles and a contract that holds funds are different artefacts. One wrong assumption in the second is not a bug report, it is a loss, and it is permanent. So we write to a standard built to survive an audit rather than one built to pass a test suite.
Why this work is different
There is no patch after deployment in the sense every other kind of engineering means it. The upgrade and access-control design has to be right on day one, because the version that is live is the version guarding the money.
The environment matters as much as the code. Cairo on Starknet has a proving model that changes what good contract design looks like, so the same mechanism implemented well in Solidity can be the wrong shape there.
How we work
Property-based and invariant testing, fork testing against real state, and a bias toward failing safely. Reverting rather than proceeding on an unexpected input. We write the spec first and the tests against the spec, not against the implementation.
We write the specification and build to it. We do not sign off on our own work, and an external audit is a complement to this, never a substitute we claim to replace.
What that means we build
Protocol contracts. AMMs and exchange logic, token and vault systems, and the mechanism-level code where correctness under adversarial conditions is the requirement. Our founder has shipped contract engineering for onchain trading, including automated market makers and exchange logic, as well as Cairo work on Starknet.
The full contract lifecycle. Specification, implementation, exhaustive testing, and the upgrade and access-control patterns that let a protocol evolve without opening a hole.
Common questions
- Do you write Solidity, Cairo, or both?
- Both. Solidity for EVM chains and Cairo for Starknet. Working across both means we can advise on which environment actually fits a protocol, not just implement in the one we happen to know.
- Is the code audit-ready?
- We write to an audited-grade standard (invariant and property-based tests, fork testing against real state, fail-safe defaults) so the code is built to go into an audit in good shape. We complement external audits. We are not a substitute for one.
- What kinds of contracts do you specialise in?
- DeFi and trading logic in particular. AMMs, order books, vaults, and the mechanism design underneath them, where correctness under adversarial conditions matters most.
Have something hard to build?
Tell us the hard part: the protocol, the client, the mechanism, or the system that has to hold.