├── .gitbook └── assets │ ├── Screenshot 2023-05-31 at 12.12.10 PM.png │ ├── Screenshot 2023-05-31 at 12.14.42 PM.png │ ├── image (1) (1) (1).png │ ├── image (1) (1).png │ ├── image (1) (2).png │ ├── image (1).png │ ├── image (10).png │ ├── image (11) (1).png │ ├── image (11).png │ ├── image (12).png │ ├── image (13).png │ ├── image (14).png │ ├── image (15).png │ ├── image (16).png │ ├── image (17).png │ ├── image (2) (1) (1).png │ ├── image (2) (1).png │ ├── image (2) (2).png │ ├── image (2).png │ ├── image (3) (1) (1).png │ ├── image (3) (1).png │ ├── image (3) (2).png │ ├── image (3) (3).png │ ├── image (3).png │ ├── image (4) (1).png │ ├── image (4).png │ ├── image (5).png │ ├── image (6).png │ ├── image (7).png │ ├── image (8) (1).png │ ├── image (8).png │ ├── image (9).png │ └── image.png ├── .report ├── README.md ├── audit-item.md ├── audit-report.yml └── examples │ ├── perpetual-118.md │ ├── perpetual-123.md │ ├── titles-264.md │ └── titles-269.md ├── CONTEST_QA_README.csv ├── README.md ├── SUMMARY.md ├── TODO ├── audits ├── judging │ ├── README.md │ ├── community-judging.md │ ├── dedicated-judge.md │ ├── discussion.md │ ├── guidelines │ │ ├── README.md │ │ └── criteria-changelog.md │ ├── judging-conduct-guidelines.md │ ├── lead-judge.md │ └── sherlocks-exclusive-judging-apprentice-program.md ├── protocols │ ├── README.md │ ├── audit-preparation.md │ ├── audit-pricing-and-timeline.md │ ├── how-it-works-for-protocols.md │ ├── interim-updates-and-upgrades.md │ ├── protocol-involvement-during-the-audit-process.md │ ├── protocol-involvement-post-audit.md │ ├── rescheduling-and-cancellations.md │ └── scheduling-process.md ├── referral-program.md └── watsons │ ├── README.md │ ├── contest-points.md │ ├── faq.md │ ├── first-submission-pot.md │ ├── fix-review-process.md │ ├── how-to-score-issue-points-in-a-contest.md │ ├── lead-senior-watson-selection-process.md │ ├── meeting-the-payout-criteria.md │ └── watson-points-example.md ├── bug-bounties ├── post-launch-bounty │ ├── README.md │ ├── dispute-resolution.md │ └── platform-rules.md └── pre-launch-bounty.md ├── claims-assessment └── deciding-on-payouts.md ├── claims └── claims-process.md ├── coverage ├── claims │ └── README.md ├── protocols │ ├── README.md │ ├── composability-and-coverage.md │ └── faq.md ├── sherlock-shield.md └── staking-apy │ └── README.md ├── developer ├── audits.md ├── claims.md ├── contract-reference.md ├── deployed-contracts.md ├── overview.md ├── protocols.md ├── sher-distribution.md └── stake-position.md ├── developers ├── contract-reference.md └── deployed-contracts.md ├── disclaimers.md ├── faq.md ├── glossary.md ├── governance └── roles.md ├── protocols ├── exploit-flow.md ├── getting-started.md ├── initiating-coverage.md ├── premium-payment-mechanics.md ├── premium-tokens.md ├── premiums.md ├── pricing.md └── protocol-premiums.md ├── security-team ├── incentives.md ├── intro.md └── payout-mechanism.md ├── stakers ├── activate-cooldown.md ├── explaining-the-cooldown.md ├── exploit-flow.md ├── harvest.md ├── interest-streams.md ├── lockup-period.md ├── overview.md ├── staking-APY.md ├── transfer.md └── unstaking.md └── tokens ├── locktokens.md ├── receipt-nfts.md ├── sher.md └── sherx.md /.gitbook/assets/Screenshot 2023-05-31 at 12.12.10 PM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/Screenshot 2023-05-31 at 12.12.10 PM.png -------------------------------------------------------------------------------- /.gitbook/assets/Screenshot 2023-05-31 at 12.14.42 PM.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/Screenshot 2023-05-31 at 12.14.42 PM.png -------------------------------------------------------------------------------- /.gitbook/assets/image (1) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (1) (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (1) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (1) (2).png -------------------------------------------------------------------------------- /.gitbook/assets/image (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (10).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (10).png -------------------------------------------------------------------------------- /.gitbook/assets/image (11) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (11) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (11).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (11).png -------------------------------------------------------------------------------- /.gitbook/assets/image (12).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (12).png -------------------------------------------------------------------------------- /.gitbook/assets/image (13).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (13).png -------------------------------------------------------------------------------- /.gitbook/assets/image (14).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (14).png -------------------------------------------------------------------------------- /.gitbook/assets/image (15).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (15).png -------------------------------------------------------------------------------- /.gitbook/assets/image (16).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (16).png -------------------------------------------------------------------------------- /.gitbook/assets/image (17).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (17).png -------------------------------------------------------------------------------- /.gitbook/assets/image (2) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (2) (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (2) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (2) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (2) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (2) (2).png -------------------------------------------------------------------------------- /.gitbook/assets/image (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (2).png -------------------------------------------------------------------------------- /.gitbook/assets/image (3) (1) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (3) (1) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (3) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (3) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (3) (2).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (3) (2).png -------------------------------------------------------------------------------- /.gitbook/assets/image (3) (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (3) (3).png -------------------------------------------------------------------------------- /.gitbook/assets/image (3).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (3).png -------------------------------------------------------------------------------- /.gitbook/assets/image (4) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (4) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (4).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (4).png -------------------------------------------------------------------------------- /.gitbook/assets/image (5).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (5).png -------------------------------------------------------------------------------- /.gitbook/assets/image (6).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (6).png -------------------------------------------------------------------------------- /.gitbook/assets/image (7).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (7).png -------------------------------------------------------------------------------- /.gitbook/assets/image (8) (1).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (8) (1).png -------------------------------------------------------------------------------- /.gitbook/assets/image (8).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (8).png -------------------------------------------------------------------------------- /.gitbook/assets/image (9).png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image (9).png -------------------------------------------------------------------------------- /.gitbook/assets/image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sherlock-protocol/sherlock-v2-docs/1d4d8018e45e33ab27ce245b0fb44bfbb59f1a95/.gitbook/assets/image.png -------------------------------------------------------------------------------- /.report/README.md: -------------------------------------------------------------------------------- 1 | # Title 2 | Structure: {actor} will {impact} {affected party} 3 | Example: 4 | - Malicious fee managers will steal funds from stakers 5 | - Attacker will lower the APY for stakers 6 | - Protocol will distribute insufficient fees to token holders 7 | 8 | ### Summary 9 | Structure: {root cause} will cause [a/an] {impact} for {affected party} as {actor} will {attack/vulernability path} 10 | Example: 11 | - The missing check in stake.sol will cause a complete loss of funds for stakers as an attacker will frontrun their transactions 12 | - An incorrect calculation in lp.sol will cause a DoS for admins as the protocol will revert on every update 13 | 14 | ### Root Cause 15 | 16 | __In case it’s a mistake in the code:__ 17 | - In {link to code} the {root cause} 18 | 19 | Example: 20 | - In stake.sol:551 there is a missing check on transfer function 21 | - In lp.sol:12 the fee calculation does division before multiplication which will revert the transaction on lp.sol:18 22 | 23 | __In case it’s a conceptual mistake:__ 24 | - The choice to {design choice} is a mistake as {root cause} 25 | 26 | Example: 27 | - The choice to use Uniswap as an oracle is a mistake as the price can be manipulated 28 | - The choice to depend on Protocol X for admin calls is a mistake as it will cause any call to revert 29 | 30 | ### Internal pre-conditions 31 | 32 | A numbered list of conditions to allow the attack path or vulnerability path to happen: 33 | 1. [{Role} needs to {action} to set] {variable} to be [at least / at most / exactly / other than] {value} 34 | 2. [{Role} needs to {action} to set] {variable} to go from {value} to {value} [within {time}] 35 | 36 | Example 37 | - Admin needs to call `setFee()` to set `fee` to be exactly `1 ETH` 38 | - Number ETH in the `stake.sol` contract to be at least `500 ETH` 39 | 40 | ### External pre-conditions 41 | 42 | > Similar to internal but it describes changes in the external protocols 43 | 44 | - ETH oracle needs to go from 4000 to 5000 within 2 minutes 45 | - Gas price needs to be exactly 100 wei 46 | 47 | ### Attack Path: 48 | 49 | A numbered list of steps, talking through the attack path: 50 | 1. {Role} calls {function}..... 51 | 52 | ### Impact 53 | In case it's an __attack path:__ 54 | 55 | The {affected party} suffers an approximate loss of {value}. [The attacker gains {gain} or loses {loss}]. 56 | 57 | Example: 58 | - The stakers suffer a 50% loss during staking. The attacker gains this 50% from stakers. 59 | - The protocol suffers a 0.0006 ETH minting fee. The attacker loses their portion of the fee and doesn't gain anything (griefing). 60 | 61 | In case it's a __vulnerability path:__ 62 | 63 | The {affected party} [(suffers an approximate loss of {value} OR cannot {execute action})]. 64 | 65 | Example: 66 | - The users suffer an approximate loss of 0.01% due to precision loss. 67 | - The user cannot mint tokens. 68 | 69 | ### PoC 70 | 71 | ### Mitigation -------------------------------------------------------------------------------- /.report/audit-item.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Audit item 3 | about: These are the audit items that end up in the report 4 | title: "" 5 | labels: "" 6 | assignees: "" 7 | --- 8 | 9 | ## Summary 10 | 11 | ## Vulnerability Detail 12 | 13 | ## Impact 14 | 15 | ## Code Snippet 16 | 17 | ## Tool used 18 | 19 | Manual Review 20 | 21 | ## Recommendation -------------------------------------------------------------------------------- /.report/audit-report.yml: -------------------------------------------------------------------------------- 1 | name: Audit Item 2 | description: Current version of the audit items that end up in the report 3 | labels: [] 4 | projects: [] 5 | title: "{actor} will {impact} {affected party}" 6 | body: 7 | - type: textarea 8 | id: summary 9 | attributes: 10 | label: Summary 11 | description: "A summary with the following structure: **{root cause} will cause [a/an] {impact} for {affected party} as {actor} will {attack path}**" 12 | placeholder: "The missing check in `stake.sol` will cause a complete loss of funds for stakers as an attacker will frontrun their transactions" 13 | validations: 14 | required: true 15 | - type: textarea 16 | id: root 17 | attributes: 18 | label: Root Cause 19 | description: | 20 | In case it’s a mistake in the code: **In {link to code} the {root cause}** 21 | 22 | _Example:_ 23 | _- In `stake.sol:551` there is a missing check on transfer function_ 24 | _- In `lp.sol:12` the fee calculation does division before multiplication which will revert the transaction on `lp.sol:18`_ 25 | 26 | In case it’s a conceptual mistake: **The choice to {design choice} is a mistake as {root cause}** 27 | 28 | _Example:_ 29 | _- The choice to use Uniswap as an oracle is a mistake as the price can be manipulated_ 30 | _- The choice to depend on Protocol X for admin calls is a mistake as it will cause any call to revert_ 31 | placeholder: "In `stake.sol:551` there is a missing check on transfer function" 32 | validations: 33 | required: true 34 | - type: textarea 35 | id: internal-pre 36 | attributes: 37 | label: Internal pre-conditions 38 | description: | 39 | A numbered list of conditions to allow the attack path or vulnerability path to happen: 40 | 1. [{Role} needs to {action} to set] {variable} to be [at least / at most / exactly / other than] {value} 41 | 2. [{Role} needs to {action} to set] {variable} to go from {value} to {value} [within {time}] 42 | 43 | _Example:_ 44 | _- Admin needs to call `setFee()` to set `fee` to be exactly `1 ETH`_ 45 | _- Number of ETH in the `stake.sol` contract to be at least `500 ETH`_ 46 | placeholder: | 47 | 1. Admin needs to call `setFee()` to set `fee` to be exactly `1 ETH` 48 | 2. `lendingRate` to be other than `1.0` 49 | 3. Number of ETH in `stake.sol` to go from `10 ETH` to `100 ETH` within 24 hours 50 | validations: 51 | required: true 52 | - type: textarea 53 | id: external-pre 54 | attributes: 55 | label: External pre-conditions 56 | description: | 57 | > Similar to internal pre-conditions but it describes changes in the external protocols 58 | 59 | _Example:_ 60 | _- ETH oracle needs to go from `4000` to `5000` within 2 minutes_ 61 | _- Gas price needs to be exactly `100 wei`_ 62 | placeholder: | 63 | 1. ETH oracle needs to go from `4000` to `5000` within 2 minutes 64 | 2. Gas price needs to be exactly `100 wei` 65 | validations: 66 | required: true 67 | - type: textarea 68 | id: attack 69 | attributes: 70 | label: Attack Path 71 | description: | 72 | A numbered list of steps, talking through the attack path: 73 | 74 | 1. **{Role} calls {function} {extra context}** 75 | 2. .. 76 | placeholder: | 77 | 1. The work calls `decrease()` and sets `mintFee` to 0.03 ETH. 78 | 2. The user calls `mint()` and uses an outdated version as he calls with 0.05 ETH as `msg.value` to pay the 0.03 ETH `mintFee` 79 | validations: 80 | required: true 81 | - type: textarea 82 | id: impact 83 | attributes: 84 | label: Impact 85 | description: | 86 | In case it's an attack path: **The {affected party} suffers an approximate loss of {value}. [The attacker gains {gain} or loses {loss}].** 87 | 88 | _Example:_ 89 | _- The stakers suffer a 50% loss during staking. The attacker gains this 50% from stakers._ 90 | _- The protocol suffers a `0.0006` ETH minting fee. The attacker loses their portion of the fee and doesn't gain anything (griefing)._ 91 | 92 | In case it's a vulnerability path: **The {affected party} [suffers an approximate loss of {value} OR cannot {execute action}].** 93 | 94 | _Example:_ 95 | _- The users suffer an approximate loss of 0.01% due to precision loss._ 96 | _- The user cannot mint tokens._ 97 | placeholder: | 98 | The protocol suffers a `0.0006` ETH minting fee. The attacker loses their portion of the fee and doesn't gain anything 99 | validations: 100 | required: true 101 | - type: textarea 102 | id: poc 103 | attributes: 104 | label: PoC 105 | description: | 106 | A coded PoC. [Required in some cases](https://docs.sherlock.xyz/audits/judging/judging#vi.-requirements) but optional for other cases. 107 | placeholder: | 108 | ```solidity 109 | // SPDX-License-Identifier: GPL-3.0-or-later 110 | pragma solidity >=0.8.0; 111 | 112 | import "forge-std/Test.sol"; 113 | ... 114 | ``` 115 | validations: 116 | required: false 117 | - type: textarea 118 | id: mitigaton 119 | attributes: 120 | label: Mitigation 121 | description: | 122 | Mitigation of the issue (optional) 123 | validations: 124 | required: false 125 | -------------------------------------------------------------------------------- /.report/examples/perpetual-118.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://github.com/sherlock-audit/2024-02-perpetual-judging/issues/118 3 | --- 4 | 5 | # The attacker will steal funds from SpotHedgeBaseMaker LPs 6 | 7 | ### Summary 8 | 9 | Calculating the price based on USD value and not USDT/USDC will cause loss of funds for SpotHedgeBaseMaker LPs as the attacker will withdraw more funds during the USDC/USDT de-peg. 10 | 11 | 12 | ### Root Cause 13 | 14 | The choice to denominate all the tokens value in USD is a mistake as USDT/USDC (collateral tokens) are susceptible to de-pegs and allow to withdraw more value than the attacker should be able to. 15 | 16 | 17 | ### Internal pre-conditions 18 | 19 | 1. The vault LP account (PnL for all of the SpotHedgeBaseMaker's LPs) has a non-zero collateral token balance 20 | 2. The SpotHedgeBaseMaker has a non-zero base token balance 21 | 3. The attacker holds LP shares worth less than or equal to the SpotHedgeBaseMaker's base tokens holding's value 22 | 23 | ### External pre-conditions 24 | 25 | 1. The USDC/USDT price to be less than $1 26 | 27 | 28 | ### Attack Path: 29 | 30 | 1. The attacker calls [`withdraw`] during USDC/USDT 30% de-peg for an amount less than or equal to the base token balance, but the collateral tokens are still valued as if there's no de-peg (100% instead of 70%). 31 | 32 | 33 | ### Impact 34 | 35 | The other LPs suffer an approximate loss of 30% when the collateral tokens need to be swapped to base tokens. The attacker gains this 30%, having not had to do the swap. 36 | 37 | 38 | ### PoC 39 | 40 | - 41 | 42 | 43 | ### Mitigation 44 | 45 | Use the \/USD oracle to convert the \/USD price to a \/\ oracle -------------------------------------------------------------------------------- /.report/examples/perpetual-123.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://github.com/sherlock-audit/2024-02-perpetual-judging/issues/123 3 | --- 4 | 5 | # Attacker will steal funds from LPs 6 | 7 | ### Summary 8 | 9 | The choice to depend on Pyth oracles will cause a loss of funds for LPs as the attacker will use the Pyth oracles to manipulate the price during `deposit()` and `withdraw()` 10 | 11 | ### Root Cause 12 | 13 | The choice to depend on Pyth oracles is a mistake as there is no guarantee that the current price is the freshest price 14 | 15 | ### Internal pre-conditions 16 | 17 | - 18 | 19 | ### External pre-conditions 20 | 21 | 1. Two signed prices with a difference in price 22 | 23 | ### Attack Path 24 | 25 | 1. Attacker calls `deposit()` with the low price 26 | 2. Attacker calls `withdraw()` with the high price 27 | 28 | ### Impact 29 | 30 | LPs suffer an approximate loss equal to the attacker's profit 31 | 32 | 33 | ### PoC 34 | 35 | - 36 | 37 | ### Mitigation 38 | 39 | Require that LP deposits and withdrawals be done by the trusted relayers or use a different oracle 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /.report/examples/titles-264.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://github.com/sherlock-audit/2024-04-titles-judging/issues/264 3 | --- 4 | 5 | # An attacker will avoid paying fees to protocol and fee recepients. 6 | 7 | ### Summary 8 | Incorrect values in [`Edition::mintBatch::L304`](https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L304) will cause an almost complete loss of fees for the protocol and fee recepients as the attacker will pay only for one token. 9 | 10 | ### Root Cause 11 | In [`Edition::mintBatch`](https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L312C28-L312C37) the fees are calculated based on the `amount` of tokens to mint, when the minting itself is made on the number of recepients. 12 | 13 | ### Internal pre-conditions 14 | 15 | - 16 | 17 | ### External pre-conditions 18 | 19 | - 20 | 21 | ### Attack path 22 | 23 | 1. The attacker calls `mintBatch` with `amount_` set to 1 `receivers` set to 1000 addresses. At `L312` the code collects mint fee based on the `amount_` value. In this case fee for only 1 token will be taken. At `L315-L316` the code loops over each address in `receivers_` array and mints a new token for each. Hence, 1000 tokens are minted. The attacker paid fees for only one token, instead of 1000. 24 | 25 | ### Impact 26 | The protocol and fee recepients suffer a 0.999 ETH loss. 27 | 28 | ### PoC 29 | 30 | - 31 | 32 | ### Mitigation 33 | Consider the following change to ensure that the minting is computed based on the total number of tokens minted to all receivers: 34 | ```diff 35 | function mintBatch( 36 | address[] calldata receivers_, 37 | uint256 tokenId_, 38 | uint256 amount_, 39 | bytes calldata data_ 40 | ) external payable { 41 | // wake-disable-next-line reentrancy 42 | FEE_MANAGER.collectMintFee{value: msg.value}( 43 | - this, tokenId_, amount_, msg.sender, address(0), works[tokenId_].strategy 44 | + this, tokenId_, amount_ * receivers_.length, msg.sender, address(0), works[tokenId_].strategy 45 | ); 46 | 47 | for (uint256 i = 0; i < receivers_.length; i++) { 48 | _issue(receivers_[i], tokenId_, amount_, data_); 49 | } 50 | 51 | _refundExcess(); 52 | } 53 | ``` -------------------------------------------------------------------------------- /.report/examples/titles-269.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://github.com/sherlock-audit/2024-04-titles-judging/issues/269 3 | --- 4 | 5 | # Protocol will not refund excess fees to users 6 | 7 | ### Description 8 | The incorrect `msg.value` in Edition.sol will cause a loss of excess fees for users as the protocol will send the entire `msg.value` into `FeeManager` contract instead of `mintFee`. 9 | 10 | ### Root Cause 11 | In [`Edition.sol::mint::L236`](https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L236) the entire `msg.value` is sent to FeeManager, but is not returned back in [`FeeManager::collectMintFee`](https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/fees/FeeManager.sol#L183). Hence, if excess ETH is sent, it's not refunded to the user on [`Edition::mint::L241`](https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L241). 12 | 13 | ### Internal pre-conditions 14 | 15 | 1. The work publisher needs to call [`Edition::setFeeStrategy`](https://github.com/sherlock-audit/2024-04-titles/blob/d7f60952df22da00b772db5d3a8272a988546089/wallflower-contract-v2/src/editions/Edition.sol#L368) to set `mintFee` to go from `X` to ` **Purpose:** To quickly crowdsource (with advanced signal scores) judgments, explanations, and de-duplication for each issue to reduce the workload for the Lead Judge. 12 | 13 | * Happens right after the audit contest ends 14 | * Lasts a fixed number of days (# of issues / 100) days (for example 500 issues would be 5 days), with a minimum of 2 days. 15 | * Dedicated Judges sign up ahead of time to give certainty that all issues will be judged and de-duplicated by the end of this period 16 | * Often, 90% of issues are judged accurately within 12-24 hours, allowing a protocol team to start on any fixes 17 | 18 | The Dedicated Judges need to judge all issues during the fixed number of days. See [Dedicated Judge](audits/real-time-judging/dedicated-judge.md) for more details. 19 | 20 | ### Phase 2: Lead Judge 21 | 22 | > **Purpose:** What's the purpose of this phase? Real-Time Judging often surfaces controversial and/or complex issues that are best judged by a top-tier security expert. 23 | 24 | * The Lead Judge will know his start date as soon as the contest ends (if 500 issues then he starts 5 days after the contest ends) 25 | * Lead Judge gets (# of issues / 200) days to do this preliminary judging, with a minimum of 2 days. (so 500 issues would round up to 3 days) 26 | * Lead Judge only needs to focus on the controversial issues (flagged in Real-Time Judging) during this phase 27 | * Lead Judge must write an explanation for every judgment 28 | * The Lead Judge may begin judging before the official start date. 29 | 30 | {% hint style="success" %} 31 | Checkpoint: Preliminary Results Announced 32 | {% endhint %} 33 | 34 | ### Phase 3: Escalation Period 35 | 36 | > **Purpose:** Sometimes a Watson will want to flag something they believe the Lead Judge got wrong. 37 | 38 | * After the preliminary results are announced, Watsons have 24 hours to flag any issues for re-review 39 | * Watsons must pay with their Signal Score to flag an issue 40 | * Watsons can then leave an extra comment explaining their rationale 41 | 42 | ### Phase 4: Final Judgments 43 | 44 | > **Purpose:** The Lead Judge will re-review any issues flagged during the Escalation Period. The Sherlock Judge will supervise and interject if needed. 45 | 46 | * The Lead Judge gets (# of controversial issues / 20) days to complete Phase 4, with a minimum of 2 days. 47 | * Lead Judge will review all controversial issues (new ones from the Escalation Period and old ones that he already judged) 48 | * Lead Judge will make final decisions on all controversial issues 49 | * The Sherlock Judge will closely monitor the decisions during Phase 4, be available for any questions, ask questions if something is unclear, and only overturn a decision if it’s clearly wrong. 50 | 51 | {% hint style="success" %} 52 | Checkpoint: Final Results Announced 53 | {% endhint %} 54 | 55 | -------------------------------------------------------------------------------- /audits/judging/community-judging.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: You’re going to review some issues anyway, why not get paid for it? 3 | --- 4 | 5 | # 🧑‍⚖️ Real-Time Judging 6 | 7 | ### What’s in it for me? 8 | 9 | Roughly 8% of the value of the audit contest pot will be set aside as rewards for judges. If an audit has a $50,000 pot, then the portion of the judging pot that will be publicly available is \~$4,000. 10 | 11 | There’s no requirement to judge all of the issues submitted in a contest. If you judge 1 very difficult issue correctly, you could technically earn the majority of the judging pot. 12 | 13 | ### How can I become a Judge? 14 | 15 | If you submit at least 1 valid issue in a Sherlock contest, you are eligible to participate in judging. 16 | 17 | Watsons that were on the audit or legacy judging leaderboard at the time of announcement will start with an initial signal score. 18 | 19 | ### What is Real-Time Judging? 20 | 21 | Real-Time Judging is a live judging contest where hundreds of Judges can contribute to judging contest issues at the same time. Normally \~8% of the audit contest pot is allocated to the judging pot. You can earn USDC by judging just one issue! 22 | 23 | You’ll be able to track every issue’s severity and duplication progress in the Overview page. You’ll also be able to see each issue’s severity and duplication status. This page will constantly update to show the latest votes of every Watson. 24 | 25 | ![](https://lh7-rt.googleusercontent.com/docsz/AD\_4nXfxORK3RQQV9cts-KCLL3Kzwf7XlX2Xn4s7vFXqbeGvglGHrJxaV5ASGuQvSf5hJncNHC5LIlfHf\_g3xMhzi0NzaEqucg3y04Sweeb8LbUIPvY5vLIDwFn0pfhEh3LZBsPPFfOYc7wvcaEIszqJzaMgpDoZ?key=vBHXKQdJakMdc1gIGcMF8w) 26 | 27 | If you want to participate, you can click on any issue to view the issue description, vote on the duplication status and choose the severity (High, Medium, Invalid). 28 | 29 | ![](https://lh7-rt.googleusercontent.com/docsz/AD\_4nXfunEKJYB2KkuBoI9mll1dGqcGBLsFS5wiviNgeB-yLLW4Q4KXbCKOfNftSk\_JUCtw6gcKX5Xjf-3KDOxswdZvjCrdfanRdxoDhTPjO0KUezkEzhr0cBkr7aPT2Ql17G2qQVj8r4JICnL76CTg\_UrYS3Nyw?key=vBHXKQdJakMdc1gIGcMF8w)\ 30 | \ 31 | 32 | 33 | ### Real-Time Judging Timeline 34 | 35 | Judging goes live right after the audit contest ends. You can find it in the [Contests](https://audits.sherlock.xyz/contests) section of the Sherlock app. It will be available for any contest in the “Judging” stage. 36 | 37 | Each issue must hit 100% on the Severity and Duplication Progress to be in the “Finalizable” state. When every issue reaches this state, the contest judging progress will reach 100% and the preliminary results can be viewed. Voting is still live during this phase. 38 | 39 | After 24 hours the voting will end and the final results will be announced. 40 | 41 | ### Key Features of Real-Time Judging 42 | 43 | * You can judge only a subset of the issues and still get paid for it (even just 1 issue!) 44 | * The votes and comments of other judges update in real-time 45 | * The currency of the system is called “signal” and you gain signal for correct judgments and lose signal for incorrect judgments 46 | * The reward for judging an issue increases over time 47 | * The reward for voting on an outcome (i.e. Medium) decreases after others vote for the same outcome 48 | * There is no escalation period, the Sherlock Judge has discretion to review controversial issues 49 | * As issues become more controversial (i.e. lots of votes on Medium AND invalid) the signal required to finalize that issue’s outcome increases 50 | * Judging contests are finalized once there is enough signal voting in the same direction on each issue 51 | * Once all issues are in a finalized state, there’s a 24-hour period for more voting to occur, and then the contest results become final 52 | * There is no fixed timeframe for a judging contest, it could finalize in 3 days and payouts could happen the day after 53 | 54 | > Important! Once you vote or write a comment, you cannot change it. Think carefully before taking any action and include as much relevant detail in your comments as possible. 55 | 56 | ### What is Signal? 57 | 58 | Signal is the currency of Real-Time Judging. 59 | 60 | Every Judge starts with Signal. Signal is the weight that your vote is assigned. The more Signal you have, the more you can influence the judging results and the more rewards you earn for valid votes. 61 | 62 | ### How can I increase my signal? 63 | 64 | After an audit contest, your Signal increases for correct judgments and decreases for incorrect judgments. You can increase your Signal in two ways: 65 | 66 | 1. Submit correct judgments 67 | 2. If your Signal is <100, you can increase your Signal to a maximum of 100 by submitting valid issues in an audit contest 68 | 69 | If your Signal gets to 0, you can no longer participate in Real-Time Judging. The maximum possible Signal is 1,000. 70 | 71 | ### How is Signal calculated? 72 | 73 | For a technical calculation of Signal, see [this spreadsheet](https://docs.google.com/spreadsheets/d/1fQ-8HS4SL0sXqKg6bHHlHFFhbj8Y14cqWOiupYIpIrQ/edit?usp=sharing). 74 | 75 | To initialize the system, every Watson’s signal was calculated based on their audit and judging leaderboard positions. See [this spreadsheet](https://docs.google.com/spreadsheets/d/1fQ-8HS4SL0sXqKg6bHHlHFFhbj8Y14cqWOiupYIpIrQ/edit?usp=sharing). 76 | 77 | ### How do I earn USDC? 78 | 79 | You can see the reward and penalty for every action you take on an Issue page. And at the bottom of the Issue page, you can see the aggregate max rewards and aggregate max penalty for your submission. 80 | 81 | The rewards earned for voting increase your signal score, and the penalties decrease it. The larger your signal score, the larger the rewards you earn for voting correctly. However, the penalty for incorrect votes will also be larger. 82 | 83 | Your USDC payout is calculated by subtracting your earned penalties from your earned rewards. The judging pool is shared proportionally with the Judges who have positive points. 84 | 85 | Example 86 | 87 | * Alice earned a reward of 25 for correctly voting High on issue #1 88 | * Alice earned a penalty of 10 for incorrectly voting Invalid on issue #2 89 | * Bob earned a reward of 5 for correctly voting High on issue #1 90 | * Alice ends up with 15 points (25 - 10) 91 | * Bob ends up with 5 points 92 | * Alice will take 75% of the judging pot (15/20) 93 | * Bob will take 25% of the judging pot (5/20) 94 | 95 | ### How are rewards and penalties calculated? 96 | 97 | AMM (Automated Market Maker) logic decides the rewards and penalties for each vote based on Signal that has already been voted on that judgment. 98 | 99 | The AMM logic allows for a fair distribution of rewards while mitigating sybil and collusion attacks. 100 | 101 | More details will be added to this section later. 102 | 103 | ### How does commenting work? 104 | 105 | Every severity and duplication judgment on every issue requires a comment. If someone has commented on that same judgment before you (and you agree with it), you can vote for their comment instead of writing your own. 106 | 107 | Writing a comment can earn you a 300% reward boost on that judgment if your comment accrues the most Signal, but it can result in a 10% penalty if it doesn’t accrue the most Signal. 108 | 109 | You are only able to write 1 comment per severity and duplication judgment. And you are not allowed to edit your comment. So only write a comment once you feel you have a strong grasp of the issue, and include as much relevant detail in your comment as possible. 110 | 111 | ### How can I escalate my issue if I disagree with the outcome? 112 | 113 | Escalations have been deprecated. Instead, the same mechanism naturally occurs in Real-Time Judging if there is a material amount of Signal voting on different outcomes (i.e. Medium vs. Invalid). 114 | 115 | Every issue with a high degree of controversy will attract the attention of the Sherlock Judge, who has the final say on every judgment. 116 | 117 | In the previous system, the ability to escalate an issue was earned by doing well in the judging contest and submitting valid issues. In the same way, you can increase your Signal by judging well and submitting valid issues in audit contests. 118 | 119 | ### How does Real-Time Judging work in private audit contests? 120 | 121 | Only the participants in the private audit contest can participate in Real-Time Judging. The threshold to finalize issue judgment will necessarily be lower in these contests. 122 | 123 | ### What if I submit spam issues in the audit contest so I can earn rewards for them in the judging contest? 124 | 125 | If a Watson does not meet the Payout Threshold after any audit contest, the issues they submitted in the audit contest will not count for judging rewards. 126 | 127 | \ 128 | \ 129 | \ 130 | \ 131 | -------------------------------------------------------------------------------- /audits/judging/dedicated-judge.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | A dedicated judge is dedicated to judge all issues in the contest and gets a 4 | 300% reward boost. 5 | --- 6 | 7 | # Dedicated Judge 8 | 9 | The offer to be a dedicated judge will be available in the Sherlock Discord's Judging channel. The signup deadline is 24 hours before the audit contest ends. 10 | 11 | **Requirement** 12 | 13 | The dedicated judge must review all issues before the community judging period ends, with a target of assessing 100 issues per day. 14 | 15 | **Penalty** 16 | 17 | If the final results are announced after more than seven days and you don't judge all issues, you will be penalized. 18 | 19 | 1. You will not receive the 300% reward boost. Like any other judge, you will receive a 100% reward boost. 20 | 2. Your leaderboard signal score will be decreased by 50%, this is a significant penalty. 21 | 22 | **Reward** 23 | 24 | If you don't receive the penalty and successfully fulfill your obligations as a dedicated judge. You will receive a 300% reward boost. 25 | 26 | This boost applies to your 27 | 28 | 1. USDC pool rewards 29 | 2. Signal rewards 30 | 3. Signal penalty 31 | 32 | Note that incorrect judging amplifies your penalties; this will increase the drop in signal score due to the boost. 33 | 34 | ### Early November Update 35 | 36 | This update applies to all judges, but is especially relevant for the dedicated judge. 37 | 38 | Previously, the risk/reward ratio remained constant, with both risk and reward increasing at a steady rate over time. With this update, however, the risk/reward ratio will gradually increase over time. 39 | 40 | Before this update, judging uncertain issues was generally penalizing. Now, it’s less penalizing, making it advantageous to judge issues you’re unsure about closer to the deadline. -------------------------------------------------------------------------------- /audits/judging/discussion.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Discussions on the issue voting pages are essential for reaching the correct judgment. To maintain healthy and high-quality discussions, certain constraints apply to commenting. 4 | --- 5 | 6 | # Issue Discussions 7 | 8 | **Important:** Be sure to include all relevant details in your comment to ensure clarity and completeness. 9 | 10 | ### Phase 1: Community Judging 11 | 12 | During this phase: 13 | - All judges can comment without restrictions. 14 | - Judges without a signal score can only comment on their own issues (as authors). 15 | 16 | ### Phases 2, 3, and 4 17 | 18 | When the Lead Judge and Sherlock Judge are involved, the following rules apply: 19 | - Each judge or author is limited to **one comment per issue** in the discussion section. Additional comments may be granted by the Lead Judge or Sherlock Judge. 20 | - Judges must have at least **100 signal** to comment on issues submitted by third parties. 21 | 22 | ### Escalations 23 | 24 | In Phase 3 (lasting 24 hours), judges can escalate issues by leaving a comment in the discussion. If no escalation occurs, the discussion closes at the start of Phase 4. 25 | 26 | Escalations require a fixed **signal cost**, which is non-refundable. This cost discourages unnecessary escalations by removing the incentive to escalate freely. -------------------------------------------------------------------------------- /audits/judging/guidelines/criteria-changelog.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: All future changes to the Issue criteria page will be logged here. 3 | --- 4 | 5 | # Criteria Changelog 6 | 7 | ## 1.11 - 06/02/2025 8 | 9 | *** 10 | 11 | Batch 6: _Links are added to each SJIP separately_ 12 | 13 | * SJIP 20: [Clarify that acknowledged issues are not valid](https://github.com/sherlock-protocol/governance-and-discussion/discussions/23) 14 | * SJIP 21:[ Clarify front-running on chains with private mempool](https://github.com/sherlock-protocol/governance-and-discussion/discussions/22) 15 | * SJIP 22: [Remove the `min/maxAnser` guideline](https://github.com/sherlock-protocol/governance-and-discussion/discussions/25) 16 | * SJIP 23: [Clarify Oracle Staleness](https://github.com/sherlock-protocol/governance-and-discussion/discussions/21) 17 | * SJIP 24: [Likelihood is not considered during judging](https://github.com/sherlock-protocol/governance-and-discussion/discussions/24) 18 | 19 | ## 1.10 - 12/11/2024 20 | 21 | *** 22 | 23 | Batch 5: [https://github.com/sherlock-protocol/sherlock-v2-docs/pull/46](https://github.com/sherlock-protocol/sherlock-v2-docs/pull/46) 24 | 25 | * SJIP 19: Update judging process 26 | 27 | ## 1.9 - 12/09/2024 28 | 29 | *** 30 | 31 | Batch 4: [https://github.com/sherlock-protocol/sherlock-v2-docs/pull/45](https://github.com/sherlock-protocol/sherlock-v2-docs/pull/45) 32 | 33 | * SJIP 14: Clarify High and Medium severities 34 | * SJIP 15: Off-chain mechanisms question 35 | * SJIP 16: Clarify future integrations and invariants in the README and Judging Rules 36 | * SJIP 17: Remove Legacy Report Template 37 | * SJIP 18: Remove the question about hardcoded values 38 | 39 | ## 1.8 - 08/07/2024 40 | 41 | *** 42 | 43 | Batch 3: https://github.com/sherlock-protocol/sherlock-v2-docs/pull/41/ 44 | 45 | * SJIP-11: Introduce new report template 46 | * SJIP-12: Clarify duplication considerations 47 | * SJIP-13: Fix typo 48 | 49 | ## 1.7 - 10/06/2024 50 | 51 | *** 52 | 53 | Batch 2: https://github.com/sherlock-protocol/sherlock-v2-docs/pull/34 54 | 55 | * SJIP-7: Duplication 56 | * SJIP-8: Missing Curcuit Breaker Checks 57 | * SJIP-9: Change Trusted/Restricted Logic 58 | 59 | ## 1.6 - 17/05/2024 60 | 61 | *** 62 | 63 | Batch 1: https://github.com/sherlock-protocol/sherlock-v2-docs/pull/24 64 | 65 | * SJIP-5: Update hierarchy of truth 66 | * SJIP-6: Improve known issue question in contest QA 67 | 68 | ## 1.5 - 29/01/2024 69 | 70 | *** 71 | 72 | * Historical decisions are no longer considered sources of truth. They may guide Watsons, but judgments should always be based on rules as they are and mistakes should not be repeated. Private messages are not sources of truth. 73 | * Updated the [broken-reference](broken-reference/ "mention") and [broken-reference](broken-reference/ "mention") sections to better explain what high and medium severity issues are. Repealed the [broken-reference](broken-reference/ "mention") description. 74 | * Added an exception to the hierarchy of truth for cases where blatant mistakes in a higher source of truth were made. 75 | * Specified opportunity loss and design choices to be out of scope. 76 | * Updated the [broken-reference](broken-reference/ "mention") section to require the PoC in more cases and ensure that Watsons need to discover the limitations and constraints of the issue being triggered. 77 | * Rephrased the "Future issues" rule to remove ambiguity. 78 | * Changed words in several places to ensure ease of understanding. Typo fixes. 79 | 80 | ## 1.4 - 10/11/2023 81 | 82 | *** 83 | 84 | * Made network liveness our of scope, with an exception of sequencer-like issues if they are preventable and the external admin is restricted in the [broken-reference](broken-reference/ "mention") section. 85 | 86 | ## 1.3 - 12/10/2023 87 | 88 | *** 89 | 90 | * Addition of CHANGELOG to the docs. 91 | * Addition of rule related to CHANGELOG in the point `Hierarchy of truth` in the [broken-reference](broken-reference/ "mention") section 92 | 93 | ## 1.2 - 12/09/2023 94 | 95 | *** 96 | 97 | * Some minor changes in the judging criteria documentation structure 98 | * Added the `Contract Scope:` sub-section under [broken-reference](broken-reference/ "mention") section in the judging criteria. 99 | * Added the [broken-reference](broken-reference/ "mention") section in the judging criteria: https://docs.sherlock.xyz/audits/judging/judging#vi.-requirements 100 | * Added `Non-Standard tokens:` point in the [broken-reference](broken-reference/ "mention") section 101 | * Extended the `EIP compliance` point in the [broken-reference](broken-reference/ "mention") 102 | 103 | ## 1.1 - 01/08/2023 104 | 105 | *** 106 | 107 | * Added rules for escalations: [broken-reference](broken-reference/ "mention") 108 | * Added the `External Admin trust assumptions` sub-section under [broken-reference](broken-reference/ "mention") 109 | -------------------------------------------------------------------------------- /audits/judging/judging-conduct-guidelines.md: -------------------------------------------------------------------------------- 1 | # Judging Conduct Guidelines 2 | 3 | Being a Judge for a customer’s audit contest is a highly privileged role. A high degree of professionalism is expected from every Judge. 4 | 5 | To be a Judge on Sherlock, the following rules should be observed: 6 | 7 | * No comments should be written that disparage Sherlock, a Sherlock team member, the customer, a customer’s team member, or other Judges 8 | * No vulgar, spam or off-topic comments should be written 9 | * No attempt to break or game the judging system should be attempted 10 | * If any issue with the judging system is discovered, it should be reported to the Sherlock team immediately 11 | * Discussion of issues can be highly sensitive, so please keep the discussion to the comments section for issues in Real-Time Judging or the appropriate channel on Discord 12 | * No discussion of judging on an external public channel (such as X/Twitter, a non-Sherlock Discord server, etc.) should occur 13 | 14 | If any of the above guidelines are not followed, a temporary or permanent ban from judging and removal of the Sherlock Judge role will follow. 15 | 16 | \ 17 | -------------------------------------------------------------------------------- /audits/judging/lead-judge.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | The lead judge holds the authority to make final decisions on all contest issues. 4 | --- 5 | 6 | # Lead Judge 7 | 8 | As Lead Judge, your role is to assess and make decisions on a subset of complex or controversial issues, typically between 1% and 10% of all cases. Your focus will be on issues that are challenging to judge and have been marked as controversial. You are expected to: 9 | 10 | 1. Evaluate Issues: Carefully analyze each controversial/escalated issue, balancing the judging guidelines and your own subjective common sense for your decisions. Use clear, reasoned explanations for why each judgment was made, especially when an issue requires subjective interpretation or a nuanced approach. 11 | 12 | 2. Use Judgement & Reasoning: While adhering to the guidelines is important, you can override them based on common-sense reasoning when you find it justified. Your decisions should reflect a balanced understanding of the context and potential impacts of each issue. Deviations from the guidelines should be made only in exceptional cases. 13 | 14 | 3. Collaborate as Needed: The Sherlock team is available to discuss decisions and provide input. You are encouraged to consult them for brainstorming or clarification, though the individual judgments remain with you. 15 | 16 | 4. Ensure Judgement Integrity: The Sherlock team will respect your final decisions unless a strong indication of error is identified. 17 | 18 | 19 | ### Deviation Template 20 | 21 | When deviating from the judging guidelines, document the decision as follows: 22 | 23 | Based on the audit context, the applicable guideline is: 24 | > {guideline} 25 | 26 | By this guideline, the issue would normally be judged as {severity}. 27 | 28 | However, in the context of the protocol's security needs, this guideline conflicts with practical considerations due to: 29 | - Reason 1 30 | - Reason 2 31 | - ... 32 | 33 | For these reasons, the issue will be judged as {severity}. 34 | -------------------------------------------------------------------------------- /audits/judging/sherlocks-exclusive-judging-apprentice-program.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | What is the Sherlock Judging Apprentice Program, and how does it help you 4 | level up your judging skills? 5 | --- 6 | 7 | # Sherlock's Exclusive Judging Apprentice Program 8 | 9 | {% hint style="info" %} 10 | Note: Judging Apprentices are hand-picked based on their performance on the platform, you **cannot** apply to this program. 11 | {% endhint %} 12 | 13 | As one of the chosen, you'll receive: 14 | 15 | * **300 Signal** for contributing to the judging process of a contest you've already participated in. 16 | * **Boost Your Leaderboard Ranking**: Your judging efforts will directly impact your signal score, offering a unique chance to climb the leaderboard based on your performance. 17 | * **Direct Communication with Sherlock's Top Judges**: Get exclusive access to Sherlock’s expert judges for personalized guidance and mentorship. 18 | * **Join a Prestigious Circle**: Once graduated you'll join the chat with other graduates, sharing insights and strategies to sharpen your skills. 19 | * **Special Recognition** in the Sherlock Discord: Stand out in the community with a unique role that highlights your expertise. 20 | * **Earn up to $10k per month**: Master the art of judging and unlock the potential to earn up to $10,000 per month by applying your expertise to contests. 21 | 22 | This program runs across **3 contests**, and once you've successfully judged all three, you will have a **high leaderboard signal score**, significantly increasing your earning potential. Performing well in these contests will allow you to make **serious money** by continuing as a top judge. However, to judge contests after you've entered the Judging Apprentice Program, you'll have to sign up as a **dedicated judge**, which means judging all the reports submitted in the contest. 23 | 24 | As a Judging Apprentice, you will be expected to: 25 | 26 | * **Thoroughly review and judge** all the issues in the contest you've signed up for as a dedicated judge. 27 | * **Provide insightful commentary** and engage in professional discussions, adhering to Sherlock’s judging guidelines. 28 | -------------------------------------------------------------------------------- /audits/protocols/README.md: -------------------------------------------------------------------------------- 1 | # 🧑‍💻 Protocol Teams 2 | 3 | Request an audit [here](https://docs.google.com/forms/d/e/1FAIpQLSfqy21chyyzhAfbCxMQOlNTlYxegfvxZDhYsPkpI\_xD6AQiag/viewform)! 4 | 5 | Security is a top priority for high-quality projects shipping code to mainnet given the inherently adversarial nature of on-chain interactions and consequently the prospect of losing user funds. And because Sherlock is willing to offer bug bounty and exploit coverage to qualifying codebases, Sherlock obsesses over the processes to keep codebases safer. 6 | 7 | The most well-known process for securing a codebase is an audit. 8 | 9 | **An audit in the crypto space usually looks something like this:** 10 | 11 | * 2-4 security experts pore over the codebase for a few weeks and flag any vulnerabilities they see. 12 | 13 | However, a new approach to auditing has also sprung up and become quite popular: audit contests. 14 | 15 | **An audit contest usually looks something like this:** 16 | 17 | * A protocol team creates a prize pool ($30k-$200k usually), and anyone in the world can submit vulnerabilities to the codebase chosen by the protocol team. The higher the severity, the more of the prize pool the security expert is awarded. 18 | 19 | Below, we’ll outline the strengths and weaknesses of both traditional audits and audit contests. Then we’ll propose a third approach that features the “best of both worlds.” 20 | 21 | ### Traditional Audits 22 | 23 | **Strengths** 24 | 25 | * You know who is going to audit your code (although far too many auditors don't even tell you that or put it in the audit report) 26 | * You know how long that expert is going to spend trying to find bugs in your codebase 27 | * When the expert finds bugs and the protocol team makes fixes, the expert will verify that the fixes don’t have bugs 28 | 29 | **Weaknesses** 30 | 31 | * Only 2-4 people look at your code, leaving room for missed bugs (even among top experts) 32 | * They are not cost-effective (\~50% of what you pay does NOT go to security experts) 33 | * They can often take a very long time (3-12 months) to schedule 34 | * There is no direct incentive for an auditor to try their hardest 35 | 36 | ### Audit Contests 37 | 38 | **Strengths** 39 | 40 | * The likelihood of missed bugs is [very low](https://docs.google.com/spreadsheets/d/1RIJCK3\_9RHvtNPObsDRTAqkP9IbyutZMsqlKNnZCO00/edit#gid=0) because 200-400 security experts try to find bugs in your code 41 | * Incentives are stronger to find bugs: experts get paid based on the number of findings and severity of findings 42 | * Contests can often be scheduled within days 43 | * You can decide your own price (size of the prize pool) 44 | 45 | **Weaknesses** 46 | 47 | * There’s no guarantee that any top-tier security experts will look at your code (especially if the contest was scheduled days before) 48 | * Even if top-tier experts participate, you don’t know how long they’ll spend looking for bugs 49 | * Once the bugs are found, there is no one who will help you fix them (no fix review) 50 | * Security experts are often incentivized to spend time submitting unimportant/non-critical findings 51 | * They are inefficient and your money often goes towards admin work and unimportant areas (Low/Informational/QA/gas findings) 52 | * The protocol team is often expected to sort through thousands of issues at the end and any overlooked issue could result in an exploit 53 | 54 | ### Sherlock's Approach: The Best of Both Worlds 55 | 56 | Sherlock’s approach provides a protocol with the focus, collaboration, and assurance of a traditional manual audit, alongside the breadth of security expert participation from an audit contest. 57 | 58 | **Overview** 59 | 60 | * At least 1 Senior Watson (top-ranked security expert) is heavily incentivized (through fixed pay and an ELO-style ranking system) to find as many bugs as possible over the entire length of the audit 61 | * The significant prize pool attracts 200-400 independent auditors who get paid based on the severity of their findings (only High/Medium severity findings are rewarded) 62 | * The Lead Senior Watson comes back to help the protocol team with fixes (provides a 1-day complimentary fix review) 63 | * Sherlock’s decentralized judging process takes hundreds of raw, duplicate issues and turns them into a digestible report, saving the protocol team days of work and reducing the possibility of overlooked vulnerabilities 64 | * Sherlock's process is the most cost-effective: 80% of what you pay to Sherlock goes directly to security experts 65 | * Sherlock is the only auditor to offer bug bounty and exploit coverage after the audit is conducted (once the fix review is finished), ensuring that Sherlock's incentives are aligned in shipping the most secure protocol possible. 66 | 67 | Sherlock’s unique offering assigns a top-ranked senior security expert (Senior Watson) to act as the lead security auditor throughout the duration of the contest, earning attractive fixed pay alongside the ability to compete for the entire prize pool. 68 | 69 | The fixed nature of the lead senior auditor gives protocols the assurance that, at minimum, one highly skilled security auditor will be conducting an in-depth review of the codebase, will be there to discuss issues with the protocol team, and will conduct a half-day fix-review to make sure any fixes have been implemented securely. 70 | 71 | The talents of this one individual will be enhanced by the skillset of an unlimited number of independent security experts / teams competing to win a greater portion of the prize pool. And the Senior Watson will only keep their “senior” status as long as they find more vulnerabilities than the rest of the field. And of course, Sherlock's continued commitment to incentive alignment is at the core of a Sherlock audit. Qualifying protocols that go through an audit (and complete the fix review) can add smart contract coverage at any point post-audit to reimburse its users in the event of a hack - helping the protocol team build trust with its early LPs, users and/or community. 72 | -------------------------------------------------------------------------------- /audits/protocols/audit-preparation.md: -------------------------------------------------------------------------------- 1 | # Audit Preparation 2 | 3 | Prepping a protocol’s code for an audit is an invaluable process to result in a higher quality security review, but it can be challenging for many protocol development teams to know what things they should prioritize to better prepare for an audit. Sherlock has designed its [Audit Requirements Checklist](https://docs.google.com/document/d/10_t7Kt814Otp-FMFK8mvCsxb3tX3wyu1Z9V4nhZxTY8/edit?usp=sharing) to guide protocols towards the minimum requirements Sherlock expects to see completed by the audit start date. For audits scheduled >7 days in advance of the start date, Sherlock will have multiple check-ins with each protocol team to make sure they are on-track to meet all the Audit Requirements Checklist items before the audit start date. 4 | 5 | 72 hours before the audit start date, the protocol team sends Sherlock the finalized commit hash, branch, and contracts to be audited. At this point, the protocol will also pay the remaining 75% of the audit cost. 6 | 7 | In the unlikely scenario where a protocol submits contracts which fail to meet the Audit Requirements Checklist or submits contracts which will require a longer audit than what was originally scheduled, Sherlock will allow the protocol to move forward with one of the following scenarios: 8 | 9 | 1. Attempt to reschedule 10 | 2. Attempt to increase the length of the audit 11 | 3. Move forward with a “best efforts” audit, which will undergo a full contest, but will not qualify for coverage afterwards 12 | -------------------------------------------------------------------------------- /audits/protocols/audit-pricing-and-timeline.md: -------------------------------------------------------------------------------- 1 | # Audit Timeline 2 | 3 | Each Sherlock audit consists of a fixed pay element to adequately incentivize at least 1 dedicated Senior Watson to lead the audit as well as a prize pool element that often draws 200-400 independent auditors. 4 | 5 | In order to properly align incentives with protocols, Sherlock offers smart contract coverage behind qualifying audits (not included in the audit cost), which can be activated at any point after the audit is completed, provided the fix review has been completed and there haven’t been subsequent changes to the code base. 6 | 7 | Sherlock has developed the following broad underwriting guidelines for how much time is needed to complete an audit of codebases of various sizes in order to offer smart contract coverage on the protocol in the future: 8 | 9 |
Solidity Lines (nSLOC)Audit Timeline
~500~3 days
~1000~6 days
~2000~12 days
~3000~18 days
~4000~25 days
~5000~32 days
~6000~38 days
10 | 11 | > Note: Sherlock utilizes the tool [Solidity Metrics](https://github.com/ConsenSys/solidity-metrics) to calculate nSLOC.\ 12 | > \ 13 | > \*Given the exponential complexity of very large codebases for any security expert, Sherlock will have final discretion whether to write smart contract coverage behind its audit for protocols with >6000 nSLOC 14 | 15 | Sometimes a protocol will need extra audit time instead of a 1-day fix review after their initial audit. This is very normal. In this case, Sherlock recommends another (shorter) contest in order to be eligible for smart contract coverage. This "shorter" contest will not need to follow the nSLOC guidelines above, because most auditors will already be familiar with it and will have audited it very recently. The cost/length of the follow-up audits will depend on the scoping/judgment of the Lead Senior Watson. 16 | -------------------------------------------------------------------------------- /audits/protocols/how-it-works-for-protocols.md: -------------------------------------------------------------------------------- 1 | # How it Works for Protocols 2 | 3 | Whether this is your protocol’s first audit before launching on mainnet, or latest version, Sherlock’s audit experience is designed to provide the familiarity of a traditional audit, with drastically better results. 4 | 5 | **A protocol’s audit process:** 6 | 7 |

The timeline for a Sherlock audit

8 | 9 | 1. You can request an audit [here](https://audits.sherlock.xyz/request-audit). Sherlock can usually start an audit within 3 days. 10 | 2. Sherlock will contact you to discuss your audit scope, expected timeline, and requirements to get an audit started (check out Sherlock's [Audit Requirements Checklist](https://docs.google.com/document/d/10\_t7Kt814Otp-FMFK8mvCsxb3tX3wyu1Z9V4nhZxTY8/edit?usp=sharing) for items Sherlock requires to start an audit). 11 | 3. Sherlock conducts an initial assessment and provides you with a quote based on the length of time required for the audit. 12 | 4. You then reserve your audit slot by putting down a refundable deposit for 25% of the cost of the audit. 13 | 5. Three days before the audit starts, you send Sherlock the final commit, branch, contracts, and the remaining portion of the audit deposit. 14 | 6. Once the audit contest portion of the audit begins, Sherlock will ask your team to be available to answer questions from security experts (mostly in a Discord channel). 15 | 7. Immediately after the audit contest ends, the judging contest starts. The judging contest will last a variable number of days, depending on the number of issues submitted. After the judging contest ends, Sherlock will provide you with a curated, de-duplicated list of all High and Medium-severity findings. 16 | 8. You then have 72 hours to acknowledge and indicate which submitted issues you intend to fix and schedule a fix review to be completed within 3 weeks. 17 | 9. Sherlock asks that you implement any fixes (a separate PR for each issue being fixed) and deliver the new commit hash to Sherlock 24 hours before your fix review starts. We also ask that you comment on each open issue (in the Sherlock repo) with a link to the PR that fixes that issue. 18 | 10. Around the same time as Step #9, Sherlock runs an "Escalation Period" where security experts can stake USDC and flag any issues that they think were not categorized correctly for a second opinion. 19 | 11. Post-fix review, you will receive sign-off to launch on mainnet and a final report, which gives you the option to add coverage at any point in the future. 20 | 12. Sherlock works with you to get your coverage and bug bounty live (if you decide you want smart contract exploit coverage). 21 | 22 | {% hint style="warning" %} 23 | **Important timeline considerations**\ 24 | \ 25 | The length of the audit contest itself will be communicated to the protocol team as part of the initial quote/scoping. However, the post-contest process can take a couple days, or it can take a few weeks, depending on the number of issues found:\ 26 | \ 27 | **Audit Contest:** Communicated in the quote/scoping\ 28 | **Judging Contest:** Variable number of days immediately after audit contest\ 29 | **Issue Verification:** Depends on the number of issues submitted, but could take 1 day or could take 7 days (also depends on the productivity of the protocol team)\ 30 | **Issues fixes:** Depends on the number of valid issues, but could take 1 day or could take 1-2 weeks (also depends on the productivity of the protocol team)\ 31 | **Escalation Period:** Once the issues have been verified, this is a "double-checking" process that takes 48-72 hours in total and usually occurs while the protocol team is fixing issues.\ 32 | **Fix review:** This will be done by the Lead Senior Watson if it can be accomplished in 1 day or less. If not, Sherlock suggests a small follow-up audit contest. Could take as little as 1 day, or it could take 1-2 weeks to schedule and complete (depending on number of issues and Lead Senior Watson availability, etc.)\ 33 | \ 34 | **Generally, Sherlock recommends a protocol team not expect to deploy/launch their protocol until 2-3 weeks after the audit contest finishes. However, if not issues are found, a protocol team could launch as soon as 3 days after the audit contest ends.** 35 | {% endhint %} 36 | -------------------------------------------------------------------------------- /audits/protocols/interim-updates-and-upgrades.md: -------------------------------------------------------------------------------- 1 | # Interim Updates and Upgrades 2 | 3 | Sherlock understands the desire and, at times, strategic importance to make smaller updates & rollouts to code ahead of larger monolithic V2/V3 rollouts. This is where Sherlock’s audit model excels above all others. By completing a full-protocol audit with Sherlock, we now have at minimum one senior Watson who has context of the entire system, and a running list of other auditors who performed best on the codebase. This breadth of coverage allows Sherlock to schedule cheap, short-term audits which will utilize the previous Lead Senior Watson (or other top performer(s)), alongside other participants, to review smaller, interim updates to the codebase before the next round of full system audits. 4 | 5 | Sherlock has already implemented this system effectively with our current customers, ensuring that no new code goes to mainnet unaudited and enabling TVL coverage to extend to any exploits in the new contracts. Since Sherlock utilizes the original Lead Senior Watson, the cost is able to be priced directly based on the time that the auditor requires to look at the smaller changes. This is a unique value that Sherlock offers to help keep our protocols secure in a cost-effective manner, removing the need for protocols to enter into extremely expensive retainer contracts. 6 | -------------------------------------------------------------------------------- /audits/protocols/protocol-involvement-during-the-audit-process.md: -------------------------------------------------------------------------------- 1 | # Protocol Involvement During the Audit Process 2 | 3 | At the beginning of the audit, the protocol team will be added to a Discord channel with all auditors competing. This is designed to facilitate any Q\&A between the auditors and protocol team as they try to better understand the system. Protocol teams are not mandated to engage with the auditor Q\&A / discussion, however, we have historically found this type of dialogue to improve the quality & outcomes of the audit and is encouraged. 4 | 5 | Throughout the contest, auditors will submit issues into a private GitHub, and unfortunately the protocol team will not be able to view the issues until the contest is complete. This policy is in place in order to maintain the integrity of audit contests and make sure that protocol teams don't "leak" exploits to other contest participants (or submit the exploits anonymously themselves). 6 | -------------------------------------------------------------------------------- /audits/protocols/protocol-involvement-post-audit.md: -------------------------------------------------------------------------------- 1 | # Protocol Involvement Post-Audit 2 | 3 | Once an audit is complete, Sherlock saves protocols days of work by utilizing its own in-house team to begin the evaluation process. The post-audit track takes the following path: 4 | 5 | 1. Sherlock will review all issues, de-duplicate submissions, and judge every issue. 6 | * Sherlock is focused exclusively on high and medium severity findings, as these are the types of vulnerabilities which will cause a loss of user funds and most materially damage the reputation protocols. 7 | 2. Protocol team will receive a final list of vulnerabilities, and then has 72 hours to indicate which issues they intend to either fix or acknowledge. Acknowledging an issue without fixing it means that the protocol team is ok with taking the risk, even though the manifestation of that risk would no longer be covered by Sherlock. 8 | 3. Once the protocol team has received their final list of vulnerabilities, they will have up to 2 weeks to schedule and complete a fix-review, where Sherlock’s Lead Senior Watson (at minimum) will conduct a 1-day (or less) fix review audit to make sure the fixes have been implemented correctly and haven’t introduced vulnerabilities. 9 | 10 | > Note: If a protocol fails to deliver a new commit hash and separate PRs for each issue within 3 weeks, then Sherlock can no longer guarantee that a fix review will be scheduled, disqualifying a protocol from implementing smart contract exploit coverage at go-live. For transparency, Sherlock puts a 3-week timeline on this fix review requirement out of best-practices, since the quality of a fix review is only as good as the senior engineer’s ability to maintain context of the entire code base into perpetuity. Given every person’s natural limitations to remember everything forever, Sherlock believes that the fix reviews must be completed in a reasonable timeframe in order to have a high-quality fix review conducted. 11 | 12 | 4\. Once a fix-review is completed, the senior engineer will verify that the protocol is good to launch on mainnet with the final commit. At this point, a protocol can be fully qualified for smart contract coverage, which can be activated at any point in the future on the previously audited commit hash. A protocol will also receive a final audit report shortly thereafter. 13 | 14 | > Note: If the senior auditor believes there are a material amount of changes required post-audit which can’t be reviewed in 1 day or less, Sherlock may require a smaller follow-up audit (see Audit Pricing and Timeline section) be conducted in order to qualify for coverage. 15 | -------------------------------------------------------------------------------- /audits/protocols/rescheduling-and-cancellations.md: -------------------------------------------------------------------------------- 1 | # Rescheduling and Cancellations 2 | 3 | Having a protocol on mainnet ourselves, Sherlock fully understands the challenges of knowing with 100% certainty that a code base will be fully ready by the original audit start date. As a result, Sherlock aims to offer one of the most transparent and flexible rescheduling and cancellation processes. While we will always attempt to seamlessly reschedule an audit, some guidelines are needed to encourage thoughtful scheduling on the part of protocol customers in order to create a positive experience for all Watsons, as the quality of any security review comes down to the quality of the participants. We’ve put together the following timelines to assist protocols with their scheduling plans. 4 | 5 | **Reschedule / Cancellation Timeline:** 6 | 7 | \>1 month before audit start date → 100% deposit refund (no rescheduling costs) 8 | 9 | \>2 weeks before audit start date → 50% deposit refund 10 | 11 | <2 weeks before audit start date → 0% deposit refund 12 | -------------------------------------------------------------------------------- /audits/protocols/scheduling-process.md: -------------------------------------------------------------------------------- 1 | # Scheduling Process 2 | 3 | Sherlock aims to provide one of the most flexible audit solutions in the space, starting with a simplified scheduling process. Once an initial assessment has been completed and a preliminary quote provided, the next steps include: 4 | 5 | 1. Protocol puts down a deposit for 25% of the audit cost and indicates which date it would like the audit to begin - can be scheduled with at least 3 days' notice. 6 | 2. Sherlock will then either: 7 | - Confirm the senior auditor and start date within 72 hours, or 8 | - Suggest an alternative start date, or 9 | - Request the protocol team select an alternative start date 10 | 11 | > Note: In the unlikely instance where Sherlock does not confirm the originally proposed start date, the protocol has the option to withdraw the full amount of their deposit. 12 | 13 | Of course, the farther out a protocol schedules an audit, the higher the likelihood they generate maximum Watson participation and secure the highest-ranked senior Watson. 14 | -------------------------------------------------------------------------------- /audits/referral-program.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Welcome to Sherlock's Audit Referral Program! 3 | --- 4 | 5 | # 🤝 Referral Program 6 | 7 | ### Referral program basics 8 | 9 | * Anyone in the world can refer protocol teams to Sherlock! 10 | * If the team does an audit contest or collaborative audit 11 | * You'll make 5% of the rewards to security researchers (everything except Sherlock's fee) 12 | * Example: If the rewards are 100k USDC, you'll make 5k USDC for your referral 13 | * Once a contest is fully paid, Sherlock will ask the protocol team if anyone referred them. If they mention you, then you get paid :moneybag: 14 | * You can also ping us ahead of time (or introduce us to the protocol in the first place) to ensure that your referral is not overlooked. At the end of the day, it will be up to the protocol team's word to decide if you referred them or not. 15 | * Sherlock will only pay out 1 address for each referral, meaning we won't split referrals between multiple people, that will be up to you and anyone you work with 16 | * Referral payouts will be done in USDC on Ethereum mainnet or Polygon 17 | 18 | Feel free to reach out to contact@sherlock.xyz if you have any questions! 19 | -------------------------------------------------------------------------------- /audits/watsons/README.md: -------------------------------------------------------------------------------- 1 | # 🕵 Watsons 2 | 3 | Check out our latest contests [here](https://app.sherlock.xyz/audits/contests)! 4 | 5 | A Watson is a security expert who submits vulnerabilities. Watsons can also be teams that sign up under one address, so whether you’re an established audit shop, full-time independent security expert, or part-time security researcher interested in finding vulnerabilities - we want to work with you. 6 | 7 | **Initial Steps:** 8 | 9 | 1\. You can sign up for upcoming audits posted in Sherlock’s Discord channel or [Website](https://app.sherlock.xyz/audits/contests) by providing your GitHub name, Discord handle, and your wallet address (so we know where to pay you). 10 | 11 | 2\. You can submit issues found during the audit to your private GitHub repo that Sherlock will create. 12 | 13 | 3\. You have until the audit ends to select to opt out of counting the contest towards your ranking. 14 | 15 | > Note: You are allowed to opt out of a contest for ranking purposes, but still get paid based on the issues you submit! We want to encourage you to show up for as much, or as little, time as you can commit. 16 | 17 | 4\. Sherlock will pay you any prize money earned from the pool and update your ranking within 2 weeks of the audit ending. 18 | 19 | You are eligible to be a Senior Watson if you make it into the top 10% of ranked Watsons. Senior Watsons have the chance to become the Lead Senior Watson for a contest and receive fixed pay (\~$10k per audit week). 20 | 21 | **Steps for Senior Watsons:** 22 | 23 | 1\. Sherlock posts the details of an upcoming audit in the Senior Watson Discord Channel. You have 72 hours to indicate your interest in being selected as the Lead Senior Watson, or propose a set of alternative dates that work better. 24 | 25 | 2\. If you are the highest ranked Senior Watson who signed up, you will be notified after those 72 hours that you were selected to lead the audit. If you aren’t selected as the lead, you can still compete in the contest by following the “Initial Steps” above. 26 | 27 | 3\. You can submit issues found during the audit to your private GitHub repo that Sherlock will create. 28 | 29 | 4\. Sherlock will pay you any prize money earned from the pool and update your ranking within 2 weeks of the audit ending, and you’ll receive 75% of your fixed pay at this time. 30 | 31 | 5\. As the Lead Senior Watson, you’ll review all fixes made by the protocol team. See “Fix Review Process” section below for more details. 32 | 33 | 6\. Post-fix review, Sherlock will compile the final audit report and you’ll sign off on it. 34 | -------------------------------------------------------------------------------- /audits/watsons/contest-points.md: -------------------------------------------------------------------------------- 1 | # Contest Points 2 | 3 | Sherlock has a cold-start problem. Because there are no rankings initially, Sherlock doesn’t know who the Senior Watsons should be. To fix this, Sherlock has whitelisted a select group of security experts to be Senior Watsons. This whitelist will be based on security experts who have led audits for Sherlock in the past. Rankings will show up on the leaderboard after each Watson’s first contest. However, promotion to the Senior Watson role or demotion from the Senior Watson role will only happen once a Watson has completed two contests. 4 | 5 | > Update: As of 9/21/22, Sherlock will change the required number of contests for promotion/demotion from the Senior Watson role. Instead of requiring 2 contests, Sherlock will require 4 contest-weeks to be completed. This will help give more credit to long, 4-week contests and give less credit to short 3-day contests. We think this is an important change to make the rankings and selection process more fair. If it helps you can think of each contest as consisting of a number of contest-days (based on the length of the contest). And 28 contest-days (4 contest-weeks) are required to be eligible for Senior Watson promotion/demotion. Since this scoring system went into effect on 9/21/22, the Notional, Harpie and Sentiment contests will use the old system, meaning each will be worth 14 contest-days. 6 | 7 | > Note: Watsons have the ability to decide if they want a contest to count towards their ranking. The only catch is that you must indicate this (there’s a button on the sign-up page) before the contest ends. This is to ensure that a Watson who is busy or not able to dedicate enough time to a contest doesn’t get penalized in the rankings. However, if you’re the Lead Senior Watson chosen for the contest (receiving fixed pay), the contest will always count towards your ranking. 8 | 9 | The amount of Contest Points available to gain in each contest (to move up the ranks) is determined by the average scores of the competing Watsons, based on previous Sherlock contests: 10 | 11 | Let’s assume Bob’s average score is 7, Joe’s average score is 13, and Mike’s average score is 5. And only Bob, Joe, and Mike compete in a contest. The total Contest Points available in that contest will be 25 (7+13+5). 12 | 13 | Once a Watson has competed in a Sherlock competition, their Leaderboard points (aka ranking) will be determined by their average contest points scored in their 5 most recent Sherlock competitions. It drops off after 5 competitions so that “bad” scores do not stay with you forever. 14 | 15 | > Update: As of 9/21/22, Sherlock will change the methodology for calculating Leaderboard points. Instead of taking the 5 most recent contests, Sherlock will take the last 10 contest-weeks (70 contest-days). This means that a 3-day contest will only count for \~4% (3 contest-days / 70 contest days) of your Leaderboard points (assuming you've competed in >=70 contest-days of contests already). And similarly, a 4-week contest will count for 40% (28 contest-days / 70 contest-days) of your Leaderboard points (assuming you've competed in >=70 contest-days of contests already). If you've competed in <70 contest-days worth of contests, then these contests will naturally make up a higher % of your Leaderboard points.\ 16 | > \ 17 | > However, the Notional, Harpie and Sentiment contests will each count for 2 contest-weeks (14 contest-days) because we don't want to make a retroactive change to the scoring. 18 | -------------------------------------------------------------------------------- /audits/watsons/faq.md: -------------------------------------------------------------------------------- 1 | # FAQ 2 | 3 | **I've earned some USDC through Sherlock, is there an entity I can invoice for tax/reporting purposes?** 4 | 5 | Yes, please use:\ 6 | \ 7 | DeFi Risk Management Foundation 
\ 8 | Dresdner Tower, 11th Floor 50th St. and 55th East Street 
\ 9 | Panama City, Panama 00000\ 10 | \ 11 | Tax ID: 25045786-3-2021\ 12 | \ 13 | And feel free to send the invoice to contact@sherlock.xyz 14 | -------------------------------------------------------------------------------- /audits/watsons/first-submission-pot.md: -------------------------------------------------------------------------------- 1 | # First Blood Pot 2 | 3 | ### First Blood Pot 4 | 5 | Three percent of the total payouts will be reserved for a first-blood pot, which is distributed among the first submitters of all valid issues. 6 | 7 | The first submitter of any valid issue is determined by the timestamp of the last modification on the GitHub issue, across all issues within a valid issue family. 8 | 9 | Each first submitter of an issue receives a number of shares from the first-submitter pot, based on the issue's severity and the number of duplicates it has. 10 | 11 | The number of shares is calculated using the same formula as for determining issue shares, with the key difference being that only the first submitter of that issue family receives the shares: 12 | 13 | > (First Submitter Shares) = (Severity Factor) \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions 14 | 15 | ### Example 16 | 17 | Consider a $100,000 contest with a $3,000 first-blood pot, which includes 2 valid High-severity and 2 valid Medium-severity issues after final judging. 18 | 19 | 1. The first High-severity issue has 4 submissions in its family.\ 20 | The first submitter will receive `5 * (0.9 ^ (4-1)) / 4 = 0.91125` shares for this issue. 21 | 2. The second High-severity issue is a solo submission.\ 22 | The first submitter will receive `5 * (0.9 ^ (1-1)) / 1 = 5` shares for this issue. 23 | 3. The first Medium-severity issue has 2 submissions in its family.\ 24 | The first submitter will receive `1 * (0.9 ^ (2-1)) / 2 = 0.45` shares for this issue. 25 | 4. The second Medium-severity issue has 4 submissions in its family.\ 26 | The first submitter will receive `1 * (0.9 ^ (4-1)) / 4 = 0.18225` shares for this issue. 27 | 28 | The percentage of the first-blood pot each submitter receives is calculated by dividing the sum of their individual shares by the total number of shares awarded. 29 | 30 | In this example, assume: 31 | 32 | * Alice was the first submitter of issue 1. 33 | * Frank was the first submitter of issue 2. 34 | * Bob was the first submitter of issue 3. 35 | * Dave was the first submitter of issue 4. 36 | 37 | The payouts for each would be: 38 | 39 | * Alice: $417.78 40 | * Bob: $206.31 41 | * Dave: $83.56 42 | * Frank: $2,292.35 43 | 44 | This example is further illustrated in [this spreadsheet](https://docs.google.com/spreadsheets/d/1eyyilZmwdjvZ2LaAsvDLzWyWKXDcqO9zabgNd2O5JWI/edit?usp=sharing). 45 | -------------------------------------------------------------------------------- /audits/watsons/fix-review-process.md: -------------------------------------------------------------------------------- 1 | # Fix Review Process 2 | 3 | The Lead Senior Watson for a contest will be expected to complete the fix review as a part of their role. The fix review ensures that the protocol’s changes post-audit have been properly implemented. The protocol will select a date within 3 weeks of the audit end-date for which they would like the fix review to be conducted. At this point one of 3 things happen: 4 | 5 | 1. Lead Senior Watson confirms that date works. 6 | 2. Lead Senior Watson proposes an alternative date for the fix review. 7 | 3. Lead Senior Watson does not have reasonable availability, and loses 25% of their fixed-pay compensation. That 25% will be used to compensate a new Watson (based on performance in that specific contest) to conduct the fix-review. 8 | 9 | If the Lead Senior Watson determines that the protocol’s code changes require >1 day to review, then Sherlock will work with the protocol team to schedule a new (hopefully smaller) contest to review these changes. The new contest can be as short as 3 days or as long as 3 weeks. When it’s determined that the protocol’s code needs a new contest, the initial Lead Senior Watson will lose their 25% fixed pay for the fix review (which did not occur), but they will get first priority to be the Lead Senior Watson on that protocol’s follow-up contest (and receive fixed pay for that). The protocol will be able to put that refunded portion (25%) of the Lead Senior Watson’s pay towards the fixed pay for the Lead Senior in that follow-up contest. The fixed pay for the follow-up contest should always be equal to or greater than the 25% fixed pay that was withheld in the previous contest. 10 | 11 | {% hint style="info" %} 12 | If a Lead Senior Watson places outside of the top 10 in the ranking for a contest they lead, then they must forfeit 25% of their fixed pay so that Sherlock can bring in a Watson who found more of the issues to conduct the fix review. 13 | {% endhint %} 14 | 15 | ### Receiving the 25% Fixed Pay 16 | 17 | The 25% Fixed Pay will be released up to two weeks after the fix review occurs. 18 | 19 | The two-week delay is so that the [Pre-Launch Bounty](../../bug-bounties/pre-launch-bounty.md) can flag any Critical issue that should have been caught in the fix review. 20 | 21 | If no issues are reported that should have been caught in the fix review, the 25% fixed pay gets unlocked. 22 | 23 | If an issue is reported that could have been caught during the original audit or audit contest, then it is not the sole responsibility of the fix reviewer to catch, and thus the 25% fixed pay gets unlocked. 24 | 25 | If a Critical vulnerability is found that could only have been caught during the fix review (was introduced after the original audit), then, depending on the size of the Pre-Launch Bounty, some or all of the 25% fixed pay will be re-routed to the bug bounty submitter, and away from the fix reviewer. 26 | -------------------------------------------------------------------------------- /audits/watsons/how-to-score-issue-points-in-a-contest.md: -------------------------------------------------------------------------------- 1 | # How to Score Issue Points in a Contest 2 | 3 | The total Contest Points which can be earned in a contest is the sum of the average Contest Points of each competitor (plus an inflation amount to offset new entrants). In this way, Watsons aren’t given an unfair advantage or disadvantage if they compete in an audit with relatively weak or relatively strong participants. 4 | 5 | Then, each Watson generates a score based on the amount of high and medium severity findings they submit. 6 | 7 | > Note: In Sherlock contests, only Medium and High vulnerabilities count for Issue Points. There is no reward for submitting Low or Informational issues. 8 | 9 | The points awarded for each issue submitted in a specific contest are called “Issue Points." 10 | 11 | A Watson’s Contest Points and payout from the prize pool is determined by calculating their share of all the Issue Points awarded, then multiplying their share by the total Contest Points and Prize Pool available. 12 | 13 | > _Watson1 Ranking Points = (Watson1 Issue Points Awarded / AllWatson Issue Points Awarded) \*_ (Total Ranking Points Available) 14 | 15 | > _Watson1 Prize Pool Award = (Watson1 Issue Points Awarded / AllWatson Issue Points Awarded) \* (Total Prize Pool Available)_ 16 | 17 | A Watson’s Issue Points earned is weighted based on severity and is calculated with sybil resistance in mind. The formula disincentivizes participants in the contest from submitting findings under multiple identities to try to earn more of the prize pool (i.e. a sybil attack). It does this by awarding a greater pro-rata portion of the prize pool based on not only the _severity_ of the finding, but also the _uniqueness_. In instances where multiple people find the same issue, the cumulative score is less than if one person found it, effectively penalizing an individual who attempts to “sybil attack” a finding. As you can see, High issues are weighted 5x more heavily than Medium issues: 18 | 19 | > _Medium Risk Issue Points Weighting = 1 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions_ 20 | 21 | > _High Risk Issue Points Weighting = 5 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions_ 22 | -------------------------------------------------------------------------------- /audits/watsons/lead-senior-watson-selection-process.md: -------------------------------------------------------------------------------- 1 | # Lead Senior Watson Selection Process 2 | 3 | In order to become a Senior Watson, you must pass 2 criteria: 4 | 5 | 1. **Compete in >=28 contest-days on Sherlock (contests where "USDC Only" is selected don't count)** 6 | 2. **Have at least 25% of the leaderboard points of the average of the Top 5 Senior Watsons.** Example: If the top 5 Senior Watsons have 800, 700, 650, 600 and 500 points, then the average is 650 points which means you must have at least 25% of 650 points (162.5 points) in order to pass this criteria. 7 | 8 | {% hint style="info" %} 9 | Senior Watsons have a pink crown next to their name on the [leaderboard](https://audits.sherlock.xyz/leaderboard). 10 | {% endhint %} 11 | 12 | These Senior Watsons have the opportunity to signal their interest in being selected as the Lead Senior Watson in an upcoming audit contest. Senior Watsons will be included in a specific Discord channel where new audit opportunities will be posted. The Sherlock team will also DM all Senior Watsons to check out the Senior Watson channel in Discord anytime a new audit contest is posted. 13 | 14 | Seniors Watsons have two options if they seek to be selected: 15 | 16 | 1. Indicate interest in being the Lead Senior Watson for the protocol and dates posted. 17 | 2. Indicate interest in being the Senior Watson, but propose alternative dates when you’re available. 18 | 19 | After 72 hours, Sherlock will select and notify the highest ranked Senior Watson as the Lead Senior Watson for the audit. Unselected Senior Watsons can still compete for the prize pool. If the Senior Watson does not confirm their participation in those 72 hours, Sherlock will select and notify the next highest ranked Senior Watson (who indicated interest) to the Lead Senior Watson position. 20 | 21 | If the audit was scheduled >72 hours in advance of the start date, then Sherlock will also contact the Senior Watson to re-confirm availability. We understand that life can sometimes get in the way of prior commitments, so Sherlock will reconfirm your participation to give us enough time to find an alternate Senior Watson to lead the audit contest if needed. 22 | 23 | ### Lead Senior Watson Fixed Pay 24 | 25 | Lead Senior Watsons have extra responsibilities compared to regular contest participants, such as conducting the fix review and helping with judging. 26 | 27 | However, a big advantage of leading a contest is earning fixed pay just for committing to participate. 28 | 29 | The amount of fixed pay a Senior Watson earns for a contest depends on the length of the contest. But it also depends on the relative ranking of that Senior Watson. Assuming a 1-week audit contest, here are the fixed pay breakdowns for Lead Senior Watsons: 30 | 31 | | Relative Position | Fixed Pay (per week) | 32 | | -------------------------- | -------------------- | 33 | | Top 33% of Senior Watsons | 12,500 USDC | 34 | | Top 67% of Senior Watsons | 10,000 USDC | 35 | | Top 100% of Senior Watsons | 7,500 USDC | 36 | 37 | For example, if there are 17 Senior Watsons in total and you are the 7th-ranked Senior Watson, then you are in the 41st percentile (7 divided by 17) of Senior Watsons. If you were selected to lead a contest, you would earn 10,000 USDC of fixed pay per week. 38 | -------------------------------------------------------------------------------- /audits/watsons/meeting-the-payout-criteria.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: How to make sure you get paid for your findings 3 | --- 4 | 5 | # Meeting the Payout Criteria 6 | 7 | Previously, anyone could sign up as a Watson, join a contest, and get paid for any valid issues they submit. The only caveat is that there was a USDC penalty for invalid issues. 8 | 9 | The USDC penalty is now gone, and it's replaced by 2 "Audit Contest Payout Criteria." 10 | 11 | {% hint style="info" %} 12 | If you don't pass either of these criteria at any time, your USDC payouts will be withheld until you pass both criteria, at which point they'll be paid out in full. 13 | {% endhint %} 14 | 15 | ## Audit Contest Payout Criteria 16 | 17 | ### 1. 2 Valid Issues 18 | 19 | Until you've submitted 2 valid issues with your Watson account, you will not receive USDC payouts. 20 | 21 | {% hint style="info" %} 22 | Although this rule is new, it will look at your account's lifetime record to see if >=2 valid issues have been submitted. 23 | {% endhint %} 24 | 25 | ### 2. Issues Ratio 26 | 27 | Your "issues ratio" must be >=20% otherwise you will not receive USDC payouts. 28 | 29 | The "issues ratio" is defined as: 30 | 31 | ``` 32 | # of valid issues submitted / total # of issues submitted 33 | ``` 34 | 35 | If less than 20% of the issues you submit are valid, your USDC payouts will be withheld until this ratio gets back above 20%. This is a lifetime ratio on your account, so it looks at every contest you ever participate in! 36 | 37 | {% hint style="info" %} 38 | Because this rule is new, it will only look at contests that started on or after July 1st, 2023. 39 | {% endhint %} 40 | 41 | #### What's the point of these criteria? 42 | 43 | The intention is to limit the number of invalid issues submitted to Sherlock. Sherlock receives hundreds of invalid issues in every contest and it requires a lot of time and resources for Sherlock to review each one of them. By implementing these criteria, Sherlock hopes that more of a contest's cost (in USDC) can be directed towards Watsons who are finding important vulnerabilities, and not on reviewing invalid issues. 44 | 45 | The "Issues Ratio" obviously wants to prevent a single account from submitting infinite invalid issues. 46 | 47 | The "2 Valid Issues" criteria is in place to prevent people from creating infinite accounts and submitting 1 issue in each account (hoping a few accounts get paid). 48 | -------------------------------------------------------------------------------- /audits/watsons/watson-points-example.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: A Hypothetical Walkthrough of How Leaderboard Points are Calculated 3 | --- 4 | 5 | # Watson Points Example 6 | 7 | First, you can find the Sherlock leaderboard [here](https://app.sherlock.xyz/audits/leaderboard). 8 | 9 | How are those leaderboard points calculated? And how you can move up the leaderboard as a security expert? 10 | 11 | ### **Where do leaderboard points come from?** 12 | 13 | Every ranked Watson carries an amount of Leaderboard Points with them into any contest where they compete for ranking. The number of Leaderboard Points each Watson brings into a contest is proportional to their leaderboard ranking.\ 14 | \ 15 | The only "new" Leaderboard Points (which come from Contest Points) are created from a small amount of Leaderboard Points inflation in each contest. This keeps the leaderboard from getting too stale over many years. Each Watson brings their Leaderboard Points into each contest, and the sum of every Watson's Leaderboard Points make up the amount of Contest Points available in that contest (plus the inflation amount). 16 | 17 | In this example, there are 5 Watsons. Each one has competed in a 7-day contest previously, so each one has some Leaderboard Points: 18 | 19 |
20 | 21 | Next, Alice, Bob, Carol, Dan, and Emily compete in their second Sherlock contest. It's a 14-day contest and at the end of the contest, there are 5 legitimate findings. One of them is High severity and four of them are Medium severity. The "1"s represent whether the participant submitted a particular finding or not. As we can see, Alice submitted the M1, M2, M3, and M4 findings. Bob only submitted the M2 finding. H1 represents the first High severity finding and M1 represents the first Medium severity finding. 22 | 23 |
24 | 25 | Here are the "sybil-resistant" formulas used to calculate how many "issue points" each participant gets for each finding: 26 | 27 | > _Medium Risk Issue Points Weighting = 1 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions_ 28 | 29 | > _High Risk Issue Points Weighting = 5 \* (0.9 ^ (IssueSubmissions - 1)) / IssueSubmissions_ 30 | 31 | As you can see, High severity issues are initially worth 5x more than Medium ones. But the final "issue points" awarded to each person depend heavily on how many others found the same issue. \ 32 | \ 33 | Here's how that same table from above looks using the "issue points" formulas: 34 | 35 |
36 | 37 | As you can see, Carol and Emily were the only Watsons to find H1 (a High severity issue) and they were awarded the most points out of anyone because of it. M2 was significantly less fruitful because it is Medium severity and everyone found it. 38 | 39 | Based on these "issue points," we can now see who performed best in the contest and earned the most from the USDC pot: 40 | 41 |
42 | 43 | Carol and Emily each make over 30% of the contest pot (over 60k USDC), largely driven by their submissions of H1, which no other Watsons found. Dan fared the worst because he only found 2 Medium severity issues, and other participants also found both of those Medium severity issues. 44 | 45 | Now comes a bit of complexity. The 5 participants have each completed a 7-day contest (previously) and a 14-day contest. Sherlock's scoring system puts a greater weight on the 14-day contest (2x weight to be exact) because it was a longer contest with a presumably larger codebase. So we'll take the old leaderboard points of all 5 participants (based on the 7-day contest) and weigh them against the new performances in the 14-day contest. As a reminder, points gained in the 14-day contest are relative to the % of the pot captured. Emily captured the highest % of the pot in the 14-day contest at \~34%, so she could see the biggest benefit from the second contest. However, the first contest will still make up \~1/3rd (7 days out of 21 days total) of her score. 46 | 47 |
48 | 49 | The formula being used to calculate Emily's score is the following: 50 | 51 | > (50.0 \* (7 / 21)) + ((33.7% \* 714) \* (14 / 21)) 52 | 53 | The 714 represents the cumulative amount of leaderboard points in the second contest from all the competitors, adding 2% inflation (14 extra points) for example. This is a simplified example where only the same 5 competitors happened to compete in similar-length contests. 54 | 55 | This is how the Sherlock leaderboard would look after these two contests: 56 | 57 |
58 | 59 | Because of the increased weighting of the 14-day contest vs. the 7-day contest, Carol and Emily ended up higher on the leaderboard than Bob, despite Bob's high ranking after the 7-day contest. 60 | 61 | Carol and Emily also earned the highest USDC payouts. But every Watson (including Carol and Emily) will need to ensure they clear [both audit contest payout criteria](https://app.gitbook.com/o/-M_eFb0i0B5bGNIG9sx8/s/IULvDRunHtCHQJQoTsGo/~/changes/107/audits/watsons/meeting-the-payout-criteria-july-1st-2023) in order to receive their USDC. 62 | -------------------------------------------------------------------------------- /bug-bounties/post-launch-bounty/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Sherlock protects teams against hacks at every step of the journey 3 | --- 4 | 5 | # 🚀 Post-Launch Bounty 6 | 7 | **Bug Bounty for Qualifying Customers** 8 | 9 | Qualifying customers who have undergone a Sherlock audit have the opportunity to participate in Sherlock's Post-Launch Bug Bounty Program. 10 | 11 | Sherlock's Bug Bounty Program is hosted on Sherlock's website. Security Researchers are able to submit vulnerabilities that relate to the customer's respective Bug Bounty program through a secure messaging portal, to which customers are given access. 12 | 13 | Customers are given access to the platform for an unlimited number of Submission Managers as whitelisted by the customer. Customers are given access to free triaging and issue explanations from a verified Security Researcher who has previously demonstrated proficiency with the customer's codebase (often through a Sherlock audit contest). 14 | 15 | Customers are also given access to Sherlock's full arbitration suite that includes access to the Sherlock Protocol Claim Committee and the UMA Optimistic Oracle to help with dispute resolution. Customers are provided with co-marketing of the customer's Bug Bounty Program according to Sherlock's standard marketing efforts. 16 | 17 | **Required Fees of Qualifying Customers** 18 | 19 | Qualifying customers are required to pay the Platform Fee. The Platform Fee is equal to ten percent (10%) of the Research Fee. The Research Fee is paid by the Customer to a Security Researcher who submits a valid finding in accordance with the rules and payout guidelines of the Bug Bounty Program. The Research Fee includes any goodwill payments. 20 | 21 | Qualifying customers are required to make payment to Sherlock as follows: 100% paid within 10 days of latest resolution (Sherlock Judge, Sherlock Protocol Claims Committee, UMA Optimistic Oracle). 22 | -------------------------------------------------------------------------------- /bug-bounties/post-launch-bounty/dispute-resolution.md: -------------------------------------------------------------------------------- 1 | # ⚖️ Dispute Resolution 2 | 3 | ## Bug Bounty Dispute Resolution 4 | 5 | From time to time, the submitter of a vulnerability will disagree with the protocol team about the owed payout amount. Because of incentives, this situation may occur somewhat frequently. 6 | 7 | Sherlock has created a system designed to maximize fairness while promoting and allowing for an environment of goodwill and friendliness between a submitter, protocol team, and any other party involved. Because of this, any participant in the system who seems to be acting in bad faith (badgering, threatening, harassing, etc.) may be removed (banned) from the Sherlock platform. Sherlock maintains full discretion in removal decisions. 8 | 9 | ### 3-Tiered Court System 10 | 11 | The Sherlock Dispute Resolution process can roughly be thought of as a 3-tier court system: 12 | 13 | * District/local courts (Sherlock Bounty Judge) 14 | * Circuit/regional courts (7-member Sherlock Protocol Claims Committee) 15 | * Supreme Court (UMA Optimistic Oracle) 16 | 17 | ### Level 1: Sherlock Bounty Judge 18 | 19 | Once a bug is submitted and the Sherlock team has been involved, the Sherlock Bounty Judge will eventually decide on the bug's validity and payout amount. The Sherlock Bounty Judge is a member of the Sherlock core team. They will make a decision after examining all facts and evidence presented by the report submitter, protocol team, and designed security expert reviewer. 20 | 21 | This is similar to other bug bounty platforms. And it’s not great because anyone who works at the bug bounty platform itself may be biased. If a bug gets paid out, the platform makes money. If not, the platform makes no money. 22 | 23 | That’s why there are 2 more levels to the Sherlock system. 24 | 25 | But before we get to the 2nd layer, a decision on validity and payout amount will be made by the Sherlock Bounty Judge. If the issue is deemed invalid or the payout amount is less than desired, the issue submitter has a few options: 26 | 27 | 1. Do nothing and abide by the decision 28 | 2. Enter into a limited (Sherlock-supervised) negotiation with the protocol team 29 | 3. Pay $1k to escalate the issue to the 2nd level of the court system: the Sherlock Protocol Claims Committee 30 | 31 | On the other hand, if the issue is deemed valid and the payout amount is higher than desired, the protocol team has a few options: 32 | 33 | 1. Abide by the decision and pay the requested amount 34 | 2. Enter into a limited (Sherlock-supervised) negotiation with the protocol team 35 | 3. Pay $1k to escalate the issue to the 2nd level of the court system: the Sherlock Protocol Claims Committee 36 | 4. “Ghost” Sherlock and the submitter and eventually get removed from the Sherlock platform (Note: Sherlock may attempt to enforce any terms of the legal agreement) 37 | 38 | ### Level 2: Sherlock Protocol Claims Committee 39 | 40 | The current members of the Sherlock Protocol Claims Committee can be found [here](https://docs.sherlock.xyz/governance/roles#sherlock-protocol-claims-committee). This committee is enforced by a 4 of 7 multisig and the members may change in the future. 41 | 42 | The Sherlock Protocol Claims Committee has been in existence for over 3 years and has shown itself to be trusted with multi-million dollar situations in Sherlock’s smart contract coverage protocol. 43 | 44 | The Sherlock Protocol Claims Committee will have 1 week to come to a decision. 45 | 46 | ### Level 3: UMA Optimistic Oracle 47 | 48 | But of course, these members may have certain biases or may not come to a decision that the submitter or protocol team agrees with. In that case, either the submitter or protocol team may pay \~$15k to escalate the decision to the 3rd level of the Sherlock Dispute Resolution process: the UMA Optimistic Oracle. 49 | 50 | The UMA Optimistic Oracle is best explained [here](https://docs.uma.xyz/protocol-overview/how-does-umas-oracle-work). It is the same mechanism that Polymarket uses to resolve disputed markets that may be worth hundreds of millions of dollars. Sherlock believes it is the best and most trusted third-party dispute resolution system in crypto at the time of writing. 51 | 52 | ### Negotiation 53 | 54 | The vast majority of legal cases in the world are settled before going to court. Sherlock hopes that the 2nd and 3rd tiers of the Sherlock Dispute Resolution process are rarely used. 55 | 56 | That’s why Sherlock allows for a limited period of negotiation as an alternative to escalating to the SPCC or UMA Optimistic Oracle. However, the negotiation MUST take place in the Sherlock-approved channel where Sherlock can view and moderate the discussion. 57 | 58 | Negotiation must not last longer than 14 days before an alternative option (pay the requested bounty, accept the decision, escalate to the 2nd or 3rd tier) must be selected. Negotiation must remain “good faith” and cordial. 59 | 60 | \ 61 | \ 62 | -------------------------------------------------------------------------------- /bug-bounties/post-launch-bounty/platform-rules.md: -------------------------------------------------------------------------------- 1 | # 📜 Platform Rules 2 | 3 | In order to facilitate cordial and productive exchanges between protocol customers and whitehats, Sherlock has established a set of rules for whitehats and protocol customers to define proper conduct. 4 | 5 | Breaking these rules as a whitehat could result in removal or ban from the Sherlock platform and/or withholding of payout. 6 | 7 | Breaking these rules as a protocol team could result in removal from the Sherlock platform and/or provide cause for breakage of the mutually signed agreement. 8 | 9 | ### Whitehats 10 | 11 | #### Ethical Standards 12 | 13 | * Adhere to ethical standards and legal guidelines. Any actions that compromise the integrity, privacy, or availability of systems beyond what is necessary for testing are strictly prohibited. 14 | * No harm: Ensure that your testing does not negatively impact users or infrastructure. 15 | * Always default to the assumption that the protocol team has good intentions. 16 | * Do not threaten, blackmail, dox, or otherwise create a negative environment for the protocol customer. 17 | * Do not communicate with the protocol customer outside of the official channel provided by Sherlock 18 | * By submitting a vulnerability through Sherlock, you are agreeing to abide by the outcome of the Sherlock dispute resolution process 19 | 20 | #### Testing Environment 21 | 22 | * Replicating tests on public mainnet or testnet is prohibited. All testing should be conducted on local forks of either testnet or mainnet. 23 | * Use only authorized environments for testing to avoid any unintended disruptions or security risks. 24 | * Avoid testing with external dependencies and third-party systems not controlled by the protocol customer to avoid any leaks of the potential vulnerability 25 | 26 | #### Service Disruptions 27 | 28 | * Any denial of service attacks that are executed against project assets are strictly forbidden. 29 | * Automated testing of services that generates significant amounts of traffic is not permitted. 30 | 31 | #### Vulnerability Disclosure 32 | 33 | * Do not publicly disclose vulnerabilities before they are resolved. Reports must be submitted through the Sherlock platform, and we will notify you when it is safe to disclose. 34 | * Do not discuss (publicly or otherwise) any aspect of a submitted vulnerability without consent from the protocol customer 35 | * Report via Sherlock: Use the official reporting channels to submit your findings. 36 | * Never exploit a vulnerability or threaten to do so 37 | * Do not attempt to rescue funds without the written consent of the protocol customer 38 | * Publicly known bugs or bugs reported in a previous audit are never eligible for payout or reimbursement of deposit 39 | 40 | #### Payouts 41 | 42 | * Do not try to cajole a protocol customer into paying you. Always use the provided Sherlock resolution mechanisms. 43 | 44 | ### Protocol Customers 45 | 46 | #### Ethical Standards 47 | 48 | * Do not communicate with the whitehat outside of the official channel provided by Sherlock. 49 | * Do not pay whitehats who submit bugs on Sherlock outside of Sherlock’s designated channel or without Sherlock’s consent. 50 | * Do not claim a bug report is a known or duplicate issue without clear evidence of where it was publicly available before the whitehat’s submission timestamp. 51 | * Always default to the assumption that the whitehat has good intentions. 52 | * By listing your bug bounty program on Sherlock, you are agreeing to abide by the outcome of the Sherlock dispute resolution process. 53 | 54 | \ 55 | -------------------------------------------------------------------------------- /bug-bounties/pre-launch-bounty.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Sherlock protects teams against hacks at every step of the journey 3 | --- 4 | 5 | # 🌱 Pre-Launch Bounty 6 | 7 | Sometimes there is a period after the fix review has been completed, but before a protocol goes live on mainnet. 8 | 9 | Sherlock wants to ensure that there is an incentive for whitehats to disclose any bugs that may be found during this period. 10 | 11 | Why? Because if a whitehat waits until the protocol is live on mainnet, this can result in bad outcomes such as a blackhat exploiting the bug first, or the team needing to do a lengthy and embarrassing re-launch. 12 | 13 | Sherlock attempts to mitigate this by creating a "Pre-Launch Bounty" program for every cooperating protocol team. 14 | 15 | This will be a very small bounty but will increase as the launch date approaches. 16 | 17 | It also acts as a "check" on the fix review. Before, there was little incentive to give maximum effort during a fix review. Now, the Lead Senior Watson (or whoever conducts the fix review) will only receive a portion of their fixed pay AFTER this Pre-Launch Bounty period has passed and no new Critical bugs were missed during the fix review. 18 | 19 | -------------------------------------------------------------------------------- /claims-assessment/deciding-on-payouts.md: -------------------------------------------------------------------------------- 1 | # Deciding on Payouts 2 | 3 | A protocol covered by Sherlock will bring a possible covered exploit in their protocol to the attention of Sherlock, specifically the Sherlock Protocol Claims Committee (SPCC). It is likely the security experts at Sherlock in charge of the covered protocol will be involved in this process and may lead the process of bringing the possible covered exploit to the attention of the SPCC. The covered protocol will also submit the amount of the claim. It is likely the security experts at Sherlock in charge of the covered protocol will also be heavily involved in advising the proper amount for which to create a claim. 4 | 5 | Once a possible exploit and the amount claimed by the covered protocol is brought to the attention of the SPCC, the process of deciding the validity of the claim begins. The SPCC will be made up of members of the core team of Sherlock as well as advisors to Sherlock. These members will be well-versed in the general nature of exploits and possible claims covered by Sherlock. This committee will be comprised of some of the foremost security experts in the DeFi space. All of the members of the SPCC will have a stake in Sherlock (likely in the form of tokens or equity) and will have an interest in doing what is best for the long-term health of Sherlock. They will also have reputations and public identities existing outside of Sherlock that they will want to uphold. These factors will make it very likely that the members of the SPCC will see it in their best interest to make the most accurate claims decision possible. 6 | 7 | ![](https://i.imgur.com/n1P41mz.png) 8 | 9 | The decision made by the SPCC will be binary (either a claim will be accepted or not). Once a decision is made on a claim by the SPCC, there are a few possible paths. The first path for a covered protocol is to accept the decision. The second path is to revise the claim (usually the amount of the claim) and re-submit. A covered protocol is limited to 3 submissions for each potential exploit (to be defined by the block number or range of the potential exploit). The third and last path is to escalate the arbitration. This would require the covered protocol to “stake” a reasonable claim amount (i.e. the lesser of $50k or 1% of the claim amount) to escalate the claim above the SPCC. The escalation would move the claim decision from Sherlock’s hands into the hands of UMA’s [Optimistic Oracle](https://docs.umaproject.org/getting-started/oracle). The claims decision would then be voted on by UMA tokenholders using UMA’s Data Verification Mechanism and the resolution of that vote will be the final claim decision. If the covered protocol is proven correct, then the amount specified by their claim will be paid out. They will also receive their stake back in full. If the covered protocol's escalation is not successful, then the amount specified by the claim is not paid out and the 1% (or less) stake is not returned. 10 | -------------------------------------------------------------------------------- /claims/claims-process.md: -------------------------------------------------------------------------------- 1 | # Claims Process 2 | 3 | One of Sherlock's biggest strengths is the fully trustless, unbiased claims process. 4 | 5 | If an eligible bug bounty or exploit is thought to have occurred at a covered protocol, the protocol can submit a claim to Sherlock. 6 | 7 | Sherlock's Watsons will first work alongside the core devs to mitigate the exploit if it is still exploitable. 8 | 9 | Once the exploit has been mitigated, the Watsons will work to understand the exploit's cause and magnitude. Through this process, a protocol will have a good sense of whether the exploit is covered by Sherlock, and thus a claim should be submitted. The Watsons will help with the general claim submission process as well as choosing the correct timestamp and amount that should be submitted for payout. 10 | 11 | The first stage of evaluating a claim is the committee vote of the SPCC (Sherlock Protocol Claims Committee). The SPCC is made up of members of the core team of Sherlock as well as security advisors to Sherlock. These committee members will be well-versed in the nature of exploits covered by Sherlock. All of the members of the SPCC have a stake in Sherlock and an interest in doing what's best for the long-term success of Sherlock and Sherlock's protocol partners. They will also have reputations and public identities outside of Sherlock that they will want to uphold. These factors will make it very likely that the members of the SPCC will see it in their best interest to make the most accurate claims decision possible. 12 | 13 | The SPCC's strength is its speed: a decision and payout can be executed in a number of hours. While the SPCC depends on a number of individuals who are associated with Sherlock, the second (optional) stage of the claims process is escalation to the UMA Optimistic Oracle. The UMA Optimistic Oracle is comprised of tens of thousands of UMA tokenholders who are likely unbiased and have an economic incentive to make a consensus decision. More about UMA's Optimistic Oracle can be found [here](https://docs.umaproject.org/getting-started/oracle). 14 | 15 | ![](https://i.imgur.com/MDFJCCt.png) 16 | 17 | The decision made by the SPCC will be binary (either the claim will be paid out or not). Once a decision is made on a claim by the SPCC, there are a few possible paths. 18 | 19 | The first path for a covered protocol is to agree and accept the SPCC's decision. 20 | 21 | The second path is to revise the claim (i.e. the amount of the claim) and re-submit. 22 | 23 | The third and last path is to escalate the claim to the UMA Optimistic Oracle. This would require the covered protocol to “stake” a reasonable claim amount, to escalate the claim above the SPCC, computed as follows: 24 | 25 | ``` 26 | Staked amount = 2 x (Sherlock's bond of 9600 USDC + UMA's final fee) 27 | ``` 28 | 29 | E.g. if Sherlock's bond is 9600 USDC and if UMA's final fee is 1500 USDC, the required staked amount for escalation would be 22,200 USDC. 30 | 31 | > Note: Even though Sherlock's bond is set at 9600 USDC, UMA's final fee can be changed in the future, which may result in lower or higher required staked amounts for escalating a claim. The current fee is fetched using the [computeFinalFee](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/oracle/implementation/Store.sol#L131) function. 32 | 33 | Half of the staked amount is necessary for the proposer (`requestAndProposePriceFor`) and half for the disputer (`disputePriceFor`), as explained in the [UMA's Optimistic Oracle documentation](https://docs.umaproject.org/getting-started/oracle) 34 | 35 | The escalation would move the claim decision from Sherlock’s hands into the hands of UMA’s Optimistic Oracle. The claims decision would then be voted on by UMA tokenholders using UMA’s Data Verification Mechanism and the resolution of that vote is the final claim decision. If the covered protocol is proven correct, then the amount specified by the claim will be paid out. They will also receive the staked amount, minus UMA's burned amount (Half of the Sherlock's bond of 9600 USDC + UMA's final fee). If the covered protocol's escalation is not successful, then the amount specified by the claim is not paid out and the stake amount is not returned. 36 | 37 | > Note: There is also an option for an UMA multisig to reject the claim decision if the core UMA team collectively believes the oracle didn't function properly. Because the UMA Optimistic Oracle is still somewhat new to this use case, and because the dollar amounts at stake could be extremely high, Sherlock has included this intermediate step in the code with the option to enable or disable it at launch. Once disabled, it cannot be re-enabled. 38 | -------------------------------------------------------------------------------- /coverage/claims/README.md: -------------------------------------------------------------------------------- 1 | # 📝 Claims 2 | 3 | -------------------------------------------------------------------------------- /coverage/protocols/README.md: -------------------------------------------------------------------------------- 1 | # 🧑💻 Protocol Teams 2 | 3 | -------------------------------------------------------------------------------- /coverage/protocols/composability-and-coverage.md: -------------------------------------------------------------------------------- 1 | # Composability and Coverage 2 | 3 | Sherlock recognizes that composability and a protocol’s need to integrate with other projects is a valuable part of the DeFi ecosystem. However, for the security of Sherlock’s staking pool, and consequently its covered customers, Sherlock needs to take a slightly risk-averse approach to how integrations are covered. 4 | 5 | Both extremes of composability/integrations are problematic. On one extreme, it’s unreasonable for Sherlock to _only_ cover integrations that are done with protocols previously audited by Sherlock. However, it’s equally unreasonable to expect Sherlock to cover any integration under the sun. So, Sherlock is taking an incremental approach, where the covered integrations will include a whitelisted set of protocols, as well as any protocol that has previously been audited by Sherlock. 6 | 7 | The current list (which will be updated periodically) can be found [here](https://github.com/sherlock-protocol/integrations-whitelist/commit/b343edd5d6d1f44e11abfc75c63240c6fc546081). 8 | 9 | If the uncovered protocol has coverage from Sherlock or another coverage provider, and a payout takes place (or is scheduled to take place) for that protocol, and the Protocol Customer receives reimbursement from that payout, then the total amount possible to be paid out to the Protocol Customer will be netted against the first payout. This is to ensure that Sherlock doesn’t pay the same affected party double their loss amount.\ 10 | \ 11 | In the event of a covered smart contract exploit or economic exploit, the Protocol Customer can submit a claim and be reimbursed for lost on-chain funds up to the stated Active Coverage Amount at the start block of the exploit. If for any reason the affected user(s) or affected protocol(s) see a partial or full return of the exploited funds before or after a payout from Sherlock, the returned funds must be deducted from the Sherlock payout and any amount paid out by Sherlock relating to the returned funds that had been lost (as part of a claim) must be returned to Sherlock. 12 | -------------------------------------------------------------------------------- /coverage/protocols/faq.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Common Questions for Adding Smart Contract Coverage to Your Protocol 3 | --- 4 | 5 | # FAQ 6 | 7 | **Can I see an example coverage agreement?** 8 | 9 | Yes. You can look through an example coverage agreement [here](https://docs.google.com/document/d/1ubWlKWrm0cOIddmvE1srKaAPfXPn9iSatDoylS3mepg/edit?usp=sharing).\ 10 | \ 11 | **What if we change the contract afterwards?** 12 | 13 | Ideally protocol teams will do update audits (through Sherlock) for any code changes that will go to mainnet. Sherlock offers 3-day micro contests for this purpose. 14 | 15 | But sometimes a protocol isn't able to get code audited before putting it live, so Sherlock will continue to cover the audited contract code even if other code within the contract is changed, but only payouts resulting from exploits that would have been possible without the unaudited, changed code would be eligible for coverage. 16 | 17 | New unaudited contracts are not covered by Sherlock, and any payouts resulting from exploits possible in those contracts will not be reimbursed. 18 | 19 | **Does the audit contest cost include coverage?** 20 | 21 | No. Coverage is an additional investment and is completely optional. You can decide to add coverage after the audit is complete. 22 | 23 | **Does Sherlock offer a bug bounty program?** 24 | 25 | Sherlock will help you set up a bug bounty program (through Immunefi) and Sherlock coverage will apply to Critical bug bounty payouts as defined by Sherlock. Bug bounty programs and audits are the best means available to prevent exploits and protect users. 26 | 27 | **Who qualifies for coverage?** 28 | 29 | Protocols that have: (1) completed a "non-best efforts" audit contest with Sherlock and (2) have received a sign-off on every fix completed during the fix review (3) have an nSLOC amount that is acceptable in Sherlock's pricing tables may request coverage from Sherlock. Request an audit [here](https://audits.sherlock.xyz/request-audit). 30 | 31 | If the fixes made after a Sherlock audit are extensive, Sherlock and the Lead Senior Watson may recommend an additional follow-up contest. This recommendation does not need to be followed, but it is mandatory to follow the recommendation to receive coverage. 32 | 33 | **If I don't get coverage after the audit contest, can I get coverage later?** 34 | 35 | It depends. Sherlock recommends getting coverage after the audit contest, but it may be possible to get coverage later if no changes were made to the smart contracts covered by Sherlock. 36 | 37 | **What is needed to go live with coverage?** 38 | 39 | All Sherlock needs to get things live are: 40 | 41 | 1\) Address controlled by your team (i.e. Gnosis multi-sig, MetaMask wallet) that you can send a transaction from so that you can file claims in the future 42 | 43 | 2\) The initial coverage payment. Here's Sherlock multi-sig address for the initial coverage payment: 0x666B8EbFbF4D5f0CE56962a25635CfF563F13161 44 | 45 | 3\) The amount of coverage desired 46 | 47 | **How much will monthly premiums cost if we went through a public contest with Sherlock, and got all of our fixes signed-off?** 48 | 49 | Sherlock can present a quote to you based on Sherlock's pricing tables. These tables take into account the nSLOC of the codebase that was audited as well as the public/private nature of the audit. 50 | 51 | **What is the address for the initial coverage payment?** 52 | 53 | The address (on Ethereum mainnet) for the initial coverage payment is: 0x666B8EbFbF4D5f0CE56962a25635CfF563F13161 54 | 55 | **Who should get coverage?** 56 | 57 | Sherlock recommends coverage to any protocol team that is interested in protecting their users from losses due to exploits. Audits and bug bounty programs are two of the best ways to protect users against losses and coverage can allow protocol teams to afford bigger bug bounties. 58 | 59 | **I already got an audit from someone else. Can I get coverage with Sherlock?**\ 60 | Unfortunately, Sherlock requires protocols to conduct a Sherlock audit contest for the opportunity to qualify for coverage. 61 | -------------------------------------------------------------------------------- /coverage/sherlock-shield.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: Sherlock now includes bug bounty and exploit coverage with every audit 3 | --- 4 | 5 | # 🛡️ Sherlock Shield 6 | 7 | Welcome to Sherlock Shield! 8 | 9 | Every protocol team that goes through a Sherlock audit gets access to bug bounty and exploit coverage on their audited code. 10 | 11 | Here's how it works: 12 | 13 | 1. Complete an audit with Sherlock 14 | 2. Complete the fix review 15 | 3. Sherlock sets up and pays for your small pre-launch bug bounty 16 | 4. Confirm the details of your post-launch bug bounty program 17 | 5. Post-launch, Sherlock covers up to $500k of bug bounty and exploit payouts 18 | 19 | After completing the fix review, Sherlock ensures that there is always a bug bounty on your code! With Sherlock's dual pre-deployment and post-deployment bug bounties, whitehats will be working around the clock to keep your protocol safe. 20 | 21 | ### Coverage Amount Criteria 22 | 23 | The amount of coverage Sherlock gives is based on the vulnerabilities found in the Sherlock audit: 24 | 25 | Each Medium severity vulnerability is worth 1 point, and each High severity vulnerability is worth 5 points. \ 26 | \ 27 | Additionally, there are multipliers for the type of audit done: 28 | 29 | | Audit type | Points Multiplier | 30 | | ------------- | ----------------- | 31 | | Recommended | 0.75 | 32 | | Minimum | 1.0 | 33 | | Best Efforts | 2.0 | 34 | | Private | 1.5 | 35 | | Collaborative | 1.5 | 36 | 37 | \ 38 | Like golf, you want your score to be as low as possible so you can access the maximum amount of coverage: 39 | 40 | | Points | Coverage Amount | 41 | | ------------ | --------------- | 42 | | 0 | $500,000 | 43 | | Less than 3 | $250,000 | 44 | | Less than 6 | $200,000 | 45 | | Less than 9 | $150,000 | 46 | | Less than 12 | $100,000 | 47 | | Less than 15 | $50,000 | 48 | | Less than 18 | $25,000 | 49 | | Less than 21 | $10,000 | 50 | | Less than 30 | $5,000 | 51 | | 30 or more | $1,000 | 52 | 53 | Note: Sherlock does not guarantee payment or the availability of funds. Payouts are determined by the [on-chain claims process](claims/) of the Sherlock protocol on Ethereum mainnet. Please review the [Sherlock Disclaimers](../disclaimers.md) to better understand the coverage offering. 54 | -------------------------------------------------------------------------------- /coverage/staking-apy/README.md: -------------------------------------------------------------------------------- 1 | # 💰 Stakers 2 | 3 | ### 4 | -------------------------------------------------------------------------------- /developer/audits.md: -------------------------------------------------------------------------------- 1 | # Claims 2 | 3 | As a security-focused project, Sherlock takes the security of its own protocol extremely seriously. 4 | 5 | You can find the list of audits for Sherlock's current (V2) protocol [here](https://github.com/sherlock-protocol/sherlock-v2-core/tree/main/audits). -------------------------------------------------------------------------------- /developer/claims.md: -------------------------------------------------------------------------------- 1 | # Claims 2 | 3 | ![Claim lifecycle](https://i.imgur.com/BEjncCz.png) 4 | 5 | ## Creating a claim 6 | 7 | Claims can be created by protocol agents. Protocol agents take actions on behalf of a specific covered protocol. The protocol agent will be the linked to the claim during it's lifecycle and is able to execute on future actions regarding the claim. 8 | 9 | Claims can be submitted for the current and previous coverage amounts of the protocol. 10 | 11 | Claims can still be submitted 7 days after coverage has ended. 12 | 13 | Only 1 claim can be active per protocol. Each claim has a state (default: nonExistent) associated with it at all times until it is removed and cleaned up. 14 | 15 | > Claims can be removed in the SpccPending or SpccDenied stage. After cleaning the previous claim, the protocol agent is able to submit a new claim. 16 | 17 | ## Sherlock Protocol Claims Committee 18 | 19 | After a claim is created, the Sherlock Protocol Claims Committee (SPCC) has 7 days to either approve or deny the claim. On approval the protocol agent is able to call `payoutClaim()`. If the SPCC denies the claim, the protocol agent is able to escalate the claim (if desired) to the UMA Optimistic Oracle. 20 | 21 | ## Escalate to UMA 22 | 23 | The protocol agent has to pay a bond to escalate the claim (~20k USDC). This bond will be paid back if UMA approves the claim. If UMA denies the claim the bond will be distributed to Sherlock stakers. 24 | 25 | ## UMA halt operator 26 | 27 | This role can be renounced, but if active this role can block a claim within 24 hours of approval by the UMA OO. In case no action is taken the claim is valid and a payout can be executed after 24 hours. The UMA halt operator role will likely be a multisig controlled by the UMA core team, who can decide if the oracle malfunctioned and block a potentially fraudulent claim result. 28 | -------------------------------------------------------------------------------- /developer/contract-reference.md: -------------------------------------------------------------------------------- 1 | # Contract Reference 2 | 3 | https://github.com/sherlock-protocol/sherlock-v2-core 4 | -------------------------------------------------------------------------------- /developer/deployed-contracts.md: -------------------------------------------------------------------------------- 1 | # Deployed Contracts 2 | 3 | ## Mainnet 4 | 5 | | Name | Address | 6 | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- | 7 | | SHER (proxy) | [0x46D2A90153cd8F09464CA3a5605B6BBeC9C2fF01](https://etherscan.io/address/0x46D2A90153cd8F09464CA3a5605B6BBeC9C2fF01) | 8 | | SHER (implementation) | [0x91f23210A34721D33C8842673f2Ba20146b8C70f](https://etherscan.io/address/0x91f23210A34721D33C8842673f2Ba20146b8C70f) | 9 | | Sherlock | [0x0865a889183039689034dA55c1Fd12aF5083eabF](https://etherscan.io/address/0x0865a889183039689034dA55c1Fd12aF5083eabF) | 10 | | MasterStrategy | [0x1E8bE946370a99019E323998Acd37A1206bdD507](https://etherscan.io/address/0x1E8bE946370a99019E323998Acd37A1206bdD507) | 11 | | SherDistributionManager | [0xe91693d47e88a0f17a827f2d4b1e7e9716326740](https://etherscan.io/address/0xe91693d47e88a0f17a827f2d4b1e7e9716326740) | 12 | | SherlockProtocolManager | [0x3d0b8A0A10835Ab9b0f0BeB54C5400B8aAcaa1D3](https://etherscan.io/address/0x3d0b8A0A10835Ab9b0f0BeB54C5400B8aAcaa1D3) | 13 | | SherlockClaimManager | [0xFeEDD254ae4B7c44A0472Bb836b813Ce4625Eb84](https://etherscan.io/address/0xFeEDD254ae4B7c44A0472Bb836b813Ce4625Eb84) | 14 | | timelockController | [0x92AEffFfaD9fff820f7FCaf1563d8467aFe358c4](https://etherscan.io/address/0x92AEffFfaD9fff820f7FCaf1563d8467aFe358c4) | 15 | | SherClaim | [0x7289C61C75dCdB8Fe4DF0b937c08c9c40902BDd3](https://etherscan.io/address/0x7289C61C75dCdB8Fe4DF0b937c08c9c40902BDd3) | 16 | | SherBuy | [0xf8583f22C2f6f8cd27f62879A0fB4319bce262a6](https://etherscan.io/address/0xf8583f22C2f6f8cd27f62879A0fB4319bce262a6) | 17 | 18 | ## Mainnet - Strategy Distribution 19 | 20 | | Name | Address | 21 | | ----------------------- | ----------------------------------------- | 22 | | Info Storage | [0xbFa53D098d7063DdCc39a45ea6F8c290FcD7FC70](https://etherscan.io/address/0xbFa53D098d7063DdCc39a45ea6F8c290FcD7FC70) | 23 | | Splitter 0 | [0x01fE7ff1162D4b4aB41bdaf99296644b7b0eE27D](https://etherscan.io/address/0x01fE7ff1162D4b4aB41bdaf99296644b7b0eE27D) | 24 | | Splitter 1 | [0x7E0049866879151480d9Ec01391Bbf713F7705b1](https://etherscan.io/address/0x7E0049866879151480d9Ec01391Bbf713F7705b1) | 25 | | AaveStrategy | [0x75C5d2d8D54254476239a5c1e1F23ec48Df8779E](https://etherscan.io/address/0x75C5d2d8D54254476239a5c1e1F23ec48Df8779E) | 26 | | CompoundStrategy | [0x5b7a52b6d75Fb3105c3c37fcc6007Eb7ac78F1B8](https://etherscan.io/address/0x5b7a52b6d75Fb3105c3c37fcc6007Eb7ac78F1B8) | 27 | | MapleStrategy | [0xB2acd0214F87d217A2eF148aA4a5ABA71d3F7956](https://etherscan.io/address/0xB2acd0214F87d217A2eF148aA4a5ABA71d3F7956) | 28 | -------------------------------------------------------------------------------- /developer/overview.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | > Repo: https://github.com/sherlock-protocol/sherlock-v2-core 4 | 5 | ## Architecture 6 | 7 | The [core contract](https://github.com/sherlock-protocol/sherlock-v2-core/blob/main/contracts/Sherlock.sol) (Sherlock.sol) is the main point of interaction for stakers. The contract has an upgradeable reference to 5 addresses. 8 | 9 | 1. Yield strategy (MasterStrategy.sol) 10 | 2. SHER rewards (SherDistributionManager.sol) 11 | 3. Protocol manager (SherlockProtocolManager.sol) 12 | 4. Claims/payout process (SherlockClaimManager.sol) 13 | 5. Non-Staker address (multisig wallet) 14 | 15 | ![Architecture overview](https://i.imgur.com/faompEY.png) 16 | 17 | Core holds USDC and the exact amount of SHER that will be distributed to stakers upon exiting their position. 18 | 19 | The yield strategy holds most of the USDC as the owner of the core contract can move funds into to the Master Strategy contract which will distribute the USDC between different protocols based on a preconfigured distribution. 20 | 21 | Protocol manager holds all the balances deposited by protocols and exposes the exact amount of debt to core, which is claimable each block. 22 | 23 | The claims/payout process contract is not supposed to hold funds. 24 | 25 | The non-staker address is able to claim funds from protocol manager based on the configuration of each covered protocol. 26 | 27 | ## Lifecycles 28 | 29 | Conceptually there a couple objects with a lifecycle 30 | 31 | * Stake position (Core) 32 | * Claim (Claim manager) 33 | * Protocol (Protocol manager) 34 | * SHER Rewards Curve (SHER distribution manager) 35 | 36 | Each object and their lifecycle can be viewed in the specific docs 37 | 38 | ## Roles 39 | 40 | Some of the contracts used in Sherlock V2 implement access control for certain functions. 41 | 42 | For Ownable, OpenZeppelin's Ownable library is being used. The owner address will belong to Sherlock governance. 43 | 44 | ### Sherlock.sol 45 | 46 | **Ownable** 47 | 48 | 1. `enableStakingPeriod()` 49 | 2. `disableStakingPeriod()` 50 | 3. `updateSherDistributionManager()` 51 | 4. `removeSherDistributionManager()` 52 | 5. `updateNonStakersAddress()` 53 | 6. `updateSherlockProtocolManager()` 54 | 7. `updateSherlockClaimManager()` 55 | 8. `updateYieldStrategy()` 56 | 9. `pause()` 57 | 10. `unpause()` 58 | 11. `yieldStrategyDeposit()` 59 | 12. `yieldStrategyWithdraw()` 60 | 13. `yieldStrategyWithdrawAll()` 61 | 62 | Functions 1 to 8 are functions calls that have a big effect on the way the protocol executes. 63 | 64 | Functions 9 and 10 are used in emergency situations when the protocol needs to be paused for investigation. 65 | 66 | Function 11, 12 and 13 are used to move the staker pool in and out of the active strategy. 67 | 68 | ### MasterStrategy.sol 69 | 70 | **Ownable** 71 | 72 | 1. `withdrawAllByAdmin()` 73 | 2. `withdrawByAdmin()` 74 | 75 | These functions are used to get USDC out of the underlying strategies. 76 | 77 | **onlySherlockCore** 78 | 79 | This role means that only the address associated with the active Sherlock.sol implementation can call the function. 80 | 81 | 1. `deposit()` 82 | 2. `withdrawAll()` 83 | 3. `withdraw()` 84 | 85 | These functions are used to get liquidity in and out of the underlying strategies. 86 | 87 | ### SherDistributionManager.sol 88 | 89 | **Ownable** 90 | 91 | 1. `sweep()` 92 | 93 | This function is used to get the remaining ERC20s and ETH out of the contract. This can only be called if it isn't the current active sher distribution manager. 94 | 95 | ### SherlockProtocolManager.sol 96 | 97 | **Ownable** 98 | 99 | 1. `setMinActiveBalance()` 100 | 2. `protocolAdd()` 101 | 3. `protocolUpdate()` 102 | 4. `protocolRemove()` 103 | 5. `setProtocolPremium()` 104 | 6. `setProtocolPremiums()` 105 | 7. `sweep()` 106 | 107 | This function is used to get the remaining ERC20s and ETH out of the contract. This can only be called if it isn't the current active sher distribution manager. 108 | 109 | **Protocol Agent** 110 | 111 | 1. `withdrawActiveBalance()` 112 | 113 | These function can only be called by the protocol agent, there are as many protocol agents as there are protocols. 114 | 115 | **Non Stakers** 116 | 117 | 1. `nonStakersClaim()` 118 | 119 | This function can only be called by the `nonStakersAddress`, which is defined in `Sherlock.sol` 120 | 121 | ### SherlockClaimManager.sol 122 | 123 | **Ownable** 124 | 125 | 1. `renounceUmaHaltOperator()` 126 | 2. `addCallback()` 127 | 3. `removeCallback()` 128 | 129 | **Protocol Agent** 130 | 131 | 1. `startClaim()` 132 | 2. `escalate()` 133 | 3. `payoutClaim()` 134 | 4. `cleanUp()` 135 | 136 | These function can only be called by the protocol agent, there are as many protocol agents as there are protocols. This agent retrieved from `SherlockProtocolManager.sol` 137 | 138 | NOTE: Function 2 and 3 use the stored protocol agent of `startClaim()` 139 | 140 | **UMA** 141 | 142 | > Read more about our UMA integration here https://docs.sherlock.xyz/claims/claims-process 143 | 144 | 1. `priceProposed()` 145 | 2. `priceDisputed()` 146 | 3. `priceSettled()` 147 | 148 | These functions can only be called by `UMA`, this is a hardcoded address in `SherlockClaimManager.sol` 149 | 150 | **UMAHO** 151 | 152 | 1. `executeHalt()` 153 | 154 | These functions can only be called by `UMAHO` (UMA Halt Operator), this is an address passed on in the constructor of `SherlockClaimManager.sol` 155 | 156 | **SPCC** 157 | 158 | 1. `spccApprove()` 159 | 2. `spccRefuse()` 160 | 161 | These functions can only be called by `SPCC` (Sherlock Protocol Claims Committee), this is an address passed on in the constructor of `SherlockClaimManager.sol` 162 | -------------------------------------------------------------------------------- /developer/protocols.md: -------------------------------------------------------------------------------- 1 | # Protocol Manager 2 | 3 | ## Adding a protocol 4 | 5 | Protocols start their lifecycle by being added using `protocolAdd()`, the same parameters are expected as `protocolUpdate()`, except for the `protocolAgent`. The `protocolAgent` address is used in the claims process and is able to withdraw active balance of a protocol. 6 | 7 | ## Setting the premium 8 | 9 | Once the protocol is added it is expected to deposit an active balance. Once the balance is deposited the premium can be set using `setProtocolPremium()`. 10 | 11 | The premium is subtracted from the active balance per second and claimable by the stakers and non-stakers. 12 | 13 | ## Being removed 14 | 15 | The protocol is expected to keep an active balance over time, this requires to call `depositToActiveBalance(protocol,amount)` every now and then. 16 | 17 | Protocols can lose their coverage in 3 different ways 18 | 19 | 1. Removal by governance 20 | 2. Removal by arb using insufficient balance 21 | 3. Removal by arb using insufficient seconds of coverage left 22 | 23 | > Protocols are still able to submit a claim for 7 days after being removed. 24 | 25 | ### Removal by governance 26 | 27 | A protocol can be removed by governance at any time. The remaining balance is sent to the `protocolAgent`. 28 | 29 | ### Removal by arb using insufficient balance 30 | 31 | If the active balance of the protocol goes below `minActiveBalance`, an arb can call `forceRemoveByActiveBalance(protocol)` and receive the remaining balance. 32 | 33 | ### Removal by arb using insufficient seconds of coverage left 34 | 35 | The protocol is expected to keep a balance that's sufficient to keep active coverage for more then `MIN_SECONDS_OF_COVERAGE`. 36 | 37 | Once the active coverage time gets below `MIN_SECONDS_OF_COVERAGE` an arb can call `forceRemoveBySecondsOfCoverage(protocol)` to remove the protocol. 38 | 39 | The arb will receive x% of the remaining balance. x is calculated using a linear formula starting at 0% and ending at 100% where the starting point is the time when 'coverage left' == `MIN_SECONDS_OF_COVERAGE` and the end point is when 'coverage left' is equal to 0 seconds. This process takes 12 hours and the peak reward will be at the 6 hour mark (50%) as the active balance of the protocol is simultaneously decreasing over time. 40 | 41 | ## Edge case accounting error 42 | 43 | > This will affect stakers in the core contract, it will not affect non-stakers. 44 | 45 | As described above the incentives are in place to remove protocols which have the potential to run higher debt than balance. As this will screw up the accounting. However, it is technically still possible for this edge case to exist: [code](https://github.com/sherlock-protocol/sherlock-v2-core/blob/main/contracts/managers/SherlockProtocolManager.sol#L309) 46 | 47 | If this scenario happens stakers could be negatively affected either way (as it could mint less shares or burn excessive USDC) but the contract tries to withhold the `insufficientTokens` by subtracting them from the claimable tokens for the stakers. If that doesn't work, it emits an `AccountingError` event with `insufficientTokens` > 0. The contract expects `insufficientTokens` to be transferred to the contract to make the accounting work again. 48 | -------------------------------------------------------------------------------- /developer/sher-distribution.md: -------------------------------------------------------------------------------- 1 | ## SHER Token Distribution manager 2 | 3 | The goal of this contract is to distribute SHER tokens to stakers who stake their USDC into Sherlock (for a specified lockup period). 4 | 5 | The core contract will call `pullReward(amount, period)` on every stake and restake action, and based on the curve described below the right amount of SHER tokens is sent back to the core contract. 6 | 7 | Enough tokens need to be available in this contract to actually transfer them to the staker at the end of a lockup period. 8 | 9 | ### Kors curve 10 | 11 | ![SHER distribution curve](https://i.imgur.com/1U3ibuR.png) 12 | 13 | The distribution curve starts with a fixed rate until a certain amount of TVL (a). Once (a) is reached, it will calculate rewards based on a linear slope until the max amount of TVL is reached (b). 14 | 15 | For this curve the current TVL is used as the starting point, the `amount` being deposited is used to get the SHER rate for the user, and the period will function as a multiplier for the SHER rate. 16 | 17 | So if you would receive 10 SHER tokens for a 1 month lockup, you would receive 30 SHER tokens for a 3 month lockup. 18 | 19 | If tokens are being staked after the TVL is past (b), no SHER rewards are distributed. 20 | 21 | ### Design goal 22 | 23 | The goal of this curve is to make sure Sherlock's TVL will never drop below a certain level. As the current TVL changes, the starting point on the curve moves more to the left if the TVL drops and to the right if the TVL increases. SHER rewards are automatically increased (on a TVL drop) or decreased (on a TVL increase) as the point on the slope changes. 24 | 25 | The flat part is there for the situation where governance wants to have a predictable, fixed SHER distribution rate up until (a). Without the flat part we would distribute an excessive amount of SHER to the earliest stakers. The curve also has the flexilbity to remove the flat part completely by setting (a) to 0. 26 | 27 | For simplicity we use the same curve for every staking `period` and use the `period` as a multiplier. This will result in the same APY for every staking period. But staking for 3 months twice or staking for 6 months once will likely result in a different SHER token reward as the point on the curve will likely be different when the second 3 month period is being initiated. It would be less SHER if the TVL is higher, it would be more SHER if the TVL is less after 3 months. 28 | -------------------------------------------------------------------------------- /developer/stake-position.md: -------------------------------------------------------------------------------- 1 | # Stake Position Lifecycle 2 | 3 | ![Stake position lifecycle](https://i.imgur.com/pUq6mkT.png) 4 | 5 | ## Minting a position 6 | 7 | Accounts can call `initialStake(amount, period, receiver)` to stake USDC into Sherlock. The lockup `period` is in seconds but periods need to be whitelisted by governance. At the initial deployment it will be possible to stake for 3, 6 or 12 months. 8 | 9 | During the `period` the position can be transferred using the ERC721 interface. But no Sherlock specific action can be executed during the lockup `period`. 10 | 11 | ## After lockup 12 | 13 | After the lockup period expires the following situations can happen 14 | 15 | * Owner calls `ownerRestake(id, period)` to restake all USDC for new `period` of time 16 | * Owner calls `redeemNFT(id)` to redeem all USDC and burn the NFT 17 | * If the owner doesn't execute either one of these actions in 2 weeks, any account is able to call `arbRestake(id)` to restake the position. 18 | 19 | > SHER rewards will be send to the owner on the first action after every lockup period 20 | 21 | ## Arb restake 22 | 23 | After 2 weeks without action on an unlocked position arbs can come in to `arbRestake(id)`, 20% of the underlying USDC amount (principal + yield) is at risk for the owner of the position. The reward rate moves from 0% of the underlying USDC amount to 20% over the course of 1 week. 24 | 25 | The position is restaked for 26 weeks after this call has been executed. At the end of 26 weeks the cycle described in 'after lockup' starts again. 26 | 27 | > All owed SHER rewards (from the previous lockup) are still transferred to the owner on `arbRestake()`. 28 | -------------------------------------------------------------------------------- /developers/deployed-contracts.md: -------------------------------------------------------------------------------- 1 | # Deployed Contracts 2 | 3 | > :warning: Don't use the Contract functions in the Etherscan contract tab. This will not result in expected behaviour as Sherlock is using a proxy. 4 | 5 | ## Mainnet 6 | 7 | | Name | Address | 8 | | ----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------: | 9 | | [Sherlock](https://github.com/mudgen/diamond-2/blob/master/contracts/Diamond.sol) | [0xacbBe1d537BDa855797776F969612df7bBb98215](https://etherscan.io/address/0xacbBe1d537BDa855797776F969612df7bBb98215) | 10 | | [Gov](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/Gov.sol) | [0x2776FB23394693829F1339154cC149391397fC3f](https://etherscan.io/address/0x2776FB23394693829F1339154cC149391397fC3f) | 11 | | [GovDev](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/GovDev.sol) | [0x3147528e778075e216aABC583aC7b823E4F133A1](https://etherscan.io/address/0x3147528e778075e216aABC583aC7b823E4F133A1) | 12 | | [Manager](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/Manager.sol) | [0x68A442cFf69bB6795528a22e2974b74c0ba8D555](https://etherscan.io/address/0x68A442cFf69bB6795528a22e2974b74c0ba8D555) | 13 | | [Payout](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/Payout.sol) | [0xC118439D0630873CdF3a1Fee798b22c2B61c23f9](https://etherscan.io/address/0xC118439D0630873CdF3a1Fee798b22c2B61c23f9) | 14 | | [PoolBase](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolBase.sol) | [0x4efE566cAb5E1018Be83E9C5De14836B96b4cA40](https://etherscan.io/address/0x4efE566cAb5E1018Be83E9C5De14836B96b4cA40) | 15 | | [SherX](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/SherX.sol) | [0xf6046651beaF118ED1f4fe2c93526c9e186Ee88B](https://etherscan.io/address/0xf6046651beaF118ED1f4fe2c93526c9e186Ee88B) | 16 | | [SherXERC20](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/SherXERC20.sol) | [0xEAFD0cE3eb91d08B36136e9FdD42b54D1bb9294A](https://etherscan.io/address/0xEAFD0cE3eb91d08B36136e9FdD42b54D1bb9294A) | 17 | | [PoolStrategy](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolStrategy.sol) | [0x3b354a4bd898d875D8eCFc4D7797FF8A1665C5E4](https://etherscan.io/address/0x3b354a4bd898d875D8eCFc4D7797FF8A1665C5E4) | 18 | | [PoolDevOnly](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolDevOnly.sol) | [0x8ca05763a3E46d27D1fc37Abaa622ed8A9067134](https://etherscan.io/address/0x8ca05763a3E46d27D1fc37Abaa622ed8A9067134) | 19 | | [PoolOpen](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolOpen.sol) | [0xCE9DD62A533cF89Abe5018af9682980922b5cE22](https://etherscan.io/address/0xCE9DD62A533cF89Abe5018af9682980922b5cE22) | 20 | | [AaveV2Strategy](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/strategies/AaveV2.sol) | [0xeecee260a402fe3c20e5b8301382005124bef121](https://etherscan.io/address/0xeecee260a402fe3c20e5b8301382005124bef121) | 21 | | [LibPool](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/libraries/LibPool.sol) | [0xeDdA10a93767b07F6913cb01479f6418Eb35aB7E](https://etherscan.io/address/0xeDdA10a93767b07F6913cb01479f6418Eb35aB7E) | 22 | | [LibSherX](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/libraries/LibSherX.sol) | [0x22b6D0df02fF7480c77d73A755e5E5eCdac53b1e](https://etherscan.io/address/0x22b6D0df02fF7480c77d73A755e5E5eCdac53b1e) | 23 | | [LockUSDC](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/ForeignLock.sol) | [0xde229e52bdb72c449db7912968e51d9d5e793005](https://etherscan.io/address/0xde229e52bdb72c449db7912968e51d9d5e793005) | 24 | | [LockSHERX](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/NativeLock.sol) | [0xca1bf9e6add6155e92dc1dc7c0bf210c159a2f43](https://etherscan.io/address/0xca1bf9e6add6155e92dc1dc7c0bf210c159a2f43) | 25 | 26 | ## Kovan 27 | 28 | | Name | Address | 29 | | ----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------: | 30 | | [Sherlock](https://github.com/mudgen/diamond-2/blob/master/contracts/Diamond.sol) | [0xAc8075751E250dBC5F09e639E75FeCa7656eeD3c](https://kovan.etherscan.io/address/0xAc8075751E250dBC5F09e639E75FeCa7656eeD3c) | 31 | | [Gov](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/Gov.sol) | [0x9796Fd72947aBB3C89E7Edf8A5ed58F731A6bA97](https://kovan.etherscan.io/address/0x9796Fd72947aBB3C89E7Edf8A5ed58F731A6bA97) | 32 | | [GovDev](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/GovDev.sol) | [0xf93ad2A54156Ac353165a6533CC4051C18FC7512](https://kovan.etherscan.io/address/0xf93ad2A54156Ac353165a6533CC4051C18FC7512) | 33 | | [Manager](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/Manager.sol) | [0xcb2c9934db15132f0de2272eAc885a53cB85660A](https://kovan.etherscan.io/address/0xcb2c9934db15132f0de2272eAc885a53cB85660A) | 34 | | [Payout](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/Payout.sol) | [0xBf3fDD0867a0c6a5F2ce62E61E16baa49D4b90f9](https://kovan.etherscan.io/address/0xBf3fDD0867a0c6a5F2ce62E61E16baa49D4b90f9) | 35 | | [PoolBase](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolBase.sol) | [0xd12b536354CE093cB9975E818C8877A21FbD0203](https://kovan.etherscan.io/address/0xd12b536354CE093cB9975E818C8877A21FbD0203) | 36 | | [SherX](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/SherX.sol) | [0x2d783Bfa056FF825cb5E4088C61B74Ef24A55C56](https://kovan.etherscan.io/address/0x2d783Bfa056FF825cb5E4088C61B74Ef24A55C56) | 37 | | [SherXERC20](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/SherXERC20.sol) | [0x9709c1922a1aac1E096Dc542cB8EBDEBcb9C1147](https://kovan.etherscan.io/address/0x9709c1922a1aac1E096Dc542cB8EBDEBcb9C1147) | 38 | | [PoolStrategy](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolStrategy.sol) | [0x813f3577B7e4373E085270dA6Cd4720f7b36D151](https://kovan.etherscan.io/address/0x813f3577B7e4373E085270dA6Cd4720f7b36D151) | 39 | | [PoolDevOnly](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolDevOnly.sol) | [0x1f232700569982D6D224fC2C3E1f02402D1F6293](https://kovan.etherscan.io/address/0x1f232700569982D6D224fC2C3E1f02402D1F6293) | 40 | | [PoolOpen](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/facets/PoolOpen.sol) | [0x3ab35b1a34f7c0f4aa755ff7a77e048800fcac5d](https://kovan.etherscan.io/address/0x3ab35b1a34f7c0f4aa755ff7a77e048800fcac5d) | 41 | | [AaveV2Strategy](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/strategies/AaveV2.sol) | [0x9Ba365766557b8ad9D1B869cd2d82d86E64e0121](https://kovan.etherscan.io/address/0x9Ba365766557b8ad9D1B869cd2d82d86E64e0121) | 42 | | [LibPool](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/libraries/LibPool.sol) | [0xe1215b2Dc94F487818d65FD7A4F8B9558602f0E0](https://kovan.etherscan.io/address/0xe1215b2Dc94F487818d65FD7A4F8B9558602f0E0) | 43 | | [LibSherX](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/libraries/LibSherX.sol) | [0x1B5eF99bbeAff23F6D7133fE421caCfC573d10ad](https://kovan.etherscan.io/address/0x1B5eF99bbeAff23F6D7133fE421caCfC573d10ad) | 44 | | [LockUSDC](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/ForeignLock.sol) | [0xd1EE32861E47c66663787579F8Ec95d3497AbaC1](https://kovan.etherscan.io/address/0xd1EE32861E47c66663787579F8Ec95d3497AbaC1) | 45 | | [LockSHERX](https://github.com/sherlock-protocol/sherlock-v1-core/blob/main/contracts/NativeLock.sol) | [0xb92c70918eb4f6d72031080Ee707281C337D4759](https://kovan.etherscan.io/address/0xb92c70918eb4f6d72031080Ee707281C337D4759) | 46 | -------------------------------------------------------------------------------- /disclaimers.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | Important information for protocol customers, stakers, security experts, and 4 | customers of Sherlock's protocol customers 5 | --- 6 | 7 | # ‼ Disclaimers 8 | 9 | #### What is Sherlock? 10 | 11 | The contributors to Sherlock don't think there's a great parallel between what Sherlock is and what may exist in other industries, etc. 12 | 13 | Sherlock was created solely to solve a problem: smart contracts are ALWAYS at risk of getting exploited, and this is not a good user experience. If crypto and smart contracts are going to be a bigger part of the world, more needs to be done to try to mitigate the exploit risk and fallout from exploits of smart contracts that were not implemented perfectly. 14 | 15 | Sherlock is trying to go further than anyone else in attempting to prevent smart contracts from being exploited and attempting to mitigate the monetary damages from those events. 16 | 17 | #### What is Sherlock NOT? 18 | 19 | Sherlock is not a perfect solution to smart contract hacks. Sherlock cannot EVER guarantee that a smart contract won't get hacked, and Sherlock cannot EVER guarantee that funds will be available to repay those hacks or bug bounties. 20 | 21 | Sherlock is not "insurance" or an "insurance company", as defined by various jurisdictions across the world. In some parts of the world, the term "insurance" only applies to entities that have government funds backing them in terms of repaying claims. If an insurance company goes bankrupt in those jurisdictions, government funds can often be used to repay claimants. Sherlock DOES NOT have backing from any government funds. Because of this (and other reasons) Sherlock cannot guarantee that any funds will be available for a protocol customer if the protocol has a bug bounty payout or gets exploited. Of course, Sherlock will try hard to ensure that funds will be there, but there is no guarantee. Traditional insurance companies also make decisions about whether insurance policies should get paid out or not. Sherlock operates very differently, and any payment to a protocol customer is NOT decided on by Sherlock. It is decided by a 4-of-7 multi-sig wallet, which Sherlock does not control. And if escalated, it is decided by the UMA Optimistic Oracle, which Sherlock does not control. For these reasons, Sherlock cannot guarantee that any payout will be made, even if it's plainly obvious to bystanders that a payout should be made. 22 | 23 | #### What is a Protocol Customer paying for? 24 | 25 | On the auditing side, a protocol customer is paying for the opportunity to use the Sherlock auditing marketplace. Sherlock does not currently employ "security experts" directly and does not claim to have expertise in finding the most pernicious bugs in the world. However, many of the security-minded participants in the marketplace are very talented at finding bugs. Sherlock's system is designed to aggregate the very best security experts in the world, but there is no guarantee that those experts will be available at all times, or that they will find every bug. Sherlock believes that any security service that claims it can prevent 100% of bugs in smart contracts is lying. Sherlock does not claim to be able to do this, but the Sherlock auditing marketplace is designed to have a strong chance of finding the most bugs possible in the smart contracts that are audited through the marketplace. However, the expectation should be that bugs will be missed. \ 26 | \ 27 | On the coverage side, Sherlock has made a large effort (more than any other crypto security firm that Sherlock is aware of) to attempt to have some amount of funds available for paying out to protocol customers for smart contract bug bounties or exploits that were missed during the Sherlock audit marketplace process. When each respective protocol seeks to engage Sherlock to identify potential smart contract exploits through the marketplace of talented security-minded participants and takes that process to completion (finishes the fix reveiw, etc.), they are eligible for activating coverage (unless it's a "best efforts" audit or any other conditions are not met). Sherlock backs its process by allowing such respective protocol a potential recovery as specified in their respective coverage agreement, in the event Sherlock missed an attack vector that is identified through a bug bounty or exploit, so long as no other nonqualifying events apply. Protocol teams (and the users of those protocols) must conduct their own research, and Sherlock makes no representations about the economic viability of each given protocol or associated cryptocurrency. Only the respective protocol itself may recover using Sherlock, and any such recovery is not guaranteed, cannot be guaranteed, and is subject to various terms, conditions, and limitations. A protocol customer may pay for a certain amount of coverage (i.e. 1M USDC), but there is no guarantee that the Sherlock staking pool will have 1M USDC to fulfill the 1M USDC repayment. It's not possible to guarantee this for many reasons: the Sherlock protocol can itself be exploited and all funds drained, other protocol customers may experience exploits first and the funds can get drained, and other instances can occur. Besides this, there are many other reasons why the 4-of-7 multisig or the UMA Optimistic Oracle may decide NOT to send funds to a protocol customer that believes it has experienced an exploit. Every protocol customer has a publicly available "Coverage Agreement" which explains to the multi-sig and to the UMA Optimistic Oracle, what the intended details of coverage are. If an event occurs which those mechanisms decide does not fall into the correct category in the Coverage Agreement, then the protocol customer may not receive funds. There are also risks such as governance attacks, smart contract exploits, malicious behavior etc. that can cause the 4-of-7 multisig or UMA Optimistic Oracle to behave unexpectedly, and potentially not send funds to a protocol customer who believes they should be paid out. 28 | 29 | #### What does a user of a protocol that has coverage from Sherlock get in a bug bounty or exploit event? 30 | 31 | Aside from all the risks and potential malfunctions detailed in the paragraphs above, a user of a protocol that has coverage from Sherlock has even more risks for why they may not receive any payout in a loss situation. The Sherlock protocol is designed for management by, and payout to, protocol customers, NOT their users. Sherlock hopes, but cannot guarantee or provide expectation, that the protocol customer will decide to use the funds to repay users. Because of this, even if a payout DOES occur to a protocol customer, there can be no expectation that a user will receive benefit, because the protocol customer would have control of any funds. If the protocol customer makes a mistake (sets up the funds to be sent to the zero address, etc.) then the user of the protocol customer may receive no monetary benefit from the coverage relationship between Sherlock protocol and the protocol customer. If the protocol customer behaves maliciously (runs away with the payout from Sherlock) then the user of the protocol customer may also receive no monetary compensation in this situation. Sherlock wants to make it very clear that there is no guarantee of a payout, and that there is no guarantee that the payout actually reaches the affected users. 32 | 33 | #### How might a protocol customer handle these risks? 34 | 35 | From the user perspective, Sherlock strongly discourages a protocol customer from messaging anything to users that includes some kind of promise or guarantee. Sherlock cannot promise or guarantee that any protocol customer, or user of a protocol customer, will receive a payout from Sherlock, even if it seems obvious that the criteria for payout have been met. Many (but not all) of the reasons (smart contract hacks, etc.) are detailed in the paragraphs above. Sherlock wants to make it very clear that a protocol customer should not message to users that Sherlock coverage is anything more than an attempt to provide a possible path to a partial or full payout in the event of a covered smart contract exploit, but with no guarantees of such payout. 36 | 37 | From a protocol customer's viewpoint, Sherlock encourages thinking about Sherlock coverage as a very uncertain, but potentially helpful payout in the event of a covered smart contract bug bounty submission or exploit and nothing more. Sherlock does not guarantee or promise the payout or availability of funds. Sherlock strives to never charge a protocol customer for an amount that is more than what is available to that customer at any given moment. For example, if a protocol is paying for 1M USDC of coverage at T=1, the protocol should also have access to 1M USDC of coverage at T=1. If the available coverage goes to 0 USDC at T=2, Sherlock strives to charge the protocol for 0 USDC worth of coverage at that time. This doesn't always happen perfectly, because Sherlock can't adjust coverage amounts every block, but Sherlock strives to at least re-align the coverage and payment aspects every two weeks, and at best much more often (whenever there is a material change). 38 | -------------------------------------------------------------------------------- /faq.md: -------------------------------------------------------------------------------- 1 | # 🙋 FAQ 2 | 3 | ## General 4 | 5 | ### What is Sherlock? 6 | 7 | * Sherlock is an audit marketplace and smart contract coverage protocol built on the Ethereum blockchain. Sherlock works to protect Decentralized Finance (DeFi) users from smart contract exploits with security reviews from top auditors backed by smart contract coverage on the audited contracts. 8 | 9 | ### How is Sherlock different from other audit firms? 10 | 11 | * Most audit firms rely on their reputation to convince protocol teams to use them. This is a poor way to guarantee incentive alignment. Sherlock provides something far more valuable than reputation: USDC. If a contract that is audited and covered by Sherlock has a bug bounty payout (or gets exploited), then Sherlock's staking pool can pay out USDC to reimburse the entire bug bounty (minus a deductible) or part of the exploit. This is a much stronger incentive to do a good job vs. relying on an amorphous reputation across hundreds of audits and dozens of individual auditors. 12 | * Many audit firms charge 100% more than what they pay individual auditors. This is the "reputation premium." Sherlock can pay top independent security experts more than they would make at leading audit firms. Then Sherlock can offer USDC backing behind Sherlock's audit. And the cost can often STILL be lower than what most traditional firms charge. 13 | * Good security work is done by talented individuals. Many audit firms have been known to hide lesser talented individuals behind their overall audit firm reputation. This means the quality of audit you will get from other firms is highly variable. You should always check to see who the individual auditors are. Sherlock is very transparent about the [qualifications of individual auditors](https://audits.sherlock.xyz/leaderboard). 14 | 15 | ### How is Sherlock different from other risk management protocols? 16 | 17 | Coverage is managed by protocols/DAOs instead of users 18 | 19 | * Right now, the burden of managing smart contract risk is borne entirely by users. By working directly with protocols, smart contract coverage can be applied to all users with no extra work required. It's very difficult for users to coordinate on a whitehat bug bounty, so this is better managed by the protocol team. Not to mention, when an exploit happens, protocol teams often find themselves deciding to reimburse all users as much as possible, so getting covered at the protocol level helps builders sleep better. 20 | 21 | Sherlock can price coverage the lowest because we do the most up-front work 22 | 23 | * Because Sherlock requires a full audit from Sherlock before coverage can go live, Sherlock gains more confidence in the security of the smart contracts than anyone else. This allows Sherlock to reward safe protocols for being safe by pricing coverage lower than anyone else can offer. 24 | 25 | Claims decisions are made by an unbiased 3rd party 26 | 27 | * Follow the incentives. Does a successful payout rely on a decision made by someone who will lose a lot of money if they decide in your favor? Sherlock has partnered with UMA to offer an unbiased claims process handled by objective, third-party voters who have economic guarantees around their incentives. Read more [here](https://docs.umaproject.org/getting-started/oracle). 28 | 29 | ### How does staking work? 30 | 31 | * A user stakes USDC for a fixed term (6 months or 12 months) and receives a market-leading yield in return. The yield is partially fixed, partially variable. The amount of SHER tokens a staker will receive is known at the time of staking and is fixed for the duration of the stake. Premiums received by stakers would be expected to increase as more protocols become covered. If there is a covered smart contract exploit during the term, a staker's funds can be slashed up to 50%. 32 | 33 | ### How can I get an audit or coverage from Sherlock? 34 | 35 | * Please reach out to contact@sherlock.xyz. 36 | 37 | ### Is coverage for a protocol always fully collateralized? 38 | 39 | * One of the superpowers of a risk management protocol like Sherlock is using diversification to increase the affordability of coverage and limit the need for full collateralization. This is what allows coverage to be affordable in traditional markets. The value staked into Sherlock's staking pools is designed to be less than the total funds that Sherlock is covering. By the same token, the staking pool is also designed to be significantly larger than the max size of coverage at any one protocol. 40 | * Isolated exploits should always be 100% paid out. Sherlock is designed to have at least 200% overcollateralization for any singular exploit event. 41 | * Things get more interesting if an exploit occurs at multiple covered protocols and drains 100% of the funds of multiple protocols at the same time. In this situation, depending on the capital efficiency of Sherlock, Sherlock may not be able to reimburse each exploit (assuming 4 or more simultaneous exploits) at 100 cents on the dollar. However, Sherlock's risk models are designed to mitigate the risk of multiple protocols being affected by the same type of exploit. Consequently, it would constitute an extremely unlikely event (never before seen in DeFi) to have multiple covered protocols hacked for nearly all of their TVL at the same time -- but it is theoretically possible. 42 | * Even in extreme scenarios where Sherlock's capitalization falls below the coverage amount for a single protocol, that protocol will only be charged for the amount it would receive in a payout. This ensures that, at any given time, a protocol NEVER overpays for coverage. 43 | 44 | ### What is a "Best Efforts" audit? 45 | 46 | * An audit labeled "Best Efforts" means that the amount of money dedicated to the contest by the protocol team is lower than Sherlock's minimum recommendation. A "Best Efforts" audit is not eligible for coverage from Sherlock afterward. Sherlock offers "Best Efforts" audits because some teams do not have the budget to meet Sherlock's minimum recommended contest cost and Sherlock still wants to do its best to find as many bugs as possible in this codebase instead of leaving these teams to use other (potentially less effective) auditors. 47 | -------------------------------------------------------------------------------- /glossary.md: -------------------------------------------------------------------------------- 1 | # 📚 Glossary 2 | 3 | ## Sherlock Terminology 4 | 5 | ### Bug Bounty 6 | 7 | * A bug bounty is essentially a reward offered to an honest participant who finds a way to exploit a protocol. Black hat hackers are "bad guys" who exploit a protocol directly, leading to losses for all users. White hat hackers are "good guys" who report a potential exploit vector to the protocol team in return for a bug bounty reward (usually USDC). 8 | 9 | ### Claim 10 | 11 | * A claim occurs when a protocol covered by Sherlock receives a bug bounty submission or believes it has been hacked and believes Sherlock has a responsibility to repay the bug bounty or hack. See the [claims section](https://docs.sherlock.xyz/claims/claims-process) for details. 12 | 13 | ### Coverage 14 | 15 | * If Sherlock takes on a protocol as a customer, the "coverage" is the amount of tokens (USDC) that Sherlock will reimburse when a bug bounty submission or exploit (that falls under the coverage agreement) occurs. 16 | 17 | ### Exploit 18 | 19 | * For Sherlock's purposes, an exploit is the act of maliciously removing tokens (usually tokens deposited by others) from a protocol in an unintended way. Sherlock covers most (but not all) exploits that a protocol could experience. For a detailed breakdown of which exploits are generally covered, take a look at our current coverage agreements [here](https://github.com/sherlock-protocol/sherlock-reports/tree/main/coverage-agreements). 20 | 21 | ### Premium 22 | 23 | * The amount of USDC a protocol pays Sherlock over a specified time interval. In return, Sherlock reimburses covered bug bounty submissions and exploits experienced by the protocol over that same time interval. 24 | 25 | ### SHER 26 | 27 | * Sherlock's governance token. See the [SHER section](https://docs.sherlock.xyz/tokens/sher) for more info. 28 | 29 | ### Staking 30 | 31 | * The act of depositing USDC into a Sherlock staking pool for a fixed period (6 months, 12 months, etc.). Once USDC has been deposited, USDC and SHER tokens accrue to the depositor in the form of APY. A portion of the staked tokens (up to 50% for an individual exploit) in the staking pool is at risk of being liquidated due to a bug bounty payout or exploit at one of the protocols covered by Sherlock. 32 | 33 | ### Unstaking 34 | 35 | * The act of removing staked USDC from the Sherlock staking pool. This action can only be taken once the staking period (6 months, 12 months, etc.) for that USDC has ended. 36 | 37 | ### Watsons 38 | 39 | * "You know my methods, Watson. There was not one of them which I did not apply to the inquiry." - _The Memoirs of Sherlock Holmes_ (1893) 40 | * Watsons are the individuals without which Sherlock would be nothing. These are the security experts who do the deep fundamental research (audits) that allows Sherlock to confidently provide coverage for a given protocol's smart contracts. 41 | -------------------------------------------------------------------------------- /governance/roles.md: -------------------------------------------------------------------------------- 1 | # Protocol Roles 2 | 3 | ### Governance Functionality 4 | While the protocol is quite governance-minimized, there are still some aspects that will be controlled by a governing party. At launch, a multi sig controlled by the Sherlock core team will be in control of upgrades, pausing and functionality related to adding and removing covered protocols. Over time, this functionality will be turned over to a DAO that will be in full control of the parts of the Sherlock protocol which can be changed. 5 | 6 | ### Sherlock Protocol Claims Committee 7 | As described in the [Claims](https://docs.sherlock.xyz/claims/claims-process) section, the Sherlock Protocol Claims Committee (or SPCC) is the first of two arbitration mechanisms that decide whether a claim should be paid out or not. 8 | 9 | The SPCC is optimized for speed, at the expense of some potential for bias. If some amount of bias is believed to have occurred, a protocol can escalate their claim above the authority of the SPCC, and put it in the hands of the UMA Optimistic Oracle. The UMA OO is a slower process but the claim decision is made by tens of thousands of UMA tokenholders who, as a whole, are probably not biased towards Sherlock or the protocol submitting the claim. 10 | 11 | The SPCC is made up of core Sherlock team members in addition to well-known security experts in the space. This committee controls a multisig that accepts or denies a protocol's claim submission. Again, if the committee votes in a way that the protocol disagrees with, the protocol can escalate to the UMA Optimistic Oracle. 12 | 13 | The address of the SPCC multi-sig is: 0x4Fcf6AA323a92EB92a58025E821f393da6C41bD6 14 | 15 | The current members of the SPCC are: 16 | 17 | | Name | Address | 18 | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------- | 19 | | [Jack Sanford](https://twitter.com/jack__sanford) | 0xfcb7493E4a059eF1CCBb53e71Cb94cc5d3d380bf | 20 | | [Evert Kors](https://twitter.com/Evert0x) | 0x3ea15C2EaF93bA32172EB8A789B937255624c24c | 21 | | [John Mardlin](https://twitter.com/maurelian_) | 0xF0001193a7919B14417c038604846D7b3F8F4BC3 | 22 | | [Rajeev Gopalakrishna](https://twitter.com/0xRajeev) | 0x7e026a0C061382B0F5935a90BC7324ab0a5A3aCc | 23 | | [Emiliano Bonassi](https://twitter.com/emilianobonassi) | eth:0x36388492077FBE730e82b408E6bec3318C54d6c3 | 24 | | [Mikko Ohtamaa](https://twitter.com/moo9000) | 0x7FfAB8b2f131AF752319A1641B52ac0a9bbB41B7 | 25 | | [Mick de Graaf](https://twitter.com/MickdeG010) | 0x0C42567e180CdEdd5B4C690678B6662D74193457 | 26 | 27 | 28 | ### UMA Halt Operator 29 | This is another multi sig that will be controlled by the core UMA team. Basically, the UMA Optimistic Oracle is completely trustless so for the first few months Sherlock has requested to have an "emergency halt" mechanism. This mechanism will be controlled by the UMA core team and allow UMA to deny/halt a claim that is moving through the UMA Optimistic Oracle in case something breaks. The protocol who submitted the claim will then be able to resubmit the claim once a fix is made. This mechanism will be removed after a few months and there will be no functionality to add it back, fulfilling the promise of a truly trustless claims process. 30 | 31 | ### Protocol Agent 32 | A protocol agent is simply a wallet or multi sig controlled by a covered protocol. This agent will have the ability to do protocol-specific actions like submitting claims and withdrawing unused funds (in the case of overpayment). 33 | 34 | ### NFT Owners 35 | When a staker deposits funds into Sherlock, the staker receives an NFT in return. If the staker tries to unstake but no longer holds the NFT, the unstake transaction will fail. Only the owner of the NFT at any given time can do important actions that are specific to the NFT position. The only exception is restaking done by arbitragers, discussed in the [Unstaking](https://docs.sherlock.xyz/stakers/lockup-period#unstaking) section. 36 | 37 | -------------------------------------------------------------------------------- /protocols/exploit-flow.md: -------------------------------------------------------------------------------- 1 | # Payout Flow 2 | 3 | If a covered bug bounty submission or exploit is thought to have occurred at a covered protocol, the protocol can submit a claim to Sherlock. 4 | 5 | Some of the Sherlock Watsons can be expected to work alongside the core devs to initially mitigate the attack vector if it is still exploitable. Once the exploit has been mitigated, the Watsons will work to understand the bug bounty report or exploit's cause and magnitude. From this process, a protocol will have a good sense of whether the bug bounty or exploit experienced is covered by Sherlock, and thus a claim should be submitted. The Watsons can help with the general claim submission process (info required) as well as choosing the correct timestamp and amount that should be submitted. 6 | 7 | Details about Sherlock's full claim process can be found [here](https://docs.sherlock.xyz/claims/claims-process). The first stage of the claims review is the decision made by the Sherlock Protocol Claims Committee (SPCC). If the protocol disagrees with the SPCC decision, the protocol can post a bond of \~$22k and escalate the claim to UMA's Optimistic Oracle. This allows the protocol to have access to an unbiased, third-party judgment on whether the claim should be paid out or not. 8 | 9 | If a claim should be paid out, the payout will go to the address specified by the protocol (protocol agent) when the claim was initiated. 10 | 11 | > Note: The address that submits a claim will be linked to the claim throughout the claim's lifecycle. This is noteworthy because a protocol can update their "agent" address, but any claim that is started will have to finish with the old address. Basically, this means a protocol team shouldn't start a claim with an address that they might lose access to before the claim is resolved (a matter of weeks at most). 12 | 13 | ## After an Exploit 14 | 15 | When the dust has settled from an exploit and the claim has been resolved, the initial coverage agreement will become void. 16 | 17 | > Note: Coverage amounts through Sherlock do not automatically regenerate after a payout. 18 | 19 | In order to reactivate the coverage agreement, a new agreement must be entered into with Sherlock. This allows Sherlock to re-assess the risk of any protocol after they've suffered a large exploit and update the premium accordingly. 20 | -------------------------------------------------------------------------------- /protocols/getting-started.md: -------------------------------------------------------------------------------- 1 | # Getting Started 2 | 3 | Sherlock offers bug bounty and exploit coverage for protocols that have gone through Sherlock's auditing process in order to maintain a high bar for security and align Sherlock's incentives with protocol teams. The process to complete an audit and get coverage live can be found [here](../audits/protocols/how-it-works-for-protocols.md). 4 | 5 | Once a protocol has completed the fix review, Sherlock will strive to give the protocol the ability to initiate coverage on the contracts that were audited as soon as the protocol team is ready, provided no material changes have been made to those contracts. 6 | 7 | A protocol team can request an audit [here](https://audits.sherlock.xyz/request-audit)! 8 | -------------------------------------------------------------------------------- /protocols/initiating-coverage.md: -------------------------------------------------------------------------------- 1 | # Initiating Coverage 2 | 3 | Any protocol with funds locked in its smart contracts for any period of time can lose those funds due to an exploit. Therefore, any such protocol can benefit from exploit protection. Once an agreement is reached about what types of coverage a protocol is looking for (the coverage agreement), the security team can begin a security assessment. A security assessment will likely take a few days to a few weeks and it will assess not only the risk of exploits in smart contracts (and smart contract bugs), but also areas like the development practices of the team, the risk management processes built into the protocol and the safety of protocols that said protocol interacts with. 4 | 5 | From this assessment, Sherlock's security and risk teams will agree on a price they would be comfortable charging the protocol. The security and risk teams will mostly come up with the “floor” price or the lowest price at which they would feel comfortable insuring a certain protocol. 6 | 7 | Sherlock and the protocol will also agree on the dollar value to be insured. If the protocol’s TVL is $500M, maybe they will want $500M to be covered or maybe they will only have a special $100M pool that they want covered. For now, size of Sherlock's staking pools needs to be at least 3x bigger than the size of any pools to be covered for a protocol. 8 | 9 | For example, a protocol wants $100M covered. Sherlock would need to have at least $300M in the staking pools, otherwise there would need to be a different agreement put in place. Because of the possibility of outflows from Sherlock's staking pools, Sherlock may implement a buffer amount (10% for example) to account for fluctuations in the size of Sherlock's staking pool. 10 | -------------------------------------------------------------------------------- /protocols/premium-payment-mechanics.md: -------------------------------------------------------------------------------- 1 | # Premium Payment Mechanics 2 | 3 | There will be two inputs that are sent on-chain (from off-chain) for protocol payments: 4 | 5 | 1. The amount of tokens that a protocol is paying block-by-block 6 | 2. The price of the tokens 7 | 8 | These values will be updated once a week (for gas efficiency) to ensure the amount of tokens a protocol is paying is roughly in line with the % fee charged on the USD value being covered. Because the token a protocol is paying with (at least during the guarded launch) will be the same token (USDC) in which premiums are denominated, there should be no need for "mid-week updates" to correct any currency fluctuations. 9 | 10 | ## Examples of mid-week updates 11 | 12 | If Sherlock comes to an agreement with a protocol to cover a certain pool for them (instead of a $ amount) and the TVL of that pool changes by a material amount (e.g. due to a whale staking/withdrawing), then Sherlock will update the protocol payment amount to reflect the increased or decreased TVL. During the guarded launch, Sherlock will only write fixed amounts of coverage, so there should be no need for mid-week updates. 13 | -------------------------------------------------------------------------------- /protocols/premium-tokens.md: -------------------------------------------------------------------------------- 1 | # Premium Tokens 2 | 3 | For now, protocols can only pay premiums in USDC. This may change in the future. 4 | -------------------------------------------------------------------------------- /protocols/premiums.md: -------------------------------------------------------------------------------- 1 | # Coverage Premiums 2 | 3 | Once an agreement has been reached on the cover amount (e.g. $500k) and the price of coverage, Sherlock can calculate the per-second USDC premium that the protocol will pay at any given time. 4 | 5 | ### Maintaining an Active Balance 6 | 7 | A protocol will add USDC to its active balance in Sherlock's Protocol Manager contract. Protocols can manage their active balance [here](https://app.sherlock.xyz/protocols/balance). In order to stay current on payment, the protocol must simply keep the balance above a minimum USDC amount (currently 500 USDC) and a minimum amount of seconds of coverage left (set to 12 hours). If a protocol's active balance drops below either of these thresholds, an arbitrager can remove the protocol from coverage for a fee. For the 12-hour minimum, the arbitrager fee increases linearly over time to ensure the arbitrager doesn't receive an egregiously large fee. Once a protocol's coverage ends, Sherlock is no longer responsible for repaying any payouts that occur. But when a protocol's coverage first ends, it will have a 7-day window to submit claims for payouts that may have occurred when the coverage was still active. 8 | 9 | If a protocol decides it wants to withdraw USDC from its active balance, it is perfectly free to do so. However, there is a minimum level of USDC that cannot be withdrawn (7 days worth). This is to give Sherlock time to react if a protocol decides to cancel its coverage. A protocol is free to cancel coverage at any time, it will just not be able to withdraw its last 7 days worth of payment. A protocol can also decide to run down the last 7 days of coverage instead of canceling, at which point an arbitrager will eventually remove the protocol when the balance is very low (i.e. 500 USDC or a few hours from being exhausted). 10 | 11 | ### Fluctuating TVL 12 | 13 | If Sherlock's staking pool TVL sinks below a threshold (defined in the coverage agreement) of the coverage policy amount (i.e. $500k) for any reason, then Sherlock will only charge based on the amount of coverage being offered. This prevents a protocol team from being overcharged in a scenario where Sherlock can no longer pay out the full coverage amount. 14 | -------------------------------------------------------------------------------- /protocols/pricing.md: -------------------------------------------------------------------------------- 1 | # Pricing 2 | 3 | Sherlock only offers bug bounty coverage. But every bug bounty coverage policy includes an equal amount of exploit coverage. If a protocol team signs up for $500k of bug bounty coverage, a $500k exploit coverage policy will be automatically included. This is to ensure that Sherlock isn't incentivized to hope protocols get exploited on mainnet instead of paying out a bug bounty. \ 4 | \ 5 | Sherlock requires 1 month's worth of upfront payment before coverage can be activated. From there, it's up to the protocol team in terms of paying bi-weekly, monthly etc. All Sherlock monitors is that the balance of payment does not reach zero. If it reaches zero (technically if it reaches 500 USDC) a protocol will be auto-removed from coverage by an arb bot. 6 | 7 | A protocol team can manage payments directly using the [protocol payment portal](https://app.sherlock.xyz/protocols/balance). 8 | -------------------------------------------------------------------------------- /protocols/protocol-premiums.md: -------------------------------------------------------------------------------- 1 | # Protocol Premiums 2 | 3 | Once an agreement has been reached on the cover amount (e.g. $100M) and the price of coverage (e.g. 2%), then Sherlock can calculate the per-block premium that the protocol will pay. 4 | 5 | Because it’s extremely gas-inefficient to send a payment every block, the protocol will initially send at least two weeks worth of payment up front. The payment for the first week will be “drawn down” in Sherlock's internal accounting block-by-block and the payment for the second week will be a buffer, just in case there is some problem with payment once the first week has been drawn down. 6 | 7 | In this way, a protocol can manage its payment by sending one week's payment at a time (or a months’ worth of prepay if they want to) after the initial deposit. If a protocol isn’t able to pay for whatever reason, the coverage stops at the block where the payment stream ended. 8 | -------------------------------------------------------------------------------- /security-team/incentives.md: -------------------------------------------------------------------------------- 1 | # Incentives 2 | 3 | One of the cruxes of the Sherlock protocol design is the alignment between stakers and security analysts. This alignment is seen in many other "financial" designs such as venture capital firms or hedge funds. In Sherlock's case, stakers are “LPs” who are not experts in a given field but have capital they want to deploy. Security analysts are like “hedge fund analysts” who have expertise in a certain field but don’t have the same level of capital or risk profile as LPs. The way these two parties coordinate in a traditional finance setup is through something like a “2 and 20” model, where analysts allocate the LP capital and receive 20% of the gains and 2% of the total value of the capital every year. Sherlock has taken after the spirit of this cooperation. 4 | 5 | For each protocol covered by Sherlock, 10-20% of the premium payments will be earmarked for the security team responsible for that protocol (as opposed to the staker pool). These fees will be "vested" for a certain amount of time. If no hacks occur on the relevant protocol during the specified vesting period, then the fees are released to the security team as incentive compensation. 6 | 7 | There is some nuance when a hack occurs during a vesting period: the pricing of the protocol’s coverage matters. If a security expert or team prices a specific protocol at 2%, there is an implied “acceptable” hack amount baked in to that 2%. If the value of the hack comes in below that implied “acceptable” amount, then the security team will still have claim to the majority of the tokens in vesting. If the hack comes in above the value implied in the 2% pricing, then the slashing of the vesting compensation can be very severe, to the point where the entire compensation pool can be drained in a scenario where the hack comes in much, much higher than the implied “acceptable” amount. 8 | 9 | ## Who would want to sign up for the security team? 10 | 11 | Being a part of the Sherlock security team is not for everyone. If someone has a very low risk tolerance for the variability of their compensation, this role may not be right for them. However, Sherlock has seen that there is a meaningful subset of the security community that is looking for a role exactly like this. Instead of having passive participation in preventing hacks, Sherlock security analysts get much more agency in securing one or many important DeFi protocols, and the hundreds of millions or billions of dollars locked in those protocols. The lead security expert (and the supporting security team members) have full responsibility for the security of a protocol. And of course, they have a massive interest in the outcome. 12 | 13 | If a Sherlock security analyst decides to take on a $1Bn policy at a protocol, they will likely have $2M-$4M of compensation paid out and/or at stake after just one year (10-20% of a 2% annual coverage premium on a $1Bn pool). If they keep the protocol safe during the vesting period, that $2M-$4M accrues directly to them (and their team, if any). Aside from being a black-hat hacker, there is no other opportunity in the security landscape that compares to the potential earnings of a Sherlock security expert. 14 | -------------------------------------------------------------------------------- /security-team/intro.md: -------------------------------------------------------------------------------- 1 | # Intro 2 | 3 | The Sherlock smart contract security team will assess protocol risk and assist in pricing the coverage for protocols. Sherlock has initially decided to utilize a more decentralized security team because of the relative availability of talent in that pool and the added flexibility of more easily matching security expert capacity with new protocols Sherlock brings on. 4 | -------------------------------------------------------------------------------- /security-team/payout-mechanism.md: -------------------------------------------------------------------------------- 1 | # Payout Mechanism 2 | 3 | The on-chain mechanism for the security team payout is not very complex. When Sherlock takes on a new protocol, the percent of fees allocated to the security team will be decided. This will likely be in the range of 10-20% of the total fees paid to Sherlock. That payment will accrue into a special pool which governance can transfer to a governance-controlled address at any time by calling a transfer function. The rest of the payout factors (tranched vesting schedule, implied hack values, etc.) will be calculated off-chain and payments will be made on a scheduled basis. Bringing this functionality entirely on-chain doesn't provide a ton of added value, which is why Sherlock will start out with a simplified (and partially off-chain) payout mechanism. However, this mechanism will be automated and decentralized over time. 4 | -------------------------------------------------------------------------------- /stakers/activate-cooldown.md: -------------------------------------------------------------------------------- 1 | # Activate Cooldown 2 | 3 | Because there is a 7-day waiting period before a staker can withdraw (i.e. unstake) their stake (lockToken i.e. lockUSDC) and owed interest (SherX), a staker must first call activateCooldown to start the timer on the 7-day waiting period. When the activateCooldown function is called, Sherlock mints the SherX a user is owed and deposits it in the SherX staker pool. This happens as a by-product of transferring the staker’s lockTokens back to Sherlock. The staker then receives lockSherX tokens. In a separate Solidity contract (to reduce complexity in the main contract), it is possible to immediately trigger an activateCooldown of the lockSherX in the same block as the activateCooldown of the original lockToken (lockETH, etc.). This allows a staker to receive their lockToken and their SherX interest on the same block when they call the unstake function. Because the method of delivery for SHER tokens is different during the guarded launch, the SHERX portion of this paragraph is not relevant. 4 | -------------------------------------------------------------------------------- /stakers/explaining-the-cooldown.md: -------------------------------------------------------------------------------- 1 | # Explaining the Cooldown 2 | 3 | A staker will not be able to unstake immediately. This is because it will take Sherlock time to recognize, diagnose and pay out a hack. A staker could easily unstake their stake during this time as soon as they hear about a hack. Because of this dynamic, a cooldown period needs to be implemented before a staker can unstake. Currently the cooldown period is 7 days. So if a staker wants to unstake, they begin the process by activating the cooldown. This will start a 7-day timer in which a staker’s funds no longer earn interest (even though they are still exposed to hacks during this time). 4 | 5 | To implement this, the staker’s lockTokens are transferred to the Sherlock protocol and earned interest goes to the “first money out” pool instead of the staker. After the 7-day cooldown expires, a staker will have a 2-day window to unstake. The same dynamic of being exposed to hacks but not receiving interest will apply for those 2 days. If a staker does not withdraw in that 2-day period then the staker must call the unstakeWindowExpiry() function in order to get their lockTokens back and continue earning interest. The staker will then have to restart the 7-day cooldown if they want to try to unstake again. 6 | 7 | ## Why doesn’t a staker get paid interest during the cooldown even though their funds are at risk? 8 | 9 | There are two forces at work here: 10 | 11 | 1. There needs to be a disincentive for activating the cooldown. Otherwise, as a staker, it would make sense to repeatedly activate the cooldown (every 9 days in this example) to try to “game” the system and time your unstaking to avoid paying out future hacks. 12 | 2. From a technical implementation perspective, not paying interest during this period is much simpler (as opposed to solutions that include paying out interest during the cooldown). We've chosen this route for our V1 protocol design. 13 | -------------------------------------------------------------------------------- /stakers/exploit-flow.md: -------------------------------------------------------------------------------- 1 | # Payout Flow 2 | 3 | There are three important stages of a payout: 4 | 5 | 1. The initial bug bounty submission or exploit event 6 | 2. When the claim gets submitted 7 | 3. When the claim gets paid out 8 | 9 | Only stakers who are still locked up during the third phase will have to pay out. Any staker who unstakes funds before the actual payout (because they are in an unstaking window) will not have to pay out. 10 | 11 | Each covered protocol will have a policy that is targeted to be 50% or less of the total Sherlock staking pool. This ensures that any single payout event at any single protocol can cause a payout for a maximum of 50% of the staking pool. More than 50% of the staking pool can be used for a payout if multiple covered protocols experience covered payouts in a short timeframe. 12 | 13 | However, if the size of the bug bounty or exploit payout is smaller than the total coverage amount at a protocol, the size of the payout will be a fraction of the maximum coverage for that protocol. Also, if a bug bounty payout or exploit becomes possible on multiple protocols due to a chain bug (i.e. a bug in Ethereum L1), then no more than 50% of the staking pool can be used to repay those similar events, even if individual protocols had policies that aggregate to a sum that is larger than 50% of the staking pool. 14 | -------------------------------------------------------------------------------- /stakers/harvest.md: -------------------------------------------------------------------------------- 1 | # Harvest 2 | 3 | Note: This section is not relevant during the guarded launch because no APY will be paid to the SHERX pool. 4 | 5 | If a staker stakes ETH into Sherlock's staking pools, they will start earning SherX tokens. These SherX tokens will accrue in the pool. They don’t physically accrue since they haven’t been minted yet, but Sherlock's internal accounting will accrue them block-by-block to the ETH pool and thus proportionally to any ETH staker. SherX tokens in the pool will be available to pay out exploits. They will also be included in the staking pools' size calculation. The only difference between interest earned in SherX and staked tokens is that users are not compensated for keeping earned SherX tokens in the pool (they aren’t paid SherX on their SherX). It’s actually in a staker’s best interest to withdraw their SherX tokens as soon as possible (since they are available to pay out exploits but not earning interest). 6 | 7 | Because of this dynamic, Sherlock has a harvest function where users can transfer their SherX into the SherX pool, and they will earn SherX on their staked SherX. The harvest function makes it so a staker doesn’t have to wait 7 days (due to the cooldown) to unstake their SherX tokens and then restake them. They can start earning SherX on their previously earned SherX immediately, they just have to spend the gas to call the harvest function. 8 | -------------------------------------------------------------------------------- /stakers/interest-streams.md: -------------------------------------------------------------------------------- 1 | # Interest Streams 2 | 3 | As a user's stake remains in a staking pool over time, it will earn three different streams of interest. 4 | 5 | ## STREAM #1 6 | 7 | A staker’s initial stake (i.e. USDC) will likely be swept into an “already insured” protocol like Aave or Compound -- where it will continuously earn market-rate interest. 8 | 9 | **Why Aave or Compound?** The #1 priority for staking pool funds is principal preservation. It doesn’t make much sense to deposit staking pool funds into the very same ecosystem that needs coverage so badly. However, certain protocols have their own Sherlock-like funds (Aave being a notable one with the Safety Module). It seems justifiable to place Sherlock's staking pool funds into protocols that meet a certain standard of safety and have some type of coverage outside of Sherlock. 10 | 11 | ## STREAM #2 12 | 13 | A staker will also earn interest from protocol payments. A protocol that is paying Sherlock for coverage will “stream” payment block-by-block for coverage. Sherlock is built to allow protocols to have lots of choice in their payment token. However, this will not be the case during Sherlock's guarded launch. Because protocols may eventually pay in a variety of tokens, a new token was introduced, called SherX, to represent a staker's proportional share in all the protocol payment tokens. If Sherlock covers 10 protocols and they are all paying in different tokens (often their governance token), it's very gas-intensive to pay stakers in 10 different tokens. So SherX is minted to represent a staker’s share of earned fees. 14 | 15 | **Why mint SherX instead of paying stakers directly in protocol payment tokens?** It really comes down to gas. If Sherlock has 20 protocols on board and 20 different tokens being paid into the pool, it’s very costly on unstake to pay stakers in 20 different tokens. On top of that, the staker might have staked ETH and they just want more ETH. So they have to do 20 separate transactions after the first 20 transactions to get all the tokens into ETH. Whereas if SherX is minted to represent a proportional share of the 20 tokens, it’s more gas efficient and it will be easier for the staker to get from SherX to ETH or a specific token they want to hold. In order to make this possible, a Uniswap pool for SherX (SherX vs. ETH) will be created. In addition, anyone can redeem SherX tokens for the underlying collateral (the 20 different tokens, in this example) at any time using the redeem function. This will insure that SherX always trades fairly close to the value of its underlying collateral (because an arbitrager could buy discounted SherX tokens on Uniswap and redeem them for the full value of the underlying collateral). 16 | 17 | **Will protocols be allowed to pay in tokens other than USDC after the guarded launch?** It seems unlikely at this point that Sherlock will allow protocols to pay in tokens other than USDC in the short to medium term. This means the SHERX mechanism is not very useful and it may be removed in future versions of the Sherlock protocol. 18 | 19 | ## STREAM #3 20 | 21 | A staker may also receive Sherlock governance token (SHER) incentives. Especially as the staking pools are ramping up, the APY generated from protocol payments may not be very high. While in the bootstrapping phase, the number of protocol customers on board will likely be less than Sherlock's ideal customer count at scale. During this bootstrapping phase, it may be difficult to grow the staking pools as stakers will have less incentive to stake (due to low APY). This is the time when it will be critical to use SHER incentives to build up the pool. There are two main ways Sherlock can use SHER to build up funds in the staking pools: 22 | 23 | 1. Paying SHER to the staker pools in order to increase the effective APY on staking and encourage more stakers. 24 | 2. Selling a small amount of SHER for ETH or another token. Sherlock governance would then stake that ETH into the staking pools. This is effectively protocol-controlled value (as it’s come to be known). Sherlock governance may decide to put these funds into a “first-money-out” pool in order to encourage stakers even more. Stakers would then be protected from losses by the “first-money-out” pool in addition to any protection received from deductibles provided by protocols themselves. 25 | -------------------------------------------------------------------------------- /stakers/lockup-period.md: -------------------------------------------------------------------------------- 1 | # Lockup Period 2 | 3 | In order to stake into Sherlock's staking pool, you must commit the funds to a lockup period. At launch, the lockup periods will be 6 months or 12 months. 4 | 5 | ### APYs 6 | 7 | The headline APY for each lockup period will be the same. Why? If you expect SHER token incentives to go down over time, then you may want to lock in 12 months worth of SHER tokens at today's rate. If you expect SHER token incentives to go up over time, then you probably want to lock in 6 months worth of SHER tokens now, and then restake your position at the higher rate later on. Sherlock generally expects the SHER token incentives to go down over time, which should incentivize a healthy mix of different staking periods. 8 | 9 | ### Unstaking 10 | 11 | After the lockup period has passed, a staker has the option to either unstake their position or restake their position. Either option will result in the owed SHER tokens being sent to the staker. 12 | 13 | If a staker doesn't unstake within two weeks of the lockup period passing, they will get auto-restaked for 6 months. Auto-restakes are done by arbitragers who receive a portion of the stake's USDC in return for paying the gas to restake the position. The "reward" for an arbitrager increases slowly over the course of 1 week (after the initial 2 week period), until it reaches the max reward rate of 20% of a staker's USDC position. The SHER token rewards from the recent lockup period are still sent to the original staker, not the arbitrager. 14 | -------------------------------------------------------------------------------- /stakers/overview.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | A staker deposits USDC into Sherlock's staking pool for a fixed term (6 months, 12 months etc.) and receives a market-leading APY in exchange for the risk of funds being used (up to 50%) to pay out a bug bounty submission or exploit at a covered protocol. 4 | 5 | The APY for a staker is made up of 2 streams: 6 | 7 | 1. Premiums from protocol customers 8 | 2. Incentive rewards paid in SHER (Sherlock’s governance token) 9 | 10 | In return for these streams, a staker’s funds are at risk of being partially liquidated (up to 50%) if a covered bug bounty payout or exploit payout occurs at a protocol covered by Sherlock (or possibly a protocol that the covered protocol depends on). Despite the risk, stakers are incentivized to stake because: 11 | 12 | 1. They are paid a substantial APY for the risk 13 | 2. They see the quality and incentive alignment of the audit process 14 | -------------------------------------------------------------------------------- /stakers/staking-APY.md: -------------------------------------------------------------------------------- 1 | # Staking APY 2 | 3 | ### Fixed vs. Variable APYs 4 | 5 | As mentioned in the [Overview](https://docs.sherlock.xyz/stakers/overview), stakers receive APY from 2 sources: 6 | 7 | 1. Premiums from protocol customers 8 | 2. Incentive rewards paid in SHER (Sherlock’s governance token) 9 | 10 | The premiums from protocol customers are generally a fixed amount (unless the protocol's TVL is lower than their coverage amount). But anytime the USDC amount provided by stakers changes, the APY to any individual staker changes. 11 | 12 | The incentive rewards are variable in $ terms, but fixed in SHER token terms. Any staker will be able to see exactly how many SHER tokens they will receive for staking. If a staker doubles the length of the stake (from 6 months to 12 months), the amount of SHER tokens to be received will double as well. In this way, stakers will have a good sense of the value they're guaranteed to receive by locking up their USDC. Of course, the APY from SHER tokens will fluctuate as the price of SHER fluctuates. 13 | 14 | ### How are the SHER tokens for each stake calculated? 15 | 16 | In short, the amount of SHER tokens disbursed for a stake depends on 3 factors: 17 | 18 | 1. The amount of USDC already staked 19 | 2. The amount of staked USDC targeted by Sherlock governance 20 | 3. The size of the stake 21 | 22 | ![SHER distribution curve](https://i.imgur.com/1U3ibuR.png) 23 | 24 | All stakes that end before point A are paid the maximum amount of SHER per USDC staked. 25 | 26 | All stakes that start before point B receive some amount of SHER per USDC staked. Any USDC staked beyond point B receives no SHER tokens. 27 | 28 | Points A and B will be set by Sherlock governance to strategically maintain the desired level of staked USDC over time in order for Sherlock to meet its potential obligations (i.e. payouts) to covered protocols. 29 | 30 | Points A and B may not be visible in the UI, but any staker will know exactly how many SHER tokens they will receive before they stake. 31 | -------------------------------------------------------------------------------- /stakers/transfer.md: -------------------------------------------------------------------------------- 1 | # Transfer 2 | 3 | Note: This section is not relevant during the guarded launch. 4 | 5 | Sherlock lockTokens (for example lockETH) will be ERC-20 compatible (fungible) in order to increase their liquidity on secondary markets. 6 | 7 | The lockTokens will accrue certain amounts of SHERX interest based on how long they have been staked in the pool. If a staker transferred lockTokens that have been in the pool for 1 year to a friend, those lockTokens would be “owed” more SherX than lockTokens that were staked yesterday. 8 | 9 | The varying amounts of interest owed to different lockTokens make lockTokens non-fungible (and thus not ERC-20 compatible). In order to fix this, logic has been implemented on lockToken transfers. Basically, all SherX associated with a lockToken is removed on a transfer event. The SherX is not burned, it is moved to the SherX staker pool and the sender address is minted the corresponding amount of lockSherX. This function avoids sending the owed SherX directly to the sender address because this could be a way to “game the system" and get SherX out immediately. 10 | -------------------------------------------------------------------------------- /stakers/unstaking.md: -------------------------------------------------------------------------------- 1 | # Unstaking 2 | 3 | ## Unstake 4 | 5 | Once the cooldown period ends, a 2-day window will open where the staker can unstake their lockTokens (both the original staked token and the staked SherX). They will call the unstake function which will receive their lockTokens and lockSherX and transfer the initial staked tokens (plus interest from Aave, Compound, etc.) and any SherX interest earned (post guarded launch). 6 | 7 | ## Recover 8 | 9 | If a user does not unstake their lockTokens during the 2-day unstake window, the user must now call "recover" in order to get their lockTokens back from the contract (and continue accruing interest). After recover is called, the lockTokens are returned to the user and a new cooldown must be activated in order to try to unstake the funds again. 10 | 11 | ## Cancel 12 | 13 | A user also has the option to cancel a cooldown period that has already begun. This action returns stakeTokens to the user so the user can continue earning interest. 14 | -------------------------------------------------------------------------------- /tokens/locktokens.md: -------------------------------------------------------------------------------- 1 | # lockTokens 2 | 3 | A lockToken is simply the "receipt" for staking a certain token with Sherlock. 4 | 5 | For example, if a staker stakes 100 USDC into Sherlock's staking pools, the staker would receive a certain amount of lockUSDC in return. The lockUSDC represents the staker's proportional stake in the USDC pool. A staker's lockUSDC balance will not necessarily correspond 1:1 with the amount of USDC staked. For example, 20 lockUSDC could correspond to 100 USDC. 6 | 7 | LockUSDC (or any other lockToken) is fungible and ERC-20 compatible. 8 | -------------------------------------------------------------------------------- /tokens/receipt-nfts.md: -------------------------------------------------------------------------------- 1 | # Receipt NFTs 2 | 3 | Each staking position must have a lockup period (6 months, 12 months, etc.) associated with it. Because a staking position can be initiated at any time, each staking position will likely have a unique lockup end date. Due to this phenomenon, staking positions are not fungible. Therefore, staking positions at Sherlock are represented by NFTs. 4 | 5 | For every staking position, an NFT is minted with a unique ID. Once the lockup period ends, the NFT can be redeemed to either unstake or restake the position. On unstake, both SHER rewards and USDC principal/rewards are transferred to the owner of the NFT. On restake, the SHER rewards are transferred to the owner of the NFT and the USDC amount is restaked for the new desired lockup period. 6 | -------------------------------------------------------------------------------- /tokens/sher.md: -------------------------------------------------------------------------------- 1 | # SHER 2 | 3 | SHER token is the governance token for the Sherlock protocol. 4 | 5 | The governance functions of the SHER token will increase over time as the protocol matures. 6 | 7 | In the short-term, the SHER token will be used as incentives for stakers and protocols as well as for compensation to the security team. 8 | 9 | In the long-term, the SHER token is expected to play a role in managing which Watsons are assigned to which protocols, as well as other critical protocol parameters. 10 | -------------------------------------------------------------------------------- /tokens/sherx.md: -------------------------------------------------------------------------------- 1 | # SHERX 2 | 3 | In the guarded launch phase of Sherlock, SHERX does not have a ton of value-add. Because all protocol premiums will be paid in USDC, SHERX does not contribute to the gas efficiency of paying stakers in the same way it would have if many tokens were being paid in as premiums by protocols. 4 | 5 | Therefore, in the guarded launch, SHERX is simply the vehicle which represents the owed underlying USDC interest. At any time, SHERX can be redeemed for the proportional amount of underlying USDC. 6 | 7 | **Important:** SHERX will always be redeemable for its proper underlying collateral so it will always have intrinsic value. All underlying funds are held by the Sherlock protocol to ensure this. 8 | --------------------------------------------------------------------------------