How to design a DEX Lock that is compatible with ANY Lock on CKB

Mon, April 29, 2024 - 1 min read

NOTE: The contract was already release on CKB mainnet. I’ve also provided a helper playground for it.

It is hard to intergrate other contracts’ logic into your own one in general. Reasons are many:

  • They may have different design/function layout.
  • They may not export the neccessary function to sign/verify.
  • Bundle their code into yours will make your contract grows like Godzilla, makes it difficult to maintan.

Of course it’s a challenge work. You can not simply use dynamic_loading to any lock as you want. Also, mixing algorithms in your contract can also lead to hell code management. And, all these will increase your consumed vm cycles.

Facing these challenges, solutions can be:

1. Forcing to request all lock contract to follow a uniformed design/implementation. A painful route, and can brings breaking-changes to on-chain live cells, especially those using data/data1/data2 as hash_type. And dapps, services will also be affected. We’ve already had those experience before. Upgrading existing lock scripts is an extremly dangrous behaviour, and developers can still reject to follow your design.