Contracts written to be read by a reviewer
Programmable workflows and decentralised applications, with testing, access controls and clear upgrade and ownership decisions. Deployed code is difficult to change and impossible to un-publish, which sets the standard for everything before deployment.
What the work covers
Contract design and specification
What the contract must do, what it must refuse to do, and what it must never allow, written down before anything is deployed. On-chain, ambiguity becomes permanent.
Testing and invariant checking
Unit and integration tests, property and invariant testing, and adversarial cases written by someone trying to break it. Testing is the deliverable, not the overhead.
Access control and role design
Who may call what, which roles exist, how they are granted and revoked, and what any single compromised key can actually do.
Upgrade and ownership decisions
Whether the contract can be changed after deployment, by whom, under what delay, and what the holder can do about it. A choice with real governance consequences, made explicitly.
dApp front end and indexing
The interface people use, the indexing layer that makes chain state readable at speed, and the transaction states that a wallet leaves you to explain.
Preparation for independent review
Documentation, specification, test evidence and code structured so an independent security firm can review it efficiently rather than starting from archaeology.
We do not call our own testing an audit
The word carries a specific meaning in this market and it is routinely misused. Here is exactly where the boundary sits on our engagements.
What we do
Design, write, test and document contracts, including adversarial testing and invariant checks, and structure the work so that independent review is efficient.What we do not claim
We do not describe our own testing as an audit. An audit is a separate, independent engagement with its own competence, scope and liability.Who reviews it
An independent security firm, engaged by you. A supplier reviewing its own contracts is not assurance, whatever the report is called.What you get from us
The specification, the test suite and its results, the deployment and ownership plan, and remediation of findings the reviewer raises.The same principle runs through the group. We engineer it. Certified helps you govern, evidence and prepare it for assurance.
Pixelette Certified is the group’s specialist compliance, cyber-assurance and AI-governance business. Where a technology programme needs formal governance, certification readiness, privacy or security-assurance support, Certified can help scope the requirement, coordinate appropriately credentialed specialists and support the route to independent assessment where required.
Upgradeable or immutable is a governance choice
An upgradeable contract can be fixed when a defect is found. It can also be changed after people have committed value under the original rules, by whoever holds the key. Both properties are true at once, and pretending otherwise is how projects end up with a governance crisis they never designed for.
We make the choice explicitly with you, document it, constrain it with delays or multi-party control where the stakes justify it, and state it plainly to whoever is relying on the contract.
A decentralised application is mostly conventional engineering: an interface, an indexing layer so chain state can be read at usable speed, wallet connection, transaction-state handling, off-chain services for everything that should not be on-chain, and monitoring.
Users experience the parts that are not on the chain. Those parts deserve the same engineering attention as the contracts, and rarely receive it.
Questions worth answering
Do you audit smart contracts?
No, and we are careful with the word. We design, write, test and document contracts, including adversarial testing and invariant checks, and we structure the work so an independent security review can be carried out efficiently. An audit is a separate engagement by an independent firm with its own competence and scope, and a supplier reviewing its own contracts is not assurance.
Should a smart contract be upgradeable?
It is a governance decision rather than a technical default. Upgradeability lets defects be fixed, and also means someone can change the rules after people have committed value under them. The decision should be explicit, documented, constrained by delays or multi-party control where the stakes justify it, and visible to whoever is relying on the contract.
What does a dApp involve beyond the contracts?
An interface, an indexing layer that makes chain state readable at usable speed, wallet connection and transaction-state handling, off-chain services for anything that should not be on-chain, and monitoring. The contracts are typically the smallest component and the least forgiving one.
Have a mechanism you want on-chain?
Bring us the rules you want enforced and who has to rely on them. We will tell you what belongs in a contract, what belongs off-chain, and what should not be built at all.