Comparison·8 min का पठन·Solingo द्वारा

Immunefi vs Code4rena vs Sherlock: bugs कहाँ ढूंढें और report करें

Bug bounties live exploits के लिए pay करते हैं, audit contests review work के लिए। यहाँ देखें कि Immunefi, Code4rena और Sherlock payouts, severity, judging और जरूरी skill level में कैसे अलग हैं।

# Immunefi vs Code4rena vs Sherlock: bugs कहाँ ढूंढें और report करें

अगर आप इतना Solidity पढ़ सकते हैं कि एक reentrancy या टूटा हुआ access check पकड़ लें, तो कोई न कोई इसके लिए आपको pay करेगा। असली सवाल है: कहाँ। तीन नाम इस चर्चा पर हावी हैं: Immunefi, Code4rena और Sherlock. बाहर से ये एक जैसे दिखते हैं (bug ढूंढो, payment लो) लेकिन ये मूल रूप से अलग काम को reward करते हैं। एक live exploits के लिए pay करता है, बाकी दो deadline के खिलाफ किए गए review work के लिए। अपनी situation के लिए गलत platform चुनना हफ्तों की बर्बादी है।

यह article payout और severity models, judging, time commitment, और किस platform वास्तव में beginner बनाम अनुभवी auditor के लिए सही है, इसको तोड़कर समझाता है।

मूल विभाजन: bounties vs contests

यहाँ दो अलग business models हैं, और यह अंतर बाकी सब कुछ तय करता है।

Bug bounty (Immunefi). एक protocol पहले से deployed और असली funds रखने वाले code पर एक स्थायी program publish करता है। आप अपने schedule पर hunt करते हैं। अगर आपको कोई valid और in-scope vulnerability मिलती है, तो आप एक private report submit करते हैं और उसकी severity के आधार पर pay पाते हैं। कोई deadline नहीं, कोई shared pool नहीं। अगर आप किसी unique bug को सबसे पहले report करते हैं, तो reward आपका है।

Audit contest (Code4rena, Sherlock). एक protocol समय-सीमित competition खोलता है (अक्सर कुछ दिनों से लेकर दो हफ्तों तक) ऐसे code पर जो आमतौर पर अभी mainnet पर नहीं होता। कई auditors एक ही codebase को एक साथ review करते हैं। एक shared prize pool उन सबके बीच बाँटा जाता है जो valid issues report करते हैं, severity के अनुसार weighted, और कुछ platforms पर इस आधार पर भी कि कितने लोगों को वही चीज़ मिली।

व्यावहारिक नतीजा: bounties live targets पर depth और patience को reward करते हैं, contests fresh code पर speed और breadth को। एक duplicate finding bounty पर बेकार है (कोई आपसे आगे निकल गया) लेकिन contest में फिर भी एक हिस्सा pay करती है।

Severity और payout models

तीनों एक जैसी severity ladder पर टिके हैं, लेकिन पैसा अलग तरह से व्यवहार करता है।

Immunefi

Immunefi ने severity को एक vulnerability classification system के इर्द-गिर्द standardize किया है जिसमें Critical, High, Medium, Low जैसे levels हैं। Smart contract के critical findings आमतौर पर वो होते हैं जो funds चुराने या स्थायी रूप से freeze करने देते हैं। Payouts program से जुड़े होते हैं: कई गंभीर DeFi programs critical reward को funds at risk के percentage के रूप में cap करते हैं, बड़े absolute maximums के साथ। सबसे अहम: एक live contract पर असली exploit पूरे क्षेत्र में सबसे ज्यादा pay करने वाला single outcome है, क्योंकि protocol एक असली loss से बच रहा होता है।

इसका trade-off: आप बिना चेतावनी के पूरी दुनिया से मुकाबला कर रहे हैं, और ज्यादातर reports duplicate या out of scope होती हैं। Income असमान होती है। आप एक महीना बिता सकते हैं और payable कुछ न मिले।

Code4rena

Code4rena अधिकांश pool के लिए High, Medium को paid severity tiers के रूप में इस्तेमाल करता है, जबकि QA (quality assurance) और gas optimization reports अलग से और कम value पर handle की जाती हैं। Prize pool पहले से तय होता है। किसी issue पर आपका हिस्सा severity पर और इस पर निर्भर करता है कि finding उन सबके बीच कैसे बँटी जिन्होंने उसे report किया। एक ऐसा High report करना जो बीस और लोगों को भी मिला, उस High से कहीं कम pay करता है जो केवल आपको मिला।

यह दुर्लभ bugs ढूंढने का असली incentive बनाता है, सिर्फ obvious वाले नहीं। Beginners अक्सर आसान Mediums farm करते हैं और छोटे payouts के साथ रह जाते हैं; leaderboard पर वही हावी होते हैं जो लगातार unique Highs सामने लाते हैं।

Sherlock

Sherlock भी मुख्य रूप से High और Medium पर pay करता है, एक fixed contest pool के साथ, लेकिन दो उल्लेखनीय mechanics जोड़ता है। पहला, इसने ऐतिहासिक रूप से कुछ audits पर एक coverage या guarantee component पेश किया है, जिससे judging की सटीकता का दांव बढ़ जाता है। दूसरा, इसकी severity definitions सख्त और codified हैं, जिससे बहस कम होती है लेकिन इसका मतलब यह भी है कि borderline findings ज्यादा आक्रामक तरीके से downgrade होती हैं। Sherlock उन auditors को आकर्षित करता है जो सटीक, rules-driven judging पसंद करते हैं।

Judging कैसे काम करती है

Judging पर ये platforms सबसे ज्यादा अलग महसूस होते हैं, और यही वह हिस्सा है जिसे beginners कम आँकते हैं।

  • Immunefi: protocol team (कभी-कभी mediation के साथ) validity और severity तय करती है। आपको आमतौर पर एक working proof of concept चाहिए जो impact दिखाए, सिर्फ एक theory नहीं। विवाद निजी तौर पर निपटते हैं।
  • Code4rena: contest बंद होने के बाद समर्पित judges सभी submissions review करते हैं, उन्हें deduplicate करते हैं, severity assign करते हैं, और community comment कर सकती है। यह पारदर्शी है और आप देख सकते हैं कि आपकी report दूसरों के मुकाबले कैसी रही।
  • Sherlock: एक head-of-judging और protocol का input, एक औपचारिक rules document के साथ। एक escalation/appeals window होती है जहाँ आप rules का हवाला देकर अपना case रख सकते हैं।

साझा बात: एक अस्पष्ट report हर जगह reject होती है। ठोस attack path और impact के बिना finding सिर्फ शोर है।

एक fundable report वास्तव में कैसी दिखती है

Severity impact के बारे में है, चतुराई के बारे में नहीं। यहाँ एक classic high-impact pattern है: एक withdrawal जो external call के बाद state update करती है, जिससे reentrancy संभव होती है।

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.24;

contract Vault {

mapping(address => uint256) public balances;

function deposit() external payable {

balances[msg.sender] += msg.value;

}

// Vulnerable: state update से पहले external call

function withdraw(uint256 amount) external {

require(balances[msg.sender] >= amount, "insufficient");

(bool ok, ) = msg.sender.call{value: amount}("");

require(ok, "transfer failed");

balances[msg.sender] -= amount; // बहुत देर हो गई

}

}

Fix checks-effects-interactions order का पालन करता है:

function withdraw(uint256 amount) external {

require(balances[msg.sender] >= amount, "insufficient");

balances[msg.sender] -= amount; // पहले effect

(bool ok, ) = msg.sender.call{value: amount}("");

require(ok, "transfer failed");

}

platform चाहे जो हो, आप इसे एक proof of concept से support करते हैं। Foundry के साथ चलने वाला PoC ऐसा दिखता है:

forge test --match-test testReentrancyDrainsVault -vvvv

एक judge attacker contract, call sequence, और अंतिम balance delta देखना चाहता है। "यह reentrant लगता है" एक submission नहीं है; एक test जो vault खाली कर दे, वह है।

Time commitment

  • Immunefi खुला है। आप एक घंटे के लिए झाँक सकते हैं या किसी target को हफ्तों grind कर सकते हैं। कोई clock नहीं, लेकिन बिताए गए समय के लिए कोई guaranteed payout भी नहीं।
  • Code4rena contests तीव्र sprints हैं। एक गंभीर entry का मतलब है एक छोटी window के भीतर कई focused दिन, अक्सर रातें और weekends, क्योंकि pool सबके लिए एक ही पल में बंद होता है।
  • Sherlock की cadence Code4rena जैसी है, इस अतिरिक्त दबाव के साथ कि सख्त judging एक जल्दबाजी में, कम justified report को सजा देती है।

अगर आपकी day job है, तो contests एक calendar collision पैदा करते हैं। Bounties आपको async काम करने देते हैं।

कौन सा platform आपके लिए सही है

अगर आप beginner हैं

contests से शुरू करें, और Code4rena से शुरू करें। क्यों:

  • पुराने contests की public reports एक मुफ्त curriculum हैं। आप winning submissions पढ़कर उनकी अपनी से तुलना कर सकते हैं।
  • आंशिक, duplicated findings भी एक छोटा हिस्सा कमा सकती हैं, इसलिए feedback loop bounty के all-or-nothing model से तेज़ है।
  • आप report format, deduplication, और severity arguments एक structured माहौल में सीखते हैं।
  • कुछ contests करें, top finders कैसे लिखते हैं इसका अध्ययन करें, और live bounties के पीछे तभी भागें जब आप भरोसेमंद रूप से एक working PoC बना सकें।

    अगर आप अनुभवी हैं

    • Immunefi वहाँ है जहाँ सबसे बड़े single payouts मिलते हैं, अगर आप एक unique live bug ढूंढ सकें और end to end impact साबित कर सकें। यह उन specialists को reward करता है जो एक protocol में गहराई तक जाते हैं।
    • Sherlock उन अनुशासित auditors को reward करता है जो सटीक, rules-aligned reports लिखते हैं और सख्त downgrades से परेशान नहीं होते।
    • Code4rena range को reward करता है: जो लोग कई contests में लगातार unique Highs सामने लाते हैं, वे एक मजबूत, public track record बनाते हैं।

    कई professional auditors तीनों करते हैं: स्थिर, public reputation के लिए contests और कभी-कभार के बड़े hit के लिए live bounties।

    ठोस तरीके से शुरुआत कैसे करें

  • toolchain बनाएं। Foundry सीखें, tests लिखें, और bugs reproduce करने के लिए mainnet state fork करने में सहज हों।
  • public reports पढ़ें। Code4rena और Sherlock पुराने findings publish करते हैं। explanation पढ़ने से पहले हर bug को source से फिर से derive करें।
  • एक live contest चुनें और submit करें, भले ही आप zero payout की उम्मीद करें। मकसद format और judging सीखना है।
  • एक bug pattern library रखें। Reentrancy, access control, oracle/price manipulation, rounding और precision loss, unchecked external calls, और upgrade/storage collisions लगातार दोहराते हैं।
  • तभी bounties के पीछे भागें। बिना PoC के एक bounty submission सबका समय बर्बाद करती है, आपका भी।
  • मुकाबले से पहले अभ्यास करें

    Contest सफलता का सबसे अच्छा predictor pattern recognition है: एक known class का bug अनजान code में तेज़ी से देख लेना। यह एक trainable skill है, और इसे exercises पर train करना एक prize pool में live सीखने से सस्ता है।

    app.solingo-blockchain.xyz पर आप उन्हीं vulnerability classes का अभ्यास कर सकते हैं जिनके लिए judges pay करते हैं, जानबूझकर टूटे हुए contracts audit कर सकते हैं, और उस तरह के ठोस, impact-first findings लिखने का अभ्यास कर सकते हैं जो accept होते हैं। पहले reflex बनाएं, फिर इसे एक असली contest में ले जाएं।

    Practice में लगाने के लिए तैयार हैं?

    Solingo पर interactive exercises के साथ इन concepts को apply करें।

    मुफ्त में शुरू करें