Hire Blockchain Developers in India
Engineers who write Solidity as though the code will be attacked on the day it ships, because it will be. And who will tell you plainly when your problem does not need a chain at all.
If you are a founder or CTO outside India weighing up where to build this, here is the short version. When you hire blockchain developers in India through us, you get people who have written and read contract code that holds value, who know the off-chain machinery that makes any of it usable, and who are willing to argue with your architecture before they write a line of it. Two things on this page will be uncomfortable. The first is that a large share of the projects that reach us should not use a blockchain. The second is that a mistake in this domain behaves differently from a mistake anywhere else in software.
Start Here: Do You Actually Need a Blockchain?
More briefs land in our inbox for chains that should be tables than for anything else. The pattern is consistent. Someone has a real problem about trust, records or coordination, and the word blockchain has attached itself to the solution somewhere between the board meeting and the specification. By the time it reaches an engineer it is a requirement rather than an option, and nobody wants to be the person who reopens it.
We would rather be that person early than build you something expensive and slow that a Postgres schema would have handled better.
The test that settles it in one conversation
Name the parties. Then ask whether any single one of them could be handed the database and trusted by everyone else to run it honestly. If the answer is yes, and it usually is, you do not need a distributed ledger. You need a well designed system of record with strong access control and an audit trail that cannot be quietly rewritten.
A chain becomes the right shape only when three things are true at once. There are multiple parties who genuinely do not trust each other. They need to agree on a single ordered history of events. And no one of them may be allowed to hold the pen, because whoever holds it could favour themselves and nobody could prove it afterwards. Take away any one of those and the cost of consensus buys you nothing.
There is a fourth situation that is honestly different: you want the asset or the rules to keep working without you. Permissionless issuance, programmable settlement between strangers, or a set of rules that continues to execute whether or not your company still exists. That is a legitimate reason to be on a public chain. It is also a call for a founder or a board rather than for an engineer, and it should be made deliberately instead of inherited from a slide deck.
What an ordinary database already gives you
People reach for a chain wanting tamper evidence, and most of them can have it far more cheaply. An append only ledger table with no update or delete grants, rows chained by hash so that each entry commits to the previous one, and periodic signed checkpoints published somewhere your counterparties can see, gives you a history that cannot be rewritten without detection. Merkle tree structures of the kind used for certificate transparency give you inclusion proofs on top of that. All of it runs on infrastructure your team already knows how to operate, back up and query.
What that design does not give you is protection against the operator colluding with one party and deleting the whole log. If that specific risk is the thing keeping your customers awake, keep reading. If it is not, you have your answer and you have saved yourself a year.
The cases where the answer is genuinely yes
Settlement between parties with no common intermediary. Assets that need to be transferable and verifiable by anyone without asking your API for permission. Multi party workflows where each participant runs their own systems and refuses to accept another participant's record as authoritative. Rules that must execute the same way for everyone with no discretion, such as an escrow that releases on a condition rather than on someone's approval. These are real. When you have one, the work is interesting and worth doing properly.
If you are still unsure after reading that, say so on the first call. We would rather spend an hour talking you out of a project than six months delivering the wrong one. A hiring decision made on top of a wrong architecture decision is just a faster way to reach the wrong place. Our broader hire developers in India page covers the ordinary application engineering that most of these briefs actually turn into.
What a Blockchain Engineer Actually Does All Week
Very little of the week is spent writing contract code. On a healthy project the on-chain surface is small on purpose, because every line of it is expensive to run and permanent once shipped. A senior engineer's instinct is to push logic off the chain until only the part that genuinely needs to be trustless remains.
The on-chain part
Writing and reviewing contracts, deciding what state must live on chain and what can be derived from events, designing the permission model, choosing between an immutable deployment and an upgrade path, and writing the tests that try to break all of it. Reading other people's contracts takes as long as writing your own, because almost nothing is built in isolation.
The off-chain part
Indexing events into a database your product can query, handling chain reorganisations, managing RPC providers and their rate limits, building wallet connection and signature flows, running a backend signer with nonce management and gas bumping, and monitoring the contract in production. This is where most of the hours go and where most of the schedule slips.
The judgement part
Arguing about what should not be built. Deciding whether an admin key is an acceptable risk or a liability. Writing the deployment runbook and the incident plan before the first deployment rather than after the first scare. Saying no to a feature because it widens the attack surface for a benefit nobody can articulate.
One clarification worth making before you write a job description. A Solidity engineer and a full stack web3 engineer are not the same hire. The first writes a few hundred lines that must be perfect. The second builds the several thousand lines of ordinary product code around them. Plenty of people can do both, but almost everyone is materially stronger at one, and you should know which half of the system carries your risk before you start interviewing. If your contracts are simple and standard while your product is complex, your real hire may be a backend engineer who has worked with chains, which is closer to our Node.js developers in India than to a contract specialist.
Solidity and the EVM: The Constraints That Shape Everything
Solidity looks like a curly brace language and reads like one for about ten minutes. Underneath it is a stack machine with a single global state, deterministic execution, no concurrency, no floating point, no ability to make an outbound network call, and a meter that charges for every operation. Those constraints explain nearly every design decision an experienced engineer makes.
A machine that charges per instruction
Every opcode costs gas, paid by whoever sends the transaction. This turns ordinary programming habits into liabilities. A loop over an array that grows with usage will eventually cost more gas than a block can hold, at which point the function becomes permanently uncallable and any funds behind it may be stuck. Copying a large struct into memory when you only needed one field is a real cost paid by a real user. Storing something you could recompute is a cost paid forever.
Storage is the part that dominates. A slot is 32 bytes, and writing one from zero to a non-zero value is among the most expensive things you can do, in the region of twenty thousand gas plus the surcharge for touching a cold slot. Since the access list rules landed, the second read of the same slot in a transaction is dramatically cheaper than the first, which changes how you order operations. Refunds for clearing storage were cut back deliberately, so the old trick of freeing slots to claw back gas no longer pays what it used to. An engineer who learned this domain three years ago and has not kept up will price things wrongly.
Versions matter more here than in most languages
Solidity 0.8.0 made arithmetic checked by default, so overflow reverts rather than wrapping. That single change retired an entire family of bugs and also created a new habit worth screening for: engineers who reach for an unchecked block to save gas without proving the bound cannot be exceeded. Explicit function visibility has been mandatory since 0.5.0, which killed the accidentally public function. Custom errors are cheaper than revert strings. Transient storage and other newer opcodes change what is worth caching within a transaction.
Ask a candidate which compiler version a codebase pins and why. The answer tells you whether they inherited a repository or understand it. Pinning matters because the compiler is part of your security posture, and a floating pragma means the bytecode you audited may not be the bytecode you deploy.
Reading is half the skill
Almost every contract interacts with contracts written by other people, most of which are deployed, unchangeable and only partly documented. A working day often means reading verified source on a block explorer, matching it against the bytecode, tracing what a function does across three inherited libraries, and deciding whether an integration is safe. Candidates who have only written greenfield code from templates find this hard. Test it directly.
Why a Contract Bug Is a Different Kind of Bug
In ordinary software, a defect is embarrassing and then it is fixed. You ship a patch, you write a postmortem, you move on. Four properties of on-chain code break that comfortable loop, and together they change what you should be screening for when you hire.
It is immutable. Once deployed, the code at that address is the code, unless you built a way to change it in advance. There is no hotfix, no rollback, no feature flag you forgot to add. Whatever you can do about a bug on day two hundred is determined entirely by decisions you made on day one.
It is public. The bytecode is readable by anyone. Verified source is usually published because users demand it. Your pending transactions sit in a public mempool before they are included. There is no security through obscurity, no internal network, no assumption that only your own client will call the function. People run automated tooling across newly deployed contracts continuously.
It is adversarial and it is fast. A vulnerability with money behind it is not exploited eventually. It is exploited by whoever finds it first, sometimes within minutes of the code appearing, sometimes by a bot that copies a whitehat's own rescue transaction out of the mempool and front runs it. Your incident response window is not measured in days.
It is composable, whether you like it or not. Anyone can build on top of your contract without telling you. Another team may take a dependency on your behaviour, and a change you consider harmless can break them. Equally, a contract you depend on can behave in ways its documentation never mentioned. You inherit other people's assumptions.
The practical consequence for hiring is that speed of feature delivery is close to worthless as a signal here, and paranoia is close to essential. The engineer you want has a slightly pessimistic personality, writes down what they assume, and gets visibly uncomfortable when asked to skip a test. In most teams that person is a drag. On this work they are the whole point.
The Vulnerability Classes You Are Hiring Against
These are classes rather than incidents. Every one of them has produced real losses more than once, and the individual stories matter far less than whether the person in front of you can recognise the shape of the mistake in unfamiliar code.
Reentrancy
The oldest class and still the one that catches people. When your contract calls out to another address, control passes to code you do not control, and that code can call straight back into you before your first invocation has finished. If you sent funds before you decremented the balance, the attacker's callback sees the old balance and withdraws again. The discipline is checks, then effects, then interactions: validate inputs, write your state changes, and only then touch the outside world. A guard modifier is a safety net, not a substitute for ordering.
The version that catches experienced people is read-only reentrancy. A view function that computes a price or a share value from state which is momentarily inconsistent during a callback will return a wrong answer, and any other protocol reading that view is now making decisions on a number the attacker controls. Nothing in your own contract has been drained. Someone else's has. Ask a candidate about this specifically. It separates people who read a tutorial from people who read audit reports.
Access control and privilege
Boring, common, and responsible for a large share of real losses. An administrative function without the modifier. A proxy whose initialiser was never called by the deployer, letting a stranger call it and become owner. Authentication written against the transaction origin rather than the immediate caller, which any contract a user is tricked into calling can abuse. A role that was granted for a migration two years ago and never revoked. A single externally owned account holding a key that can drain everything, sitting on somebody's laptop.
A good engineer will treat the privilege map as a deliverable in its own right: who can call what, under what conditions, behind which multisig, with what timelock, and how each of those powers is revoked. If your team cannot produce that map on request, that is the first thing to fix, before any new feature.
Arithmetic, decimals and rounding
Checked arithmetic dealt with silent overflow, but precision problems are alive and well. Integer division truncates, so dividing before multiplying quietly discards value. Different tokens use different decimal places, and a contract that assumes eighteen everywhere will misprice anything with six. Rounding that always favours the user rather than the pool is an invitation to loop a tiny operation many times and extract the difference.
The share accounting pattern used by vault style contracts has a well documented weakness where the first depositor manipulates the ratio between total assets and total supply by donating directly to the contract, so that later deposits round down to nothing. The fix is known and cheap. What matters in an interview is whether the candidate has internalised the general rule: every division is a decision about who absorbs the remainder, and it should be deliberate.
Oracle and price manipulation
A chain cannot see the outside world, so anything that needs an external value needs an oracle, and the oracle is frequently the weakest link. The classic error is reading a spot price directly from an automated market maker's reserves. Because a single transaction can borrow a very large amount, move that price, act on the distorted value, and repay, the attack fits inside one atomic transaction and requires no capital of its own.
The mitigations each have their own weaknesses. A time weighted average price resists a single block manipulation but is expensive to attack only if the pool is deep, so a thin market gives you a false sense of safety. A published price feed pushes the trust to the feed operator and needs the consuming contract to check that the answer is not stale and that the round is complete, which a surprising amount of production code skips. Ask a candidate what they do when the oracle returns a value outside a sane band, because the correct answer is usually to halt rather than to proceed with a number you do not believe.
Front-running, sandwiching and MEV
Your transaction is visible before it is executed, and the order of transactions in a block is a thing others can pay to influence. A trade with a loose slippage tolerance can be bracketed by two transactions that move the price against you and take the difference. A contract that awards something to the first caller invites a bot that watches for your submission and copies it with a higher fee. Anything decided by a value in the current block, including timestamps and block hashes, is influenceable by the party building the block and is not a source of randomness.
Design answers exist and each costs something. Tight slippage bounds and deadlines that the user sets rather than the interface guessing. Commit and reveal schemes where the intent is hidden until it is too late to act on. Batch auctions that clear at a single price. Sending sensitive transactions through a private relay rather than the public mempool. A candidate who has never thought about ordering has not built anything that carried value.
Upgradability, and the risk it creates
Upgradability is the standard answer to immutability, and it is a trade rather than a free win. The usual mechanism puts a proxy at the address users interact with, which forwards calls into an implementation contract using delegatecall so that the logic runs against the proxy's storage. That creates a class of bugs that exists nowhere else. Reorder or insert a variable in the implementation and the new code reads the wrong slot, silently, with values that are now nonsense. Standardised slots for the implementation address exist precisely to keep the proxy's own bookkeeping out of the way of yours.
There is also the pattern where the upgrade logic lives in the implementation itself. Cheaper per call, and it introduces the failure where a faulty new implementation removes the ability to upgrade again, which is unrecoverable. And an implementation contract left uninitialised is a standing invitation for someone to claim ownership of it.
The larger point is governance rather than mechanics. If you can upgrade the contract, then you can change the rules people agreed to, which means your users are trusting you rather than the code. That is sometimes exactly right, particularly for enterprise deployments. It should be stated openly, put behind a multisig with a timelock so that anyone can see a change coming and leave, and never described as decentralised when it is not.
Assumptions about tokens that are not true
The token standard is a specification that a lot of deployed tokens follow loosely. Some widely used ones do not return a boolean from transfer, so naive integration code reverts or, worse, ignores a failure. Some take a fee on transfer, so the amount that arrives is smaller than the amount sent and any contract that records the requested amount is now wrong. Some rebase, so balances change without a transfer event. Some have a blocklist. Some have more than one address pointing at the same token.
The safe wrappers exist for exactly this reason, and the measure-the-balance-before-and-after pattern handles fee-on-transfer correctly. What you are screening for is whether the candidate treats an external token as a hostile input rather than as a well behaved interface.
If you already have code in production and want an independent look at the whole surface rather than a new hire, that is a different engagement and it runs through our security testing services in India.
Gas Is a Design Constraint, Not a Tidy-Up at the End
Teams treat gas the way they treat performance in web applications: something to look at once the features work. On a public chain that ordering is wrong, because gas changes what the product can be. A design that requires users to pay a meaningful fee for an action they do fifty times a day is not a slow product, it is a dead one.
The decisions that actually move the number are structural, and they are made early. Whether state lives on chain or is reconstructed off chain from emitted events. Whether a batch of updates can be committed with one proof instead of fifty writes. Whether variables are packed so several fit in one slot. Whether a mapping replaces an array so nothing has to be iterated. Whether the contract pays for storage that only the user interface ever reads, which is the single most common piece of waste we find in code reviews.
Fee mechanics matter too. A base fee that adjusts with demand and is burned, plus a priority tip to the block producer, means your users pay different amounts at different times of day, and any contract that hard codes a fee assumption will misbehave under congestion. On rollups the cost split is different again: execution is cheap and publishing data to the settlement layer is the dominant term, which is why the introduction of blob transactions changed rollup economics so noticeably and why an engineer whose mental model is Layer 1 only will optimise the wrong thing.
There is a failure mode here that is not about cost at all. An operation whose gas grows with the number of participants will, past some threshold, exceed the block limit and become impossible to execute. If that operation is how anyone withdraws, the funds are stranded. Pull based patterns where each user claims their own share, rather than push based patterns where one transaction pays everyone, exist for this reason. Ask about it. It is a good five minute question and the answer is revealing.
Testing: The Bar That Separates Serious Teams
Testing standards in this field are higher than in most application work, and the tooling has consolidated enough that you can ask concrete questions about it.
Foundry or Hardhat, and when each is wrong
Foundry runs the tests in Solidity itself, which removes the context switch and makes the tests fast enough that people actually run them. Its cheatcodes let you impersonate an address, expect a revert, move time forward, or manipulate storage directly, which makes adversarial scenarios straightforward to express. Fuzzing is built in rather than bolted on. For contract-heavy work it is the default now, and a candidate who has never used it is either very experienced on an older codebase or has not been paying attention.
Hardhat is the better fit when the team is mostly TypeScript and the contract layer is thin. Deployment scripts, integration with the same libraries your frontend uses, and a plugin ecosystem that covers the boring parts of a product. Plenty of serious projects run both: Foundry for property tests on the contracts, Hardhat for deployment and end to end flows. What you should not accept is a project with only end to end tests in JavaScript, because that combination tests the happy path in the language furthest from the risk.
Fuzzing and invariant testing
This is the technique that separates teams that find their own bugs from teams that wait for an audit. Instead of asserting that a specific input gives a specific output, you state a property that must hold no matter what: total shares must never exceed total assets, the sum of balances must equal the recorded supply, no user may withdraw more than they deposited. Then the tool generates thousands of random inputs trying to break it.
Invariant testing goes further by generating random sequences of calls against the whole system, which is where the interesting bugs live, because almost nothing fails on a single call in isolation. Foundry supports this directly, and there are dedicated fuzzers that do it well too. The hard part is not running the tool. It is writing invariants that are true and that mean something, which takes a deep understanding of the system. When a candidate says they used fuzzing, ask which invariants they wrote and which one turned out to be false. That second question is the one worth listening to.
Forked mainnet tests
If your contract talks to anything that already exists on a live chain, testing against mocks proves almost nothing. Forking gives you a local node with the real chain's state at a chosen block, so your tests run against the actual deployed contracts with their actual quirks, their real liquidity and their real access controls. You can pin to a block for reproducibility and pick a different block to see how your code behaves under different conditions.
This is also how you rehearse an upgrade properly. Fork the chain, run your migration against real storage, and assert that every value your users care about is still where it should be. Anyone who proposes to upgrade a live contract without doing this first should not be allowed near the deploy key.
Static analysis and formal methods
Static analysers catch the known shapes cheaply and belong in continuous integration, with the caveat that they generate noise and a team that suppresses warnings without reading them has made the tool worse than useless. Symbolic execution and formal verification are heavier: you state a property mathematically and the tool tries to prove it holds for all inputs rather than for the ones it sampled. It is expensive, it does not scale to every line, and for a small number of critical functions it is worth every hour.
Why coverage percentages mislead here
Full line coverage on a contract tells you that every line executed at least once under conditions the author chose. It says nothing about whether the author imagined an attacker. A codebase can sit at complete coverage and still have a reentrancy hole, because no test called back into the contract mid-execution. Use coverage to find code nobody tested at all, then ignore the headline number. What we look for instead is whether the test suite contains tests written from the attacker's point of view, with names like the attempt they describe. Their presence is a personality signal as much as a technical one.
What Does a Security Audit Actually Guarantee?
Less than most people assume, and it is worth being blunt about this because the word audit does a lot of unearned reassurance work in board meetings.
An audit is a time boxed review by people who did not write the code. A competent one gives you a real second perspective, finds the classes above, and produces a written report with severities and recommendations. It also has hard limits. It covers a specific commit, so any change afterwards is unreviewed. It covers a defined scope, so the integration you added last week may be outside it. Reviewers have a fixed number of days and cannot exhaustively explore a large system. And they cannot review your operational security, which is where a meaningful share of real losses actually originate: a compromised key, a malicious dependency in the build, a deployment made from an unverified artifact.
What an audit does not do is transfer risk. If it is exploited afterwards, the loss is yours. Treat the report as information, not as insurance, and read the findings the auditors marked as informational, because they are frequently the design smells that turn into the next problem.
The way to get value out of one is to arrive prepared. Freeze the code. Provide a specification of what each function is supposed to do, including who may call it and what must remain true afterwards. Hand over your own test suite and your invariants. Fix your own findings first. Teams that show up with a moving codebase and no documentation spend most of the engagement paying senior reviewers to work out what the system is meant to do, and then wonder why the report is thin.
One consequence for hiring: an engineer who has been through several audits from the developer's side is significantly more valuable than one who has not, because they know what preparation looks like and they write code that is easier to review. Ask directly. Ask what the worst finding against their code was and what they changed in how they work afterwards.
The Off-Chain Half Nobody Budgets For
Budgets get written around contract development and audits. Then the project stalls for two months on infrastructure nobody costed. Here is the part that gets left out.
Node access and RPC
Your application needs to read the chain constantly, and that means either running nodes or paying a provider. Providers rate limit, occasionally lag, and sometimes disagree with each other about the current head. Historical queries frequently need an archive node, which is a different and pricier product. Production systems end up with a primary, a fallback, and health checks that notice when one of them is quietly serving stale data. None of that appears in a proof of concept, and all of it appears in the first month of real traffic.
Indexing
You cannot query a chain the way you query a database. There is no filter by user and sort by date. So you index: read events, write them into Postgres or a hosted subgraph, and serve your product from that. The hard part is chain reorganisations, where blocks you already processed get replaced and your derived data is now wrong. Handling that properly means tracking finality and being able to unwind, which is real engineering that teams routinely discover late.
Wallets and signatures
Connecting a wallet is the easy part. The rest is not. Typed structured data signing so users see something legible rather than a hex blob. Domain separation including the chain identifier so a signature cannot be replayed on another network. Nonces so it cannot be replayed on the same one. Contract accounts that sign differently from ordinary accounts. Account abstraction flows where a sponsor pays fees on the user's behalf. Every one of these is a place where a plausible looking implementation is subtly unsafe.
Keys and backend signing
If your server sends transactions, it holds a key, and that key is now the most sensitive thing you own. It belongs in a hardware backed service rather than an environment variable. The signer needs nonce management so concurrent sends do not collide, fee bumping so a stuck transaction can be replaced, and idempotency so a retry does not send twice. Administrative keys belong behind a multisig with a timelock, and someone needs to have rehearsed what happens if a signer is compromised.
A reasonable planning heuristic from projects we have seen: the contracts are a minority of the effort, and the off-chain product plus infrastructure is the majority. If your plan says otherwise, the plan is wrong, and the overrun will land in the month you had reserved for launch.
Choosing a Chain, and What That Choice Locks In
Chain selection is usually made for reasons that have nothing to do with engineering, and then engineering lives with it for years. Worth understanding what is actually being decided.
EVM chains and rollups
Choosing anything EVM compatible means Solidity, the deepest pool of engineers, the widest tooling, the largest body of audited reference implementations, and the most auditors who can review your code. That last point is underrated when planning. Rollups give you far cheaper execution while settling to a more secure base layer, at the price of a more complicated trust story: who operates the sequencer, what happens if it censors or halts, whether there is a way to force a transaction through the settlement layer, and how long a withdrawal takes. Optimistic designs hold withdrawals for a challenge period of roughly a week unless you use a third party liquidity provider. Validity proof designs settle faster and have different maturity considerations. Neither is simply better.
Leaving the EVM
Solana work is Rust, usually with the Anchor framework, and it is a different discipline rather than a dialect. The account model means a program is passed the accounts it will touch, so a whole family of bugs comes from failing to verify that an account is what it claims to be: missing signer checks, missing ownership checks, one account type substituted for another, or a derived address whose seeds collide. Anchor removes a lot of that boilerplate and therefore a lot of those bugs, which is why asking whether someone writes raw or uses the framework, and why, is a good question. Resource limits are expressed as compute units rather than gas, and accounts pay rent for the space they occupy.
The resource oriented languages used by some newer chains encode ownership in the type system so that assets cannot be silently copied or dropped, which eliminates certain errors at compile time. Interesting, safer in some respects, and a much smaller hiring pool. Choose it because the design suits your product, not because it is newer.
What you cannot easily change afterwards
Assume the language, the tooling, the hiring pool and the auditor pool are locked in on the day you choose. Assume your users' wallets are locked in. Assume any liquidity or integrations you build up are not portable. Bridges exist and add their own risk rather than removing the problem, since a bridge is a contract holding value on both sides and has historically been the softest target in the whole stack. Multi-chain is a legitimate strategy and it multiplies the surface you must defend and the deployments you must keep synchronised. Have a reason.
Where a Permissioned Ledger Is Genuinely the Right Answer
Set aside public chains entirely. There is a category of enterprise problem where a shared ledger between known, identified participants is the correct design, and it looks nothing like the consumer version.
The shape is always the same. Several organisations, each with their own systems, who must agree on the state of a shared process and who currently reconcile by exchanging documents and arguing about which spreadsheet is right. Trade documentation moving between an exporter, a freight forwarder, a carrier, a bank and a customs authority. Provenance for a regulated product across suppliers who will not give a competitor's platform authority over their data. Reconciliation between institutions that each keep their own books and spend real money on breaks.
Technically this is a different job. In a Fabric style network you have identity issued through membership services, channels so that only relevant parties see a given transaction, chaincode that runs on endorsing peers, and an endorsement policy that expresses which organisations must sign off before a transaction is committed. Chaincode is commonly written in Go, which is why this work often draws on the same people as our Go developers in India rather than on Solidity engineers. Other enterprise designs avoid broadcasting to everyone entirely and share transactions only with the parties involved, with a notary preventing double spends. Private networks based on Ethereum clients with a permissioned consensus algorithm give you familiar tooling with known validators.
The real failure mode is not technical. Most enterprise ledger pilots die because the participants could not agree on governance: who onboards new members, who pays for the infrastructure, who arbitrates when the ledger and reality disagree, and what happens when one party wants to leave. A consortium is a legal and commercial structure with a database attached. If your pilot has one enthusiastic participant and four polite ones, the technology will not save it, and an engineer worth hiring will tell you that in the first workshop.
One more honest note. In a permissioned network with a known operator, the tamper resistance argument is much weaker than on a public chain, because the operator could in principle coordinate a rewrite. What you actually gain is a shared, cryptographically signed, jointly validated record that removes reconciliation work and settles disputes quickly. That is a genuinely valuable outcome. It is just a different one from trustlessness, and conflating the two is how these programmes end up oversold internally and then quietly cancelled.
How Do You Screen a Blockchain Developer in an Hour?
Not with definitions. Anyone can recite what reentrancy is. These are the questions we use, with what a weak answer sounds like and what a strong one sounds like, so you can run the same conversation yourself.
Walk me through a reentrancy bug you have actually read
The weak answer defines the term and mentions the guard modifier. The strong answer picks a concrete function, points at the line where funds moved before state was updated, and explains what the attacker's fallback did on the way back in. Push a little further and ask about the read-only variant, where nothing in the vulnerable contract is drained but a view function reports an inconsistent value that another protocol trusts. Candidates who read audit reports know this one. Candidates who read tutorials do not.
What do you check before an external call?
You are listening for a checklist that comes out without effort, because this is a habit rather than knowledge. Have all state changes already been written. Is the destination address something the caller controls. What happens if the call returns false rather than reverting, and are we checking. What happens if it returns an unexpectedly large amount of data. Is there a gas assumption baked in that will break on a chain with different costs. Anyone senior also mentions that they would rather the user pull funds than have the contract push them.
How would you test an upgrade?
The answer must include storage layout before anything else. A strong candidate describes forking the live chain, running the migration against real state, and asserting that specific user balances and configuration values still read correctly afterwards. They mention append-only changes to the storage layout, gaps reserved in base contracts, and the tooling that diffs layouts between versions. If the word storage does not appear in the first thirty seconds, they have not done this on anything that mattered.
A deployed contract has a bug. What now?
The first thing a good answer establishes is what is at risk and whether the bug is exploitable right now. Then it goes to the powers you already have: can it be paused, is there an upgrade path, is there a migration route, who holds those keys and how fast can they be assembled. Then disclosure, privately and to the right people, in the knowledge that public discussion is itself an attack vector and that a rescue transaction sitting in the mempool can be copied. A weak answer starts with a patch. There may be no patch.
When would you tell a client not to use a blockchain?
The single most informative question on this list, and the one that most reliably separates engineers from enthusiasts. Someone with judgement will happily list situations: a single trusted operator, no external parties, data that must be deletable on request, latency or throughput requirements a chain cannot meet, or a team with no capacity to operate keys safely. Someone who cannot think of any case where the answer is no has not been in a room where the honest answer was no.
Show me a test you wrote that found a real bug
Concrete and hard to fake. We want the invariant they wrote, why it turned out to be false, and what changed in the contract as a result. Follow it with a question about their deployment runbook: what is verified before the key comes out, who watches, what the rollback is. Engineers who have deployed something that held value have a runbook and are slightly nervous describing it. That nervousness is the correct response and we treat it as a positive signal.
Seniority: What the Levels Mean for This Particular Skill
Job titles travel badly, and in this field they travel worse than usual because the whole discipline is young enough that a person with four years of experience can genuinely be senior. We grade on what can go wrong when this person works unsupervised.
Junior
Writes contracts from established base implementations, understands the tooling, can write unit tests and read a block explorer. Should not be the only person reviewing anything that holds value, and should not hold a deployment key. Useful and productive on the off-chain product and on test coverage. Dangerous as your only contract engineer, and that combination is more common than it should be because the title on the profile does not say junior.
Mid
Recognises the standard vulnerability classes in unfamiliar code, writes fuzz tests without being asked, has integrated with contracts they did not write and been surprised by one. Can own a feature end to end under review. Usually still learning where their own assumptions are, which is why every change they make to a live system goes past someone else first.
Senior
Designs the system rather than the contract. Decides what belongs on chain, what the privilege map looks like, whether to be upgradable, and what the incident plan is. Has been through audits from the developer's side and writes code that survives them. Can read an unfamiliar protocol and tell you within a day whether integrating with it is safe. This is the level most projects actually need and frequently try to economise on.
Lead or architect
Decides whether you should be doing this on a chain at all, and which one. Sets the boundary between on-chain and off-chain, the key custody model, the governance structure, and the standards the rest of the team works inside. You need this level in concentrated bursts at the start and then far less often, which makes it a good candidate for a few hours a week rather than a full-time seat.
A staffing observation worth stating plainly. On most kinds of software, two competent mid-level engineers outproduce one senior. On adversarial code they do not, because the thing you are buying is judgement about what not to do, and judgement does not aggregate. If your budget forces a choice, put it into the person who reviews rather than the person who types.
Three Situations We See Repeatedly
Composites, assembled from the shape of the briefs that reach us. None of them describes a particular client or a particular project.
The contract works and the product does not exist
A team ships contracts, gets an audit, and then discovers the application around them is most of the work. There is no indexer, so the interface reads the chain directly and takes eight seconds to load a history page. There is no reorg handling, so a user's balance occasionally flickers. Transactions submitted from the backend get stuck at a low fee with no replacement logic, and support tickets pile up from people whose action never confirmed.
What fixes it is unglamorous. Build the indexer, treat the chain as an event source and your own database as the read model, and track finality so you know which data is safe to show as settled. Put the backend signer behind a proper queue with nonce management, fee bumping and idempotency. Then decide what the interface shows a user between submission and confirmation, because that gap is where trust in a product is won or lost. This work is closer to ordinary backend engineering than to cryptography, which is why the staffing for it is often wrong from the start.
The enterprise pilot that should have been a database
A large organisation runs a consortium pilot for supply chain traceability. The technology works. Eighteen months later there are four participants, one of whom is enthusiastic, and the shared ledger contains data that the enthusiastic participant put there and the others copy into their own systems by hand.
The diagnosis is almost never the code. Nobody agreed who governs membership, who pays for infrastructure, or what happens when the ledger and a physical shipment disagree. Meanwhile the actual business need, which was proving that a record had not been altered after the fact, was satisfiable with a signed append-only log and a published checkpoint. When we are brought in at this stage the useful first deliverable is an honest architecture review that names the option nobody wanted to say out loud, and a plan that either fixes the governance or replaces the ledger with something cheaper.
Inheriting contracts from a team that has gone
A live deployment, an original author who has left, a repository whose last commit does not match the deployed bytecode, and a multisig where one signer no longer works at the company. Nobody is confident enough to change anything, so nothing changes, and the risk quietly compounds.
The order of work here is fixed. First, verify what is actually deployed and reconcile it with the source, because everything downstream depends on that being true. Second, map the privileges: every address that can do anything, what it can do, and who controls its key. That map is usually the moment the room goes quiet. Third, rotate what can be rotated and get the multisig back to a set of signers who all still work there. Only then look at features. And expect the assessment itself to take a couple of weeks, because reading unfamiliar contract code carefully is slow and rushing it is how you introduce the incident you were trying to prevent.
Working With an Engineer Eight and a Half Hours Ahead
India runs on IST, which is UTC+5:30 with no daylight saving, so at least the arithmetic stays fixed while yours moves twice a year. Take an ordinary Indian day, 09:30 to 18:30 local, and in UTC that runs from 04:00 through to 13:00. Here is what it leaves you.
| Where you are | Overlap with a standard Indian day | What it means for this work |
|---|---|---|
| London | Roughly four to five hours, your morning into early afternoon | Enough for a daily call and a live review session. Deployments fit comfortably inside the window. |
| New York | Effectively none. 18:30 IST is about 09:00 in New York. | Their day ends as yours starts. Someone has to shift hours for anything that needs both of you awake. |
| San Francisco | None on standard hours. 18:30 IST is about 06:00 on the west coast. | An evening schedule in India is the only way to get live overlap, and it has to be agreed, not assumed. |
| Sydney | About three hours, your afternoon | Workable with one standing call. Deployments are best scheduled early in your afternoon. |
| Dubai | Most of the working day | Only ninety minutes apart. Effectively a co-located team for scheduling purposes. |
Want three live hours with a North American morning? Then somebody in India is at a desk until about half past nine at night. A person pays for that, not a spreadsheet, so settle it in writing before the first working day and settle how it is recognised at the same time. Shifted hours nobody agreed to are why offshore arrangements quietly rot around the fourth month.
Why the overlap window matters more on this work than on most
On an ordinary product team, a decision made without you can be reversed tomorrow. Here some actions cannot be reversed at all. So we set a simple rule and hold to it: anything irreversible happens inside the overlap window. Mainnet deployments, upgrades, key operations, and administrative transactions all wait until your side is awake and reachable. The sequence is rehearsed on a testnet and against a forked node first, and someone on your side watches it happen.
The rest of the day runs written first, because it has to. Design decisions get argued in pull requests and documents rather than in calls, so there is a record of why something was done that outlives the person who did it. The Indian day ends with a written handover covering what changed, what is blocked and what needs your decision, so your morning starts with an answer rather than a question. And there is a standing escalation path for the case that does not respect any of this, which is a live contract behaving unexpectedly. That case gets a named person, a phone number and permission to wake people up. We agree who that is before there is anything to escalate about.
Three Ways to Engage
Which one fits depends on whether the work has an end and on how much of your risk sits in the contracts rather than the product.
Full time on your system
One or more engineers whose week belongs to your project, working in your repositories and your process. This is the right shape when you are building something substantial and the on-chain and off-chain halves have to be designed together. Context accumulates, which matters a great deal on a codebase where the reason a line exists is often more important than the line.
Added to your existing team
The engineer reports to your engineering manager, sits in your standups and works through your review process. Best when you already have a product team and the gap is specifically contract and chain expertise. It also moves knowledge in both directions, which is what you want if the plan is to bring the capability in-house eventually rather than depend on us forever.
Senior eyes, part of a week
Senior time in small slices, for teams who can write the code themselves but want a second opinion before anything irreversible. Typical use is design review before contracts are written, reading pull requests that touch privileged functions, preparing for an external audit, and being the person your team can ask before they reach for the deploy key.
Where This Hire Goes Wrong, and How We Try to Prevent It
The failure modes here are predictable enough to name in advance, so we would rather name them than let you discover them.
Hiring the wrong half of the skill set. The most common and most expensive mistake. You need a product engineer who understands chains and you hire a contract specialist, or the reverse. The result looks like a productivity problem and is actually a matching problem. We try to prevent it at the brief stage by asking which half of your system you are worried about, and by putting forward people whose actual history matches that answer rather than whose keywords do.
Confidence that outruns experience. This field has a high ratio of enthusiasm to production scars. Someone who has deployed a dozen tutorial projects can sound extremely fluent. The screening questions on this page exist mostly to catch exactly this, and the read-only reentrancy question and the storage layout question are the two that do most of the work.
A single point of knowledge you just created. One engineer who understands the contracts is the same risk as one engineer who wrote them and left. The counter is dull and effective: written design decisions, the privilege map kept current, tests that document intent, and someone on your side who reviews changes even if they could not have authored them.
Scope drifting into the parts that carry risk. A capable engineer gets pulled into an urgent change to a privileged function because they are available and the ticket exists. It feels efficient right up to the point where it is not. Anything touching privileged code goes through review by a second person regardless of how small it is, and we keep that rule even when it is inconvenient.
The person simply is not right. Sometimes the technical assessment was fine and the working relationship is not, or the problem turned out to be different from the brief. If that happens, a replacement is provided within 48 hours, and you draw your own shortlist from a pool of developers instead of receiving a single name to accept or reject. Handover expectations and the rest of the commercial terms are settled with you in the agreement before work starts, because those depend on your situation and we would rather negotiate them than publish a promise that may not fit.
Costs That Do Not Appear in the Engineering Line
Whatever the engineering costs, it is not what the first quarter costs. The items below are the ones teams consistently leave out of a plan, and every one of them has delayed a launch somewhere.
Infrastructure that only exists because you are on a chain: node or provider access at production volume, an archive tier for historical queries, indexing infrastructure, and monitoring that watches contract state rather than server metrics. Testnet operations, which sound free and are not, because testnet funds are rate limited and a realistic rehearsal environment takes real effort to keep in a useful state.
Then external review. An audit is a scheduled engagement with lead times, and the calendar rarely bends to your launch date, so it has to be planned months out. Budget for the fix cycle afterwards as well, because a report with findings implies work, and teams routinely plan the audit but not the two weeks of remediation that follow it.
Key custody is a cost too. Hardware wallets for signers, a multisig whose signers are reachable on a bad day, and a rehearsal of the recovery process. The rehearsal is the part everyone skips, and it is the only part that tells you whether the scheme works.
Finally, your own time. A remote engineer needs a counterpart on your side who answers design questions, makes trade-off calls and approves anything privileged. Reserve a few hours each week of somebody senior while the engagement finds its footing. The ones that go badly are nearly always the ones where nobody on the client side had capacity to play that part, and seniority on our side does not compensate for its absence.
How Hiring Blockchain Developers From Us Works
Tell us what you are actually trying to do
Not the technology, the outcome. Who the parties are, what they disagree about today, what is already built, and what is at risk if it goes wrong. If part of the honest answer is that the chain was chosen before the problem was defined, say so. It changes the conversation for the better and it changes who we put forward.
We match within 48 hours
We are not opening a recruitment cycle when your brief lands, which is why matching takes 48 hours instead of the weeks that hiring from scratch would cost. You get profiles with the specific chains and codebases each person has worked on, and an honest note on where they are strong and where they are not.
You interview them properly
Use the questions from this page if they are useful. Bring your own contract code and ask them to read it in front of you, which is the single most informative exercise available. We would much rather you interrogate a candidate hard than take our assessment on trust.
Start within 7 days
From your decision to the first working day is 7 days. The first week is deliberately read-only: repository access, reading the deployed code, mapping privileges, and writing an assessment you are free to disagree with. Nothing touches a live contract until that document exists and you have read it.
Frequently Asked Questions
How do we know whether we need a blockchain at all?
Ask who the parties are and whether any one of them could be trusted to run the database. If your company can be the system of record and everyone else is willing to read from it, you want an ordinary database with a signed audit trail. A chain earns its place when several parties who do not trust each other need to agree on one history, and no single one of them may hold the pen.
Is a Solidity developer the same as a full stack web3 engineer?
No, and mixing them up is the most common staffing mistake on these projects. Contract work is a small volume of adversarial code where correctness is everything. The surrounding product is indexers, RPC handling, wallet flows, backend signing and ordinary application code. Some people do both well. Most are stronger at one, and you should decide which half is your risk before you interview anyone.
What happens if a bug is found in a contract that is already deployed?
That depends entirely on what you built into it before deployment. A pause function, a timelocked upgrade path, a migration route, and a rehearsed disclosure plan are the difference between a bad afternoon and a total loss. If none of those exist and the contract is immutable, the options shrink to deploying a replacement and persuading everyone to move. Decide this on day one, not during the incident.
Do your engineers work on chains other than Ethereum?
Yes. EVM chains and Layer 2 rollups are where most commercial work sits, so Solidity is where most of our chain experience sits. Solana work in Rust with Anchor is a genuinely different discipline with its own failure modes around account and signer checks. Permissioned ledgers such as Hyperledger Fabric are different again. We match the engineer to the chain rather than claiming one person covers all three.
Can an engineer in India deploy to mainnet while our team is asleep?
They can, and we would rather they did not. A mainnet deployment is irreversible and usually involves keys, so it belongs inside the hours when your side is awake and can be reached. We schedule deployments and upgrades into the agreed overlap window, run the same sequence on a testnet and a forked node first, and treat anything that touches a live contract as a two person action.
How do you screen for security skill rather than tutorial knowledge?
We ask candidates to reason about attacks rather than recite definitions. Talk me through a reentrancy bug in code you have read. What do you check before every external call. How would you test an upgrade without breaking storage. Someone who has only followed tutorials answers in vocabulary. Someone who has shipped answers with an ordering, a tool they reached for, and something they got wrong once.
What do you need from our side in the first two weeks?
A written description of what the system is supposed to do when everything works, and who is allowed to do what. Repository access, a testnet budget, and a named person on your side who can answer design questions within a day. Most delays in the first fortnight are not technical. They are an engineer waiting on a decision nobody has been made responsible for.