Blockchain Development
A blockchain is a shared record that several parties can write to and none of them can quietly alter. That property is valuable in a narrow set of situations and expensive everywhere else.
We write smart contracts and the applications around them. We also spend a good part of first conversations explaining why a project would be cheaper, faster and easier to correct on an ordinary database. If that is the case for yours, you will hear it from us before any money is spent on code.
Blockchain or a normal database?
A ledger may be justified when
- Several organisations must share one record and none is trusted to run it.
- Assets are already on a public chain and your product has to interact with them.
- Anyone must be able to verify the rules without asking your permission.
- The parties accept that published transactions cannot be reversed.
A database is better when
- One company controls the data and the users trust it to do so.
- Records contain personal data that someone may ask you to erase.
- Mistakes have to be correctable by an administrator.
- The goal is an audit trail, which an append-only table with signed entries already gives you.
What we build
Engineering only. Token sales, investment schemes and price promotion are outside what we do.
Smart contracts
Written in Solidity for Ethereum and compatible networks. Standard token and access-control logic comes from widely reviewed open-source libraries instead of being rewritten.
Test suites
Unit tests, fuzz tests and tests against a fork of the live network. These lower the number of defects. They do not replace an audit.
Web and mobile front ends
Interfaces that connect to a wallet, show the user exactly what they are about to sign, and handle rejected or stuck transactions.
Indexing and back end
Services that read chain events into a regular database so that pages load quickly and reports can be run.
Permissioned ledgers
Private networks among known organisations, where the members run the nodes.
What you should know before commissioning a contract
These are properties of the technology, not of any one developer.
Deployed code is hard to change
A defect found after launch cannot simply be patched. Upgrade mechanisms exist, and each one adds its own risk and a party who must be trusted.
Bugs lose money directly
A flaw in a contract holding funds can be exploited by anyone, within minutes, with no way to recover the assets.
An audit is necessary and still not proof
Any contract that holds value needs review by an independent security firm before launch. We do not perform that audit. Audited contracts have been exploited too.
Keys are the weak point
Whoever holds the administrator key controls the contract. We recommend multi-signature wallets and hardware devices, and we never hold your keys.
Regulation varies by country
Tokens may be treated as securities or payment instruments. Whether your plan is lawful is a question for your lawyer, not for us.
Fees and speed fluctuate
Transaction cost on public networks rises with demand. Users bear that cost unless you design for it.
How the work is organised
Slower than ordinary software on purpose.
Discovery
We examine the idea and state whether a ledger is needed. A written recommendation for a database is a valid result.
Specification
Every function, permission and edge case is written in plain language first. The auditor will need this document.
Build and test
Contracts and tests are developed together, in your repository.
Test network
Deployed where tokens have no value, and used by your team through the real interface.
Independent audit
Code is frozen and handed to the auditor you select and pay. We fix the findings and the auditor rechecks.
Launch
You deploy with your own keys, following a script we have rehearsed with you.
Tools in use
Mature tooling only.
- Networks
- EthereumPolygonOther EVM-compatible chains
- Contracts
- SolidityOpenZeppelin Contracts
- Development
- FoundryHardhat
- Front end
- TypeScriptReactviemethers.js
- Permissioned
- Hyperledger Fabric
Answered directly
Why do you not audit your own contracts?
Authors are poor at finding their own mistakes, and a review by the builder gives your users no assurance. Auditing is a specialism, and independence is the point of it.
Can you recommend an auditor?
We can describe what to look for: published reports, named reviewers, and experience with your type of contract. The selection and the contract with them are yours.
Will you launch a token for us?
We can write and test the contract. We do not advise on its sale, pricing or legal status, and we take no part in marketing it.
What does it cost?
It is quoted per engagement after discovery. Budget separately for the audit, which for a contract of any size is a significant sum.
Who owns the code?
You do. It is committed to your repository and the deployer addresses are yours. Terms are set out in the agreement signed before work begins.
Tell us who needs to trust whom
Describe the parties, what they record, and why a shared database run by one of them will not do. We write back within one business day.