Blockchain engineering

Web3 and smart contract development

Contracts, and the frontends and services around them, written with standard tooling and a security-first review process — to be read and audited, not only to compile.

All services

Typically built with

  • Solidity / Hardhat / Foundry
  • OpenZeppelin
  • Ethers.js / Web3.js
  • React / Next.js Frontends

Scope

What this covers.

  • Smart contract development

    The on-chain code that moves tokens and enforces the rules, written to a test suite built to break it before anyone else can.

  • Security-first patterns

    Built on audited, standard building blocks with access control designed in, so the code is ready for a third-party audit rather than hoping to survive one.

  • dApp frontends

    The app your users actually touch, wired to their wallet and to the chain, so signing a transaction is the only unfamiliar step.

  • Protocol & DeFi work

    The logic behind a protocol — tokens, staking, swaps — where the maths has to be right because the mistakes are public and permanent.

Read before deployed

Contracts are not shipped. They are published, permanently.

There is no patch release for something already on chain, which changes how the code gets written: ordering that assumes an attacker, loops that cannot be starved, and events that let anyone off-chain reconstruct what happened.

contract review · sample

function withdraw(uint256 amount) external {  require(balances[msg.sender] >= amount);  (bool ok, ) = msg.sender.call{value: amount}("");Review note: External call before state update — reentrancy  require(ok, "transfer failed");  balances[msg.sender] -= amount;Review note: Move above the call; checks-effects-interactions}Review note: No Withdrawal event emitted — off-chain indexers go blind

3 findings on 6 lines · fixed before deploy, not after

Written to be read and audited, not only to compile.

The work

This is not our first mainnet.

Three named engagements on public chains — two DEXs and a DeFi lending protocol. Each has a full write-up.

How the work runs

The order things happen in.

Contracts are immutable once deployed, so we test exhaustively and design for security before a single line ships to mainnet.

  1. Threat-model the contract before writing it

  2. Write tests alongside contracts for full coverage

  3. Deploy and validate on testnet, then review

  4. Coordinate third-party audits ahead of a guided mainnet deploy

How it gets built

Reviewed line by line.

Contract work is read more than it is written. Ordering, bounds and events get argued about before anything is deployed.

Before you ask

Questions we get.

  • Do you audit contracts?

    We write audit-ready code using OpenZeppelin standards and full test coverage, and coordinate third-party audits before mainnet.

  • Have you shipped real Web3 products?

    Yes. On-chain, we have built for tanX, ShibaSwap and Bru Finance — DEXs and a DeFi lending protocol. And our founder was technical lead at WazirX, a crypto exchange. Production contracts and the services around them, not demos.

  • Which chains do you support?

    Ethereum and EVM-compatible chains, mainly — the same tooling carries across most Ethereum-style networks, so moving between them is rarely a full rebuild.

  • Do you actually need a blockchain for this?

    Often not. If a normal database would do, a contract just adds cost and risk, and we will tell you that. This is for the cases where the trustlessness is the point — a token, a DeFi protocol, on-chain settlement — not where a chain is the label on top of an ordinary app.

Next to this

This work is usually not on its own.

Tell us what you are building.