We need a DeFi subnet

what if the called canisters would also call other canisters in such a scenario? I am wondering what happened with this idea :thinking:

100% agree. this statement still applies :sweat_smile:

I think I am more in the atomic transactions camp. this might be a harsh question, but why would I as a user prefer a DEX on ICP over a CEX if there are more or less the same risks involved? (actually the risk on a DEX might be even much higher)

a similar question comes from the developer side. why go through all the pain and risks involved in developing a reliable DEX in this async world that aims to target the masses? actually I would love to hear (again?) from existing builders what they think about all of this after more than 2 years. (cc @ICPSwap @KongSwap @bitbruce @simpson, @memecake, @timo)

a short summary of (IMO serious) issues that I recognized so far:

  • possibility of canister deletion
    • cycle drainage
    • no default possibility to track cycles balance
    • misuse of freezing threshold (set too low)
  • lack of knowledge about ICRC-1/2/3 standards and index canisters (that’s a matter of improving docs, libs & guides/explainers/…)
    • specifically the importance of ICRC-3 (block-log) for traceability of the history
    • keep in mind: again, all canisters could be deleted and typically need to be monitored and maintained
    • what ICRC-1/2/3 implementations can I as a DEX (or other DeFi related dapp) “trust”? how to verify the code of “custom” implementations? (I am probably better off only supporting the “official” reference implementation of DFINITY)
    • who is the minting account and can I trust it?
  • canister control issues (for ICRC-1/2/3 ledgers and also DEX canisters)
    • what’s the path between single controller & SNS?
    • again the trust issue: can and shall I even “trust” an ICRC-1/2/3 implementation where there is a single controller defined?
    • is blackholing a possibility to “solve” this? what are the possible consequences and risks associated with blackholing? (to a certain extent this depends on the implementation details)
      • is it “safe” to blackhole the my ledger suite (including ICRC-3 archive canisters) if I am certain that I do not want to perform a future upgrade and I assume the community will take care of topping the canisters up with cycles?
  • lack of atomicity (I think this has been discussed enough here already)
    • I think the biggest “issue” here is that it is very hard to compose a function set of many independent canisters (why would I even want to rely on a 3rd party canister where I know its code and state can be changed or removed anytime)

there are other things to consider when it comes to adoption, e.g. simplifying the “bridging” experience for ck assets or providing (better) guidlines and tooling how to integrate und use the signer standards.

I am also wondering what happened to the efforts of Annoucement: HPL - a ledger for 10k tps

same question about the idea of user-paid messages.

I think it is time to pick up this topic again and I would love to hear as many opinions as possible on this matter, especially from those that are actively working on DeFi related applications or integrating with ICRC-1/2/3 tokens on the IC. thanks! :pray:

4 Likes