A Tuesday evening. A contest repository is open, the pool is $4,000, the clock runs four days. You read a lending contract line by line, hunting for the one place its accounting disagrees with itself. On day three you find it, and your heart jumps.
That jump is why people stay in this work. The money is slower than the stories suggest.
Maybe you are a developer watching AI write the code you used to be paid for. Maybe you are stuck in a job where nobody notices careful work. Auditing pays for exactly that care, in public, with a scoreboard anyone can check.
Code4rena publishes the arithmetic. Severity sets your weight inside it, 10 for a High and 3 for a Medium, which makes grading a money question as much as a technical one. Plan against the $2,000 median rather than the $52,800 average, which a few outliers drag upward.
The urgency is about skill, and it compounds. Every contest you sit out is a report you never studied and a pattern you will not recognise next time. Newer chains and categories are less crowded today, and the auditors who learn them early take findings others miss.
Pools on the board run from $4,000 to $135,000, tooling costs between nothing and $200, and most people need six to eighteen months before anything arrives steadily. Keep your day job while you learn.
Today, open the audits page, find the smallest pool listed, and read its scope end to end without submitting a thing.
Doing that arithmetic honestly is what this guide is for, and I will warn you now that the answer is uncomfortable. The published numbers are large, the published distribution is brutal, and both facts come from the same sources.
There are two separate markets here, and they behave differently.
The economics only make sense once you look at the problem from the protocol's side, and doing that tells you what they are really buying from you.
Deployed contract code is usually impossible or hard to change, holds funds directly, and runs in public, where anyone can read it and call it. A bug in ordinary software is a defect you patch in the next release. A bug in a contract holding a hundred million dollars is a standing invitation, readable by anyone, exploitable by the first person who notices, and the team cannot take the system offline while they fix it.
That mix makes ordinary software assurance too weak on its own. A traditional audit hires a fixed team for a fixed period, which means a fixed number of eyes and a fixed set of mental models. Contests buy something else: many people with different backgrounds reading the same code in parallel, each bringing whatever odd things they happen to know. The duplicate decay in the award formula exists for exactly that reason. The protocol is paying for coverage it could not get any other way, and rewarding the twentieth person to find the obvious bug buys it nothing. Fairness to participants was never the design goal.
Standing bounties buy something different again: a legitimate way for someone who finds a live vulnerability to get paid instead of exploiting it. That is why the cap is set as a percentage of funds at risk. It has to be big enough to outbid the exploit.
Two useful conclusions for you as a participant. First, you are paid for information the protocol does not have, which is why being unique beats being thorough in the reward structure. Second, the market exists because the protocol's alternative is a catastrophic loss, which is why recognisable, well-funded projects take part, and why the pools are paid in stablecoins and honoured.
Notice two things before we get to the arithmetic.
The clients are names you know. Chainlink, LayerZero, Jupiter, Injective. Established protocols use this market as part of their security process, which is why the pools are funded in stablecoins and actually paid out. Anonymous projects are the minority here.
And the range is wide, from $4,000 to $135,000. The spread of pool sizes is strategic information in its own right, and the small ones matter more than they look. If you had to pick one row of that table for your first try, which would it be? Hold that answer; the formula below may change it.
Code4rena publishes how awards are calculated. For a High Risk finding, the shares a participant receives are:
For a Medium Risk finding, the leading weight is 3 instead of 10. `split` is the number of participants who submitted the same finding. Each award is then redeemed for the pool divided by the total shares issued.
That `0.85 ^ (split - 1)` term does something severe, and it is the most important fact in this whole field. Each extra person who finds the same bug both divides the shares and knocks a further 15% off what remains. Here it is worked through:
If you find a High Risk bug that twenty other people also found, you get roughly one four-hundredth of what you would get finding it alone. A Medium Risk finding carries a weight of 3 against a High Risk finding's 10, so a solo High is worth about 3.3 times a solo Medium at the same split.
Everything strategic flows from this. Time you spend confirming the obvious vulnerability that fifty people will report is close to worthless. Time you spend on the part of the codebase nobody else is reading is where the entire return lives. Competitive auditing rewards being unusual far more than being thorough, and those are different skills. Which corner of a codebase do you naturally drift to when everyone else is reading the main contract? That habit is worth more to you than any single trick.
There are bonuses on top, and they push the same way. The submission picked for the audit report gets a 30% slice bonus. Two more bonuses, each worth 10% of the High and Medium pool, go to Top Hunter, for the greatest number of unique Highs and Mediums, and Top Gatherer, for the greatest number of valid ones. Notice the word "unique" in the first.
Because the formula rewards unique findings and punishes duplicates, your early contest money will tend to be small and late. Six to eighteen months is the honest runway, so the rent has to come from somewhere steady while you learn. Keep the day job paying the bills, and count each valid High as money on top once the reward has actually landed in your wallet.
Reading the judging rules carefully is worth more to you than an extra day of searching.
That covers contests, where a fixed pool is shared among everyone who found something. Bounties run on a different bargain, and it is worth weighing before you give a month to either.
Standing bounty programmes work differently, and the headline figures are much bigger. Programme terms on Immunefi are usually set as a percentage of funds at risk with a hard ceiling, and the ceilings vary enormously. Live examples: critical smart contract bugs rewarded at 10% of the funds directly affected, capped at $250,000 on one programme, $100,000 on another, and $5,000 on a smaller one.
Now the distribution, which is the number that should set your expectations. Analysis of Immunefi payouts puts the average payout per confirmed report at about $52,800 and the median at about $2,000.
Sit with that gap for a moment. When a mean is twenty-six times the median, the mean is describing a handful of enormous outliers and the median is describing what will probably happen to you. A guide that quotes the average and stops there is misleading you. The typical confirmed report on the biggest bug bounty platform in this space pays about two thousand dollars, and that is for a report that was confirmed, which most are not. If your first confirmed report paid $2,000 after three months of evenings, would you feel it was worth it? Your honest answer to that tells you a lot about fit.
The structure differs from contests in another way that matters. A bounty pays the first person to report, with no split, so nothing gets diluted. But the code is live, deployed, and has usually already been through paid audits and earlier bounty hunters. You are hunting for what professionals missed, in production, and that is genuinely harder than finding bugs in fresh code before it ships.
The platforms differ in ways that change what you can expect to earn, and picking one because you recognise the name is a mistake.
Direct protocol programmes. Some protocols run bounties on their own infrastructure, outside any platform. Fewer people find these, which cuts both ways for you: fewer competitors, and less recourse if a payout is disputed, since no middleman is holding the funds.
Private and retained audit work. Security firms and protocols hire auditors directly, on contract or salary. This is where the predictable income lives, and public contest results are the usual way in.
The way to read these four is as a ladder. Contests build a public record cheaply. The public record gets you private work. Private work pays reliably. The most common mistake in this field is treating contests as the destination.
What Separates a High From a Medium
Severity sets your weight, 10 versus 3, so understanding how it is judged is directly about your money.
Severity here comes down to impact and likelihood, and the impact that matters most is loss of funds. A vulnerability that lets an attacker drain a contract, mint tokens without backing, or lock user deposits forever is a High. One that weakens a mechanism, causes wrong accounting within tolerable limits, or needs unlikely preconditions tends to land as a Medium.
Beginners lose value on likelihood again and again. A finding that needs the protocol's own admin to act maliciously is usually judged below High, because the trust model already assumes an honest admin, and it often gets classed as a centralisation risk and bundled into the QA report. A finding that needs an attacker to control a block, hold an implausible amount of capital, or rely on a specific outside protocol failing may be downgraded on likelihood, even though the impact would be severe.
The most valuable finding is an ordinary-looking issue with a severe consequence that an ordinary user with ordinary capital can reach. Those survive judging at full severity, and because they look ordinary, they are exactly what other participants walk past.
Two practical tips. Spell out the preconditions in your write-up and make them as weak as you honestly can, because the judge assessing likelihood is reading exactly that part. And when you find something whose impact you cannot describe in terms of funds, ask yourself whether it is really a QA item before you spend a day on it.
The Free Practice Path
So far this has been about where the money sits and how a finding gets graded. Next is how you get good enough to reach it while spending nothing.
The learning material in this field is unusually good and costs nothing, which is rare for a skill with this earning ceiling.
Deliberately vulnerable contract series. Purpose-built sets of contracts, each with one class of exploit, designed to be solved in order. They teach you to recognise vulnerabilities efficiently because each level isolates one idea, and nothing replaces having exploited a reentrancy bug yourself. Reading about one is a pale copy.
Published audit reports. Every finished contest publishes its findings. That gives you a large, structured, free library of real vulnerabilities with severity assessments and fixes attached. Reading lots of reports for protocols in one category is the fastest way to build the domain knowledge that produces unique findings.
Post-mortems of real exploits. When a protocol gets exploited, the analysis is usually published in detail. These teach you more than practice exercises, because the bug survived audits and review, which shows you what plausible-looking but wrong code really looks like.
Entering contests before you feel ready. Enter, spend the window genuinely trying, submit whatever you find, then read the published report and work out precisely what you walked past and why. It is uncomfortable, and it is the most efficient feedback loop you have, because it measures you against the same distribution you will one day earn from.
A sequence that works: go through the vulnerable-contract series until the standard classes are automatic, read thirty published reports in one protocol category, then enter mitigation reviews in that category. The narrow category matters because of the duplicate formula. Depth in one area gives you findings other people miss; breadth gives you the findings everybody has. Which category already interests you enough that thirty reports would feel like reading, more than homework? Start there.
Every week you wait, another contest closes with findings you could have learned from. The practice path costs nothing but evenings. Tonight, pick one vulnerable contract exercise, finish it, and read one published report in the category you want to own.
The Sensible Entry Point Nobody Mentions
Look again at the bottom of that pool table. Intuition Mitigation Review, $4,000, four days. Panoptic Mitigation Review, $6,000, five days. Swafe Mitigation Review, $12,000, four days.
A mitigation review is a narrow follow-up job. The protocol has already been audited, has fixed the reported issues, and now wants confirmation that the fixes work and have not created new problems. You review a diff, which is far smaller than a whole codebase.
If you are starting out, this is a much better bet than a $135,000 flagship contest, for three reasons that build on each other.
The scope is small enough for you to read completely. You can genuinely understand every changed line in a few days, which is impossible on a large protocol in the same time.
The competition is thinner. A $4,000 pool over four days draws far fewer people than a six-figure pool, and with the duplicate decay, the number of competitors matters more to your earnings than the size of the pool.
The skill it asks for is one you can learn. Checking whether a specific fix really solves a specific issue, and whether it broke an invariant somewhere else, is a bounded reasoning task. Finding a brand-new vulnerability in 8,000 lines of unfamiliar code is far harder.
The arithmetic can favour the small pool. A $4,000 pool where you find the only High is worth more than a $105,000 pool where you find the same High as thirty other people, and by the formula above it is worth dramatically more.
What You Actually Need to Know
There is no credential and no gatekeeper. There is a real technical floor, though, and pretending otherwise would waste your time.
Solidity, well enough to read unfamiliar code fluently. Writing contracts is easier than reading someone else's and reasoning about what an attacker could do with them. Reading is the skill.
The standard vulnerability classes, deeply enough to spot variants. Reentrancy, access control failures, arithmetic and rounding issues, oracle and price manipulation, flash loan attack paths, signature replay, upgrade and initialisation problems, denial of service through gas, and the whole family of accounting errors where a contract's internal bookkeeping drifts away from reality. Recognising the textbook version is only the entry ticket, because everyone finds those and the split wipes out their value. Recognising an unusual variant is the job.
Protocol domain knowledge. Most valuable findings come from how a specific mechanism behaves under conditions its designers never considered, far more than from generic code defects: how a lending market handles bad debt, how an automated market maker behaves in extreme volatility, how a bridge copes with a reorganisation on one side. This is why specialising in one protocol category pays, and it is your most reliable route to finding what others miss.
Testing and proof of concept tooling. You need to write a test that demonstrates the exploit, because live criticals require a coded proof of concept, and because a demonstrated exploit is far harder for a judge to downgrade.
Reading published audit reports. Every contest publishes its findings. That is a free, enormous, structured dataset of what real vulnerabilities look like and how they are written up. Working through past reports for protocols in your chosen category is the single best preparation you can do.
The free practice environments are genuinely good: deliberately vulnerable contract series built to be exploited one level at a time, and open competitive platforms where you can enter a contest at any skill level and compare your findings with the published results afterwards. Entering a contest, finding nothing, then reading the report to see what you walked past is an unpleasant and extremely effective way to learn.
Turning a Scoreboard Into an Income
Placing in contests proves what you can find. Making that proof pay on a schedule is a separate skill, and this is where it starts.
Plan the move from contests to reliable money deliberately, because contest income alone will not get you there.
Your public record is the product. Contest results are permanent and carry your name. A profile showing valid Highs across several audits in one protocol category is a credential no course can give you, and it is readable by exactly the people who hire auditors. That is the reason to enter contests even when the expected earnings are poor: you are buying evidence.
Specialising is what gets you hired. "Smart contract auditor" puts you up against everyone entering the same contests. "Lending protocol liquidation mechanics" or "cross-chain bridge message verification" is a description a security firm can match to a client's need. The same depth that produces unique findings in contests gives you a hireable identity outside them, which is a happy overlap.
Write publicly about your findings once reports are out. Wait until then, since publishing early forfeits awards. After publication, a clear explanation of a vulnerability class and how you found it does more for your reputation than the finding itself, because it shows your reasoning, and reasoning is what clients hire.
Team up. Experienced participants often audit in pairs or small teams and split the shares. This cuts variance, covers more of a codebase, and means two people reasoning about the same mechanism, which catches more than two people reading separately. If your income cannot absorb months of nothing, sharing the variance is worth giving up some upside.
The destinations are specific. Private audit engagements with security firms, retained security reviews for a protocol, protocol security engineering roles, and running your own review practice once you have a name. All of them pay on schedule, which contests never do.
The sequence that works is unglamorous: learn on free material, enter small contests for the record, specialise narrowly, publish your reasoning, then turn the record into engagements. The people earning well in this field nearly all followed some version of it, and very few of them earn mainly from prize pools.
A profile showing valid Highs in one protocol category changes how people talk to you. The developer friend who thought this was your hobby starts forwarding you audit requests, and a protocol team writes first to ask when you are free. Published reasoning builds that moment, so post your next writeup.
What You Can Realistically Expect to Earn
Putting the published figures together into an honest picture:
The median confirmed bug bounty report pays around $2,000. Contest pools run $4,000 to $135,000 and are split among all valid finders, with duplicate decay making the number of competitors more important than the pool size. Bonuses for report selection and for Top Hunter or Top Gatherer add 30% to a slice and 10% of the High and Medium pool respectively, and they go to the strongest participants, well above the median.
Here is what that means for you, plainly:
There is no income floor. A month of full-time effort can produce nothing, and that happens to competent people all the time. Nobody pays you for looking.
Treat your early attempts as paid education with an expected value near zero. Your realistic goal for the first several contests is one valid finding of any severity. Income comes later.
The distribution is extreme and stays that way. A small number of specialists earn very well. Most participants earn little, and the published gap between mean and median is the evidence.
It grows with reputation in a specific way. Consistent results in public contests are visible, and they lead to private audit engagements and retained security work, which pay predictably. That move is where this turns from a lottery into a living.
The honest framing: this gives you no predictable monthly side income. What you get is a skill investment with a public scoreboard, and the scoreboard is what eventually gets you paid reliably. If you lost $200 on tools and six months of evenings and found nothing, would the rent notice? If not, you can afford to learn this way.
When a payout finally arrives, it lands as something specific. A month of rent paid by a bug you found. A flight home to see family. The first private engagement that follows a strong contest result is the moment this skill starts paying for your life.
Rookie Mistakes
Submitting volume. Code4rena's documentation warns explicitly against high volumes of low-quality reports, and you pay a real price in reputation and in judging. Twenty speculative submissions are worse than one demonstrated finding.
Chasing the obvious bug. The vulnerability you spotted in the first hour is the one everybody spotted in the first hour. By the formula, a High found by twenty people pays 439 times less than one found alone. Once you have noted it, move on to the code nobody is reading.
Skipping the proof of concept. A finding without a coded exploit is easier to downgrade, and for live criticals a coded proof of concept is a stated eligibility condition, so treat it as required.
Arguing severity instead of finding the top case. Duplicates are judged on the underlying functional vulnerability, however well you argue severity or exploit path. A more persuasive report about the same bug still gets split, and missing the top severity case can drop you to partial credit at 25%.
Spreading across every contest. Enter six contests shallowly and you get six sets of duplicate findings. Enter one contest in a protocol category you understand deeply and you have a chance at the unique finding the whole reward structure is built around.
Ignoring the mitigation reviews. They are unglamorous, small, short and far less contested, which by the formula makes them the best expected value open to you as a beginner.
Treating the average as your expectation. The $52,800 average payout figure is a product of outliers. Plan against the $2,000 median.
Who This Suits and Who It Does Not
It is worth being direct with you, because the failure rate is high and much of it comes from poor fit more than from missing skill.
It suits you if you can take long stretches of unrewarded effort without losing heart. The feedback arrives weeks later, is often negative, and has little to do with how hard you worked in any given window. If a month of effort that produced nothing would knock you off course, that tells you something important about fit, and nothing about your ability.
It suits you if you already read code like an attacker, for fun. The people who do well tend to find the puzzle interesting for its own sake, because that keeps them going through the unrewarded stretch that filters everyone else out.
It suits you if you have another income. With no floor, extreme variance and weeks between effort and payment, this makes a poor main income for anyone without savings. It is a good use of evenings if you are employed, which is the opposite of how it is usually marketed.
It does not suit you if you need predictable monthly money. Nothing here produces that until you reach private engagements, and reaching those takes a public record that takes months to build.
It does not suit you if you cannot accept discretionary judging. Severity and partial credit are openly at a judge's discretion, and you will sometimes be marked down in ways you think are wrong, with limited recourse.
It does not suit you if you want a fast route. No credential you can buy shortens this. The floor is genuine fluency in reading unfamiliar adversarial code, and that takes months of deliberate work, whatever any course promises.
The honest summary: a high-ceiling, no-floor skill investment with a public scoreboard, best taken on alongside a stable income, by someone who would find it interesting even unpaid. Would you still open that contest repo on a Tuesday night if you knew it would pay nothing this month? If yes, you are the person this suits.
Gotchas Worth Knowing
All your time is unpaid until something lands. There is no retainer, no hourly rate, and nothing for a contest where you find nothing. Budget your hours as an investment and stop thinking of them as paid work.
Payouts come with conditions. Code4rena notes that awards are paid in two batches partly to give winners time to meet payout requirements. Identity verification and sanctions screening are normal in this market, and eligibility can depend on where you live. Check before you put in weeks.
Tax is your problem, and it is not simple. Payment often arrives in stablecoins, and stablecoins are still taxable. Depending on where you live this is self-employment income, prize income, or both, with a taxable event at receipt and possibly another when you dispose of it. Get advice early, well before year end.
Scope rules are strict and worth reading twice. Every programme defines what is in scope, which contracts, which chains, which severity definitions apply, and what is explicitly excluded. Findings outside scope go unpaid however good they are.
Confidentiality is enforced with real consequences. If you publish or discuss findings before the report is out, without permission, you forfeit the award and can be disqualified from the platform.
Live code carries ethical weight. In a bug bounty you are looking at contracts that hold real people's money. Testing on mainnet in ways that could move or lock other people's funds is plainly wrong. Fork the chain locally and test there.
Judging is discretionary, and you will sometimes disagree. Severity assessment and partial credit are openly at the judge's discretion. Appeals exist, and outcomes will still sometimes feel wrong. If you cannot shake that off before your next contest, you will find this exhausting.
Behind the Scenes: A Contest Week
The real thing has a shape most descriptions leave out.
On day one you barely read code. You read documentation, the protocol's own explanation of what it is meant to do, and any previous audit reports. You are building a picture of intended behaviour, because a vulnerability is a gap between intent and implementation, and you cannot see the gap without knowing the intent.
Day two is reading, broadly and without judging. Contracts, inheritance, external calls, where value comes in and goes out, which functions are permissioned and which are open. Resisting the urge to report the first suspicious thing is genuinely hard, and that discipline is what separates good outcomes from poor ones.
By day three you have a list of a dozen suspicions, and you know most of them are intended behaviour, already documented, or things every participant has seen. Triaging that list honestly is where the money is made. For each item, the question to ask yourself is "is this a bug that thirty other people have not already written up?" Asking merely "is this a bug?" sets the bar too low.
Day four is going deep on two or three of them, which means writing tests. Most collapse under a test, and that is the point: the test is what separates a real finding from a plausible story.
On day five, if you are lucky, one holds. Now comes the write-up, which matters more than people expect. A clear description of the vulnerability, the exact conditions, a coded proof of concept, the impact, and a suggested fix.
Then you wait, often for weeks, through judging. Then the results arrive, and you discover that your best finding was found by eleven other people, that one thing you dismissed on day three was a valid High, and that someone you have never heard of found something in a corner of the codebase you never opened.
Then you read the full report properly, which is the part that compounds. Every contest you enter and lose teaches you a class of bug you will spot faster next time. That is the real asset you are building, and it grows whether or not you were paid.
Somewhere past the contest weeks that pay nothing, private engagements start to arrive. Should that work ever hold near 12,000 a month, the high end on this page, for months with enough left after costs, it could let your dad drop the weekend shift for good. Most people take a long time to get there, so start with the contest you lost and work through the bug you missed.
Where This Goes Next
These are arguments about direction, offered without confidence about timing. Use them to position yourself, and keep your plans free of dates.
Tooling raises the floor and pushes value upward. Automated analysis and ever more capable models will find the standard vulnerability classes reliably. That erodes the value of textbook findings, which were already worth little after the duplicate split, and raises the premium on findings that need an understanding of what a protocol is for. The direction matches everywhere else: mechanical detection becomes cheap, and judgment keeps its price.
Contests professionalise and the middle empties. As specialists gather, the gap between serious and casual participants widens, and casual participants will find valid findings harder to come by. Expect the accessible ways in to be the small, narrow engagements, while the flagship pools go to specialists.
Private engagements remain the real income. The public scoreboard is a marketing tool for a services business. Retained security reviews, private audits and protocol security roles pay predictably, and consistent public results are what qualify you for them. If you treat contests as the destination, you are misreading the market; they are your credential.
Scope spreads beyond Solidity. The pool list already includes a Stellar endpoint and a Cosmos bridge. Auditing skill is moving across execution environments, and getting in early on a less crowded chain is one of the few structural ways to shrink the duplicate problem for yourself.
The gap between mean and median stays. Nothing in the reward structure trends toward evenness. A formula that pays 439 times more for a solo find than for one of twenty produces extreme outcomes by design, and protocols want it that way because that is what makes it useful to them. Plan accordingly.
New chains and new protocol types keep opening, and each starts with fewer experienced eyes on it. The people who study one of them now become the auditors protocols request by name. Wait, and you arrive in a category already full of familiar handles.
Liability: What You Are Actually Signing
That settles the work and what it pays. What follows is the risk you take on when you put your name to a report.
This section separates a lasting audit practice from one that ends after a single engagement, and most guidance on entering the field leaves it out.
An audit is a review under limits of time and scope. It cannot be a guarantee, because proving that a non-trivial program has no vulnerabilities at all is beyond what the state of the art can deliver. Audited protocols get exploited. When one does, everyone turns to the report, and the question becomes what you said and how you said it. If an exploit hit a protocol you reviewed, would your report and your notes show exactly what you checked and what you flagged?
The contract terms that matter more than your rate
Four provisions do most of the work protecting you as an independent auditor. Get them in writing before your first engagement, long before any incident.
Scope, stated as commit hashes. The audit covers specific files at a specific commit. Clients routinely change code after your review and ship it under the audit's name, and if your report does not pin the exact commit you reviewed, you will be arguing about what "the audited contract" means at the worst possible moment.
A limitation of liability capped at the fee. No individual can carry uncapped liability against a protocol holding hundreds of millions. A cap at the engagement fee, or a small multiple, is standard in professional services, and reasonable clients accept it.
Clear language that the audit is neither a guarantee nor an endorsement. Put this in the contract and in the report itself, and be specific about what was and was not examined: economic and game-theoretic assumptions, oracle behaviour, governance, off-chain infrastructure and dependencies are all commonly outside a code review, and all common sources of loss.
Control over how your name is used. Protocols market audits, and "audited by" is a trust signal they will use to raise money. Require approval over public use of your name and the report, and require the report to be published in full, with no summarising. A client quoting your name while leaving out the findings you raised is exposing you to a reputational and legal problem of their making.
Insurance, and why the ordinary policy will not respond
Professional indemnity, sometimes sold as errors and omissions cover, is the product you want. Two cautions.
Many policies written for general IT consultancy exclude work involving digital assets, blockchain or financial infrastructure. A policy that excludes the thing you do is worse than no policy, because it feels like protection. Read the exclusions, and get the exclusion tested against your actual work, in writing.
And cover is usually written on a claims-made basis, which means it responds to claims brought while the policy is live, regardless of when you did the work. An exploit can surface years after your review. If you stop practising and stop paying, you may need run-off cover to stay protected for past work.
Findings discipline
Your report is both your work product and your defence, so write it as both.
Record every finding, including the ones the client declines to fix, with the client's decision noted. An unfixed critical finding that you documented and they declined puts you in a very different position from one you only mentioned on a call.
Keep the severity rating honest under pressure. Clients push back on criticals because criticals delay launches and complicate fundraising. Downgrading a finding to keep the engagement pleasant creates exactly the record you never want read back to you.
Keep your working notes as well as the final report. What you tested, what you could not test, and why scope was limited are the facts that show you did a competent review.
Where You Sit in the Regulatory Picture
Auditing is a professional service, so the crypto-specific licensing regimes mostly regulate your clients and leave you alone. Two indirect effects are worth understanding, because they shape your demand.
In the EU, the Markets in Crypto-Assets Regulation applied fully from December 2024, and the Article 143(3) grandfathering for firms operating under earlier national rules ran only until 1 July 2026 or until authorisation was granted or refused. Authorised firms carry governance and operational resilience obligations, and a formal security review is a natural way for them to show they meet those. Regulating your clients tends to increase demand for your work.
The same pattern is showing up elsewhere. Pakistan's Virtual Assets Act 2026 requires virtual asset service providers to be licensed before offering services, and Nigeria's framework now puts specific obligations on service providers and P2P operators. Every licensing regime creates a class of client that needs a documented review, and each one is a potential client for you.
Where your own position does get complicated is payment. Taking fees in the client's token turns your services business into a speculative bet on a client you just audited, creates an obvious independence problem, and produces income taxed at its value on receipt whatever the token does afterwards. Bill in fiat or stablecoin, and if you do take tokens, treat that as a separate investment decision made with open eyes, and never as a discount you offered.