Web3 & Solidity Development

Solidity, dApps, and custom chains — engineered, not hyped.

We write smart contracts that pass review, ship dApps that read and write on-chain reliably, and stand up custom L1/L2 networks when that's what the system actually needs.

Custom SolidityTested + AuditedGas-OptimizedEtherscan Verified

Web3 work is mostly software engineering with sharper edges: immutable code, public state, and adversarial users. We treat it that way — Foundry tests, OpenZeppelin patterns, gas budgets, and verified deployments.

Audit-ready code

OpenZeppelin patterns, Foundry + Hardhat coverage, and Slither static analysis before any mainnet deploy.

Gas-budgeted

Storage layout, packed structs, and assembly only where it pays — every byte of calldata accounted for.

Multi-chain ready

Deploys on Ethereum, Polygon, Base, Arbitrum, and the OP stack from a single, reproducible pipeline.

Smart contracts — Solidity, tested, audited

We write Solidity against current best practices: OpenZeppelin contracts for the standard surface (ERC-20, ERC-721, ERC-1155, AccessControl, ReentrancyGuard), then custom logic on top — only where custom is justified. Every contract ships with a Foundry test suite and Hardhat scripts for deploys and verification on Etherscan, Basescan, or Arbiscan. Gas is treated as a first-class constraint. We profile storage layout, pack structs, prefer immutable and constant where applicable, and use `forge snapshot` to track regressions per function. Where state must be mutable, we choose between transparent and UUPS proxies deliberately, document the upgrade authority, and timelock it. Risk is named out loud: what is immutable, who can upgrade, and what an attacker controls.

ERC-20 tokens

Fixed-supply, mintable, capped, or fee-on-transfer — with permit, votes, and snapshot extensions when needed.

ERC-721 / ERC-1155 NFTs

Royalty-aware (ERC-2981), enumerable, with on-chain or IPFS-pinned metadata.

Custom logic contracts

Staking, vesting, escrow, distribution, and access-controlled state machines built to spec.

Upgradeable proxies

Transparent or UUPS proxies with timelocked admin and OpenZeppelin upgrades plugin.

Gas-optimized patterns

Packed storage, unchecked math where safe, custom errors, and `forge snapshot` regression checks.

Hardhat + Foundry coverage

Unit tests, invariant tests, fork tests against mainnet state, and Slither static analysis.

dApps — frontend that talks on-chain

On the frontend we use wagmi and viem over ethers v6 — typed contract bindings, predictable cache, and first-class support for WalletConnect v2 alongside MetaMask, Rainbow, Coinbase Wallet, and Safe. Reads are batched, writes show clear status (pending, confirmed, reverted), and transactions surface the actual revert reason rather than a generic failure. For anything beyond a single contract, we index events through The Graph (or a self-hosted subgraph) so the UI doesn't depend on direct RPC pagination. Token-gating, allowlists, and signature-based auth (SIWE) are wired the same way: verifiable on-chain or off-chain with a clear trust boundary.

MetaMask + WalletConnect

WalletConnect v2, EIP-6963 multi-wallet discovery, and Safe multisig support out of the box.

On-chain reads/writes (wagmi)

Typed contract hooks via wagmi + viem, with optimistic UI and proper revert handling.

Token-gated UX

Balance, ownership, and signature (SIWE) gates with server-side verification.

Multi-chain

Ethereum, Polygon, Base, Arbitrum, Optimism — chain-aware UI and RPC fallbacks.

The Graph indexers

Custom subgraphs for events, holders, and historical state — hosted or self-managed.

Custom L1 / L2 chains

A custom chain is the right answer in a narrow set of cases: app-specific throughput, custom fee tokens, sovereign governance, or regulated validator sets. Most projects do not need one. When they do, we scope the trade-offs honestly — bridge security, validator economics, and the long-term cost of maintaining a chain. We work with Cosmos SDK and CometBFT for sovereign app-chains, Substrate for Polkadot parachains, and Arbitrum Orbit or the OP Stack for L3s that inherit Ethereum security. Deliverables include node images, genesis configuration, validator onboarding docs, a bridge plan, and a block explorer.

Cosmos SDK chains

Sovereign app-chains with CometBFT consensus and IBC connectivity.

Substrate parachains

Polkadot parachains and solo-chains with custom pallets.

Arbitrum Orbit / OP Stack L3s

L3 rollups inheriting Ethereum or Base settlement, with custom gas tokens.

Custom validator sets

Permissioned or PoS validator onboarding, slashing, and governance modules.

Case study

Case study: GrumpyShib

Charity-focused BEP-20 token on BNB Smart Chain — Solidity contracts, React dApp, and the wallet flow that ties them together. Distribution mechanics and on-chain donation routing are enforced at the contract level, with allocations split between holders, liquidity, and a charity wallet. The dApp uses MetaMask and WalletConnect, on-chain reads via BscScan, and a holder dashboard backed by an indexer. Contracts verified, test suite checked in, deploy scripts in the repo. Live on BSC and still running.

FAQ

Common questions

Do you audit the contracts you write?
We do internal review with Foundry tests, invariant tests, and Slither static analysis on every contract, and we write code to be audit-ready. For mainnet deployments holding significant value, we recommend a third-party audit (Spearbit, Trail of Bits, Code4rena) and will coordinate it. We do not market ourselves as an auditor — that's a separate discipline.
Which chains do you deploy to?
Ethereum mainnet and the major EVM L2s — Polygon, Base, Arbitrum, Optimism — plus testnets (Sepolia, Base Sepolia). For non-EVM work, we have shipped on Cosmos SDK chains. We do not currently take Solana or Move-language work.
Upgradeable or immutable contracts?
It's a deliberate trade-off, not a default. Upgradeable proxies give you a path to fix bugs but introduce admin-key risk and complexity. Immutable contracts are simpler and more trustless but unforgiving. We recommend per project and document the choice — including who controls upgrades and behind what timelock.
Can you handle the dApp frontend as well as the contracts?
Yes — that's the common case. We use wagmi, viem, and WalletConnect v2 on the frontend, and we treat the contract ABI as the source of truth. Subgraphs and indexers are built alongside so the UI doesn't depend on RPC pagination.
Do you advise on token economics or distribution?
We implement what you specify and will flag mechanical risks (rug vectors, MEV exposure, broken incentives) we see in the spec. We are not a tokenomics or legal advisor — for regulatory and economic design we will point you to specialists.
Ready when you are

Have a contract or dApp to ship?

Send the spec — or the rough idea. We'll come back with a scope, a chain recommendation, and a realistic timeline within two business days.