The problem Twyne solves

Protocol view:

Cross-collateral markets share liquidity and risks. The weakest token in the market can wreck all others, so new listings impact current risk trade-offs. That makes the listing process very risky and slow, and conservative parameters are set to minimize insolvency risk
--> Outsource risk-taking to Credit-LPs. There’s no new systemic risk, we comply with Aave’s rules. Aave sees the combined collateral of the borrower and the credit-vault. If the liquidation fails on Twine level (the loan was too risky) then the credit-LP gets liquidated on Aave.

User view:

The collateral factor discounts the collateral, therefore the liquidation happens while debt is way lower than the collateral. Repaying close to liquidation is selling the bottom, and the liquidation incentive is a huge penalty.

—> We extend the amount a user can borrow, so there's more time to repay, and prices could revert.

Asset view:

There's not much yield for high quality assets, as it gets arbed away quickly. Crypto is long BTC, which means there’s very low borrowing demand and that translates to low supply rates on lending markets. (Aave/Compound rates are close to 0)
—> We create a venue for BTC to repurpose it’s lending properties to earn yield by securing other assets.

Challenges we ran into

Contract size limit

When deploying the contracts, we noticed that one of the contract is too large to be deployed (Unknown1 is above the EIP-170 contract size limit (24702 > 24576).` error). To alleviate the issue, we decided to remove the functions that were not currently used. These functions allowed the users to do the gasless transactions - a functionality thats useful but not crucial for the core logic of the protocol.

Testing

We had some troubles testing the contracts initially. The codebase we forked to begin the project used mock contracts to test the integration of the protocol with existing contracts. When we changed some of the functionality, these mocks broke down. Additionally, there were some new contracts that we were integrating with that did not have existing mocks in the repo and it was cumbersome to develop them. To solve this issue, we used anvil to fork the chain locally and run the tests against the existing contracts on that local fork.

Notable bugs

One of the bigger bugs we found during the development was our conversion of the decimals. Our Credit Vault contract accepts a collateral and a debt asset. In the hackathon example, we used USDC and WBTC respectively, which have 6 and 8 decimals respectively. For all of our logic to work correctly, we needed to scale the user asset positions by these decimals.

Arbitrum Deployment

Arbitrum has one of the strongest DeFi ecosystems and we wanted to tap into it. Our project, however, requires the Aave V3 smart contracts to be deployed on a given chain. Unfortunately, Aave V3 is only deployed on the Goerli testnet on Arbitrum, which is getting discontinued and doesn’t have an explorer frontend functioning. Because of that, we needed to make sure that the deployed contracts work purely in a programmatic way, without the explorer frontend. For that purpose, we used a couple of different framework like ape and foundry.