Aiken Implementation

[ken-underscore]

Hello! I'm a big fan beacon tokens and the work you both do. I was looking to get a better feel for beacon tokens and also to get some experience with Aiken so I decided to rewrite cardano-loans in Aiken. I learned a lot by reading through and re-implementing this project, not just about Aiken but about smart contracts on Cardano in general. The comments and error messages were extremely helpful for my understanding as I was going through.

I believe you're already re-implementing this yourself and are perhaps even already finished and working on the unimplemented features, but I thought I'd share my repo in case it's useful at all, it's currently private as I still have some things I'd like to finish up. I'll just say again I think your work is really cool, if you ever find yourself in need of an extra pair of hands, keep me in mind!

[zhekson1]

Thank you for this! It's very encouraging for us to see community members' interest and contribution to what we're doing!

Although Aiken is still in alpha, it shows great promise in creating more headroom for additional features, such as compounding interest, min payments, e.t.c. These protocols are still in R&D phase, so there'll be plenty of experimenting/prototyping going forward, which may lead to significant design changes. Your repo may help speed this up!

Anyway, we really appreciate this and will definitely keep an eye out!

[fallen-icarus]

@ken-underscore Apologies for the delayed response. As zhekson1 says, this is still very much R&D right now so the focus is on brainstorming features and possible implementations. The way the protocols currently work is more a fact of "that is just how I thought to do it" than "that is the optimal way to do it". If you have any ideas on how to implement something better, please don't hesitate to mention it. I will definitely look at your code to see how you did things.

You are correct that the aiken version is already in the works. I am currently in the middle of testing it. It won't be finished but I can publish the current code in a separate branch this week for you to take a look if you are curious. The new version has the following features:

• Compound interest through rollover checkpoints (no minimum payments yet).
• Tradable Key NFT that is unique for every loan.
• Able to disallow a collateral asset by setting the collateralization to zero for that asset (in the offer datum).
• Able to pay the lender directly rather than having to accumulate the repayment in the collateral utxo. This address can be updated by the owner of the Key NFT.
• Allow accepting multiple loans in a single transaction.
• Allow mixing partial and full loan payments in a single transaction.
• Allow swapping out collateral for a loan as long as the lender's collateralization and required collateral value is respected.

If you have any suggestions of features to include (or not include), that would be helpful. Currently, zhekcson1 and I are the only ones really brainstorming features.

If you have the time and are curious, I think it would be worthwhile to also try implementing cardano-options since some of the major features from that are going to make their way into the other protocols (lock/key NFTs, paying the owner directly, and off-loading some work to the beacon minting policy during certain tasks).

[ken-underscore]

@fallen-icarus I appreciate your response! I wish I'd seen it before I disconnected for a bit, sorry for the delay. I'm getting back into the swing of things this week and would love to take a peek at your implementation of cardano-loans (and all the new features) if you're still open to it, I also plan to check out cardano-options!

As for suggestions, it occurred to me that the execution cost of AcceptOffer could probably be reduced by moving validation logic into the minting policy, specifically when minting the Active datum, this would reduce the cost of the redundant execution for the Ask and Offer utxo's. However, it seems that you've already thought of this and done it for cardano-options? I only took a quick look since you mentioned "off-loading some work to the beacon minting policy" which sounded like saving costs on redundant script executions.

Feature wise, one thing that came to mind was the concept of a flash loan, although honestly I didn't really see a use case for it so I'm unsure of the utility. It seems like this could be a special case of an Offer that is not associated with any Ask and has a term of 0 and no collateralization, in such a case AcceptOffer would expect that the principle+interest is paid to the contract. However the lender would probably prefer that after use the principle is immediately available to be borrowed again, so perhaps a separate AcceptFlash redeemer that requires the principle and Offer datum be paid back to the contract while the interest is paid to the lender would make more sense. This would be quite different than the lifecycle of a normal loan though, so without a relevant use case probably doesn't make much sense.

So I guess in the end I don't have any major suggestions at the moment, I'll be thinking about this when I look through cardano-options though, should help having some beacon token experience under my belt this time around.

[fallen-icarus]

The aiken branch for cardano-loans is now up. The README and GettingStarted are not updated yet but the code is finished (and commented). I hope you find it as accessible as the previous version!

You are correct that the acceptance logic was moved into the minting policy since the Active beacon needed to be minted anyway. The logic is quite complicated since it is using a third person perspective for validation. It is probably the step with the largest attack surface so I tried to be as thorough as possible with testing. Despite that the benefits are obvious: users can now accept up to 6 loans in a single transaction. You can see the benchmarks here. The logic for this step in cardano-options is a basic version of what is implemented in this version of cardano-loans. In options, I was simply trying to see if it would work so I deliberately kept it simple by limiting the protocol to one acceptance per transaction.

I am skeptical of the idea of flash loans. Just like you, I don't really see a use case outside of speculating on trades. Furthermore, it seems to dramatically increase the attach surface of the protocols that have them. When looking into them, traditional finance doesn't seem to have them which means they are historically untested. Personally, I'd rather not add them unless there is a very clear reason that a healthy economy needs them. Besides, given the composability of these protocols, a dedicated protocol can be created for flash loans without increasing the attack surface of the other protocols. Perhaps @zhekson1 has a different opinion?

Let us know when you finish cardano-options! I am interested to see how you do it and any ideas you come up with.

[zhekson1]

Agreed - flash loans are a bit niche and I don't think they should be prioritized (if at all implemented). Perhaps we can revisit the idea sometime in the future