Backed Protocol contest - VAD37's results

NonCritical vulnerabilities but could be critical later

CreateLoan() input ERC721 address can interchangeable with ERC20 address

IERC721.TranferFrom have same function signature with ERC20.TransferFrom

This allows anyone create loan to transfer ERC20 token to facilitator address and close loan to withdraw ERC20 token from contract. Reference1. Reference2

As far as external function is called, it revert whole function when IERC721().transferFrom hit require() check. So there is no direct way to withdraw ERC20 or ERC721 token from contract without transfer same amount first.

Sending ERC20 token to contract and borrower token owner can withdraw it later instead of ERC721 NFT is possible with this exploit.

For reentrancy or pass ERC20 as collateralContractAddress, it will not pass first lend() if condition check. There is not much concern with reentrancy in this case.

User susceptible to scam and abuse with fake borrow ticket

Because BorrowTicketNFT can be transfer to someone else, it is possible to create fake borrow ticket and give debt away with worthless collateral. And, NFTs value on OpenSea can be easily manipulated by anyone, which naive user might consider the borrower NFT worth something and pay the debt for it.

Fake Borrower 1: buy low value NFT. Using several accounts to push the highest price on OpenSea by sell and resell to themselves. Fake Borrower 1: create loan with NFT collateral (fake 10 ETH value) with 1 ETH loan. Fake Lender 1: give 1ETH loan to this fake ticket borrower. Wait a few days. (no money was lost here except gas fee) Fake Borrower 1: transfer borrower NFT ticket to somebody like a lender who have history of loaning. Real Lender 2: see a new borrow ticket on their account (it might be worth something as NFT value on OpenSea is 10 ETH and I only have to pay 1 ETH). Click pay debt. => Scammer got 1 ETH + interest from Real Lender 2.

I test on the current demo website, it didn't work because the website not using the data from blockchain directly but through known Event database. (CreateLoan with receiver address as mintBorrowTicketTo work fine. Scammer can still create fake borrow ticket and send it to other user) I would recommend against using self-made database unless from some trusted 3rd party provider for event data. Since normal database can still be manipulated directly.

ERC721 descriptor symbol open up HTML injection attack

The chance of this happen is very low. But, it is possible. The Descriptor contract return the entire NFT symbol string to pre-formatted HTML.

If frontend developer use string concat to show text, it is possible to inject script like popup window or button depend on website integration. I would recommend to use max character length limit on frontend or on contract directly.

Non related to audit

I check UniswapV3 position NFT. The reward will be stuck during loan time with no way to change it. So lender can profit a lot from seizing NFT if borrower fail to pay back.