01
New projects
A paragraph about the problem is enough to start. We reply within two working days, usually with questions rather than a quote.
Blockchain · Service Smart contract development
Solidity and Rust smart contracts with invariants written before the code, readable Foundry tests, fuzzing, and admin keys under multisig and timelock.
In short
A smart contract is a program deployed on a blockchain that holds assets and enforces rules without an operator. Once deployed it is public and hard to change, so mistakes are expensive. We write contracts in Solidity and Rust with the rules stated as invariants before the implementation, a test suite another engineer can read, and administrative powers split across more than one key.
- How to engage
- Product build, Security review
- Practice
- Blockchain
Signs this is the right service
- You are launching a token, a protocol or an on-chain product and the contract will hold real value.
- An existing contract needs new behaviour and nobody is sure the change is safe.
- An auditor is booked and the code needs to arrive in a state worth auditing.
- Admin control sits with one key and that needs to change.
What you get
Specification and invariants
What must always be true — balances sum to supply, only these roles may do that — written down before any code.
Implementation
Solidity or Rust built on audited libraries where they exist, with custom logic kept small and clearly separated.
Tests, fuzzing and coverage
Foundry unit tests, invariant tests that attack the stated rules with random inputs, and coverage reported honestly.
Access control
Roles separated, privileged actions behind a multisig and a timelock, and an upgrade path that is deliberate rather than accidental.
Deployment and verification
Scripted, repeatable deployments, source verified on the explorer, and a runbook for the first hours after launch.
The process
- 01
Write the rules
The specification and invariants are reviewed with you before implementation starts.
- 02
Build with tests alongside
Every function arrives with its tests; invariant tests run from the first week.
- 03
Internal adversarial review
An engineer who did not write the code tries to break it.
- 04
External audit and launch
We prepare the code for an independent audit, fix the findings, and deploy in stages.
SolidityRustFoundryOpenZeppelinSafeSlitherEchidna
Smart contract development: common questions
Which chains do you build on?
- Ethereum and EVM-compatible networks, including the main layer-2 rollups, in Solidity; and Rust-based chains where the project calls for it. The choice follows your users and liquidity, not our preference.
Should the contract be upgradeable?
- Only if you can state who may upgrade it, how users are warned, and what happens to the upgrade keys over time. Upgradeability is a power, and it needs the same care as the contract itself.
Do we still need an external audit?
- Yes, for anything holding meaningful value. Our internal review reduces what an auditor finds; it does not replace an independent team with no stake in the code.
Who owns the code and the keys?
- You do, from the first commit. Contracts are deployed from your accounts and admin roles are held by your signers.
06 / Let’s build
Bring us the difficult problem.
02
Careers
Engineers, designers and researchers who like systems that are hard to get right. Send something you built and what you would change about it now.
03
Studio
Based in India and working remotely, with overlap hours agreed up front so your team always has a time to reach us.
04
Read
Guides on AI agents, RAG, MCP, tokenization and chain abstraction, written by the engineers who build them.