Skip to content
This repository has been archived by the owner on Apr 8, 2024. It is now read-only.

Latest commit

 

History

History
206 lines (168 loc) · 13.8 KB

README.md

File metadata and controls

206 lines (168 loc) · 13.8 KB
Raw

Zivoe contest details

Q&A

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

Ethereum mainnet

Q: Which ERC20 tokens do you expect will interact with the smart contracts?

USDC, DAI, USDT, FRAX, and in some yield lockers CRV, CVX

Q: Which ERC721 tokens do you expect will interact with the smart contracts?

None

Q: Do you plan to support ERC1155?

No

Q: Which ERC777 tokens do you expect will interact with the smart contracts?

None

Q: Are there any FEE-ON-TRANSFER tokens interacting with the smart contracts?

No

Q: Are there any REBASING tokens interacting with the smart contracts?

No

Q: Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?

RESTRICTED

Q: Is the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?

TRUSTED

Q: Are there any additional protocol roles? If yes, please explain in detail:

There are multiple roles in the protocol, the permissions of these roles are outlined (in terms of accessibility to smart contract endpoints/functions) for each contract here: https://docs.zivoe.com/developer-docs/core-contracts

See the Figma here https://www.figma.com/file/qjuQ0uGQl9QD7KeBwyf73d/Zivoe-Visualization?type=whiteboard&node-id=0-1&t=ZF3HuGmByCAkU6NT-0 for additional context on which endpoints these Roles can access

In general: ZVL (referenced in ZivoeGlobals) will have access to protocol settings OCC (referenced in OCC_) will have access to underwriting endpoints in that particular OCC locker ZVE (governance) will be able to initiate proposals, vote on proposals Pausable (multi-sig) will also have ability to "pause" proposals deemed hostile

2 Please see Figma for access to endpoints

3 Per the NatSpec

4 Only access to the provided endpoints should be allowed

Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?

Not necessarily, other than generic ERC20 integrations from OpenZeppelin library

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

None

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

https://github.com/runtimeverification/publications/blob/main/reports/smart-contracts/Zivoe_Core_Contracts.pdf https://github.com/runtimeverification/publications/blob/main/reports/smart-contracts/Zivoe_Locker_Contracts.pdf

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

Keepers will handle conversions in the OCT_ lockers (via 1INCHv5 APIs and submitting tx's to smart contracts) For minting tranche tokens (or participating in ITO, minting tokens there) we have front-end mechanisms to validate input

Q: In case of external protocol integrations, are the risks of external contracts pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

Not acceptable

Q: Do you expect to use any of the following tokens with non-standard behaviour with the smart contracts?

Yes, I believe it's USDT that has issues with 0 approval, we have integrated SafeERC20 to handle these situations USDC also has 6 decimals however we've integrated adjustment/conversion helper functions

Q: Add links to relevant protocol resources

https://docs.zivoe.com/developer-docs/core-contracts https://docs.zivoe.com/developer-docs/lockers

Audit scope

zivoe-core-foundry @ ad27cffdf96eaaa33274bfba0dda9b60e36d29a2

zivoe-core-testing @ 478e13327af672e7b5dfffda38b69acfed37b346

zivoe-core-foundry @ ad27cffdf96eaaa33274bfba0dda9b60e36d29a2