Development for Ethereum (EVM)

The Ethereum Virtual Machine (EVM) is the execution environment shared by Ethereum and dozens of other networks: Arbitrum, Base, Polygon, Optimism, BNB Chain. Choosing it means entering the ecosystem with the most mature tooling, the widest pool of auditors, and the wallets your users already have installed.

That turns into three concrete advantages: the standards are already written, the talent exists, and third-party infrastructure is already integrated.

When it does not make sense. If you need personal data on chain, confidentiality between participants, or thousands of operations per second, a public EVM network is not the answer: there we propose a permissioned network, or rule out blockchain altogether. Saying so before anything is signed saves budget.

The network drives cost per operation, how long a transaction takes to become irreversible, and how complex it is to move funds. Three criteria:

• Gas costs. Ethereum mainnet is the expensive option and the one that demands the fewest assumptions. A rollup such as Arbitrum or Base cuts cost per transaction by orders of magnitude, in exchange for trusting its sequencer.
• Finality. A fast confirmation on an L2 is not finality on Ethereum: on optimistic rollups the withdrawal window back to L1 is measured in days. If you settle against a bank or a registry, that detail belongs in the design from day one.
• Bridges. Every bridge adds attack surface. We favor a network's canonical bridge over third-party bridges, and keep cross-chain hops to the strict minimum.

We write in Solidity and start from OpenZeppelin for everything already solved and reviewed: role-based access control, emergency pause, ERC-20, ERC-721 and ERC-1155 implementations. Custom code is reserved for business logic, which is where line-by-line review actually pays off.

The working environment is Foundry (Solidity tests, fuzzing, invariants and gas profiling), with Hardhat when the project needs TypeScript scripts. Every contract goes through unit tests, tests against a fork of the live network, and static analysis before it gets anywhere near a deployment.

One warning we always give: the token standard does not determine its legal nature. An ERC-20 can be a crypto-asset under MiCA, or a financial instrument governed by securities law (LMVSI, MiFID II), with very different obligations. Settle that classification before fixing supply and contract permissions; our MiCA/MiFID classifier is a starting point.

A deployed contract can no longer be patched casually. Governance of the system is decided before it is written:

• Upgradeability. A UUPS or transparent proxy if the product will evolve; an immutable contract if the promise to users is that nobody can change the rules.
• Keys and permissions. Privileged functions are signed from a multisig, never from a single key, and sensitive changes go through a timelock that leaves room to react.
• Circuit breakers. Emergency pause, per-operation limits, and separation between the contract that holds funds and the one that runs the logic.

External review before mainnet: for any system that will hold value we recommend a smart contract audit run by someone other than the team that wrote the code.

Deployment runs from versioned, reproducible scripts, not by hand from a console. Source code is verified on each network's explorer so that anyone can check the published bytecode against the source.

What you receive when the project closes:

• Repository with contracts, tests and deployment scripts.
• Addresses and verified source on every network, with the deployment transaction hashes.
• Architecture document: roles, privileged functions, upgrade and pause procedures.
• Event monitoring and alerts on the critical functions, with the response runbook.

Monitoring is not an optional extra: an unwatched contract only speaks up once the damage is done.