Platform: Code4rena
Start Date: 29/03/2022
End Date: 31/03/2022
Period: 3 days
Status: Completed
Pot Size: $30,000 USDC
Participants: 24
Reporter: liveactionllama
Judge: HardlyDifficult
Id: 101
League: ETH
Auditor per page
Sublime is a decentralized protocol for building and accessing credit. Borrowers can use Sublime to create fully-customizable loan pools or credit lines, allowing them to utilize their social capital to borrow undercollateralized loans from lenders that trust them. The protocol has been developed with the idea of trust minimization - a lender’s capital is only utilized by borrowers they trust. Integration with overcollateralized money markets like Compound enables lenders to generate passive yield on their assets for times when users they trust aren’t actively borrowing. Sublime also features a flexible identity verification module which allows users to link their identities to their wallet addresses to bootstrap their on-chain reputation.
For more information and technical specs, please refer to the documentation.
To learn more, please join the Sublime Discord server.
Please note that the contest duration is 3 days.
The scope includes the following files, which are a part of 0.0.7 release:
The main focus of this audit are the first two contracts, which is a new type of loan product we're introducing called Pooled Credit Lines. Pooled Credit Lines allow the creation of generalized loan offerings. It allows a borrower to raise a line of credit from multiple lenders. Capital from lenders is pooled together, and any unused capital is supplied onto a passive yield strategy such as Compound chosen during the creation of the loan. Participation of lenders in the loan can be restricted by the borrower by choosing a verifier that matches their requirements.
The third contract is a verifier used to verify user's Twitter IDs. Verification involves a combination of on-chain and off-chain steps. All verifiers involve the following general flow:
Additional details (overview as well as technical spec) can be found in our documentation.
Following is a list of few key design choices implemented in the architecture. Please keep in mind that issues that closely resemble the below assumptions might be considered invalid.
1. The admin is a trusted actor
For the initial stages of the protocol development, the admin is going to be handled by us. Thus, contracts, functions, and critical thresholds are set to be upgradeable by the admin to allow effective action in case of emergencies. Over time, such functions would be decentralized.
2. Verifiers are trusted actors
Verifiers are picked after necessary due diligence is completed. Verifiers handle the mappings of identities to wallet addresses. Thus, users interacting with the Sublime protocol trust the verifiers that they personally utilize to find other members.
3. Since the loans can be undercollateralized, economic loss during liquidations are possible
Loans that are undercollateralized possess an inherent economic risk - in case of a liquidation event, the lender might not be able to fully recover the funds they deposited.
Collateral thresholds are meant to serve as trigger points after which liquidation actions can be taken - they do not guarantee recovery equal to the pool/credit line’s collateral ratio at the time of creation. This could be due to inaction, front-running, high volatility in asset prices. Thus, collateral ratios serve as benchmarks for lenders to approximately assess the amount of risk they’re taking.
4. Functions that place requests are susceptible to spamming
By design, it is possible for anyone to create loan requests, send receive address verification or master address linking requests. Thus, while it is possible to spam other users, we expect transaction fees to keep such activities limited. Furthermore, optimizations on the UI will be implemented to handle this.
5. Oracle prices from Chainlink and Uniswap are considered accurate
We rely primarily on Chainlink price feeds, but for assets for which price feeds don’t exist, we use Uniswap V3 as a fallback. We are assuming these feeds to be reliable. Assets will be carefully whitelisted to ensure price manipulations are unlikely.
6. The system configuration of all the contracts including all the global variables and system parameters are assumed the be deployed without anyone able to frontrun
Cases of frontrunning initializations can be handled by redeploying the contracts.
7. In cases where a verification by a verifier is revoked in the middle of an active loan, the loan can be terminated prematurely by the admin
8. The PooledCreditLine.sol contract exceeds the contract code size under the current release. This issue has been fixed, although the fix is not ready for this release