sherlock-audit / 2024-05-elfi-protocol

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Elfi Protocol contest details

Q&A

Q: On what chains are the smart contracts going to be deployed?

Arbitrum & Base


Q: 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?

Only standard ERC20 tokens.


Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED? If these integrations are trusted, should auditors also assume they are always responsive, for example, are oracles trusted to provide non-stale information, or VRF providers to respond within a designated timeframe?

Oracles: We use our own offline oracle mechanism, where the oracle protocol administrator is only responsible for providing the oracle price. Subsequently, we consider using Chainlink for deviation verification on-chain.

Both are TRUSTED.


Q: Are there any protocol roles? Please list them and provide whether they are TRUSTED or RESTRICTED, or provide a more comprehensive description of what a role can and can't do/impact.

We have the following protocol roles. Admin Role (TRUSTED): Used for managing other Roles Deploy Role (RESTRICTED): Only used for smart contract deployment and dynamic upgrades. Config Role (RESTRICTED): Only used to modify some business configuration information, such as adding a new Market. Keeper Role (RESTRICTED): Only used for executing two-phase commits and scheduled tasks.


Q: For permissioned functions, please list all checks and requirements that will be made before calling the function.

  1. All two-phase commit functions (functions starting with 'execute' in Facet) can only be called by the Keeper Role, such as executeOrder().
  2. All first-phase cancellation functions can only be called by the Keeper Role (except for cancelOrder, which users can also use to cancel orders).
  3. The set functions in ConfigFacet can only be called by the Config Role, such as setPoolConfig.
  4. All fund transfers out of the Vault can only be handled by the smart contract Diamond.
  5. All StakeToken can only be minted and burned by the smart contract Diamond, such as users staking ETH to receive StakeToken.
  6. DiamondCutFacet.diamondCut can only be called by Admin.

Q: Is the codebase expected to comply with any EIPs? Can there be/are there any deviations from the specification?

The codebase is optionally compliant (compliancy issues will not be valid Medium/High) with EIP-2535, and we have added an additional layer of process structure on top of EIP-2535 to facilitate the sharing of more


Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, arbitrage bots, etc.)?

Our offline mechanisms include a Keeper bot and Oracle Service. The Keeper bot is used for executing two-phase commits and triggering scheduled tasks. The Oracle Service is used to integrate top CEXs and DEXs to obtain ultra-low latency oracle prices, meeting the low latency requirements for Portfolio Margin

The platform involves collateral liquidation, where third-party users can execute liquidation and obtain reward profits by calling the liquidation contract through self-developed liquidation bot.


Q: Are there any hardcoded values that you intend to change before (some) deployments?

No


Q: 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?

Yes, It should be assumed the Sequencer wont misbehave.


Q: 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?

yes


Q: Please discuss any design choices you made.

The system risk control and liquidation require millisecond-level latency oracles. We have developed our own ultra-low latency offline oracles, which fetch the latest price from the oracle during risk control and liquidation execution.

To improve code reusability, we have added a process layer on top of the Diamond standard model, encapsulating all core business logic into the process. Facets are more used for parameter safety verification, business assembly, and other processing tasks.

Subsequently, we consider using Chainlink for deviation verification on-chain.


Q: Please list any known issues/acceptable risks that should not result in a valid finding.

  1. Regarding the Pool's Mint and Redemption operations, there is no emergency disable function; we are addressing this issue.
  2. The smart contract lacks a Pause feature

Q: We will report issues where the core protocol functionality is inaccessible for at least 7 days. Would you like to override this value?

No, keeping the default value is fine.


Q: Please provide links to previous audits (if any).

This is our first audit


Q: Please list any relevant protocol resources.

Testnet: https://sepolia.elfi.xyz/trade/ETHUSD Docs: https://docs.elfi.xyz/


Q: Additional audit information.

No


Audit scope

elfi-perp-contracts @ 592f4ca0ea256d9474012d9665796bb6e453f107

About


Languages

Language:Solidity 55.7%Language:TypeScript 44.2%Language:JavaScript 0.1%