Cork Protocol
Cork is building a protocol to price, hedge and trade risk. In this contest our core contracts will be audited in advance of our mainnet launch.
Details
Scope
On what chains are the smart contracts going to be deployed?
The contracts will be primarily deployed on Ethereum.
If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?
Yes, the Redemption Asset and Pegged Asset will only work after admin initialise pair through config contract (currently token whitelisting is enabled)
Standard ERC-20 tokens with 18 decimals are supported
Rebasing tokens are supported with exchange rate mechanism through Asset contracts
Fee-on-transfer and non-18 decimals tokens are NOT supported now but will support them in future versions subject to additional security review
Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?
Yes, RepurchaseFeeRate, EarlyRedemptionFeeRate, PsmBaseRedemptionFeePrecentage will be between 0 to 5% (0% <= x <= 5%)
Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?
There are currently no limitations.
For permissioned functions, please list all checks and requirements that will be made before calling the function.
For all permissioned functions in corkConfig contract, modifier will ensure that caller must have MANAGER or DEFAULT_ADMIN role
Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?
Our internal Asset.sol contracts should be ERC20 and ERC20Permit strictly compliant
Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?
No - there will likely be external arbitrage bots operating around our system but they are not within scope and act as any market participant
Are there any hardcoded values that you intend to change before (some) deployments?
No
If the codebase is to be deployed on an L2, what should be the behavior of the protocol in case of sequencer issues (if applicable)? Should Sherlock assume that the Sequencer won't misbehave, including going offline?
N/A
Should potential issues, like broken assumptions about function behavior, be reported if they could pose risks in future integrations, even if they might not be an issue in the context of the scope? If yes, can you elaborate on properties/invariants that should hold?
Any potential misbehaviour regarding DS/CT/FlashSwap mechanism that is not an issue right now but could pose risk in future integrations should be counted, but reported as Low issues.
Please discuss any design choices you made.
Design decisions are discussed in the litepaper: https://corkfi.notion.site/Depeg-Swaps-Litepaper-f21a57d5c19d48209dfa0f0c2ab776c4
Please list any known issues and explicitly state the acceptable risks for each known issue.
Admin will be multisig contract and every multisig transaction from admin multisig will be reviewed by trusted team members, so here we can assume that multisig owner contract will not act maliciously
We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?
N/A
Please provide links to previous audits (if any).
N/A - This is the first audit
Please list any relevant protocol resources.
Additional audit information.
N/A
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
15,252 USDC
8,498 USDC
1,800 USDC
2,200 USDC
Status
Scope
Start Time
End Time
Judging Rules
Reserved Auditors