Zivoe is a real-world asset credit protocol aiming to disrupt predatory high-interest consumer lending. Leveraging a B2B2C model, Zivoe offers on-chain loans to regulated consumer lending entities, who then use that capital to fund consumer credit products off-chain. These entities then utilize the yield from such products to fulfill their on-chain obligations to Zivoe.
Scope
Contest Results
On what chains are the smart contracts going to be deployed?
Ethereum mainnet
Which ERC20 tokens do you expect will interact with the smart contracts?
USDC, DAI, USDT, FRAX, and in some yield lockers CRV, CVX
Which ERC721 tokens do you expect will interact with the smart contracts?
None
Do you plan to support ERC1155?
No
Which ERC777 tokens do you expect will interact with the smart contracts?
None
Are there any FEE-ON-TRANSFER tokens interacting with the smart contracts?
No
Are there any REBASING tokens interacting with the smart contracts?
No
Are the admins of the protocols your contracts integrate with (if any) TRUSTED or RESTRICTED?
RESTRICTED
Is the admin/owner of the protocol/contracts TRUSTED or RESTRICTED?
TRUSTED
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
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
Please list any known issues/acceptable risks that should not result in a valid finding.
None
Please provide links to previous audits (if any).
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
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
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
Add links to relevant protocol resources
Total Rewards
Contest Pool
Lead Senior Watson
Judging Pool
Lead Judge
47,500 USDC
24,500 USDC
2,700 USDC
3,300 USDC
Status
Scope
Start Time
End Time
Judging Rules
Reserved Auditors