Hire a Solidity Developer: The Audit-Ready Brief
KEY TAKEAWAYS
- Choose a Solidity developer by evidence of system design, adversarial tests and deployment ownership, not contract counts alone.
- Describe permissions, asset flows and upgrade authority before asking for an implementation quote.
- Treat audit preparation, independent review and deployment verification as separate deliverables.
On this page
Hire for the system around the contract
I worked on permissioned tokens at Tokeny and later led blockchain engineering at Biconomy, including modular smart-account work. I am also a named author of ERC-3643.
That range changes the first question I would ask a Solidity candidate. Before discussing gas savings, I want to know who can move an asset, who can change that authority and how the team will detect a mistake.
To hire a Solidity developer, assess the whole delivery: contract design, permission boundaries, adversarial tests, audit preparation and deployment. A contract that compiles is one artifact inside that responsibility.
Code-level evidence
- Ask
- Can you explain a relevant function and its failure cases?
- Look for
- Clear assumptions, external-call behavior and tests that demonstrate both allowed and forbidden operations.
System-level evidence
- Ask
- Who controls this contract after deployment?
- Look for
- A permission map, explicit upgrade authority and a deployment record the receiving team can verify.
Describe the asset flows and authority
I would write the permission model before the feature list. “Build a token” leaves most of the work unspecified. Can it be paused, upgraded, recovered or transferred by an operator? Which of those powers does the product actually need?
OpenZeppelin’s access-control documentation covers ownership and roles. Choosing the roles and their administrators is still a product and engineering decision.
- Assets: name what enters the system, who holds it and what must happen before it can leave. Include external tokens and dependencies.
- Actors: list users, operators, administrators, upgrade authorities and external systems. Define what each may do and how its authority can be revoked.
- Lifecycle: describe creation, normal operation, pause conditions, recovery and retirement. State which transitions should be impossible.
- Environment: name the target chain, existing contracts, wallet integrations and any oracle or off-chain service the design relies on.
For permissioned assets, ERC-3643 specifies identity and compliance mechanisms around transfers. Treat those as engineering primitives. A legal or compliance owner must define the actual rules for the product; the standard itself is not a legal approval.
Four questions for the technical interview
I would use a small relevant code sample and ask the candidate to talk through changes. These questions reveal more than a vocabulary quiz. They also give a senior developer room to explain tradeoffs without exposing a client repository.
External calls
- Ask
- What state can another contract observe or change during this call?
- Look for
- A concrete reentrancy analysis and the assumptions behind state-update ordering, with a test for the chosen design.
System properties
- Ask
- What must remain true after an arbitrary sequence of user actions?
- Look for
- A protocol-specific invariant, explicit preconditions and a test setup that reaches meaningful states.
Upgrade authority
- Ask
- What changes when the implementation is replaced?
- Look for
- Initialization and storage reasoning, compatibility validation and a clear answer about who can authorize the upgrade.
Deployment verification
- Ask
- How do we establish that the deployed system matches the reviewed one?
- Look for
- Pinned build inputs, verified source, recorded addresses and constructor or initializer arguments, plus post-deployment role checks.
For reference, Solidity documents reentrancy and checks-effects-interactions. Foundry documents invariant testing across randomized call sequences. These are useful interview anchors, not proof that a particular implementation is safe.
Ask what the test could miss. A candidate who can describe unreachable test states, an unmodeled token behavior or an external dependency gives you a more useful signal than a coverage percentage by itself.
What an audit-ready delivery contains
I use “audit-ready” to describe a reviewable handoff. It does not mean audited, and it certainly does not mean vulnerability-free. Put the exact artifacts in the statement of work so both sides can agree when preparation is complete.
- Pinned scope: repository commit, contracts in scope, compiler and dependency versions, build commands and known exclusions.
- Design: intended behavior, asset-flow diagram, role matrix, trust assumptions and external dependencies.
- Tests: unit tests, negative permission cases, relevant fuzz or invariant tests and instructions to reproduce failures.
- Upgrade and deployment plan: initializer arguments, storage assumptions, administrative transfers and checks against the reviewed build.
- Review handoff: known issues, questions for the auditor, ownership of remediation and a record of changes requiring re-review.
Upgradeable contracts need particular care. OpenZeppelin’s upgrade guide explains initializer constraints and storage-layout hazards. Ask the developer to explain those in the context of your contracts, including migrations and existing deployed state.
Book independent review against an agreed scope. Material changes after review deserve an explicit decision about additional review. Keep deployment approval separate from the delivery acceptance: the team operating the system must know what it is authorizing.
Choose the engagement by the missing ownership
A freelance Solidity developer can own a bounded contract delivery. A senior hire can own a protocol over time. An independent auditor supplies a different perspective. Decide which responsibility is missing before comparing proposals.
New implementation
- Ask
- Do we have a specification and a receiving engineering team?
- Look for
- A scoped build with acceptance criteria, review preparation and documentation the team can maintain.
Ongoing protocol ownership
- Ask
- Who will own future integrations, upgrades and incidents?
- Look for
- A senior engineer with continuing responsibility, access to product decisions and a defined operational remit.
For smart accounts, be specific about module permissions and the integrations you need. ERC-7579 defines interfaces for modular accounts; it does not remove the need to assess what a particular installed module can do.
I work on Solidity, smart accounts and tokenization infrastructure. If you are hiring for a mission or a permanent role, send me the repository context, target chain and scope. If an AI agent will interact with those contracts, the AI engineer hiring guide covers the application-side ownership too.
Solidity developer hiring questions
How do I hire a good Solidity developer?
Ask for relevant code or a sanitized technical walkthrough, tests of forbidden behavior, an explanation of administrative permissions and experience preparing a deployment. Use a paid, bounded exercise when you need more evidence. Match the developer’s experience to your specific system, such as smart accounts, permissioned tokens or lending contracts.
Is smart-contract development the same as a security audit?
No. Development designs and implements the system. An independent audit reviews a defined implementation and scope, usually at a pinned commit. Developer testing and audit preparation help the reviewer but do not replace independent review or guarantee that a contract has no vulnerabilities.
What should a Solidity development quote include?
It should state the contract scope, target networks, integrations, permission model, tests, documentation, deployment tasks, audit-remediation allowance and exclusions. Price and timing depend on those inputs. Ask who pays for independent review and who owns changes requested after scope is agreed.
Does using ERC-3643 make a token legally compliant?
ERC-3643 defines technical mechanisms for permissioned tokens, including identity and compliance checks. It does not determine whether a particular issuance satisfies applicable law. Product and legal owners must specify the required rules; engineers implement and test those rules.
Can Adam Boudjemaa work on a Solidity mission or join an engineering team?
Adam is open to discussing Solidity development missions and senior engineering roles. His experience includes ERC-3643, tokenization and modular smart-account infrastructure. Share the target chain, current repository state, expected responsibility and timing to assess fit.
Hiring for Production
Episode 2 · 2 published
Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.
Have a project to ship or a role to fill?
Discuss your project or roleFollow the engineering notes
Get new articles on production AI and smart contracts by email.