Blockchain and smart contract development in South Africa

The trouble with permanent code

Most software can be fixed after launch. A deployed smart contract usually cannot. Its code is public, it holds value, and anyone can call it in whatever order suits them. A bug is not a bug report; it is an incident, and often one with no way back.

That changes how the work has to be done. Tests that walk the happy path prove very little, because the cases that matter are the hostile ones. Upgrade paths, admin keys and who may pause what are design decisions to make deliberately at the start, not features to add after a scare.

And there is a question that comes before all of it: does this need a blockchain at all? Sometimes the honest answer is a well-designed database with an audit trail, which is cheaper to run and easier to change. We will tell you when it is.

What we build

• Smart contracts

  Contracts in Solidity for EVM networks, written for the auditor who will read them: small, explicit and documented, with tests that try what an attacker would try rather than only what a user would do.

• Tokenisation

  An asset, a right or a unit of value represented on-chain, with the rules about who may hold it, transfer it and redeem it written into the contract, and kept in step with the off-chain records those rules depend on.

• Wallets and custody

  How keys are held, who can sign, and what happens when someone leaves or a device is lost. For a business this is often the riskiest part of the whole system, so we would rather settle it early than leave it to the end.

• On-chain settlement

  Payments and transfers that settle on-chain and reconcile against your own ledger, so your finance team can answer an auditor's question without reading a block explorer.

• Audit preparation

  Helping get contracts ready for an independent security audit. That usually means writing down what the code is meant to do, giving the auditor tests they can run, listing the risks already known, and working through the findings afterwards. We help prepare for the audit. The audit itself should come from someone who did not write the code.

Where it fits

On-chain work earns its place where several parties need to rely on the same record without having to trust each other: settlement between businesses, assets that change hands, and value that has to be provable long after the fact. It rarely earns its place as a replacement for an ordinary database inside one company.

The contract is also a small part of the system. Around it sits everything that talks to it: the API, the admin tools, the reporting and the reconciliation. We build that too, with the same engineers, which is how the on-chain and off-chain records end up agreeing with each other.

How an engagement runs

1. 1

   Decide whether it belongs on-chain

   A call with the engineers who would build it, or a First Pass if you would rather gauge it first. The first question is whether a blockchain is the right tool. The second is which parts of the system belong on-chain and which do not.

2. 2

   Start with the risky parts

   Our approach is to work out keys, permissions, upgrade paths and failure cases, and write them down, before much contract code is written. Changing a design document is cheap; changing a deployed contract is not.

3. 3

   Build and test against the adversary

   The contracts, their tests and the platform around them are built in your own repositories, with commits from the first week and decisions recorded where the code can be read against them.

4. 4

   Audit, deploy, and stay on

   We help prepare the code for an independent audit, work through the findings with you, and plan the deploy with the care a permanent change needs. Afterwards the contracts, the accounts and the documentation are yours, and we can stay on as the team that knows the system.

Capabilities